Closed timwis closed 7 years ago
@timwis I think it makes sense to support a f=geojson
parameter on the /featureServer
endpoint if we're going to use geoservices-style query options. What do you think?
Hey Daniel! I'm sorry, I really can't remember what this was for :-/
Dude, your memory must be slipping. You only made this request 18 months ago :P
As of Koop 3.0, all providers are going to automatically have /featureServer
endpoints, same goes for anything that's in the cache, so I think that's going to accomplish the goal of supporting those query parameters on geojson.
As for supporting Koop-Soda, I've created a new plugin type called Output
, that lets you query Providers and/or Koop's cache however you want. Docs are coming soon, I'll send them your way!
That's awesome! I've been in reverse proxy land recently with soda-carto, so hopefully that can benefit this project too!
Edit: I assume you're referring to the functionality of those "interfaces" that we discussed in the past? If so, that's great!
These parameters only work for the FeatureServer interface, and are done in post-processing, after the database query. Any reason they're not incorporated into the initial query? The logic for this appears to be in pgcache/index.js#324.
For instance, instead of
select id, feature->>\'properties\' as props
, something more likeselect id, feature->'properties'->>'ADDRESS' AS ADDRESS, feature->'properties'->>'CITY' AS CITY
whenoutFields
are specified.This would be necessary to support other interfaces like OData / SODA2 beyond the
&where=
clause. Happy to spend some time on it, just wanted to ask if there was a particular reason it was done this way first.(Ref #195)