logo separator

[mkgmap-dev] New locator branch

From Felix Hartmann extremecarver at gmail.com on Thu Mar 17 22:09:44 GMT 2011

On 17.03.2011 22:57, WanMil wrote:
>>> And another requirement is also hard to achieve: performance. The 
>>> branch
>>> is not optimized very well yet. But I am sure that such searches for 
>>> big
>>> areas from all items of a tile are quite expensive no matter how
>>> optimized they are.
>>> WanMil
>>> _______________________________________________
>> I currently really don't want to use the locator branch, due to it's
>> speed. I need already about 12 hours to compute all maps for weekly
>> updates and osm data alone growing is already a concern. Wouldn't it be
>> enough to use no guessing and just input correct addresses (best with
>> working housenumber search)? The searching for streets not addresses is
>> anyhow kinda strange and seems much more like a workaround than a clean
>> solution.
> Yes ... but how should mkgmap input the correct addresses? ;-)
> In an ideal world you are right. But OSM data is far (very far) away 
> from complete address tagging.
> Beware that all POIs would have to contain a complete set of addr-tags 
> (addr:country, addr:county addr:region(?), addr:city, addr:street, 
> addr:housenumber). The same with the is_in tags for all streets that 
> do not have any POIs attached until now. I havn't tested it but it 
> should not be too complicated to make a statistic with osmosis and a 
> dump file.
> Maybe the completeness of tagging will change within the next 2 years 
> but we are implementing for now.
> WanMil
Well if mkgmap supported it, that would be the best headstart! As 
already said, In Vienna I would say we have already 1/3 of all addresses 
with complete and correct information - on local gatherings we face 
problems on how to decide what to do with houses that have two 
streets/addresses on corners and their like. In Germany there were talks 
on the forum of people asking if we already have a major town address 
complete - result was for a few not far off. Also the consensus is clear 
that noone wants ise information on streets, cause streets often do not 
belong to one disctrict or town (sometimes either side of a street is a 
different district, and so on). So mkgmap should not prosper incorrect 
tagging, but the goal should be to support addresses correctly.

A good example are non connected streets. When mkgmap got routing loads 
of streets were not connected, especially streets and 
hiking/cycling/walking ways. Now only few beginners do mistakes here and 
all editors got checks for this. By that time one could have argued (and 
I think a few people did) that mkgmap should try to connect streets 
intelligently - good we did not do this, as data got good enough fairly 

I only would expect searching for streets where there are no addresses 
(e.g. hiking networks on tracks/paths cause usually there are no 
addresses). However one might argue that it would maybe better to 
include signposts that mark significant places of a route into the 
address search (and hence give them sufficient ise info). That behaviour 
would even be more of what one expects when searching for a route 
(start, finish, and major points inbetween - maybe guideposts).

More information about the mkgmap-dev mailing list