Socrata table not rendering properly in ArcGIS Online map viewer

[sirws]

http://www.arcgis.com/home/webmap/viewer.html?url=http://50.18.49.187/socrata/wa/3uf4-3kn2/FeatureServer/

Socrata data is a table. Try to view the table in the ArcGIS Online map viewer and it doesn't render any records. Must be some sort of formatting of the output from koop/socrata that is causing this issue.

[chelm]

@sirws Im guessing that since its a Table it doesnt have any geometries show adding it to the map in AGO wont render anything, since it has nothing...

http://50.18.49.187/socrata/wa/3uf4-3kn2/FeatureServer/0/query -> see no geoms to map...

[sirws]

Yes, but the table is in the Table of Contents of the map (like I would expect)... and when I go to show the table, it gives me the above screenshot that doesn't show the grid of data, just the count of records...

[sirws]

Here is an example of a table coming from an ArcGIS Server feature service:

http://www.arcgis.com/home/webmap/viewer.html?url=http://sampleserver5.arcgisonline.com/arcgis/rest/services/SF311/FeatureServer/1

See how it renders data in the grid below? Even if it is a table and not a layer:

[sirws]

Here is some more information. It appears that the socrata provider is returning data that isn't expected in ArcGIS clients.

Attributes should only contain simple data types, and we are returning objects:

The "phone" field has an object in it.

Also, this is a table (non-spatial) and it is returning this info in the object:
hasZ: false,
hasM: false,
geometryType: "esriGeometryPoint",
spatialReference: {
wkid: 4326
},
All of that can be dropped from a table object. ArcGIS Feature Services do not return that information for table objects.

[chelm]

@sirws Awesome, Yes I think the correct course of action would be to flatten these properties into something like:

{ phone_phone_number: "123456789", ... }

We just need to be sure that those get turned into "fields" in the feature service out put as well. Probably a pretty straightforward to do in koop-socrata's model, in the toGeoJSON method...

[sirws]

Cool! Also, I am seeing records that have fields / attributes that are not in the fields array:

Note the object above has a "mobile_phone" attribute and fields collection does not contain a mobile_phone attribute:

[chelm]

Right, that is an issue, if not THE issue :)

[chelm]

I've got an idea of what this is going to take:

1. While processing features in toGeoJson build a list of all attributes a feature should have (all flattened objects become fields)
2. A second pass on the features is then required to ensure that each feature has each field.

I'm not stoked on the 2nd pass but since each incoming may only have a subset of the feilds AND since while we process features we will actually be creating new fields (as flattened objects) we need to take a final pass and add any missing fields.

[sirws]

@chelm Have you made any progress on this flattening effort? Is there a different issues for it, or is this it? Let me know if you want me to create a new issue...

[chelm]

@sirws Yes flattening is in master - fd5a555#diff-8f1da6e78158e3e881a0eeceaef15258R197

[sirws]

This appears to be fixed. Closing.