[mkgmap-dev] problems at map intersections?From Steve Ratcliffe steve at parabola.me.uk on 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
- Previous message: [mkgmap-dev] problems at map intersections?
- Next message: [mkgmap-dev] problems at map intersections?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the mkgmap-dev mailing list