Overpass-API icon indicating copy to clipboard operation
Overpass-API copied to clipboard

Additional sort orders

Open drolbr opened this issue 11 years ago • 11 comments

For the POI clicking feature, it would be useful to order areas decending by size.

drolbr avatar Mar 17 '14 17:03 drolbr

Another useful ordering would be to order by distance to a given pair of coordinates.

drolbr avatar Mar 17 '14 17:03 drolbr

~~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

tyrasd avatar Mar 17 '14 17:03 tyrasd

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.

drolbr avatar Mar 17 '14 17:03 drolbr

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

species avatar Mar 17 '14 18:03 species

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.

Gustry avatar Jun 16 '14 09:06 Gustry

+1 for order node>way>relation in the file, as ogr2ogr needs it and is used by some widespread GIS tools like QGIS

mdouchin avatar Jun 23 '14 11:06 mdouchin

Isn't node>way>relation already the default (and sort="id") ordering‽

tyrasd avatar Jun 23 '14 12:06 tyrasd

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.

Gustry avatar Jun 23 '14 12:06 Gustry

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.)

tyrasd avatar Jun 23 '14 13:06 tyrasd

I want buildings or points? close to lat,lon

My use case: phone app,

  1. user takes a picture of a building/name/address,
  2. "is it one of these: (list of names/addresses)"
  3. "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 avatar May 13 '20 17:05 CarlFK

@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

mmd-osm avatar May 13 '20 17:05 mmd-osm