Re: [mkgmap-dev] problems at map intersections?
Steve Ratcliffe wrote: 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 In your patch, is the value of // TODO need to change this private final int topBits = 15; the first level in the overview map? If so, then could it not be read directly from the detailed maps, rather than being a constant? I noted the TODO. Thanks Garvan ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] problems at map intersections?
Hi // TODO need to change this private final int topBits = 15; the first level in the overview map? If so, then could it not be read directly from the detailed maps, rather than being a constant? I noted the TODO. Yes that is exactly right. It should be calculated so that the whole area covered by all the maps can be represented by a single area. Regards, ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] problems at map intersections?
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
Re: [mkgmap-dev] problems at map intersections?
Mark Burton schreef: OK - I have looked at your example and can confirm there is a problem in that mapsource doesn't display the region near the tile boundary, it has a gap of 200m or so. Don't know whether this is just mapsource being it's usual crap self, or the problem also exists on the gps. It will route through the tunnel (as the attached picture shows) but Yes, I noticed that - but could not reproduce it yesterday. Please notice however, that the route you found has both starting points at the lower map. That may or may not have anything to do with it. Your picture also shows that the upper map vanishes (which you confirmed already). Now, this may be because mapsource thinks that using the tunnel and then looping back to the S again is not a good route so it decides you're better off going to the E. If that's the case, I don't think there is anything we can do about it. If you could recheck with a map without the split, you'll see that routing through the tunnel is no problem at all. Just download some surroundings of the tunnel and build a map to try it. Valentijn -- Durgerdamstraat 29, 1507 JL Zaandam; telefoon 075-7074579 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] problems at map intersections?
On 17/07/09 22:59, Valentijn Sessink wrote: Steve Ratcliffe schreef: That is intentional; the bounds should not overlap and should meet exactly. Are you really (as in really-really-really) sure about the fact that the Oh, I'm not usually sure about anything. I do know what you are talking about though, there have been similar before. So you will probably also find that in the area that disapears, if you hover over a road you do not also get the usual pop-up that tells you the name of the road. Anyway I'll take a look at the example you posted in another message. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] problems at map intersections?
Steve Ratcliffe schreef: So you will probably also find that in the area that disapears, if you hover over a road you do not also get the usual pop-up that tells you the name of the road. Yes, but actually I blamed Wine instead of you ;-) (I feel I actually can safely blame whoever I want, being in an unroutable part of the world - if you come to get me by bike, that is ;-) But now you mention the pop-up, did you notice that the pop-ups work just above (so within) the (shifted, see previous post) bounds of a map and when you hover outside the (grey lined) bounds, they immediately don't work? And that they do start to work again some 250 meters below the actual split and *that* is again the precise point where the map will not vanish anymore? So for the lower part of the split: the part of the map that will always show, is also the part of the map that has these pop-ups again. Since you know what you're talking about: is there a discussion, explanation or otherwise for the reason that you did not let the maps overlap? An overlap of 300 meters sounds like a good idea for the routing - but as said before, I'm saying this from a position of blessful ignorance. Best regards, Valentijn -- Durgerdamstraat 29, 1507 JL Zaandam; telefoon 075-7074579 -- Durgerdamstraat 29, 1507 JL Zaandam; telefoon 075-7074579 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] problems at map intersections?
Hi, Since you know what you're talking about: is there a discussion, explanation or otherwise for the reason that you did not let the maps overlap? An overlap of 300 meters sounds like a good idea for the routing - but as said before, I'm saying this from a position of blessful ignorance. I will answer this one for Steve: The inter-tile routing is accomplished by having a set of boundary nodes that have exactly the same coordinates in each of the tiles that borders the boundary. To route across tiles, it has to go via a boundary node. To ensure the boundary node coordinates are the same in both tiles, there is no overlap in the bounding boxes. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] problems at map intersections?
Hi all, I tried to line up Splitter with the map boundaries; instead of having (hexadecimal showing) 63240008: 251000,25800 254800,38800, I had to use 63240008: XX,X 254c00,X). Now the tool tips would not show up in the +-250 meters around the boundary. Then I used: 63240008: 251000,25800 254c80,38800 63240010: 254b80,25800 262800,4 ... now the tool tips show *and* the map does not disappear anymore around the boundary. But - as Mark predicted - now inter tile routing does not work anymore. Just another idea: could be possible to line up the boundary nodes, then add some surroundings to have an extra overlap, right? Like so (ascii art alert) (maps below should be joined horizontally, not vertically) map 1--+-- 1 11 1 1B 1 1 11 B1 ---+-- --+map 2--- 2 2 B 2 22 B2 --+--- (It you can't, for any reason, please feel free to ignore my mail - as we say here: a fool can ask more questions than 100 wise man could answer) Best regards, Valentijn -- Durgerdamstraat 29, 1507 JL Zaandam; telefoon 075-7074579 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] problems at map intersections?
Steve Ratcliffe schreef: 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. In fact, I think it's two related, but different, problems: 1) the overview map is out of sync with the actual bounds. Please see my e-mail about a splitting area that will have these synchronised (*); it's a sort of rounding issue, as far as I understand. 2) the fact that, around a map split, some things do not work as they work on the rest of the map. An overlapping map helps here - and you wizards will probably know if it's possible to have a map overlap and still have the routing nodes in place. [...] So the conclusion is that the definition areas in the overview map are wrong. This would explain problems in mapsource, but not on the device. Yes, that's what I think, too. [...] Best regards, Valentijn (*) Use splitter with: 63240008: 2428928,153600 to 2444288,231424 63240010: 2444288,153600 to 2500608,262144 Please note that 2444288 is the only number I changed, the other corners aren't lined up, but since we only use 2 maps here, 2444288 is the only number that is at a map intersection. -- Durgerdamstraat 29, 1507 JL Zaandam; telefoon 075-7074579 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] problems at map intersections?
Hello list, I'm having a great time corresponding to myself here :) but these are my observations so far. Running Splitter, then Mkgmap.jar, then MapSetToolKit.exe, then Mapsource, the resulting submaps are shifted from their bounding box: they are about 2.4 kilometers left, up, from the map itself. (So you have a bounding box that does not bound the map). The resulting submaps have no overlap now, which results in strange behaviour around the edges of the map: 1) It looks like sometimes Mapsource doesn't know how to get to the other map - a sort of short-arc between maps; it will refuse to take certain ways and will stubbornly route you around something, even if it's a trivial, 50 meters route on the map. 2) Also, sometimes Mapsource (and my Garmin Nuvi) seem to choose the wrong submap to display data from - resulting in a blank screen instead of mapping information. This is best seen at high zooming levels. Now I tried to get around this. If I use splitter to output a header of writer.append(String.valueOf(Utils.toDegrees(extendedBounds.getMinLat(; instead of the regular bounds.getMinLat(), I'm getting better results - the maps now overlap. I decreased the bounds size in addToOverviewMap in mkgmap. But is probably not be the correct way, as the bounding box still seems a bit off - I'm guessing that now the map itself grows, which will only work as long as the result will round down to a value within the map itself? If I'm unlucky, the new bounding box will - again - be larger than the map? If I knew Java, I would try to get Splitter to output something like Utils.toDegrees(bounds.getMinLat() + (extra / 2)), but as I don't know enough about scope of variables, I will leave that to more knowledgeable people. And maybe it's a stupid idea after all. I'll stop hacking around in unknown code now and have a beer, but my feeling is that 1) something should be done about the bounds in the overview map 2) I'm guessing that Garmin wants some overlap in submaps, so it can choose from what file to display the data from. Maybe 1 and 2 are the same problem (i.e. if the bounds are right, the choice of map will be right as well). I realise that I should have tried to hack an area.list with overlap, then use --split-file=areas.list, which is easier than randomly hacking around the source. Anyway. Maybe someone with knowledge of Mkgmap could say something about it? Best regards, Valentijn -- Durgerdamstraat 29, 1507 JL Zaandam; telefoon 075-7074579 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] problems at map intersections?
Hi Since no one replies to my mail, I'll do it myself ;) Thanks for studying the problem so closely - it is very useful. What I found is the following. Splitting a file with a border will produce a file that has the exact bounds, without the overlap, in the resulting map. That is intentional; the bounds should not overlap and should meet exactly. There is extra data in the file that extends beyond the bounds and mkgmap should cut the lines at exactly the bounds. Cutting the lines at the exact boundary is bes done in mkgmap rather than splitter for several reasons, for example you have to know whether something is a line or a polygon to know what to do. Then, in addToOverviewMap, I added -1 to the minimum lat/lon values: int minLat = roundDown(bounds.getMinLat(), overviewMask) -1; int minLon = roundDown(bounds.getMinLong(), overviewMask) -1; I think that three things must line up exactly, the tiles them selves, the areas within the overview map and the areas in the TDB file. Probably one or more of those are out of step. Its also possible that it only goes wrong in certain circumstances such as +ve or -ve longitude. The next step is to find out exactly which one is wrong and compare with a working map if necessary. Cheers, ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] problems at map intersections?
Hi Valentijn, Did anyone else notice this problem before? Were you able to reproduce it? If it helps, I can prepare a map that will have a routing problem just at the edge (there's a biking tunnel that MapSource avoids, no matter how hard I try, while letting mkgmap render the map without a boundary, the tunnel works just fine). I believe (because the ML is not showered with emails complaining about it failing) that inter-tile routing is generally working OK. Please provide an example of it failing so we can study it. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] problems at map intersections?
Hi Mark, Mark Burton schreef: I believe (because the ML is not showered with emails complaining about it failing) that inter-tile routing is generally working OK. It really does work great. In fact, it took me quite a while to come to the conclusion that the map edge seemed to be involved and that there might be a routing problem after all. At first I thought it was the tagging of tunnel, the fact that I tried to send a bike through a tunnel, the fact that I chose a bicycle for routing at all (Garmin doesn't do a really good job there - or maybe they like biking so much that they send you for 30 kilometer trips when 11 could do). But a few days ago I noticed that the map dissapeared at the same spot where the routing went wrong when I biked around with my Garmin Nuvi. Oh, and yes: I really think there aren't enough people riding around on their bicycles at OSM/splitter map edges, while looking at their Garmin Nuvis loaded with Openstreetmap-data in Driving Direction Up (i.e. non-3D), Highest Detail, Highest zoom mode. I really should start a support group ;-) Please provide an example of it failing so we can study it. memory=1700m maxn=50 wget 'http://download.geofabrik.de/osm/europe/netherlands.osm.bz2' bzcat netherlands.osm.bz2 netherlands.osm wget 'http://www.mkgmap.org.uk/snapshots/mkgmap-latest.tar.gz' tar -zxf mkgmap-latest.tar.gz wget 'http://www.mkgmap.org.uk/splitter/splitter.jar' java -Xmx$memory -jar ./splitter.jar --max-nodes=$maxn netherlands.osm java -enableassertions -Xmx$memory -jar mkgmap*/mkgmap.jar \ --country-name=Nederland --country-abbr=NL --latin1 \ --remove-short-arcs --lower-case --route --preserve-element-order \ --location-autofill-1 --gmapsupp --net 63240008.osm.gz 63240010.osm.gz Then load the resulting map in MapSource; to be sure, select Edit-Preferences-Routing, Bicycle, shortest distance. (Set detail to Highest if you want to see the biking path). Then route from N52.42701 E4.82707 to N52.42625 E4.82736, they are on the same biking path, some 80 metres apart. You'll see the route deviate 3 kilometers. Also, if you try to zoom on one of the points above, you'll see a blank map. (This is Mapsource 6.11.5 running under Wine, but as said before: my Garmin Nuvi does the same - only on highest zooming level though, and only around the edges on the OSM map - it does not do that on the Garmin native map - I did check that). I hope you can reproduce my findings - that would be a help. Thanks so far, best regards, Valentijn -- Durgerdamstraat 29, 1507 JL Zaandam; telefoon 075-7074579 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] problems at map intersections?
2009/7/18 Garvan maew garvan.m...@online.com.kh Did anyone else notice this problem before? Were you able to reproduce it? If it helps, I can prepare a map that will have a routing problem just at the edge (there's a biking tunnel that MapSource avoids, no matter how hard I try, while letting mkgmap render the map without a boundary, the tunnel works just fine). Let me know if you need the map/script/other stuff to reproduce it. I have been experimenting with maps with only one tile, but I did notice the misalignment of the map selection box and the detailed map in mapsource. I assumed it was a rounding issue between the detailed map and the overview map which are at different scales, and never thought to report it as an issue. For a large map it is almost unnoticeable, but for a small sample it can be completely wrong. For small maps what I did was increased the size of the bounding box in the osm file, and the alignment problem was fixed, or no longer a problem, because the box was bigger than the tile. One reason why others have not reported this may be because they do not use mapsource or QLandKarteGT. Those with external storage GPSr may never have seen this misalignment. Or like me, they just adjusted the boundaries. Garvan ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev Garvan, IMHO you misconcept real boundary overlay with the overview map overlay. There is in my opinion a problem that overview maps sometimes get created smaller than the actual map (i.e. when using gmaptool to create the mp overview map). I don't use mkgmap for overview map creation because it long was pretty buggy. Then in Mapsource maps will be cut off, while the data actually continues. Try a huge overview map (i.e. whole of europe) with your maps, to see if it is not an overview map problem instead of a real map data failure. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
