[mkgmap-dev] problems at map intersections?

Sun Jul 19 17:52:29 BST 2009

On 18/07/09 13:09, Steve Ratcliffe wrote:
>
> Hi
>
> I've run your example and looked at the bounding boxes of everything
> important that I know about.
>
> First the actual bounds as given in the input files.
> All the bounds below I believe should be exactly equal to this.
> Also the first number on the first line should be the same as the
> third number on the second line bottom of 63240010 matches the
> top of 63240008 (only the last four digits of the map number shown below).
> 0010: 52.4267578125,3.2958984375 53.6572265625,5.625
> 0008: 52.119140625,3.2958984375 52.4267578125,4.9658203125

> Inside the overview map there are definition areas that should cover the
> individual maps.
> 0010: 52.470703,3.339844 53.701172,5.668945
> 0008: 52.163086,3.339844 52.470703,5.009766
> So top matches bottom, but not the same as the bounds.
> This could explain mapsource, but as it is not used
> on the device can't explain the problem in the GPS.

So I know why this happens now.

Coordinates in the file are recorded by using an offset from a central
point in a subdivision.  The central point is recorded exactly but
the offset is in multiples of 2048 map units (in this case - it depends 
on the zoom level).  This is called a 'shifted unit' elsewhere so that
is the term I will use here.

So if the tile height or width is an odd number of these shifted units 
then the centre point will be half way between a shifted unit boundary.
Therefore adding any offset will leave you half a shifted unit out.

I'm not sure if I explained that very well, but my conclusion is
that

1. The tiles produced by splitter should be aligned on an even lower 
zoom boundary, so that they will be an even number of units on the 
overview map.
2. This is probably a problem throughout elsewhere.  The central point 
should probably always be on a shifted unit boundary.

A quick test with the attached patch shows that the boundaries shown in
mapsource now line up with the map.  The places where there are no 
tool-tips near the boundaries still exist though.  I've not tried 
routing to see if it makes a difference.

The attached patch is not a fix to the problem.

..Steve
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: b.patch
Url: http://lists.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20090719/f75c0538/attachment.pl 