Closed jkerr5 closed 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.
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.
That would be great, thanks. Can you also provide me with the request URL so I can get some more context?
@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.
Closing this, but opening an issue to add warnings for invalid GeoJSON. See https://github.com/koopjs/FeatureServer/issues/110.
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.
@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.
OK, thanks @rgwozdz I'll make the change on my side and let you know if I see any issues. Thanks.
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:
No
extents
and nogeometryType
are set.This results in the following stack trace: