POST
|
Faced the same problem today. Solved it by: - Added any editable hosted feature layer with edition capabilities (in my case from an old Survey123) in the webmap - Saved the webmap --> The "Use in Collector" checkbox appeared in the webmap settings and I could edit in the Fieldmap App - Delete the newly added useless layer and saved the map again. In my case, I suspect that the fact that I published layers only from ArcGIS Pro without Editing capabilities caused some weird problem after, even if I activated the edition later in AGOL. There are some troobleshooting indication on that page: Problem: The Use in ArcGIS Collector Option is Unavailable in a Web Map’s Settings (esri.com) Cheers, Léo
... View more
03-13-2024
06:56 AM
|
0
|
1
|
148
|
POST
|
Hi! Thank you for your response, that I haven't seen before. I have just noticed that the bug for Portuguese settings has been fixed in the new release (3.10) but unfortunately it still doesn' work with French. We will contact the support and hope that we can solve the problem for the next release. This is rather problematic as we can not test properly our surveys when they include calculations with decimals. Cheers, Léo
... View more
08-11-2020
12:30 AM
|
0
|
0
|
974
|
POST
|
Hi George, Indeed, it seems that since 3.5, the validation occurs only when the form is submitted. I made a new thread some time ago about that issue: https://community.esri.com/thread/244051-constraintvalidation-occurs-only-when-the-survey-is-submitted And Gee made an ArcGIS idea to change that behavior: https://community.esri.com/ideas/17630-constraint-messages-to-show-up-on-the-fly Please consider voting for it ! Léo
... View more
04-20-2020
05:50 AM
|
1
|
1
|
724
|
POST
|
ArcGIS Idea to that: https://community.esri.com/ideas/17630
... View more
03-15-2020
03:50 PM
|
3
|
0
|
4019
|
POST
|
Hi, Someone recently added an ArcGIS Idea for that: https://community.esri.com/ideas/17630 Please consider voting it up if you'd like to have the constraint validation immediately, and not only when you submit the form. Léo
... View more
03-15-2020
03:48 PM
|
2
|
0
|
1925
|
POST
|
Hi, Old thread, but someone recently created an Idea for this issue: https://community.esri.com/ideas/17630 Give it a vote up! Léo
... View more
03-15-2020
03:43 PM
|
0
|
0
|
970
|
IDEA
|
Hi Gee, Great idea. We posted a question directly related to that here some time ago: https://community.esri.com/thread/244051-constraintvalidation-occurs-only-when-the-survey-is-submitted This is something new, it appeared version 3.5 and it does not make sense to me, totally. Constraints become almost useless if they come only when submitting, especially if the form is long. Worst, it could impact the rest of the form if calculations are based on a value which does not meet the constraint and the field user is not aware that he made a mistake. It seems to me that constraint is a fondamental, basic option for a survey, so this change is critical to us. Why not keeping it simple and intuitive as before? Hope we'll have some feebacks on this issue. Léo
... View more
03-15-2020
03:34 PM
|
2
|
1
|
4127
|
POST
|
Hi, The option "Set as favorite answers" is quite different than the new option that Ben is talking about available in Collector: - It saves all the answers of one survey and copy all of them in the target survey - Only one set of answers can be saved We would really appreciate to have the equivalent of Collector "Reuse entry field" in Survey, as the use of the "set as favorite answers" is very limited and not much appreciated by our field staff. It is only relevant for informations that are common for all the surveys (weather of the day, date, name of user…) but not for more specific questions. We think the "Reuse entry field" as an extent of lists, or as an history function: each project may have its own objects to inspect but those objects are not necessarily known before going on the field, so it is not possible to prepare a choice list. As an exemple, during asbestos inspections, each building may have their own objects that should be assessed, and those objects can be encountered several time (pipes, glue on floor tile, specific painting...). Currently, it is not possible to group them by type while processing the data as the user need to rewrite every time the name of the object (time consuming), leading to many typos. We have many other projects where this will be relevant: when we want our observations to refer to another one made before, recurrent measured values… This would be a really functional enhancement for field users. We were excited to see that this was implemented in Collector, hope this will be implemented soon for Survey123 (maybe we should create an ArcGIS Idea for that?). Léo -
... View more
03-11-2020
09:50 AM
|
3
|
2
|
1838
|
POST
|
Hi, We have an issue with latest release of Survey connect (3.7) and fields with calculations and decimals. We are working on Windows 10 computers, with French as system language, but with dot as a decimal symbol instead of comma by default: The example below shows a very simple calculation where the second field (type = note) just takes the first field (type = decimal) value. The expected behavior is the following: But with our system configuration, this is what we get: No calculation done = whoops. If we change back to the default settings (with comma instead of dot), the input in the first field needs to be with a comma, but the calculation works and gives a value with a dot. Fun fact: when using pull-data from a csv file with dots, the input is not valid as it expects a comma but the calculation works anyway… The thing is that we don’t want to change this setting only for Survey123 connect, as it is necessary for other software. After publishing, there is no issues with the calculation in Survey App (although there is one with our Samsung tablets and default keyboard, as mentioned here). Is that a bug or is there a way to solve this without changing the system settings? It was working well with previous versions of connect. Léo
... View more
03-07-2020
08:58 AM
|
0
|
2
|
1052
|
POST
|
Thanks James, the idea is here. As stated there, I do thing that "preventing" unwanted behavior by "restricting" customisation is not worth it in that case. The user should know on which scale he is working on, and if the shape goes out of the map, I don't think it should be a big deal to readjust it. In the meantime, I am thinking of a workaround by combining geoshape (in a repeat) and geopoint for the main feature class. The geopoint would be read only and automatically calculated from the geoshape centroid cooordinates. Is there a way to pull the centroid coordinates of a geoshape?
... View more
12-21-2019
01:51 PM
|
0
|
4
|
1963
|
IDEA
|
The idea is to have the same possibilty as for geopoint to add a custom scale when printing the map in the report. Current situation: The scale is automatically based on the extent of the feature. This is to make sure that the entire feature is displayed in the map. It is impossible to set a custom scale as for geopoints. Issue: For any extent smaller than few km², which happens most of the time I assume, the scale will be too large to give any information about the location and the surroundings. As a result the map becomes rather unuseful (apart from giving a shape of the feature). Example: The image below shows an example of geoshape export. From this image, our client cannot have any clue of where this feature is located within the 3'000 km² of the area of study: we lose the spatial information and the science of where. Suggestions: - Let the user set the scale as an optionnal parameter, but somehow add a warning that the entire feature might not be comprised in the map if the scale is to large. It is therefore to the user to take the responsability to set a custom scale or let it by default. - Calculate automatically the scale in the report as max("feature extent scale", user-defined scale) - Add an option to map the centroid of the shape instead of the shape itself (not necessarily the best option, neither the easiest to implement I guess) Link to the initial thread. Even though it was probably thought to avoid any unfortunate behavior, I do believe that "preventing" by "restricting" is not the good way here. Let the user the choice to take the risk ! Not much to lose in this case...
... View more
12-21-2019
01:17 PM
|
6
|
1
|
818
|
POST
|
Hi James, and thank you for your answer. I was indeed thinking that it might be the intended behavior in order to keep the entire feature in the map. If it stays like this in the future, I think it could be useful to make it explicit in the documentation, as I spent some time (and credits looking forward for preview reports) trying to figure out the issue. Here are some more details about what we are expecting, and why it is problematic in our case: Context: We have a hundred of different sites to control over an area of 3'200 km². Each site has its own report for our client. We have two maps in the report, one on a small scale (1:50'000) giving information abour the location and one on a larger scale (1:5'000) showing the geometry. The issue in our case is more problematic with the small scale. Expected behavior: The small scale map in the report is supposed to give in one glance an indication of where is the site located in this area so that our client knows instantaneously which site the report is about. Issue: Without the larger scale, it is impossible to visually identify the site (as illustrated in the second picture), in other words, we lose the information about the location (which I think is rather paradoxical for a map-centered survey). Suggestions: - Let the user to set the scale, but somehow add a warning that the entire feature might not be comprised in the map if the scale is to large. The user takes then the responsability to set a fixed scale or let it by default. - Calculate automatically the scale in the report as max("feature extent scale", user-defined scale) - Add an option to map the centroid of the shape instead of the shape itself (not necessarily the best option, but it would be fine in our case) Hope I made it clear, and I am truly willing to help if you have some more questions. This is an important issue, which might prevent us from using geoshape and going back to geopoint. This would be a real shame as it was a long time hoped-for option and the result is great in my opinion apart from that. Léo
... View more
12-20-2019
02:14 PM
|
1
|
6
|
1963
|
POST
|
Hi, I have a template for feature report in which are included two maps: one with the 50'000 scale giving an overview and one 5'000 scale. This is working fine with geopoint question. It doesn't work with geoshape question, the scale is set to the feature extent. Geopoint result: Geoshape result: ${localisation |mapSettings:" 70a459d5e15f410d88eb66ae06d4cc6b":50000|size:200:220} ${localisation |mapSettings:" ce9ce9c68772456c8af1e7f33ee7bc70":5000|size:200:220} Thanks for your help, Léo
... View more
12-20-2019
02:23 AM
|
0
|
9
|
2156
|
POST
|
Hi Nicole, I had similar issues as you are describing. After a long period of tests and research, it seems that I found one explanation to this behavior although I cannot explain why. It might be a bug from survey123. When your Survey contains a geopoint question, if you open it in a browser (Firefox or chrome does'nt matter) the Browser will open a popup and ask something like "Do you allow survey123.arcgis.com to acces to your location?". The question varies according to the browser, and the behavior also varies. If you ignore the question or just close the popup, the Survey is very likely to not be able to submit at the end. If you choose to answer "I don't allow", sometimes it doesn't work and sometimes it works. If you choose to answer "I allow", it usually works. In some browsers, the question is asked a second time when you submit the Survey. There again you have to pay attention to your answer. I don't know if this helps you, let me know! Léo
... View more
01-18-2018
08:17 PM
|
1
|
2
|
926
|
POST
|
Hi John Thank you for your answer. Do you know in which time frame the issue might be solved? As this function is central in our public survey that will start within a month, we would like to know if we have to think of an alternative solution or if there is a chance that it will be addressed quickly. It seems to me that fixing this bug is crucial for the good usage of the web application and the new possibilities it offers with geoforms. Thank you for keeping us informed Leo
... View more
10-09-2017
12:56 AM
|
0
|
0
|
1145
|
Title | Kudos | Posted |
---|---|---|
2 | 03-15-2020 03:48 PM | |
1 | 04-20-2020 05:50 AM | |
3 | 03-15-2020 03:50 PM | |
2 | 03-15-2020 03:34 PM | |
3 | 03-11-2020 09:50 AM |
Online Status |
Offline
|
Date Last Visited |
03-13-2024
02:58 PM
|