WanMil (wmgcnfg@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