|
I‘m trying to understand how I can find the long/lat for a given relation. I would like to archive this based on a sql query. Would I need to create a new polygon based on the members polygon and the find the center of that polygon? Looking forward to any tips Thx! |
|
Relations (not relationships) are simply lists of other OSM objects (potentially with an associated "role" attribute). The actual meaning/semantics of the relation are dependent on the "type" attribute of the relation. Examples:
For all of these it is possible to define a meaningful centroid, however how to exactly do so really depends. Now assuming what you are actually looking at is a multipolygon (or a boundary which for this purpose is essentially the same) and the geometry of the polygons have already been built (don't try to do this yourself, use a library) it is relatively easy because any database with support for spatial values will have built in functions for this. Unluckily you haven't given any details as to where you are retrieving the relations from in what format and where you intend to store them, so I have to stop here for now. What I did so far. I loaded a subsetdata of OSM data via osmosis into my postgres database. Now lets say we look into following relation (this is supposed to be a relation for a winter resort in Switzerland) SELECT * FROM relations WHERE id = 6720604 or SELECT * FROM relation_members WHERE relation_id=6720604 As you see no member_role attribute has been given. I'm aware that with. e.g. ST_Centroid you can let the DB calculate you the center. But how do I get a meaningful multi/polygon of the above relationship? Hope this explains my issue in more detail
(24 Feb '18, 14:31)
gabac
2
"But how do I get a meaningful multi/polygon of the above relationship?" You can't. You need to have a database in which the geometry of the OSM objects have actually been built. The most popular way to do this is to create a database in the osm2pgsql schema and import data to it (while osm2pgsql is mainly intended for rendering, the requirements overlap in this respect).
(24 Feb '18, 14:37)
SimonPoole ♦
Oh ok I see. Then I’m now off to the task of understanding osm2psql as well :) Thx for your help
(24 Feb '18, 15:04)
gabac
|