You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After taking a deeper dive, I realise that the section of code I was referring to here, in the original issue, is executed way after the ID problem arises.
When using
get_buildings()
, the resultingid
column (usually containing the way id etc) is overwritten with the tagid
when it's present.For example in Dorset, England there's a few cases where buildings have been tagged with
id: 123
.When you then load this data in using
get_buildings()
the way ID is overwritten with the tagOutput
As you can see, people have tagged the buildings with duplicate IDs and these have made their way into the dataframe.
I can see that keeping an id tag was an intentional choice made in the
get_osm_ways_and_relations
function ofdata_manager.pyx
: https://github.com/HTenkanen/pyrosm/blob/66de74bd0496d1148618842cac58923bf22d97ea/pyrosm/data_manager.pyx#L104C1-L107C63.I was wondering whether this was the expected behaviour? As this makes it challenging to guarantee the ID is unique and from the correct OSM source.
Environment:
The text was updated successfully, but these errors were encountered: