How can I contribute with data fixes?

Avatar
Marko Schilde
  • updated
  • Answered

Hi there,

First of all thanks for the project, you're saving me a lot of time :-)

I'm currently trying to make sense of the data, using Germany as an example. For the most part the data is correct, but there are issues here or there. E.g. relation '310385' lists the relations  '-569767,-51529,-51477' as parents, but not the immediate administrative parent ('27026').


I'm not sure how to fix this. Is there a tag in OSM missing? Do I need to change the relation borders?

Replies 3
Avatar
0
Magnus

To us it's something that we needed to feed another site with polygon data for countries and two depths of "states". When building the site for ourselves we also decided to make it public.

This specific case is not something we will fix. It would be against our whole design. As we use OSM-Boundaries ourselves is that we have a rule-set in the other end of how different areas are defined, it then fetches what it needs are transforms that into a result. In some cases that includes intersecting or subtracting polygons as well.

Avatar
0
Marko Schilde

Aah, I see, thanks for the quick reply.

Are you generally interested in fixing this, i.e. in country specific contributions? Or is this more of a fun project based on OSM data mining?

E.g. in my case I'll probably fix this by joining via "gemeindeschluessel", which seems to be tagged consistently and is the German version of the LAU classification.

Avatar
0
Magnus
  • Answered

Hi.

The reason that -310385 (Grebin) isn't sorted under -27026 (Plön) is due to how we build the relation tree. For each (administrative boundary) polygon in Openstreetmap we look for the smallest (administrative boundary) polygon with a higher level (lower number) that the polygon fits inside (with some minor tolerance).


Grebin fits inside Großer Plöner See, which doesn't fit in Plön. Therefore Grebin isn't sorted where you expect it to be. So the issue here is that Großer Plöner See doesn't really match the hierarki of administrative boundaries, since it spans more than one of those being of lower level number.

This might actually be the first case I see where our algorithm doesn't work as one would expect. But I think it's safe to assume there are plenty of cases like this. Not the least when looking at polygons with higher number for administrative level.

The data we show is as is from Openstreetmap. There is nothing that can be fixed in our data except changing our whole concept. Changes to specific polygons/boundaries can't be made. If Großer Plöner See actually should exist as an administrative boundary there is no real fix. If that boundary shouldn't exist, the fix is to remove it, or at least remove tags that makes it appear as an administrative boundary.

If that relation should be an administrative boundary or not is out of our knowledge. It requires knowledge of both Germany and much deeper knowledge or Openstreetmap than we have. To be honest, we are not following OSM very  much. We just fetch the data and transform it into what you see.

Sorry that I couldn't give you a better way to fix things.

// Magnus


Customer support portal powered by UserEcho