A lot of data is missing for Germany
Good evening!
For Germany, many and significantly important data have been missing for several weeks! This is the case as of the data slice of 07.08.2023.
Thank you.
Sven
Pinned replies
Replies 24
Then use another database. We serve data as is in OSM. If the data is broken in OSM it's broken in our end as well. We do not spend any time to try to fix it, that would be financially impossible for us.
OSM always has broken boundary polygons somewhere, that's why there are several databases served.
See Multiple databases under https://osm-boundaries.com/Documentation .
Yes, definitely, there is a bug!
I constantly and regularly monitor possible broken borders. I repair them promptly if I can. 99.9% of the time I can! The OSM inspector (https://www.openstreetmap.org/relation/62504 has not been broken for years! It's the same with other federal states!!! ...for Germany the vast majority of borders are missing!!! You have to do something, the current state is not sustainable! Sven">https://tools.geofabrik.de/osmi/?view=areas&lon=13.18608&lat=52.07960&zoom=9&baselayer=Geofabrik%20Standard&overlays=duplicate_node%2Csingle_node_in_way%2Cduplicate_segment%2Cway_in_multiple_rings%2Cintersection%2Cintersecting_segments%2Cring_not_closed%2Ctouching_rings%2Crole_should_be_inner%2Crole_should_be_outer%2Cinner_with_same_tags%2Cways) shows broken geometries. The border of Brandenburg https://www.openstreetmap.org/relation/62504 has not been broken for many years! It's the same with other federal states!!!
...for Germany the overwhelming majority of borders have been missing for many months!!! The current state of affairs is untenable!You have to do something about it!
Sven
See: https://community.openstreetmap.org/t/osm-boundaries-hangt/104934/4
...Another explanation: here in Germany, especially here in Brandenburg, we have the best and ideal conditions for OSM to use, for example, data on administrative boundaries! This also applies to a great deal of other data!
It is therefore good and appropriate to re-record detailed boundaries.
Sven
I apologize for the short answer. But since you didn't provide an example of a relation ID that was missing it was hard to help.
You mention relation https://www.openstreetmap.org/relation/62504 and database osm20230807. That relation does exist, however it's not listed under Germany. It's listed under Federal Republic of Germany (land mass).
Right now I am unsure why that Federal Republic ... isn't listed under Germany itself. It's either because OSM-Boundaries always keeps admin-level 2 in the root of the tree, or because it doesn't fit within Germany (which it sounds like it should). That's something I can try to look up.
I am however still convinced that the site is doing what it should in this case. It shows the data as it is in that OSM dump. It sorts the data and creates the tree according to the rules it has been given.
Ah right. When building the tree there are several rules. One of them is that a child must have an admin_level that's higher than its parent. Therefore the Federal land mass polygon (admin level 2) can't be a child of Germany (also admin level 2).
So it's working as intended. The big question is, should this new big polygon even exist in OSM, and should it really be tagged like it is? Or should OSM-Boundaries adapt somehow.
If the later, I don't know how to adapt in a practical way. This is an anomaly which doesn't exist anywhere else in the world. Hard coding exceptions and maintaining those aren't really in our plans. Our goal is to present the OSM data in a more practical way, but we also depend on the OSM data to be logical and consistent.
The data status of 3.7.2023 is correct and complete.
As of the data status of 7.8.2023, the predominant borders are missing.
It is always assumed that https://www.openstreetmap.org/relation/51477 is admin_level=2, for all data...
The border https://www.openstreetmap.org/relation/62781 is only land mass, but that does not appear in your data... nor should it: see note=* for this relation.
Is it possible that the diffs were broken at some point? I once observed this at https://www.knooppuntnet.nl/ and got this hint.
Sven
I still don't understand what you want us to do. What is the exact issue? You said data is missing but I haven't been able to see any missing data. Can you give a specific example?
You also just said this:
The border https://www.openstreetmap.org/relation/62781 is only land mass, but that does not appear in your data... nor should it: see note=* for this relation.
This does appear in the data, I was looking at it yesterday when I wrote the post about it. See screenshot. The note the polygon has is irrelevant. We don't parse that tag, and even less try to read and interpret them. We import data as it is, sort it according to our rules, and serve the data.
Also the site doesn't work with any diffs. Every database is a complete import of a planet.osm, generally the first created by OSM every month.
...and "Germany" 8 lines down?
This is the relation https://www.openstreetmap.org/relation/51477 should be the real start for admin_level=2.
The relation https://www.openstreetmap.org/relation/62781 clearly states:
note=this is not a boundary for Germany, only its land_area (see http://wiki.openstreetmap.org/wiki/Relation:boundary)
No one can see through what is being done here!
That's not the design of the site. I tried to explain the rules used when importing. There is no manual steps, no hand crafting, no repairing, no manipulating. We import data as is, and display it as it turns out. It's not in our scope to maintain the hierarchy for a million polygons manually.
What might happen in the future is that there might be multiple versions of the tree. For example there could be a tree that uses boundary=administrative only.
But our standpoint is still that the site does what it should and that the data in OSM is wrong. Other countries does not have a polygon like the Federal land mass only. This is the polygon that ruins things for you, by sorting things in a way you do not expect, or want.
If you have a suggestion for a solution, feel free to present it. We don't see any solution that's within the scope of the site. But easiest solution in my opinion is to just remove the admin level of that polygon.
Then use another database. We serve data as is in OSM. If the data is broken in OSM it's broken in our end as well. We do not spend any time to try to fix it, that would be financially impossible for us.
OSM always has broken boundary polygons somewhere, that's why there are several databases served.
See Multiple databases under https://osm-boundaries.com/Documentation .