[mkgmap-dev] Address search and index.

Tue Feb 15 11:49:23 GMT 2011

On 14/02/11 18:09, WanMil wrote:
> Am 14.02.2011 13:20, schrieb Steve Hosgood:
>> On 14/02/11 10:21, Steve Ratcliffe wrote:
>>>> If there are faults in the data, they should be fixed.
>>>
>> It's really an issue to be debated at OSM level, not mkgmap level, but I
>> have considered for quite a while now that the "is_in" tag should be
>> entirely deprecated in favour of a concept of boundary polygons. "Is_in"
>> is fraught with problems, some illustrated above.
> Steve, that was my first idea and I think that's the only solution to 
> the problem. But it's not that easy to realize.
I never said it would be easy! But in the long run, it would solve many
problems. Mkgmap already illustrates the problems inherent in the
existing system. But any navigator software using OSM data has the same
problem - just look at the search tab of the main OSM slippy-map, or any
of the web-hosted route-planners. Their street searching systems are
better than what we have currently on Garmin (even with Steve
Ratcliffe's latest and best efforts), but even so they are a bit dodgy.

> I propose two solutions.
> 1. Quick fix
> Use the Locator.xml to merge different notations of the same country / 
> region name. This won't be perfect but will probably fix the most 
> obvious problems for a first release of the index branch.
>
>
This will probably have to be human-driven to have any chance of
success. But yes, it could be done. It would get rid of the
inconsistencies, but the problem of working out to which village a given
street belongs, when there are two villages nearly touching - that will
still remain.

> 2. OSM boundary data (the general solution)
> It sounds great to use the OSM boundary data but there are some pitfalls 
> we need to go around. I'll list the pitfalls here. Maybe someone finds 
> an easy solution for them.
>
> 1st problem: Splitter (as you already mentioned)
> The tiles do not contain the full information for multipolygons that 
> exceed the tile bounds. I don't think that this will be easy fixable. 
> You would need to implement a complete multipolygon handling in splitter 
> to decide which data must additionally added to a single tile. That's a 
> big deal and will consume lots of resources.
It may be possible to pre-process the planet file to divide the world
into (say) 1° by 1° squares and pre-tag each one with any outer
bounding-polygon information which applies to the whole of that tile.
When a splitter produces an output file it will know that level of
information instantly and will only have to work hard to "shrink" any
bounding-polygon whose border actually crosses the area of interest.

But we must be doing this (or something like this) already for
coastlines, yes?
> 2nd problem: Incomplete data
> The boundary data has a similar structure to the coastline data. The 
> coastline processing is working now with mkgmap but the failure rate is 
> quite high. Only a single OSM data failure can cause the complete 
> workflow to fail.
>
Yeah - this is indeed an issue. But any map is only as good as its data.
If the data is wrong it must be fixed. I would propose a suite of
sanity-checker programs that should be periodically run over the planet
file looking for broken polygons. It should be easier to maintain than
the coastline data because the political (or adminstration??) bounding
polygons should obey certain rules that could be checked automatically.

> 3rd problem: Amount of data
> A solution for pitfall 1 (and 2) could be to provide quality checked 
> extra data containing boundary information only. This is already 
> available for the generate-sea processing. You can provide the coastline 
> data in a separate file. But the amount of data will be VERY high. I 
> don't think that it is a good thing to have minimum memory requirements 
> of some GB.
> So in the end we would need to throw away the tile concept and implement 
> a database interface for mkgmap.
> Maybe that's the solution?
>
The outer boundary for a land-locked country will consist of a LOT of
data, agreed. For island nations it will be vastly less because you can
draw a crude polygon off-shore to encompass all the land area. And you'd
have to do that, because you want to include all the minor off-shore
islands. You want an extreme example, look at Greece! But the outer
polygon for Greece might not be all that detailed yet still do the job
correctly - except for the northern land-border of course which will be
crazy.

Steve