Additional sort orders
For the POI clicking feature, it would be useful to order areas decending by size.
Another useful ordering would be to order by distance to a given pair of coordinates.
~~I heard that for some tools it is necessary to sort elements in such a way that relations come first, then ways and then nodes. Basically like the current id-sorting, but with the element types reversed.~~ //cc @species
I tend to define distance for ways to be the smallest distance from any segment and for relations the minimum distance of all node and way members. I'm confident that this is the best choice for linestrings: If you click near a street, it is quite likely that you meant the street, regardless of the length of the street (which would rule out all variants of centroid). For areas the situation is less clear but nonetheless: Usually the whatever center variant of an area is not a special point for that area, but to ask what object has its boundary at a given position makes at least in some cases sense. I think for areas sorting ascending by size would already be the best choice.
Side-note: for tools like osmfilter and osmconvert[1] - it is NEEDED that the items in the osm-xml file are present in the following order: nodes; ways; relations. The sorting inside one element-type does not affect usage by osmfilter/convert.
It would be nice if the node-way-relation sorting would be considered on XML output, because these tools are frequently used in processing overpass data.
[1] https://wiki.openstreetmap.org/wiki/Osmfilter
I approve according the order relation-node-way is not very convenient. A lot of tools (like the OSM driver in OGR) want the order node-way-relation and I guess a lot of other processing tools.
+1 for order node>way>relation in the file, as ogr2ogr needs it and is used by some widespread GIS tools like QGIS
Isn't node>way>relation already the default (and sort="id") ordering‽
If I ask route=bus in Overpass Turbo and I look to the data (export -> data -> row data in overpass), it's relation-way-node : http://overpass-turbo.eu/s/3QV Overpass
I tried to change the sort quadtile to id, but the id of a relation is still lower than node.
This is because this query uses multiple <print> statements. The first one prints all the route=bus things (most likely relations), the second one prints all the child elements. You can re-structure the query to use only one single print statement and get the desired output ordering: http://overpass-turbo.eu/s/3Rn
(PS: The reason why overpass turbo's query wizard produces a query with two print statements is such that it can use the skeleton output mode in the second print statement to reduce unwanted by-catch data and reduce bandwith.)
I want buildings or points? close to lat,lon
My use case: phone app,
- user takes a picture of a building/name/address,
- "is it one of these: (list of names/addresses)"
- "no, let me add name/address/etc."
2 and 3 can be done by someone else later.
I want to catalogue health care facilities. There are lots of databases, which is a good start, but the data is dynamic and needs help filling in the gaps. As new places are identified, someone can find a phone number and call them. Part of the goal is to avoid bothering them more than once.
@CarlFK : please don’t add random comments to unrelated issues. This GitHub repository is meant for bug reports and enhancement requests for the Overpass API