logo separator

[mkgmap-dev] POI Adresses

From Bernhard Heibler bernhard at heibler.de on Thu Feb 26 19:07:11 GMT 2009

Hi Guys,

thanks for testing my stuff.
> Ah - and another one - i get an entry for a Junk Food shop which has no
> addr: tags - It becomes "33330, 33332, 33334, 33335 Guetersloh" which
> is a list of postcodes in this city ... (And a correctly escaped ü)
Yes this is indeed a bug. I should just ignore the postcode if there is 
a list.

>> I have tested the latest version of patch from Bernhard Heibler.  I
>> can see, that as far as the data is correct, the patch works fine with
>> my etrex and should be merged to the trunk possibly soon.  I do not
>> know what to think about --location-autofill option.  The missing data
>> should be corrected at the source and not heuristicly patched in
>> mkgmap.  For this purpose a tool for listing POIs with incomplete
>> addresses could be created.  I would like to have the default
>> behaviour of --pois-addresses flipped.  I mean add the addresses
>>     
>
> I second this - Make pois-addresses the default - remove heuristics 
> until explicitly asked for and remove the "Fix My Address" fill string
> if there is nothing. 
>
>   
I also don't like the auto filling that much. Problem is that with the 
current osm data most location will end up in the default country / 
region since is_in tagging is rare for hamlets in Germany. This will 
make it difficult to distinguish between hamlets with same name in the 
city list. And in most other countries situation is even worse. I don't 
have a problem to disable the heuristic by default as long as there is a 
switch to enable it ...

What should we do with the Road POI's ? I think disabling heuristic for 
them makes no sense since we need the city name to make them more unique.

I experimented a little bit with ZIP data provided by geonames.org. This 
seams to help to improve the quality of the heuristic in non opengeodb 
countries. But this datasource also provides points and no polygons so 
it will be still guessing. I also looked a little bit in using 
administrative boundary data for the region naming but I'm not sure if 
the data sources are good enough ...

I hope I could provide a patch with your suggestions on the weekend ...

Thanks
Berni.





More information about the mkgmap-dev mailing list