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 NODES OR OUTLINES - 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. TAG OR RELATION 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 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. Regards, Sander 2013-11-25 13:24 GMT+01:00 Pieren <pier...@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@openstreetmap.org > https://lists.openstreetmap.org/listinfo/imports >
_______________________________________________ Imports mailing list Imports@openstreetmap.org https://lists.openstreetmap.org/listinfo/imports
