[Imports] Belgium address import

Sander Deryckere sanderd17 at gmail.com
Sat Oct 4 11:49:06 UTC 2014

I think it's time to get it going again. We have such a nice and precise DB
and are not using it at all.

Reading this discussion, I propose to


- Put address on buildings when it's clear enough. F.e. in the case of
separated residential buildings with one street next to it (like
http://osm.org/#map=19/50.96196/3.10456), or row-buildings with clearly
separated roofs (like http://osm.org/#map=19/50.94060/3.06118)
- When there are multiple buildings belonging to one address (like in farms
or industrial sites), with only one road leading to it or passing next to
it, the site should be mapped with a housenumber.

- Put addresses on nodes in the other cases, so:
** When it's not clear which street leads to the entrance (f.e. nr 122 here
http://osm.org/#map=19/50.96482/3.10321 is not accessible from the western
street, only from the eastern street). In this case, put the address node
on the building (or site) outline, near the entrance.
** When there is no building, or it cannot be traced. Sometimes, parcels
also get an address when there is no building present yet, or the building
is in the woods and can't be traced. In this case, the address node should
go on the best known position.
** When there are multiple addresses belonging to one building. It might be
possible there's a shop on the ground floor, and some apartments on higher
levels. They normally have a different front door, often different
addresses, but are in the same building. the mapper should try to estimate
the position of the door and map the address nodes as good as possible on
the common building outline. This should also be done when it's not clear
where the separation between two buildings is.

As a tag on a building is generally easier to map and to maintain (one less
node used, not necessary to map the front door position), that's why I
propose to map the building outlines in the simple cases. But the more
advanced cases will need nodes to guide routers via the right way.

Since data users need to be able to work with both anyway, I don't expect
that this mixed approach is a problem.


I think we do want some conformity in this case. Since working with
relations is indeed still hard, I'd propose we go with addr:streetname
tags. There's not a lot of difference between looking up object ids
(through relationship members) or looking up tags that should have the same
value (like name and addr:streetname tags). Both are XML attributes and can
be easily processed by data users. When working with JOSM, you have the
good search function available to select all buildings of the same street
at once (if they are tagged with the same addr:street tag). So I think the
addr:streetname tag costs as much effort as the associatedstreet relation
in JOSM, and the addr:street tag is easier in other editors.

There's no need to tag the city or postal code as all municipality
boundaries of Belgium are drawn, and the postal codes are normally bound to
the municipality boundaries (sometimes to part municipalities, but there's
always a clear boundary). There are only 3 exeptions to this: the NATO, VRT
and RTBF get their own postal code as an organisation. But these will be
easy to handle separately.


Abbreviations normally only happen with names (where the initials are used
instead of the full first name), with titles (Sint, Burgemeester,
Monseigneur, ...) and the abbreviation O.L.V  or O.L. Vrouw for
Onze-Lieve-Vrouw.. Sometimes it's very hard to find where the abbreviation
is deduced from (you have to look in library archives to find references to
the person, and even then it could result in different spellings), but in
most cases, a quick Google search will find the correct one, as it's
normally about rather famous persons (mayors, priests, artists, ...). But
since most of these abbreviations are impossible to expand algorithmically,
it's something for the mapper to do while importing. Suffixes like straat,
laan, weg, ... are very seldom abbreviated on street signs, and are also
seldom abbreviated in databases or streetname lists. I don't expect CRAB to
abbreviate any of those.

Since the DB will be used more as a mapping aid (like Bing imagery) than a
direct import, I think it's fine to just update the data (given that data
of a year old will be outdated in parts), and get going.


2013-11-25 13:24 GMT+01:00 Pieren <pieren3 at gmail.com>:

> In France, we "import" addresses since ~2010. I can provide some feedbacks
> here:
> - "address on building vs node" : we see two camps here although a
> majority seems to agree that on densified urban zones, the node model
> is better because it is easier for multiple addresses on the same
> building and your routing software will be more accurate even if the
> node is not "exactly" at the entrance point. Think that "one address
> per building" and "one building per address" is not valid in many,
> many cases.
> - "proliferation of address schemes" : I know only 2 models, the one
> with all "addr:" tags repeated on the element and the one with the
> relation "associatedStreet". Again, we have two camps in France,
> irreconcilable this time, where some contributors prefer the relation.
> I made recently some stats in France and it seems that both models are
> co-existing (~50-50%) and in some rare places, there are even both
> used together (mainly because some applications don't recognize the
> relation "associatedStreet"). I will not argue for one model or the
> other since both have advantages and disadvantages, as usual in OSM. I
> personnally stoped worrying about this since both can work and it's
> even possible to swap from one model to the other. But what I like is
> that contributors have the choice. Nobody should be "enforced" to
> adopt one scheme. Sounds scary in the OSM environment. Where we have a
> consensus is to not duplicate some tags like "addr:country" or
> "addr:city". The postcode is another subject and is probably a more
> country specific subject (in some areas, the postcode is related to an
> administrative boundary, sometimes it's completely unrelated or hard
> to define by polygons, etc). Postcode will probably need a better
> standardization in OSM in the future but today, we accept to duplicate
> it when it's not possible to define it in the admin boundary.
> - "addresses before buildings" : it sounds easier to add addresses on
> buildings than the opposite but is it really true ? I cannot see who
> is enough authoritative in OSM to decide mapping priorities. Some
> people like to see their bicycle path first because they use OSM for
> their bike routes. Other people are fully concentrated on mapping
> power lines first, before roads, before landuse's. Why not. Who am I
> to decide what has to be mapped first ?
> - "address is a feature or an attribut" : the question was already
> raised in the past without a clear answer. It seems that many people -
> or even applications - do not
>  care about addresses as a feature and they like to duplicate the same
> address on all the POI they add into the same building. So when I read
> that conflation should avoid duplicates, I'm unconvinced because
> duplicates will come back later, anyway.
> - it was not mentionned here but OSMI is providing a nice QA tool for
> addresses ([1]).
> Pieren
> [1]
> http://tools.geofabrik.de/osmi/?view=addresses&lon=2.36419&lat=48.85332&zoom=16&opacity=0.58&overlays=buildings,buildings_with_addresses,postal_code,nodes_with_addresses_defined,nodes_with_addresses_interpolated,no_addr_street,street_not_found,interpolation,interpolation_errors,connection_lines,nearest_points,nearest_roads
> _______________________________________________
> Imports mailing list
> Imports at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/imports
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/imports/attachments/20141004/74dc08bc/attachment-0001.html>

More information about the Imports mailing list