Hello all. I've got a Coded Value list of street names in and AGOL feature service. The list has grown to over 1200 and as a matter of convenience, I'm tired of having to scroll to drop the new value in its appropriate location. Anyone have a fix to sort the list of of values with a couple of clicks?
Hi @JasonBritton1 , in AGOL, you can open the attribute table from the content page in the map, go to the field header and when clicking it, choose either sort ascending or descending. This will sort the field and tables accordingly. However it sounds like your problem is more specific than just this sorting feature. I've done similar work and the short answer is usually no, I've gone through datasets with over 100,000 features on the same work flow and sorting in this manner has been a great boon to have but you still have to scroll unless you select by attributes or by location. One other option is using excel spreadsheets and feature updates or overwrite workflows to help with large datasets; however this is very technical and can put more constraints on the data than it sounds like what you need or want. Hopefully this will help, could you describe your workflow and maybe there is something more specific that can be identified?
Ok, that makes sense. Thanks for the details then. I haven't encountered this personally but am aware of the workflow. Now I understand why >1200 is so much for this scenario, I've gone to 100 but nothing of that scale. Even in Survey123 there are no ways to alphabetize these lists that I am aware of. There may be a way to code it so it shows alphabetically, but I digress from my knowledge and would defer to the other ESRI contributors.
One solution I can think of it having a preset feature service where your field and dropdown automatically draws from the list rather than manually entering them, however that sounds about what you are already doing so I don't see any benefit specifically.
It may be a benefit to keep unchangeable fields to select from over having field users manually enter it. Errors with street names can be costly. However after 1000 entries maybe having a select location, using location services on devices, or project specific actions may also be of benefit. I'm interested on having dropdowns like this to select from the entirety of a layer's attribute list but weighing out options would be good if you are concerned for size and time spent scrolling and working out of the data like this. Like I said I am not specifically well versed on that scale so I look forward to the solution.
The use of the Domain is to ensure that the field crews don't misspell the road name or have some that use Dr instead of Drive, etc, etc. All the different spellings caused some issues with reporting
Come to think of is @JasonBritton1 & @JoeBorgione , there was a workflow described at one of the ESRI UC conferences in the past two years where you would preload the domain list of feature attributes based on location services. For example, in a survey123 or collector form, (i forget which) some of the fields could be automatically loaded from a hosted feature service based on proximity to the feature. If you are within 2nd Street by a matter of a few yards closer than 3rd street, the field would choose 2nd street for example. This would retain the domain, allow you to not have to alphabetize your lists and dropdowns, as well as streamline your field workers efforts and yours alike. Perhaps this would be of greater benefit to look into?
Street Types I can see, but all the different street names is a tall order. We deploy ESRI's Address Data Managment Solution and it uses a domain of street names. I opted not to use it at all.