Possibility of including "admin_center" node relation IDs?

d b

2 years ago
updated 2 years ago
Under review

I'm trying to make a bridge (imperfect) between population centres and admin boundaries - where the boundaries allow a crude map of a user lat/lon to a population center - at the lower Admin levels we often have 'parish', 'council' etc that is intuitively understood to be the area around the admin_center.

Many thanks for the service - I am learning about the complexities of this data for a project, and this service has been extremely helpful.

Replies 7

Oldest first
Newest first Oldest first

Magnus

2 years ago
Under review

Please provide an example node with a link to OpenStreetMap.org since we don't know what this is. I could find zero nodes which had boundary=admin_center, and two that had boundary=admin_centre.

It's very likely that it's something that will be out of scope for this site. But without knowing what you are looking for I can't be certain.

Reply Link

d b

2 years ago

Thanks for looking at my query - sorry it was vague!.

Mostly, an administrative boundary (the relation) includes a reference to a node, role:admin_center (American spelling :) -

for eg

area[name="United Kingdom"];
relation(area)["admin_level"~"^(2|3)$"]["type"="boundary"]["boundary"="administrative"];
out meta;

references :

...

<member type="node" ref="107775" role="admin_centre"/>

...

This one ID would be very useful in the extract I think (for me certainly, but I hope for others!).

Kind regards,

Dan.

Reply Link

Magnus

2 years ago

Thank you for the additional information. As a disclaimer you should know that we aren't experts in OSM, not even close. We created this site for our own needs and chose to make it public, to give something back to the community.

I spent some time investigating our possibilities earlier this week. I can see that https://www.openstreetmap.org/node/107775 references several relations tagged as being the admin_centre of them, for example https://www.openstreetmap.org/relation/175342 (London). So far good, but it mostly says pretty much what you already said.

We use osm2pgsql to import a planet.osm file into our DB server. This basically gives us four database tables.

* planet_osm_line

* planet_osm_point

* planet_osm_polygon

* planet_osm_roads

Node 107775 does exist in table planet_osm_point, which is expected. But I can not find any reference to that node in table planet_osm_polygon for osm_id 175342. Neither the other way around.

I have checked the template file used by osm2pgsql, and read the man page. I have also tried to Google around for a while. But I can't find a solution to match these together. Without any reference between them we'll have a hard time supporting this.

It should also be mentioned that we use osm2pgsql version 1.2.x, which is very old now. Latest version is 1.8.1. Besides the fact that we haven't felt a need to upgrade, 1.3.0 also introduced quite a lot of changes which would require us to do a lot of testing. They implemented something called "Flex output" which, to my understanding, would require us to make new template files for importing data. This feature didn't become officially stable until the 1.5.0 release either. So we intentionally stayed away from upgrading for quite a while.

Reply Link

d b

2 years ago

I am no expert either :) - Finding my way, so your time investigating is very much appreciated.

It seems that the ID I'm looking for would be in a relations table that (it looks like?) you don't need are not importing? That would be a big change!

I've started to look more closely at osm2pgsql and it's quite a lot to take in but I do think I can find my data through that method - Boundaries from you, Places (nodes) from Overpass, and the links between them from processed world files.

There's bound to be better ways, but for now that will help us move on!.

Thanks again for your help and providing this service.

Reply Link

Magnus

2 years ago

osm2pgsql doens't create a relations table. We don't filter what tables it should create upon import. At least not intentionally. And by that I mean that it could be a side-effect of something else we do of course.

Relations, to my knowledge, only describes what items to use to create a polygon. osm2pgsql's purpose is probably primarily to provide those polygons, and on the way to that it imports nodes into table planet_osm_point, ways into table planet_osm_line, and then finally creates the polygons in planet_osm_polygon.

Later on we actually do drop all the planet_osm_* tables. Mostly because we don't use them and they are ~400 GB of data, while the data we actually need is less than 100 GB. That's why the size is so much smaller for most databases listed at https://osm-boundaries.com/Status . We generally keep those tables for the last two imports or so though, for debugging purposes and discussions like these.

Reply Link

d b

2 years ago

Ah, yes - I was jumping ahead and just reading the Flex documentation, which mentions a relations table. https://osm2pgsql.org/doc/manual.html#the-flex-output

Reply Link

d b

2 years ago

Oh, and no, the relations do include the admin_center. For e.g. https://www.openstreetmap.org/relation/3946276 - "Members' at the bottom includes the ways that make up the boundary, and the 'admin_center' relation to a Node.

Thanks again - so much to learn!

Reply Link