OpenStreetMap logo OpenStreetMap

I love to get in touch with nearby mappers and talk about conventions, how they solve typical Belgian mapping issues. In case I've added you as a friend, well I know we aren't friends (yet) but I would love to discuss and share ideas, especially map editing.

I'm also interested in analyzing the nature of the participation of individuals for a case study (trying to put OSM data ahead of commercial vendors). I have a feeling that Belgians are way behind in their open initiative. I would expect a lot more mappers in the area.

Professionally, I am the principle designer/programmer of a commercial track and trace system. We've been playing with OSM data since the early days when Belgium was nothing but a green triangle. We currently depend heavily on OSM nominatim reverse geocoding use of OSM data and have noticed serious shortcomings in terms of postal code data for Belgium. I also want to hear other opinions about that (reasons why for example). So we are very much keen on getting clean address data into OSM.

Give me a shout if you feel you have a thing or two to share ;-)

Location: Kleine Linde, Zemst, Halle-Vilvoorde, Flemish Brabant, Flanders, 1980, Belgium
Email icon Bluesky Icon Facebook Icon LinkedIn Icon Mastodon Icon Telegram Icon X Icon

Discussion

Comment from Stijn De Wachter on 21 August 2011 at 14:49

Haha, I lived in Weerde but I moved past month. To bad.

Comment from Sanderd17 on 21 August 2011 at 18:34

Belgium is indeed a bit behind. Germany just has good quality (as we all know), the OSM project started in the UK, The Netherlands got all road data from AND (which was a kickstart) and in France they can use the cadastre for buildings and boundaries (which also speeds up the editing quite a lot).

So I believe we're a bit behind because we do it all ourselves, and we ain't Germany :-D.

I live in Oostnieuwkerke (West Flanders) and I also have a list of nearby, active mappers (if you want them, I can pm them, but I don't want to put them online like this).

What do you think about the addresses in ONK? They are not quite complete, but I'm getting close.

Could you tell us some more about your track and trace system. Would you/your employer be willing to open-source certain parts?

Comment from Glenn Plas on 24 August 2011 at 08:55

Hi both!

The devices we are using are coming from http://www.trace.me/index.asp?page=product&item=powersupply&sub=hardware. It's a dutch manufacturer who has taken the professional market in a storm. They are absolutely ace. The data comes in over GPRS/EDGE of course. I'm not sure that going the open source way would benefit OSM. I do have lots of tracking data I can easily anonymise as the only reference is the device's Imei number.

I'am writing a 'light' version of what we call the 'socket server' which stores all incoming data. They are not cheap however but they are supported with open code. (not open source I guess since it's lacking licenses. See here for the capabilities of those tracers: http://qontrol-vision.com/CGPSBETA/cgpsinfo.php

You can check a development map of mine here: http://trackme.byte-consult.be/g.html

It's my own car I'm experimenting with. Notice the accuracy of this device, it CAN but doesn't have to be used with timers, it checks the direction changes, distances. I've seen like 5 different devices, all kinda sucked until we found this supplier. Currently we have about 2500 running in the field.

It's all implemented in PHP since that was the only available Class about 5 years ago when we started out. No ideally but we have no performance issues due to PHP. I'm implementing a SQLITE backend which totally rocks. Having Mysql as a backend was a very bad idea since it didn't scale at all when we needed it. Hence we use MariaDB now.

Thanks for the comments.

Comment from Glenn Plas on 24 August 2011 at 08:55

By the way, what is ONK ? I failed to google anything :)

Comment from Sanderd17 on 24 August 2011 at 10:42

ONK is short for Oostnieuwkerke.

Btw, nice things you have done. But I don't really understand what problems you have with the postal codes. Are they tagged wrong, can you give examples of cities that have right tagging for your purpose and cities that don't have right tagging. I didn't think it would be that difficult, since the postal codes are all available on various sites. They are easy to find via wikipedia or even with a google scraper if you want. (I don't know how legal it is, but I think you'll be OK if you get it from sites of restaurants etc)

Since you are a coder, could you make a layer, or a patch for the keep-right website to show us what cities or villages that need other tagging?

Comment from Glenn Plas on 24 August 2011 at 11:19

Have you tried building a gazetteer service ? Allmost reverse geocodings end up without a postal code in the resultset.

My patchwork solves that outside the OSM realm

http://gazzy.byte-consult.be/reverse.php?format=json&lat=51.06878&lon=4.45820&zoom=12&[email protected]&maxareadistance=2&addressdetails=0&accept-language=http://gazzy.byte-consult.be/reverse.php?format=json&lat=51.06878&lon=4.45820&zoom=19&[email protected]&maxareadistance=2&addressdetails=1&accept-language=nl,fr,en-gb;q=0.8,en;q=0.7

If you follow the gazetteer installation instructions as-is you don't get the same result from the OSM run nominatim service. So I assume they have other database sources.

A good example of badly tagged cities WAS 'Tongeren' It had the standard and the french name set but not the :nl one. So in the resultset with language preferences set to prefer dutch first, then french and if all else fails you get the plain name tag back.

See osm.org/browse/changeset/8920543

It DOES give you back the city name wich I use to translate the postal code but obviously there are many dubious names in our little country which makes that not as easy as one would think.

So in essence, the big question is why does my own nominatim installations (I do those with my eyes closed after 20 times now ;-) fail to return a postal code.

Scraping is out of the question as Google's data is full of easter eggs (I found 5 already in Belgium).

I ended up writing a PHP class just to see how different those results are among the top 5 players.

https://github.com/gplv2/PHP-GeoRev-Class

The development version is different in the nominatim service implementation, the master branch is written against the standard nominatim service, the former is written against my own solution.

I've made a list of postal codes coming from different data sources. (De Post) But OSM data is filled with Village/Town names that share a postal code with another city so you have a 1 to m relation. I use proximity to solve that but as you can see here:

http://gazzy.byte-consult.be/postcode.php?format=json&full=true&sort=city&place=Antwerpen&accept-language=nl,en;q=0.8,fr;q=0.5

Big cities have many codes and they are all very close to eachother so that solution won't work perfectly.

Also the other way around

http://gazzy.byte-consult.be/postcode.php?format=json&full=true&sort=city&postcode=1982&accept-language=nl,en;q=0.8,fr;q=0.5

Also returns 2 results. So which one is it?

I think by now I probably have the most complete database of cities/postal codes mappings in Belgium. Since I manually include failed geocodings I encounter in the logs.

I just don't know enough about the inner workings of gazetteer to fully understand where that problem occurs.

Thanks for discussing this!

Comment from Glenn Plas on 24 August 2011 at 11:26

By the way, Bing has the same issue. I noticed that when you revgeocode coordinates in a city that could potentially returns more than 1 hit for the cityname, they just drop the postal code from the resultset. That's why I have that postal code service up and running to complete Bing data when I need it. Not always but I saw a nice corolation between my own problems and Bing's results

Comment from Glenn Plas on 24 August 2011 at 11:32

Mmm... I actually found this while viewing that changeset concerning Tongeren. There are OpenGeoDB tags in there that got my attention.

osm.wiki/OpenGeoDB

I think this is the alternative datasource I intuitively suspected to exist.

Log in to leave a comment