logo separator

[mkgmap-dev] [locator] What's next?

From charlie at cferrero.net charlie at cferrero.net on Mon Jun 6 21:02:09 BST 2011

WanMil (wmgcnfg at web.de) wrote:

> Hi all,
>
> it's been a long time since the locator branch was merged and I want to
> start thinking about what has to be done to merge it back to trunk.
>
> So please post your bugs or features that need to be fixed before
> merging it back to trunk.
> By the way: do you think the branch should be merged or should we
> abandon the branch because it has too many flaws?
>
> WanMil
> _______________________________________________
Bear with me, because I haven't tried the locator branch for the  
reasons I'm about to explain, so my comments may be off the mark...

 From my perspective, the locator branch as I understand it will not  
be much use because the area I live in (in the Middle East) has no  
useful boundary relations that the locator branch could use.  It's not  
necessarily that people haven't got around to adding this information  
to the OSM database, but often that this information is not publicly  
available at all.  In the UAE, for instance, there is no formal,  
systematic address system *whatsoever* (it is completely normal here  
to give your home location relative to local landmarks such as parks,  
mosques and malls, rather than giving an address.  Makes getting home  
deliveries a nightmare, but that's another story) so we couldn't add  
data to the database even if we wanted to.

Secondly, the need to pre-process OSM data for boundaries using  
osmosis strikes me as unwieldy and difficult to maintain. I would much  
prefer if everything could be self-contained in one executable.

Thus, in my opinion any merge back into trunk should still preserve  
the branch algorithms for retrieving address information.  In  
particular, as Felix said a few weeks ago, I would encourage that  
address info for POIs is gathered from the addr: tags in those OSM  
objects (which will encourage people to tag POIs with address info)  
and the locator algorithms are only:
a) offered as an alternative or supplementary option to  
--location-autofill to get address information for POIs; and
b) offered as an option to get address information for streets that  
are typically never tagged with addr: info.

Incidentally, one very quick improvement to the branch handling of  
addr: tags for POIs would be to fix the bug I pointed out a few weeks  
ago and the addition of processing of the addr:full tag if that is  
present as an alternative to individual addr:street, addr:housenumber  
etc.

Just my two fils worth...

-- 
Charlie




More information about the mkgmap-dev mailing list