[gdal-dev] osm_id vs osm_way_id?

Thu Dec 1 23:59:35 PST 2016

Hi,

ogr2ogr creates these ids:

-          for point data node_id becomes ”osm_id”

-          for linestrings way_id becomes “osm_id”

-          for multilinestrings relation_id becomes “osm_id”

-          for other relations relation_id becomes “osm_id”

-          for polygons which come from relations relation_id becomes “osm_id” and osm_way_id is null

-          for polygons which come from ways the way_id becomes osm_way_id and osm_id is null

GDAL cannot write ids of the way polygons and relation polygons into the same ID field because there would be duplicate ids (same numbers coming from way_id and relation_id).

Historically GDAL wrote way polygons into layer named ”polygons” and relation polygons into ”multipolygons” and both had just “osm_id”. It was perhaps more clear when it comes to ids but more fuzzy for users to find polygons from two different tables. Remember that in the OSM model a way polygon must be converted into relation polygon if user wants to make a hole into the polygon.

If I understand right you consider that instead of having now in the multipolygon layer relation_id as osm_id and way_id as osm_way_id it would be better to have way_id as osm_id and relation_id as osm_relation_id.  Perhaps yes, but for my mind the difference is not huge.

I guess that when the developer of the OSM driver stopped using the “polygons” layer they made the driver to write also the way polygons into the existing “multipolygons” layer. That layer already had osm_id so a new field osm_way_id was simply added into that layer.

If you can prove that there are some general use cases where renaming the id fields of the multipolygons layer would be a big improvement, please file a feature request.

-Jukka Rahkonen-

Djordje Spasic wrote:
Re: [gdal-dev] osm_id vs osm_way_id?

Hi Jukka,

As always thank you for the useful share of knowledge!!

> IDs are unique only for nodes/ways/relations but not across the elements. I
do not think that renaming osm_id into relation_id (and probably osm_id of
points into node_id, or?) and osm_way_id into way_id to follow the native
model would make things very much more clear.

I was only questioning why can't "osm_way_id" be renamed to "osm_relation_id". The "osm_id" would remain the same.

Of course I am not a developer, I was just thinking out loud, and hopping that somebody might explain to me, why is there the "osm_way_id" key.
I could totally be wrong.

All three examples you've sent me:

http://www.openstreetmap.org/api/0.6/node/389960161
http://www.openstreetmap.org/api/0.6/way/34028339 http://www.openstreetmap.org/api/0.6/relation/125519

Show the id of three different elements: An id of a node, of a way, and of a relation.

What makes it confusing (at least to me) is why did developers of the GDAL OSM driver decided to use a separate key(field) to depict the closed ways?

I understand that and ESRI shapefile can not differentiate between a closed way and a relation (for example: a relation consisted of two closed ways). So they had to "group" both closed ways and relation into a single shapefile geometry type (multi)polygons/polylines. But still, if they wanted to differentiate between these two elements, it's more logical (at least to me) that a relation should have gotten a separate key(field), instead of a close way. A relation is higher in the hierarchy of OSM elements, and can contain different elements (a node and a way, three ways, fours nodes...).

I am just thinking out loud, nothing more.
I can definitively be wrong, and I am eager to learn more about the OSM in general.

----------------------------
On Thursday, December 1, 2016 11:03 PM, jratike80 <jukka.rahkonen at maanmittauslaitos.fi<mailto:jukka.rahkonen at maanmittauslaitos.fi>> wrote:

georges wrote
> Hello,
> I am converting an .osm file to shapefile, and there is one thing that I
> do not understand:
>
> What is the difference between: osm_id and osm_way_id fields (keys)?
>
> They are defined in osmconf.ini file, but only for [multipolygons].
> Here is an explanation from the osmconf.ini file:
>
> # note: for multipolygons, osm_id=yes instanciates a osm_id field for the
> id of relations
> # and a osm_way_id field for the id of closed ways. Both fields are
> exclusively set.
> Does that mean that osm_way_id will be used to represent the osm id number
> of a closed way, while osm_id will only be used for to represent the osm
> id number of relations?
>
> It's a bit confusing concept.
>
> What makes the closed ways so special so that they need to have their own
> special field (osm_way_id)?
> Why wasn't there a separate field for relations instead: like:
> osm_relation_id, while closed ways would use the osm_id.
>
> Thank you for the reply.

Indeed, OSM data model is a bit confusing concept. You can read about it
from https://wiki.openstreetmap.org/wiki/Elements. Simple, small polygons
are usually modeled as a one continuous, closed ring. That makes one "way"
and the ID for it is found from way_id. All the other polygons are modeled
as relations which are collections of ways and they have "relation_id" in
the data as you can see

node_id http://www.openstreetmap.org/api/0.6/node/389960161
way_id  http://www.openstreetmap.org/api/0.6/way/34028339

relation_id
http://www.openstreetmap.org/api/0.6/relation/125519

IDs are unique only for nodes/ways/relations but not across the elements. I
do not think that renaming osm_id into relation_id (and probably osm_id of
points into node_id, or?) and osm_way_id into way_id to follow the native
model would make things very much more clear.

-Jukka Rahkonen-

--
View this message in context: http://osgeo-org.1560.x6.nabble.com/gdal-dev-osm-id-vs-osm-way-id-tp5298287p5298304.html
Sent from the GDAL - Dev mailing list archive at Nabble.com.
_______________________________________________
gdal-dev mailing list
gdal-dev at lists.osgeo.org<mailto:gdal-dev at lists.osgeo.org>
http://lists.osgeo.org/mailman/listinfo/gdal-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20161202/5ebf723a/attachment-0001.html>