Latest Contributions by AaronKoelker

‎05-14-2019

Adding my experience to this discussion since it is close, though I see it on all my surveys instead of just one. Using a Samsung Galaxy S9+ and Survey123 for Android has become unusable for me since the 3.3 update. Upon opening any survey, the app crashes somewhere between immediately and maybe 30 seconds or so. I can open a survey and not make any inputs on the screen, and the app will still close out at random. Disabled the app's permissions for location services and still see that same behavior, so not sure what's running in the background and tripping the crash. I get this behavior on all surveys, ranging from complex surveys with pulldata and external CSVs, to a simple test survey with a single yes/no question. Have reinstalled the app multiple times, and cleared installation folder manually through the file explorer. I also attempted to test the 3.4 EAC beta, but see the same behavior. If anything, the crash occurs quicker. Haven't been able to get a hold of another android device in my office to test, but my coworkers iPhone devices are able to run the same surveys without issue. Works ok in the browser, too. So it seems to be android or device specific. Wondering if anyone else is seeing issues on Galaxy devices after 3.3? Part of my position is to help support all our GIS users with their mobile solutions, including Survey123, so not being able to test or use any of our surveys has me in a bit of a pickle. EDIT: Looks like the addition of a 64-bit version in 3.5 has solved my issue regarding the Samsung Galaxy S9+, which is a 64-bit device. The app is much more stable and usable!

‎05-07-2019

Ah! Thanks James. That's exactly what I'm looking for. I had done it in the pop-up configuration. Don't know how I've missed that "define fields" option after all this time. Appreciate it! -Aaron

‎04-29-2019

I know that through hosted feature views I can protect my public survey submissions from being edited or deleted, and I can control what fields are visible for a public-facing AGO web map, but is there anyway to completely hide a field from a hosted feature layer view? I've found that while I can disable them in the view's Visualization tab, you can simply open the REST service URL of the public view, click the the "View In: ArcGIS.com Map" button, and see all the fields via the pop-up on submissions that were created by anonymous users. I'm in a scenario where we're collecting submissions on storm debris from the public, and need them to provide contact info in case we need more detail from them, but I don't necessarily want that contact information to readable by the public as well, only my org users. There's the option to control what anonymous editors can see, but I need an option to control what anonymous viewers can see.

‎04-29-2019

If they just want to use your survey as a starting point to design another survey for their own needs, you can send them the XLS file from Survey123 Connect.

‎04-17-2019

Hey Robbie, did you ever find a fix or workaround to this? Other than removing the attribute expressions? I'm running into the same issue.

‎04-15-2019

Thanks for the info Zhifang! The workaround functions like you said and will work out just fine for us. Much appreciated! -Aaron

‎04-11-2019

I created another discussion for this same issue after not finding anything in the GeoNet search, and then came across this one in related content afterward... I'm seeing the same inconsistencies in my reverse geocode as you. Works fine in the field app, but the same survey in the web form only returns intersections (sometimes the intersections don't even make sense if the point is away from one.) Trying to get a survey reconfigured for hurricane season and am eager to get this solved before then. Inconsistency in reverse geocoding results across field app and browser EDIT: There's now a workaround in the linked topic above.

‎04-10-2019

I've never been able to get this to function correctly, even though it is supposed to be possible. Not using Portal though, but ArcGIS Online with enterprise logins. Would be curious to know if this was ever resolved. As a workaround I've resorted to using non-enterprise logins for my scripts.

‎04-10-2019

I think that might be a customized Story Map (tabbed/Story Map Series) based on the look, and then each tab is linked to a different Web App Builder application. You can achieve the same thing using the basic Story Map Series template, though. Just have each tab link to a web page and insert the URL to your individual Web App Builder apps. EDIT: Here's an example of a Story Map Series that links to separate Story Map Journals on each tab.

‎04-10-2019

When sharing or overwriting a web layer/hosted feature service from ArcGIS Pro to ArcGIS Online, you are given a few options for the editing settings of the feature service -- however they don't match the available settings you can find on the item details page for that service once it is up in ArcGIS Online. It would be convenient to have additional checkboxes and toggles in the dialogue window of the share/overwrite tool to match these (particularly the Editor Tracking settings!). I managed to do it through a script when overwriting a web layer from a Pro project using the ArcGIS Online API for Python, so it seems like the functionality is there. It would also help if the existing settings in Pro had their phrasing updated to match the settings in ArcGIS Online, to be as clear as possible for users. Also, (and maybe this should be it's own idea?) when sharing/overwriting a web layer from ArcGIS Pro, you have the option to designate the time zone of the data before sending it up as a service/overwriting. It would be amazing to have that setting available on the item details page in ArcGIS Online as well, so that existing hosted feature layers in AGO uploaded from a source other than Pro can have their time zone defined. Also also (getting nitpicky, but) it would be super helpful for some of our users to have the phrasing for the editor tracking settings on the ArcGIS Online item updated. Even just adding a "when" somewhere in the second setting would help users know that it's for tracking creation dates and edit dates, as opposed to keeping track of the user for the third setting. We get a lot of feedback with confusion over the two "Keep track of" options available. -Aaron

‎04-10-2019

When sharing or overwriting a web layer/hosted feature service from ArcGIS Pro to ArcGIS Online, you are given a few options for the editing settings of the feature service -- however they don't match the available settings you can find on the item details page for that service once it is up in ArcGIS Online. It would be convenient to have additional checkboxes and toggles in the dialogue window of the share/overwrite tool to match these (particularly the Editor Tracking settings!). I managed to do it through a script when overwriting a web layer from a Pro project using the ArcGIS Online API for Python, so it seems like the functionality is there. It would also help if the existing settings in Pro had their phrasing updated to match the settings in ArcGIS Online, to be as clear as possible for users. Also, (and maybe this should be it's own idea?) when sharing/overwriting a web layer from ArcGIS Pro, you have the option to designate the time zone of the data before sending it up as a service/overwriting. It would be amazing to have that setting available on the item details page in ArcGIS Online as well, so that existing hosted feature layers in AGO uploaded from a source other than Pro can have their time zone defined. Also also (getting nitpicky, but) it would be super helpful for some of our users to have the phrasing for the editor tracking settings on the ArcGIS Online item updated. Even just adding a "when" somewhere in the second setting would help users know that it's for tracking creation dates and edit dates, as opposed to keeping track of the user for the third setting. We get a lot of feedback with confusion over the two "Keep track of" options available. -Aaron

‎04-10-2019

While designing a survey that takes advantage of reverse geocoding a user created geopoint to populate an address field, I'm seeing a difference in the information pulled from the default ESRI World Geocoding service depending on if I fill out the form via the field app or the browser app. See screenshots below. Both points are in the same location, and while the field app returns an address number and a street, the browser form always returns an intersection of two streets, and never an address number. Often if the geopoint is not near an intersection, the two streets returned won't even make sense. It might grab a second street hundreds of meters away or a block over, and which never intersects the first street. Or two distant streets entirely. I don't see this level of inaccuracy in the field app. It's also not a matter of the two points having slightly different lat/lon. I'm able to reproduce this consistently, where the field app can semi-reliably return an address number and street and the browser form only gives two street names. Is this a bug, or am I doing something wrong? For this test field I'm just using < pulldata("@geopoint",${locationfield}, "reversegeocode") > and the default ESRI World Geocoder. Appreciate any help. I get the same results on the Android field app that I do on the Windows field app above. -Aaron

‎04-08-2019

In case anyone stumbles across this later... still haven't figured out how to designate existing editor tracking fields when uploading/overwriting a hosted feature layer. However we did manage to overwrite a hosted feature layer that had editable views (with editor tracking) by disabling via an definition update in a specific order, since editing, tracking who and tracking when, and sync capabilities have certain two-way dependencies on one another. So first turn off editing (box 1 below), change-tracking (box 2 on editing settings, last-edited-on), and sync (box 4) for the views all at once -- then turn off change-tracking (2), editor-tracking (box 3 in editing settings, last-edited-by),and sync (4) for the source hosted feature layer. Then disable editing (box 1) for the source hosted feature layer. You don't have to disable box 3/last-edited-by on the views after this. Then after you finish overwriting your hosted feature layer, you go in reverse, but turn on everything for the source hosted feature layer at once (1,2,3,4), and then turn on editing (1), change-tracking (box 2/lasted-edited-by) and sync (4) for the views. Box 3/editortracking/last-edited-by on the views will take care of itself. box 1 controlled by "Editing" under capabilities in service definition. box 2 controlled by "ChangeTracking" under capabilities in service definition. box 3 controlled by "enableEditorTracking: True/False" within "editorTrackingInfo" in service definition. box 4 controlled by "Sync" under capabilities in service definition. Hope this helps someone on the seas of Google.

‎04-05-2019

The work around I ended up doing for my project was to have two layers, a "working" layer and a "reference" layer. The working layer was symbolized by subtype and went to Collector, which lets users have the shortlist of options for creating new features. Then I wrote a python script to append data nightly from the "working" layer into the "reference" layer -- which is symbolized by the subtype domains (but doesn't actually have subtypes enabled, the values are just getting copied from the working layer domains into a field for symbolization).

‎04-05-2019

Great, thanks for the update

Online Status	Offline
Date Last Visited	4 weeks ago

My Ideas

Latest Contributions by AaronKoelker

Re: Survey123 Android App - Intermittent Crashing opening one survey

Re: Getting Started with Public Surveys

Re: Getting Started with Public Surveys

Re: Getting Started with Public Surveys

Re: Info Summary Widget fails to list features from AGS

Re: Inconsistency in reverse geocoding results across field app and browser

Re: ReverseGeocode results showing in Connect, but not in Web Browser

Re: Using Active Directory and Portal Tier Authentication

Re: Web tabs in web mapping application

Add missing web layer editing settings to dialogue when sharing/overwriting web layer from ArcGIS Pro

Add missing web layer editing settings to dialogue when sharing/overwriting web layer from ArcGIS Pro

Inconsistency in reverse geocoding results across field app and browser

Re: How to designate Editor Tracking Fields when overwriting a service using ArcGIS Online Python API

Re: Collect features by subtype, symbolize by domain

Re: Problems with Attribute Table Widget in Dashboard Theme

Improve 360 Photo UI in Indoors Viewer app

Multi-level Allocations in Space Planner

Re: Floor Filter doesn't honor the hosted views cr...

Dynamically filter data in a List widget based on ...

Re: Spatial join/intersect with overlapping polygo...