I try to create multipolygon describing border of Poland to test if some building are in this administration area. I took data from db (I imported OSM data to local db first preserving order of ways and nodes during the import). What I see is some ways in relation definition (members) are not on proper position. The question is: should I reorder ways on relation data or it's an issue with Geofabrik data export and look for other source of OSM data? asked 21 Jul '16, 12:20  stalek |
One Answer:
Do not write your own multipolygon building code. You are re-inventing the wheel. Re-use the code that already exists in osm2pgsql (PostGIS importer), libosmium (C++ processing library with Python bindings), or GDAL (has an OSM input driver and can write various output formats) instead! OSM does not require that relation members be stored in the right order; this is something the software must do. answered 21 Jul '16, 12:28  Frederik Ramm ♦ showing 5 of 9 show 4 more comments |
In addition, even if you were to make sure that all objects in a relation (such as a route relation) were "in order", as soon as someone edits that relation (e.g. to split a way) the objects will be "out of order" again.
I don't plan to draw any shapes. I have to test if some coordinates belong to some administration hierarchy (country, region, county and so on). To do it I have to create the shape of boundary to test if any point/location is withing such shape. I will take a look if PostGIS importer creates such shapes during the import (as mentioned by you). It's not a rocket science to reorder ways when I know they are in random order. btw: I use SqlServer and its spatial support to speed up things during the processing and I don't load any data to any external applications to not slow it down (it's not necessary in reality, because every complex operation on such data is easy to implement using T-SQL). It's like using many "db engine cursors" in case of external apps versus raw performance of group of queries optimized by DB engine :)
Thanks for the info :)
After reordering of a few ways/lines I received proper shape already, so the info from Frederik helped :)
Thanks.
"This is something the software must do"
But how must the software do it? It seems that the order of the ways in the relation/members field is still not correct, from time to time it gives me discontinuous graphs. I read everywhere that ways do not need to be sorted, and sure, I can plot 16 lines separately to make a trail, but what if I want to offer a relation as a GPX file? Those need to be sorted, right?
Maybe the question is: Is the proper way to sort the nodes in a relation anywhere in the relation object? If so, where is it? Or do I need to write some code to find the closed "first node of a way" to the other "last node of a way" and sort based on that? Is that what the software must do?
Some more info on what I'm trying to do: https://stackoverflow.com/questions/68375034/plotting-openstreetmap-relations-does-not-generate-continous-lines
Reading your stackoverflow post, I am not sure if you are distinguishing between ordering the member ways, and ordering the nodes within each way.
E.g. suppose a relation runs from east to west and all members are correctly sorted from east to west. Within any given member way, the nodes might happen to run from east to west or west to east, as ways (unless they are one way streets) have an arbitrary direction. So if you are trying to order nodes within a member way you need to pick the right one of the two possible directions. That information is not contained in the relation itself. (Apologies if you already know all this).
Other things to bear in mind
There may be nodes or ways with specific roles, e.g. guidepost, that you probably would not want to try to sort.
Recreational trails in the real world are not always "sortable", there may be spurs, alternate routes etc. Recently there has been a trend to try to identify these with roles within relations (https://wiki.openstreetmap.org/wiki/Proposed_features/hiking_trail_relation_roles), but you can't rely on that being the case.
While recreational routes ideally should be sorted by mappers who input them to OSM, not everybody does this, and there is nothing in the editors that forces them to do so. Even if a route is sorted initially, the sorting can get broken quite easily for large relations, often by mappers editing member ways for reasons unrelated to the route relation. I often find hiking relations I have carefully sorted in the past have been "unsorted" by subsequent edits.
Ok,thanx, clear, the data model is just what it is. I do wonder how GPX trails are generated by some websites then. They probably do some math to sort based on last/first coordinates of trails.
If you look at the output that some tools like http://ra.osmsurround.org/index generate, you can see how it's arranging various pieces of relations.
If you have the constituent geometries in a PostGIS database as linestrings, then ST_LineMerge can usually do a pretty good job of piecing them together to make continuous lines. https://postgis.net/docs/ST_LineMerge.html