Sometimes we find in some cities/countries some boundary ways (the ones that define the political borders of provinces/towns/countries) that are missing some tag(not appearing already in the relations, because it’s better to avoid redundant data.

Example of boundary way without any tag:

For the renders and 3rd party apps that is not a big problem because that way is indide the the corresponding relations with different admin_level, it can be shared by one or many relations, but what happens if we need to add a tag to those ways based on the data from their relations?

The script is the following, based on Dmitri Lebedev’s osm2python library (not python3 compatible yet, help migrating).

# -*- coding: utf-8 -*-
# Use python2, since osm2python is not ported to python3

from osm2python.tree import load, dump
from collections import defaultdict

origin_osm_filename = 'boundaries.osm'
destiny_osm_filename = 'boundaries_updated.osm'

# loading the .osm file
osmtree = load(open(origin_osm_filename))

ways_min_admin_levels = defaultdict(int)
for i, r in osmtree.relations.items():
    if 'admin_level' in r.tags:
        admin_level = int(r.tags['admin_level'])
    else:
        print(r, 'has no admin_level')

    for way in r.members:
        if ways_min_admin_levels[way.ref] == 0 or ways_min_admin_levels[way.ref] > admin_level:
            ways_min_admin_levels[way.ref] = admin_level

for i, w in osmtree.ways.items():
    w.tags['admin_level'] = str(ways_min_admin_levels[i])

# Saving to .osm
dump(open(destiny_osm_filename, 'w'), osmtree)

The result example looks like this: As you can see the way now has admin_level=5 which is the minimum level of all the boundary relations that way is inside of.

After some comments below, I realized that adding redundant data in OSM is not a good practice so better to use the script for other cases.

I hope it is helpful for you and you can hack it to do more things than needed.

After few days of working with the quality assurance of the original OSM data extracted I finally finished the python script that generates the administrative boundary relations from level 5 to level 9

All the .osm files(original and results) can be downloaded here to check them out.

Here are the statistics and screenshots:

• Original ways: 7717 (between level 8 and some level 9)
• (after conversion) Splitted ways/segments: 21627

admin_level=9(in Indonesia: RT) 5006

admin_level=8 (RW) Total: 2708

admin_level=7 (Desa) Total: 263

admin_level=6 (Kecamatan) Total: 44

admin_level=5 (Kabupaten) Total: 5

The script takes all the ways from the OSM file and detects the intersections with other ways in order to split them into small segments(some segments will belong to different administrative boundaries).

It’s important that if you want to use the script to convert the boundaries into OSM format, take a good look at it, understand it, and ask for help if there is something that doesn’t understand. The script can be found here: create_administrative_boundaries.py. I added enough comments, you can use github to send feedback too.

The script is specific for the current data from Jakarta, it would be very hard or hardly impossible to make a universal script that can work with any data, therefore it’s better to understand it and modify it for your needs. You can also send me a private message or email at capiscuas AT gmail DOT com if you want help with some boundaries conversion.

During the creation of the script, many warnings or errors appeared when the data had some gaps or duplicates, for example some level9 or level8 names were missing, or had some typos, or some ways had the wrong level5(For example I found a small part of Central Jakarta inside East Jakarta boundary.

You will also see in the original file I had to add some auxiliary ways in the external(outter) parts of the region in order to force the splits(for those nodes shared by more than 3 ways which didn’t happen at the external part).

The HOT Indonesia data regarding flood management has been saved also in the relations, if that is not needed anymore, it can be easily removed later on with JOSM from the database.

I would like interested people in the area to give some feedback before importing all the generated relations and remove the current ways from OSM.

Things to do: -Simplify all the ways(some ways have many nearby nodes with similar angle). -After uploading the new boundaries I will join the external ways with with the neighbouring level4 areas.

After having announced in the Indonesia and Imports mailing list about my intentions of fixing the current administrative boundaries in Jakarta, capital of Indonesia.

So the first I did was to download the boundary:administrative ways in Jakarta area, by using the following Overpass API rule while downloading in JOSM.

(way["boundary"="administrative"];node(w); way(bn);); out meta;

Total boundary:administrative ways: 7809 of admin_level = 9 ways = 5082 of admin_level = 8 ways = 2717

I analyze the data and soon realize that there is a lot of overlapping ways, unjoined nodes with similar coordinates, and some areas that contain ways of admin_level=9 doesn’t have the father way of admin_level=8

I have prepared an script to take the highest admin_level ways, split their ways into segments and create as many boundary relations hierarchically as possible, for example, in this case, I can create the boundary relation of admin_level=8 by using the external borders of those relations with admin_level=9, and so on for the admin_level=7, etc… I will explain this algorithm in the next post when I release the script to the public.

My first task was to prepare the data(offline) before creating those relations. Therefore I had to deal with those duplicated nodes with exact same coordinates.

By using the following python script join_duplicated_nodes.py I eliminated the duplicity and joined all the duplicated nodes at once. (this task is equivalent to selecting one by one each of the nodes and clicking the ‘Merge nodes’ tool of JOSM), but you don’t want to waste that much time with 77657 nodes.

After executing the script, the total of nodes become 74936, so it joined almost 2700 nodes and we reduced the size of the OSM file a bit.

The second task was to get rid of those ways of admin_level=8 that overlap over those ways of admin_level=9 inside. In order to find out these duplicates, I made another python script(see detect_redundant_ways.py) but this time customized for the Indonesian boundary tags(you can change them to fit for your country or area context, you just need to understand the script).

Here is the result(the blue areas are those redundant level-8 ways that can be deleted in our local OSM to be ignored later on when creating the final boundary relations).

Keep tuned for the next post with the final conversion to boundary relations. Feedback wanted!

Hi everybody, apa kabar?, this is my first post in OpenStreetMap so I’m quite excited.

My name is Ivan Garcia and I’ve been contributing to OSM since many years now, I am currently living in Yogyakarta Indonesia where I do digital volunteering for various projects. I am an opensource python programmer and I love useful is OSM for the world, no wonder we all feel contributing back to the community when we have free time.

I realized that HOT Indonesia contributed adding most of the administrative boundaries of the Jakarta province in order to make a program for disaster management(flood related), my thumbs up for that team and their tremendous efforts, here is their blog

I see those boundaries have an obsolete OSM format to represent the boundaries, that is, still using the obsolete is_in tags, instead of the new boundary relations.

You can take a look at here:

https://www.openstreetmap.org/#map=17/-6.172219373575377/106.8088689627239 Boundary RW03 duplicates way with RW06

![Boundary RW06 duplicates way with RW03] (http://imagizer.imageshack.com/img910/4026/XEHwJ6.png) Boundary RW06 duplicates way with RW03

You can see that many ways are overlapped(duplicacy). My goal is to transform all those boundary ways(hundreds of them) into OSM relations by respecting all the current tags that HOT may be using for their disaster program: (OBJECT_ID, flood_prone)

I am preparing a python script that will generate automagically all those boundaries relations by going trough each of the nodes of the current boundary ways, detect what ways are overlapped, and if necessary, and create new relations for the relations:

(See Indonesia tagging conversions) https://wiki.openstreetmap.org/wiki/WikiProject_Indonesia#Tagging_convention

• admin_level=5 - City / Regency (Kotamadya / Kabupaten)
• admin_level=6 - Subdistrict (Kecamatan)
• admin_level=7 - Village (Kelurahan / Desa)
• admin_level=8 - Community Group (Rukun Warga)
• admin_level=9 - Neighborhood Unit (Rukun Tetangga)

Although this is not really an import but a bulk transformation of the OSM data that is already in the database, I am following the OSM Import procedure, I am informing the Indonesian mailing list as well as the Import mailing list for review and feedback.

Please comment here in the post.

Thanks.

Ivan.