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

Mon Jun 6 22:26:30 BST 2011

>> 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.

Ok, I really wasn't aware of such things...

>
> 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.

You've never done that? In case the branch is merged I hope we will be 
able to provide a download for the precompiled boundaries. So you don't 
have to do it yourself.
By the way: You are using splitter to create tiles? I think that's a 
quite similar step. The osmosis call is not nice but maybe we get an 
easier way to filter the boundaries.

>
> 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)

Using the locator branch you can use the style file to decide yourself 
which tags are used to assign the address information. So you can 
configure to use the addr:* tags.

> and the locator algorithms are only:
> a) offered as an alternative or supplementary option to
> --location-autofill to get address information for POIs; and

In general: we need an algorithm that helps in regions without boundary 
information. And maybe some parts of the current location-autofill can 
be used for this.

> b) offered as an option to get address information for streets that
> are typically never tagged with addr: info.

You can already do this with the style file. But an additional parameter 
would have some advantages for processing time. So that sounds useful.

>
> 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

Can you give me a link to your post? I don't remember...

> and the addition of processing of the addr:full tag if that is
> present as an alternative to individual addr:street, addr:housenumber
> etc.

I wonder how to achieve that. The garmin format has some address fields 
like street, zip, city, region, country (and housenumber - but we don't 
know how to code it?!). All information must be put into these fields. 
Do you have an idea how to convert addr:full into this schema?

>
> Just my two fils worth...
>

Thanks for your feedback!
WanMil