search

koopjs / FeatureServer

An open source Geoservices Implementation (deprecated)
https://geoservices.github.io
Other
104 stars 32 forks source link

The FeatureServer/layers route is not working for tables #89

Closed jkerr5 closed 6 years ago

jkerr5 commented 6 years ago

There is code that tries to recognize when a layer is actually a table but this is not working when the metadata is actually for a table.

The provider returns this for the metadata:

          id: 1,
          name: 'All',
          decription: 'All US ZIP code boundaries (table-only)',
          idField: 'OBJECTID',
          displayField: 'zipcode',

No extents and no geometryType are set.

This results in the following stack trace:

Trace: TypeError: features.forEach is not a function
    at module.exports (/koop/node_modules/esri-extent/index.js:8:12)
    at Object.getExtent (/koop/node_modules/featureserver/dist/utils.js:24:17)
    at /koop/node_modules/featureserver/dist/info.js:83:29
    at Array.forEach (native)
    at Object.layersInfo (/koop/node_modules/featureserver/dist/info.js:82:10)
    at execInfo (/koop/node_modules/featureserver/dist/route.js:73:21)
    at Object.route (/koop/node_modules/featureserver/dist/route.js:36:14)
    at /koop/node_modules/koop-output-geoservices/index.js:9:24
    at /koop/node_modules/koop/dist/models/index.js:15:9
    at mq.providerGetData.then.data (/koop/marklogic.js:45:8)
    at execInfo (/koop/node_modules/featureserver/dist/route.js:80:52)
    at Object.route (/koop/node_modules/featureserver/dist/route.js:36:14)
    at /koop/node_modules/koop-output-geoservices/index.js:9:24
    at /koop/node_modules/koop/dist/models/index.js:15:9
    at mq.providerGetData.then.data (/koop/marklogic.js:45:8)
rgwozdz commented 6 years ago

@jkerr5 - I'm having some trouble reproducing this. Your stack trace notes it is failing here, presumably because features is not any array and therefore doesn't have a forEach function.

However, in stepping through this myself, I'm unable to reproduce that behavior by removing extents and geometryType. I've also ensured that all of my incoming features are missing the geometry property. However, it all of those cases, I still have features as an array instance by the time it gets here. Are you able to put a break point in there and see what is assigned to features? If so, let me know what you find. That will really help resolve.

jkerr5 commented 6 years ago

The features array is null as the provider plugin does not return any features for this kind of call. The provider returns the metadata for each layer but no features. I can post a full provider response to help you debug.

rgwozdz commented 6 years ago

That would be great, thanks. Can you also provide me with the request URL so I can get some more context?

rgwozdz commented 6 years ago

@jkerr5 - the GeoJSON spec notes that the features property should be an array. We'd like to stick to that spec, so getData should always return a property features that is an array. This will ensure any dependencies expecting valid geojson function as intended. Instead of null, are you able to set features to an empty array? I'll add some explicit documentation of this requirement in the provider spec and also add an informative error in FeatureServer if an array is not found.

rgwozdz commented 6 years ago

Closing this, but opening an issue to add warnings for invalid GeoJSON. See https://github.com/koopjs/FeatureServer/issues/110.

jkerr5 commented 6 years ago

I can change my code to include a features:[] property but are you sure there's nothing else that depends on checking if that features array is there? Koop is relaxed on GeoJSON spec in other places (e.g. statistics responses) so you may need to change those to make compliant GeoJSON.

rgwozdz commented 6 years ago

@jkerr5 thanks for the additional input. I just meant to say that the getData function in a provider should pass valid GeoJSON to the callback. That GeoJSON can include additional key-values, but the standard GeoJSON properties should conform to the spec to ensure all downstream operations that depend on GeoJSON get what they need. The provider spec already alludes to this, but not explicitly.

You're right regarding other parts of Koop - I'm definitely not suggesting responses from FeatureServer or other output-services be strict GeoJSON.

jkerr5 commented 6 years ago

OK, thanks @rgwozdz I'll make the change on my side and let you know if I see any issues. Thanks.