Select to view content in your preferred language

Domain values on fields not coming through to Open Data

5733
18
12-22-2014 03:44 PM
MalcolmJ
Occasional Contributor II

I have noticed that fields with a domain are not bringing the domain description fields through to the open data site.

So I have a layer with a few domain fields. One field has a text coded values domain. E.g. the code is "Prohibited" and the Description is "Dogs NOT Allowed". In webmaps etc the field will display as Dogs Not Allowed as I would expect. In Open Data it displays Prohibited.

Same on another field which is using short integer coded values. Field values come through open data as 1, 2, etc instead of 'One way',

'Two way' etc.

Is this a issue with open data or is there something I need to change somewhere in order to bring through the domain values?

I am accessing the data through the Open Data site using a feature service in ArcGIS Server 10.2.2. Underlying data is stored in SDE in SQL server.

Thanks

18 Replies
DanielFenton1
Regular Contributor

Hi Malcolm this is in our backlog and we will get to it but I cannot give a timeline yet. Sorry I can't give more information right now.

0 Kudos
C_EHoward
Occasional Contributor III

Are there any recommendations on how to manage until this important functionality is added?

0 Kudos
DanielFenton1
Regular Contributor

Hi C E, you could use a string field instead of a coded field. Instead of those codes just put the actual values in their place.

0 Kudos
C_EHoward
Occasional Contributor III

thanks, yes I know. I was hoping to not have to create dozens more fields just to have values that are already coded and described. an alternative, yes, but not a very realistic one for many

0 Kudos
DanielFenton1
Regular Contributor

Just curious, can you explain why you created these as coded fields instead of strings in the fist place? Was this about maintaining data consistency?

0 Kudos
C_EHoward
Occasional Contributor III

I did not for the most part, I inherited data from several sources/entities that use codes. There are a lot of reasons that they may use codes but I cannot really speculate. I think I remember way back in GDB design 101 that domains and subtypes are even encouraged to be used to manage data/consistency. Of course there was no way knowing which way things would go with data sharing, etc. But my bottom line and expectation is that we should not lose functionality in the name of sharing and using web GIS. Domains and-- even more important to me-- related records-- should not be sacrificed or thought of as 'enhancements'

I appreciate the strides being made by AGO and OpenData. But you (meaning Esri) cannot expect us to all think this is the answer when there are usually more workarounds to get things going. I do not want to have to rely on 3rd party apps/widgets for basic functions.

0 Kudos
MalcolmJ
Occasional Contributor II

That's why we use them, for data consistency.

I did consider creating string fields with the descriptions instead of the codes but dismissed this idea due to the amount of fields and layers we have using domains.

0 Kudos
MalcolmJ
Occasional Contributor II

As a similar item to look at, I've just noticed that if a field name has an Alias, when you download the data it will revert back to the original field name in the downloaded data.

e.g. Layer: Drains (ID: 19)

The field "SecondTier" has an alias name of "Type". It displays as Type when using the Open Data website, but when downloaded displays SecondTier.

Ideally, this should download using the alias field name.

0 Kudos
AndrewTurner
Esri Contributor
0 Kudos