Multiple Coded Values per Record

1992
9
05-10-2012 12:18 AM
Status: Open
Labels (1)
SimonTrinder1
New Contributor II
I would like the ability to choose multiple values from a Domain and assign to a field. ie. Apples, pear, Oranges

Field name =  Contents
Domain Name  =  Fruit
Coded Values =Apples(A), Orange (O), Pears(P), Strawberry(S).

I would like to be ableto choose one or a combination of the values Apples or Apples & Oranges or Apples & Oranges & Pears etc.

So instead of a drop down, when editing the field, there is a check list where I could choose mutiple values.
9 Comments
EmilianoTondi

I think is needed to permit to choose form multiple coded values in a Domain. Often the user just wants to add more than one value present in the list of the Domain; now you have to add more fileds to store more info from the same domain. Instead I think it is necessary to able the geodatabase to insert more than a coded value from the same Domain as it happens in Access (from 2007 version).

CarmellaBurdi1
If this hasn't been created yet, especially with the concept behind GeoForms, this would be a very valuable resource to have. 
KelseyBoyd
This would be incredibly useful to our organization. I am trying to figure out work arounds for this, but it is resulting in very long collector forms, increased time to fill in forms, and/or loss of consistency. If ESRI doesn't add this function, we may have to use a different product.
ChrisMathers
The problem here is the the form mirrors the database functionality. The goal of a domain is to standardize input into a field and this would do the opposite. Database opperations would be slowed because to search accurately on that field you would have to parse the list contained in each record.
SamJenkins2

Chris,

I like the functionality of this idea, but was concerned about searching data afterward as well. Could your hesitancy be persuaded if the domain was interpreting a bitgate?

Cheers

Sam

AndrewZimba

Not exactly - If in the example the OP posed the user selected that all 4 types apply the stored value could be a delimited string - A; O; P; S and searches could be done using Like instead of =

JohnDye2

I like the idea but the biggest problem I see with it is that the having a multi-value selection has development implications across the entire ArcGIS Platform. Esri would need to come up with a well known multi-value selection syntax, say semi-colon delimited as demonstrated by Andrew Zimba‌ and the somehow reserve that syntax across the platform and ensure that all applications and solutions had built-in logic to detect, parse and visualize that data in the solution UI.

That means dev effort for Pro, Online, Web App Builder, OpsDB, Workforce, Collector, GeoPlanner...the list goes on and on. Multi-value selections are useful, I agree. It's just that this while seemingly a small development effort has some pretty massive implications when you scale it out to the entire platform.

Fwiw, Survey123 already does multi-value selection but perhaps there's a standard defined there and all of the other  Esri App teams could just on board with that, but even so - this is no small ask.

ChrisMathers1

What if it was a NoSQL database being used? With everything essentially as JSON objects you can make the field an array and the chosen values can be objects within it. The query as a concept changes a bit as does storage in general but it would work. They would need to write an ODM to run in place of the normal ORM for relational databases though and like you said that's a system wide undertaking. esri products don't do much with NoSQL databases at the moment but I can see that changing in the future especially with the shift towards big data analytics. They already use MongoDB with Monitor but that's not a core spatial product so it only tangentially applies. Mongo uses GeoJSON as its spatial type so hypothetically you could run the esri JS API off of it with changes to the query back end.

Bud
by

Interesting idea. The underlying data could be stored in a related table (1:M). But the multiple values could be chosen and displayed in the main attribute table/field. That would be easier to view & edit when compared with navigating to a related table.

Alternatively, the multiple values could be stored in an XML column, which would be queryable via SQL in enterprise geodatabases (not sure about mobile geodatabases).

There are probably other ways to do it, such as a comma-delimited field, as mentioned in a comment above. The values could be automatically sorted in alphabetical order upon entry.


Related: Automatically select related records