Can we have GeoJSON output please

[naomap]

I am aware of issue #48 that was closed in 2013 because "the semantics are not clear" and @drolbr decided to "to implement GeoJSON output for after the history feature".

A lot of water has flown under the bridge since then. In particular, the introduction of the convert and make statements came along the output of geometries that are effectively in GeoJSON format, as this example shows. This result is actually very close from proper GeoJSON, the code to convert geometries to GeoJSON is already there ! The only bits missing are to rename elements to features, wrap them up in a FeatureCollection, and rename tags to properties.

This example also illustrates the semantics issue mentionned in #48 : the bicycle parkings defined as a closed way probably ought to be converted to a Polygon rather than a LineString. Maybe the time has come to discuss this point :-)

The use case is to be able to integrate in uMap the result of a query that uses make or convert.

[tordans]

@naomap did you experiment withconvert item ::=::,::geom=geom(),_osm_type=type(); which is explained at https://github.com/drolbr/overpass-doc/blob/master/en/targets/formats.md as a way to transform the overpass JSON output to GeoJSON? I wonder, though, how this knows what to render as line vs. polygon (there are libraries like https://github.com/ideditor/id-area-keys for this)

[mmd-osm]

https://dev.overpass-api.de/blog/flat_world.html#geojson has a bit of discussion on GeoJSON format deficiencies, but it doesn't cover that topic. There's at least no tag-based ruleset in place which decides to go for either linestring or polygon.

[naomap]

@naomap did you experiment withconvert item ::=::,::geom=geom(),_osm_type=type(); which is explained at https://github.com/drolbr/overpass-doc/blob/master/en/targets/formats.md as a way to transform the overpass JSON output to GeoJSON? I wonder, though, how this knows what to render as line vs. polygon (there are libraries like https://github.com/ideditor/id-area-keys for this)

I did and this is the point of this issue : convert together with geom() enables us to produce proper GeoJSON geometries, however the request response is close to but not quite proper GeoJSON : the elements would just need to be Feature objects wrapped into a FeatureCollection.

The semantics issue is sort of independant to my point. My point is that adding support for [out:geojson] "just" requires to

rename elements to features, wrap them up in a FeatureCollection, and rename tags to properties.

Ok, it probably requires more than that, as it needs to handle queries other than those using convert together with geom()...