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
Index: src/uk/me/parabola/mkgmap/reader/overview/OverviewMapDataSource.java
===================================================================
--- src/uk/me/parabola/mkgmap/reader/overview/OverviewMapDataSource.java
(revision 1088)
+++ src/uk/me/parabola/mkgmap/reader/overview/OverviewMapDataSource.java
(working copy)
@@ -45,7 +45,7 @@
// TODO need to change this.
private final int topLevel = 5;
- private final int topBits = 14;
+ private final int topBits = 15;
/**
* This is a fake source of data and is not read from a file, so always
@@ -132,6 +132,7 @@
* @param shape The polygon to add.
*/
public void addShape(MapShape shape) {
+ System.out.printf("shift for overview " + getShift());
mapper.addShape(shape);
}
_______________________________________________
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
