Socrata table not rendering properly in ArcGIS Online map viewer about koop-socrata HOT 11 CLOSED

@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...

from koop-socrata.

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...

from koop-socrata.

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:

from koop-socrata.

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.

from koop-socrata.

@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...

from koop-socrata.

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:

from koop-socrata.

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

from koop-socrata.

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.

from koop-socrata.

@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...

from koop-socrata.

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

from koop-socrata.

This appears to be fixed. Closing.

from koop-socrata.