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

Tue Jun 7 06:15:59 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.
>
> 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.

Yes, I agree splitter is an extra step, but on my computer splitter  
takes 18s to split the whole of the GCC countries (into precisely one  
tile, natch), whereas from what I've read on the mailing list, osmosis  
takes much longer to produce the bounds.  I understand that if the  
bounds files are provided for download, that avoids the processing  
time but unless the bounds are mature (e.g. as they are in Europe),  
you will have to constantly regenerate it.

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

OK, that's great.

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

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

http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2011q2/011267.html

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

I would suggest that you either parse addr:full (harder, more error  
prone) and split it down to fields, or just shove it all into  
addr:housename (if there is no character limit).

-- 
Charlie