tobinbradley / dirt-simple-postgis-http-api

Dirt Simple PostGIS HTTP API
368 stars 101 forks source link

Add support for feature id #34

Closed mapsgeek closed 4 years ago

mapsgeek commented 4 years ago

I would love to see support for the feature id parameter in the mvt endpoint Since it's required for the function setfeaturestate in the mapbox gl js api And i found that postgis has support for that but i couldn't figure out how to add it and make a PR.

tobinbradley commented 4 years ago

I added an optional id_column argument. Note that the column name in the id_column argument must exist in the columns argument, and also must be unique per the Mapbox spec (not sure what would happen if it wasn't, YMMV).

The trick was changing the last line of the SQL statement to:

SELECT ST_AsMVT(mvtgeom.*, '${params.table}', 4096, 'geom' ${query.id_column ? `, '${query.id_column}'` : ''}) AS mvt from mvtgeom;

Basically you have to string out all of the optional arguments as their defaults so you can get to the feature_id_name argument they tacked on the end. Seems to work. Let me know if you run in to any issues with it.

mapsgeek commented 4 years ago

Thank you tobin, that will do

mapsgeek commented 4 years ago

A hint for anyone who wants to use this,

the column name in the id_column argument must exist in the columns argument this works just as it's been intended to be but that column will be used as ID and won't be available in the feature properties, so in my case i wanted the field as a feature id and also wanted it as a property for filtering so you have to provide the same column name twice as the columns params eg. http://localhost:3030/v1/mvt/routes_merged/{z}/{x}/{y}?columns=tour_id,tour_id&id_column=tour_id

tobinbradley commented 4 years ago

Thanks for pointing this out. I updated the service so you no longer have to list the id_column in the columns argument (it does that behind the scenes now if a id_column is specified). That way you can put it once in both places if you need it in both places, which makes more sense. I don't know why I thought the other way was a good idea :).