This blog post is part of a series of blog posts about the new OSM file format “OMA”. This is the seventh post. At the end of the article you’ll find links to the other blog entries.
To create and use blocks and slices, you need to know the type of an element - is it a highway
, a landuse
or a barrier
. And if it is a highway, is it a primary
, a secondary
or a footway
.
Keys
Apart from relations where the type
key stores it, this information is not available within OSM data. Again, it has to be guessed, and there is much discussion on the forums and elsewhere about the “main keys”, as they are sometimes called. Several apps, such as most OSM editors, contain such a list, but the lists are not always the same.
The approach I took was this: I counted all the keys of all the tags of all the elements and took the one that appeared most often in this list. I considered this the first main key and removed all elements with this key from the set of elements. Then I repeated this process.
After a while some “dirt” remains: elements that do not show a clear “main key”. I think if you start digging around in that dirt, you might find some hidden gems, that is, main keys that aren’t used very often, because the items they represent do not exist very often in the real world. But I didn’t.
I repeated this process twice,1 once for nodes and once for ways. You have to keep an open mind, because sometimes the top key is clearly not a “main key”, for example name
pops up after a while. Addresses needed some special treatment, because there is no address
key. Addresses are stored as a collection of addr:*
keys. Fortunately the addr:housenumber
is almost always present, so I used that as the key for addresses.2