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.rahko...@maanmittauslaitos.fi<mailto:jukka.rahko...@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@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org>
http://lists.osgeo.org/mailman/listinfo/gdal-dev
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Reply via email to