André, your example is the postal code of the centre of a village. I'm talking about streets, especially streets at the border of the postal code area, close to the postal code node of the next village.
The Germans have those postal code area's. it's also mentioned on the Nominatim FAQ page [1]. So it is documented. Of course feel free to keep adding them to all individual address nodes or street segments. Wouldn't they laugh at us when we display the wrong postal_code at a SatNav ? :-) regards m [1] http://wiki.openstreetmap.org/wiki/Nominatim/FAQ#postal_codes On Fri, Dec 6, 2013 at 12:57 AM, André Pirard <a.pirard.pa...@gmail.com>wrote: > On Thu, Dec 5, 2013 at 9:25 PM, Marc Gemis <marc.ge...@gmail.com> wrote: > > Bart, > > I just added a postal_code boundary for 2840 Rumst. And yes, both the > Hondstraat and Steenweg op Waarloos now get the correct postal code: 2840. > They had 2550 (from Kontich) before. So postal_code boundaries are the > solution for my nominatim problems. > > regards > > On 2013-12-05 22:52, Marc Gemis wrote : > > Did the same (duplicate the admin relation, change into a postal-code > relation) for Bornem and there it works as well. Sas & Nattenhaasdonkstraat > now show the correct 2880 postal code. It took several minutes though > before all street segments were updated. > > Since in Belgium the postal code areas coincide with village borders, we > have to double them. This 1-to-1 mapping might not be the case in other > countries. When we use those postal code boundaries, we do not have to put > the postal code on streets or admin relations anymore. At least not for > applications that understand those boundaries. > > > I find bizarre to have to add such additional relations to villages to get > a correct postcode and to have to do it by guessing, without a written > specification explaining how to do. I'd say the proof that it's not > necessary is Dolembreux below and that if it doesn't work in other cases > the reason should be found rather than finding a workaround and concluding > that it's what has to be done. > Village Boundary Dolembreux, Sprimont, Liège, French Community, Wallonia, > 4140, Belgium <http://www.openstreetmap.org/relation/2792257> > > This said, I returned to Минск (Minsk, a big city) where I once saw things > like that. > > They of course use boundary > relations<http://www.openstreetmap.org/relation/59195>, > but with no subarea and a single name on some ways (interesting to know > that the borderline or Minsk is called Minsk), they have address type > relations <http://www.openstreetmap.org/relation/79847> that look a bit > like the German associatedStreet but they are different, they also have > postal_code relations <http://www.openstreetmap.org/relation/79847> but > look at what they contain, Автобусы г. > Минска<http://www.openstreetmap.org/relation/295203>(buses of City Minsk) > that seems done differently from elsewhere and a > strange route to me, etc. > > I compare with Moscow where I see no address nor postal_code relations, > but a strange street relation<http://www.openstreetmap.org/relation/85473>, > .. > > No wonder that Nominatim does not work if everybody is doing it their own > way. > > I think OSM is going crazy. Is all that really necessary? Why don't we > first try to have it work correctly as a routing (GPS) database? According > to my tests, it is unreliable, and Guy even added "they laugh at us". > > Cheers, > > André. > > > _______________________________________________ > Talk-be mailing list > Talk-be@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-be > >
_______________________________________________ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
