Dealing with tree hierarchy of non-administrative boundaries

Benjamin Bock

2 years ago
updated 11 months ago
Under review

Besides using the boundaries themselves, I use the data from the tree on the left.

My first comprehensive usage of OSMB was in Q1 2021, when mostly administrative boundaries were part of the dataset.

Now (and since quite a while), there are many others, e.g. region, religious_administration, etc..

While this is mostly nice, I have some issues now, so I'm asking the community how you're dealing with it.

So, there are e.g. "region" boundaries like Klagenfurt-Villach (-2754657), inside Austria/Carintia which I can simply skip and go directly to their children which are again administrative. So far all good.

There are however issues with e.g. some (mostly religious) boundaries which receive children which should be in another administrative boundary:

E.g. Province ecclésiastique de Lyon (-14059783) is in Metropolitain France and almost in Auvergne-Rhone-Alpes (-3792877) but not fully, there's a tiny extension in the center north. I understand why it's thus not inside but parallel, all fine.

However, the administrative boundaries which should (IMHO) end up in Auvergne-Rhone-Alpes (-3792877, administrative) end up in Province ecclésiastique de Lyon (-14059783, religious).

Finally the question itself:

Is there any way (in the UI, from the tree JSON data, ...) without using a complex Poly-in-Poly detection, to move the administrative sub-boundaries into their matching administrative boundary?

Visually speaking: I want children green icons preferably inside green-icon parents, not in red-icon siblings of the parent, see red arrows in the attached screenshot. Similarly (but not relevant for me), the religious Dioceses and Communities could be inside their specific parent (I wanted to show that with the yellow arrows but only later saw, that the yellow arrows are actually wrong because those children are NOT inside the region the arrows point to.

Replies 4

Newest first
Newest first Oldest first

Magnus

11 months ago

Quote from antoine riche

Thank you for this very helpful service, which I point to from my uMap tutorials. and get (non-tech) people to use when I train them to uMap.

My suggestion to this issue (although I have no idea how easy or difficult this would be to implement) would be, for each country, to produce one hierarchy for each value of the boundary tag. Thus the administrative hierarchy would match boundary=administrative, the religious hierarchy would match administrative=religious_administration, and so on.

The tag administrative=local_authority is slightly annoying, as these are generally below the "département" level (admin_level=6) though they may overlap two of them. There are probably similar cases, so maybe a compromise would be to produce the main hierarchy using boundary=administrative, then insert other boundaries within that hierarchy using the current algorithm.

Regards and thanks again for this useful service.

@antoine riche

Sounds like a very reasonable suggestion. At least for some of the values of the boundary tag. Since OSM allows any text string there could potentially be a lot of unique values.

We will at some point implement different hierarchies. When you see that this has been implemented and you don't see your suggestion there, feel free to remind us. At the point where we have implemented support for multiple trees it will hopefully be fairly easy to add yet another variation.

Reply Link

antoine riche

1 year ago

2 years ago

First of all, I appreciate that you provide this project as is and free. No need to excuse for your limited time investment or priorities - it's all fine.

I don't know if having the checkbox would be sufficient. If you just filter the non-administrative entries from the tree (and move the children up), it won't help, as e.g. "Departemental constituency of Rhône" (lvl 5, -7378) would become sibling of "Auvergne-Rhône-Alpes" (lvl 4, -3792877), but it should be its child.

Also, looking at the geojson data, the parent relationship seems to (currently) not contain -3792877:

{
  "osm_id": -7378,
  "name": "Departemental constituency of Rhône",
  "parents": "-14059783,-1403916,-2202162"}

I extracted the above with this command:

cat france.geojson | jq '.features[] | .properties | {osm_id, name, parents}'

So... basically, it sounds to like you want to maintain two completely separate hierarchies... which I think is neither worth the effort nor a all-fullfilling solution.

My initial idea was to just improve the creation of the existing hierarchy by adding priorities (or constraints) when building the hierarchy: if there are multiple candidates for parents of an object, instead of taking ANY parent which contains the current object, out of those having the same administrative level, take preferably one which has the same boundary type.

This way "Auvergne-Rhône-Alpes" (lvl 4, -3792877, administrative) would win over "Province ecclésiastique de Lyon" (lvl 4, -14059783, religious_administration) as parent candidate.

As a solution for myself, I think, I don't really need the hierarchy later in the process. I'll just throw out all non-administrative, thus having no parent for "Departemental constituency of Rhône" (lvl 5, -7378). Then I'll add all remaining (administrative) into Tile38 and if there is an event in this area, I do the point-in-poly and thus receive both "Auvergne-Rhône-Alpes" (lvl 4, -3792877, administrative) and "Departemental constituency of Rhône" (lvl 5, -7378) and show them ordered by there level. It's not necessary for my use case to know if the latter is a strict child of the former.

Regarding a possible solution which might not need multiple tree hierarchies nor PiP, maybe all parents could be added to the geojson data... not sure what side effects this would have for your underlying data structure, for the tree, etc.

2 years ago
Under review

From our perspective we know that this is, or at least can be, an issue. We haven't figured out the perfect solution to this, and honestly haven't spent too much time on it either. Note that the site was created to cover our own needs in another project, and therefore we haven't made it perfect in all other aspects.

The best idea we have this far is to have a checkbox for administrative-only (as the site originally was), or not (as it is now). Implementing this isn't super easy though, we have to make some fundamental changes for it. Though the code of the site isn't enormous, so it's doable.

There is a todo-list for the site and the third item is names Option to remove none administrative. The list is unordered though.

I didn't look into details of your example since I am actually not working right now, though I could keep myself away from answering. Does this sound like a solution that would help you, or should I study your example more careful?