Lately, for some reason, I’ve been interested in mapping the “addr:neighbourhood” tag, which I use to represent Indonesia’s RT-RW addressing system.
To me, the RT-RW system is both ubiquitous and mysterious at the same time.
I use it every day whenever I want to send or receive an address, yet all this time, I haven’t even known where to find the official map showing the boundaries between neighbouring RT-RW areas.
Rumour has it that government officials might have access to such elusive maps. Perhaps people working in the logistics industry do, too. But personally, I want to unravel this mystery by myself as a personal pastime project.
In the city where I live, we use this kind of hierarchical addressing system, starting from province → city → kecamatan → kelurahan → RW → RT.
All those fields are text, except the last two (RT/RW), which are numbers, sometimes written in different formats.
Sometimes people write them as RT 01/32 (meaning RT 01 + RW 32). Sometimes it’s RT 01 RW 32. Sometimes it’s RT 003/032 (where all RT/RW numbers are forced to use three digits).
Because those RT/RW numbers are only unique within a kelurahan, people sometimes write them as kelurahanName RT 003/032, or, more elegantly, kelurahanName 003/032.
Sadly, kelurahan names are not globally unique (the same name might exist in different cities or provinces), so this format quickly becomes meaningless outside its immediate context. To make it consistent and unique, I think it should be written as provinceName, cityName, kecamatanName, kelurahanName 003/032. But nobody writes it like this because it’s too cumbersome.
In the end, most people stick to the “two-number system” (one number for RT and another for RW). They put those two numbers at the end of the address string, especially after specifying the higher-level hierarchy (province / city / kecamatan / kelurahan).
But there’s one more caveat. People don’t usually write addresses from the “highest hierarchy” to the “lowest hierarchy”. They usually write them from the very bottom: street name → house number → RT/RW code → kelurahan → kecamatan → city → province → postcode.
Even this format, however, is biased towards my own city. In other regions, this scheme doesn’t work at all because there are plenty of exceptions. For example, instead of kelurahan, there is desa. Other regions have their own region-specific administrative hierarchies. I guess that, in some regions, the RT-RW system might not exist at all.
Personally, though, I like to write it in the RT 003/033 format : mandatory three-digit numbers, separated by a slash, with a simple RT identifier at the beginning. I like it because it looks elegant enough.
Of course, this piece of information is still incomplete as a representation of an entire address. It still needs the rest of the higher-level hierarchy: the kelurahan–kecamatan–city–province quadruplet. But by combining those two parts, I think we get something elegant enough:
Province X, City Z, Kecamatan D, Kelurahan A + RT 001/023
Well, that’s just my opinion.
So, I want to hear what other OSM mappers think about this tag.
I ran a QLever query to retrieve 1,000 OSM objects containing the addr:neighbourhood tag (in Indonesia).
Then I picked several samples to represent the diversity of RT-RW writing formats.
I also checked the OSM users who preferred each format, when they added that format, the areas where they focused their mapping activities, and when they last mapped.
Here we go.
Quite a diverse variety, isn’t it?
Form C is interesting because it includes the kelurahan name in the RT/RW field.
Meanwhile, the rest agree on including both numbers. However, they disagree on (1) how many digits each number should have and (2) how the numbers should be written: just numbers, slash-separated numbers, or numbers with RT and RW prefixes.
But should we enforce “the one and only correct format” in OSM?
Should we mass-edit everything to conform to a “standardised format”, then start enforcing this “law” on every OSM mapper and harshly reprimanding them in changeset comments whenever they use a “wrong, illegal format”?
Now, this is where the can of worms begins.
This is where lifelong conflicts and vengeance can arise in OSM mapping.
And it’s not limited to this specific tag. I guess other “differences of opinion” about other tags could lead to similar conflicts. I mean, I’ve already seen conflicts arising from similar issues myself.
Ideally, everyone would converge organically on the most popular format, without force or drama. Then, apps that rely on OSM data would start recognising that “most popular format” and consuming the data properly. This would create an instant feedback effect : more people would adopt the format because it is “properly rendered in many apps”.
However, since OSM uses the wiki model as its main mode of operation, things can get nasty.
In this wiki system, at any given time, only a single version of the “truth” exists. You write a tag value, and someone changes it to a different format. The currently active tag value is considered “the right one” (at that moment), while every overridden value in the past is considered “the wrong one”.
Well, you can revert the tag to switch it back, but that will surely make things even nastier.
This wiki model sometimes turns great potential into a painful experience. Imagine thinking, “Oh, all my hard work has been destroyed by someone else. Not only that, they even mocked me in the changeset comments and continued to mock and harass me by contacting me through my other social media accounts.”
All because this wiki system can hold only one version of the “truth” at any given time. Deleted contributions are considered “false”. Edited contributions, now buried in the changeset history instead of appearing in the current list of tags, are considered “false”.
One day, I came across a lengthy edit war on OSM. It simply wouldn’t end. One of the participants figuratively said, “I will change your tag to my tag, and I will accept no concessions at all. Go on, change it. I will change it again, and I won’t stop changing.”
In the meantime, we could look at this issue from a completely different perspective.
A group of people, all of whom care enough to map a specific aspect of the world, have somehow gathered in this particular corner of the internet. Instead of building lifelong resentment and hostility over “small differences” like “my tag is better than your tag”, they should bond over their shared love of mapping that specific aspect of the world. I think that would be much more beautiful. After all, not everyone cares enough to map that particular aspect of the world.