[mkgmap-dev] Address search and index.

Wed Feb 16 10:10:08 GMT 2011

On 15/02/11 18:16, WanMil wrote:
>
>>> 1st problem: Splitter (as you already mentioned)
>>> The tiles do not contain the full information for multipolygons that
>>> exceed the tile bounds....
>> 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...
> I like the idea of creating smaller tiles with consistent information. I 
> would not implement this in splitter. I have implemented the 
> multipolygon algorithms for mkgmap and that was hard work until it 
> reached the current quality. Handling boundary data is nothing else than 
> multipolygon handling. We don't need to reinvent the wheel and can use 
> mkgmap (at least the mkgmap codebase) to do that.

Excellent. After further thought I suspect that my idea of 1° x 1° tiles
would be too big - you'd want to choose a tile size so that several
would be used to create a typical user's request from the splitter.
> By the way: The coastlinefile processing has not such a mechanism. It 
> simply loads all coastline data from one file and keeps that in memory. 
> That's not a good choice for large areas. This could be tuned.
>

Yeah - I'm surprised it doesn't do that already.

>
>> I would propose a suite of sanity-checker programs that should be periodically run over the planet
>> file looking for broken polygons.
> Ok, that's not mkgmaps task. There are already some fine tools like the 
> WayCheck suite. Maybe they could be tuned to do that. In the end people 
> will set more value on valid boundary data if mkgmap makes use of it.
>

That's true - and remember it won't just be used by mkgmap. If (when?)
there is ever a "mktomtommap" project, they would need it too. So would
the slippymap gazetteer and any route-planner software.

>> 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.
> Can you give an example? I don't see why it should be easier than 
> coastline checking.
>

1) A bounding polygon ought to form a closed way. Coastlines seem to be
composed of many open ways that happen to share end-points (more like
roads). That latter fact makes it harder to check a coastline since a
"way" flagged as "coastline of France" will at some point share
endpoints with a "way" flagged as "coastline of Spain", and that's true
but not checkable automatically.

2) A bounding polygon's name ought to be unique within its own parent
bounding-polygon. If for some reason you really want two
bounding-polygons to be disjoint, but refer to the same logical place,
you'd put them both in a "relation".

3) There should not be an intersection of two bounding polygons at the
same level. In other words, two towns can't intersect.

4) There are such things as cities that span multiple counties (like
London, England for instance). There needs to be rules to allow that,
maybe where the bounding-box for the majority of the county of Middlesex
is required to be entirely outside the bounding box for London, but a
second bounding-box (also flagged as 'county of Middlesex') is placed
inside the bounding-box for London, but a member of a "relation" with
the other Middlesex to prove that they are supposed to be the same. If
the 'relation' was omitted, the auto-checkers would barf because you'd
have two disjoint places called Middlesex inside the same parent
bounding box (England). (You might choose to relax that rule if the two
Middlesex bounding-boxes shared one or more periphery vectors, as they
would here.)

5) The "political:layer" tags should increase in value as the
bounding-boxes nest. In the unusual case of enclaves that I mentioned in
my earlier post, you allow the layer value to break that rule (within
the enclave the inherited knowledge of the parent bounding boxes is
forgotten), but there has to be a tag to say "political:enclave=yes" or
something to let it happen without the auto-checher barfing.

6) Er - there must be more!

>
>> 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.
> Sounds easy although I have no idea how to put that into a good 
> algorithm that does not exhaust common memory and processor configurations.
> Example:
> * How do you want to detect island nations?
>

Sorry - I didn't make myself clear. No-one has to detect island nations.
Some mapper draws the polygons! But the mapper will have an easy time
with a country with a coast - just a straight line or two to encompass
all the relevant landmass. In the case of the top-level political, I
suppose the bounding box should follow that nation's agreed "national
waters and fishing limit" or whatever it's called.

My example of the Greek OSM'er above was meant to show that he/she would
have an easy time with most of the Greek Aegean islands, but would have
to spend quite a while drawing the polygon along the border with
Macedonia (say).

Steve

PS: If you look at my village, Bishopston in South Wales (
http://www.openstreetmap.org/?lat=51.58046&lon=-4.0451&zoom=15&layers=M
) you'll see that I drew an urban polygon for it and for the adjoining
village of Murton. My street is officially in Bishopston even though I'm
closer to Murton village centre than I am to Bishopston village centre.
Only the bounding boxes can tell you which street belongs where.
Additionally, the flagging on the boxes makes the built-up area of the
twin villages be coloured grey on the map, which is nice.