Seems that my message doesnt reach the list with attachments, so I try it again: Attachments: https://dl.dropbox.com/u/64716698/OSM/mkgmap/corners.jpg https://dl.dropbox.com/u/64716698/OSM/mkgmap/gap.jpg
I noticed a gap in my maps and artefacts at the outer tile boundaries when I tried to make a Europe map. Maybe it is my mistake, because I have drawn a few big rectangular polygons over Europe and let the splitter calculate those areas. I then let mkgmap run and combined the img tiles of those sections. When I look at the total map there are some issues.
First, there is a big gap at 49.5 longitude (a few 100 meters wide) between the northern and southern part. It is only visible at the highest zoomlevels (<200m). When I zoom out, the gap disappears and routing is possible. If I make a different selection of a fewer tiles around this latitude, the gap is not there.
See gap.jpg
North tile 10131034: 2306867,4096 to 2344960,22528 # : 49.499996,0.087891 to 50.317383,0.483398
South tile 10135076: 2301952,4096 to 2306867,40960 # : 49.394531,0.087891 to 49.499996,0.878906
If you look at the Garmin units, 2306867 is not divisible by 2048. Could this be the reason? Is it a bug in the splitter or should I use an option to let the splitter draw areas that exactly fits with 2048 garmin units?
Second, I noticed in the corners of the map that the background polygon does not match. See pic "corners.jpg".
10132142: 3266560,1212416 to 3327481,1444704 # : 70.092773,26.015625 to 71.399996,30.999985
Again, the most northern latitude 3327481 is not divisable by 2048
I also notice that the map disappears when zooming in at the border tiles (only at very high zoomlevels, like 100 m or closer).
I use splitter r297 and mkgmap-r2513, precompiled sea tiles (in splitter and mkgmap) and a custom background (generate-sea: land-tag=natural=background), maybe this is also relevant to mention?
Hi Minko, Minko-2 wrote
If you look at the Garmin units, 2306867 is not divisible by 2048. Could this be the reason? Is it a bug in the splitter or should I use an option to let the splitter draw areas that exactly fits with 2048 garmin units?
If you use a simple polygon with spitter (e.g. a rectangle), it will fit the tiles into the polygon. If I got that right you use multiple splitter passes, each with a single polygon area. Later you try to combines the tiles to one map. You should instead run splitter with a polygon that contains the complete area. If that doesn't help, please post the polygon files and the splitter parms that you use. Gerd -- View this message in context: http://gis.19327.n5.nabble.com/issues-with-tile-boundaries-tp5753275p5753289... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi, I tried to align the polygon files along a Garmin raster with units divisable by 2048. Howver, the splitter still does another sort of rounding and draws a different polygon, sometimes it is only one garmin unit difference, but this causes that the polygons doesn't touch each other, and also are not a multiple of 2048 which I think can cause those gaps and artefacts along the borders. Am I correct? I can manually edit the areas.lists file to make the tiles one garmin unit bigger to see if this will improve the map, but I think the splitter could be improved here? In the archives I found this rule: #The numbers used in areas.list are in Garmin units. To get from #latitude and longitude in degrees to Garmin units multiply by 46603 #which, incidentally, is (2^24)/360. #To avoid overlap you have to make sure that the Garmin units are exactly #divisable by 2048. Gerd wrote:
If you use a simple polygon with spitter (e.g. a rectangle), it will fit the tiles into the polygon. If I got that right you use multiple splitter passes, each with a single polygon area. Later you try to combines the tiles to one map. You should instead run splitter with a polygon that contains the complete area. If that doesn't help, please post the polygon files and the splitter parms that you use.
Gerd
-- View this message in context: http://gis.19327.n5.nabble.com/issues-with-tile-boundaries-tp5753275p5753289... Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Minko,
I tried to align the polygon files along a Garmin raster with units divisable by 2048. Howver, the splitter still does another sort of rounding and draws a different polygon, sometimes it is only one garmin unit difference, but this causes that the polygons doesn't touch each other, and also are not a multiple of 2048 which I think can cause those gaps and artefacts along the borders.
Am I correct? I can manually edit the areas.lists file to make the tiles one garmin unit bigger to see if this will improve the map, but I think the splitter could be improved here?
1) According to Steve the alignment to 2048 units is not mandantory, the ony important point is that you don't have gaps. The value 2048 results from the default resolution 13 : 2 ^ (24-13) = 2048. 2)The rounding in splitter works like this (l is the value in degrees): public static int toMapUnit(double l) { double DELTA = 0.000001; // TODO check if we really mean this if (l > 0) return (int) ((l + DELTA) * (1 << 24)/360); else return (int) ((l - DELTA) * (1 << 24)/360); } (1<<24) / 360 gives ~ 46603,378 The comment for the DELTA value is alarming. In mkgmap a slightly newer code is used with double DELTA = 360.0D / (1 << 24) / 2; //Correct rounding @Steve: I assume it would be better to use the same code in splitter ? 3) It was recommend by Henning to fit the tiles into the polygon, see http://gis.19327.n5.nabble.com/splitter-r269-tp5741292p5741673.html Regarding improvements: If I got this right your problem is that you don't have enough memory to split Europe with option keep-complete, and the bottleneck is in the " handle-problem-list" phase. I see these options to help in your case: 1) Complex: Implement an algorithm in splitter which does something similar to your approach: Partition the input file into a few large areas and calculate each partition seperately. 2) Simple: Implement a parm that tells splitter not to trim the tiles to the polygon boundaries. Since splitter initially generates tiles which are aligned this might help. is implemented in the attached patch. You have to add parm --no-trim-to-polygon to activate this. The binary is available here: http://files.mkgmap.org.uk/download/90/splitter.jar Gerd
In the archives I found this rule: #The numbers used in areas.list are in Garmin units. To get from #latitude and longitude in degrees to Garmin units multiply by 46603 #which, incidentally, is (2^24)/360. #To avoid overlap you have to make sure that the Garmin units are exactly #divisable by 2048.
Gerd wrote:
If you use a simple polygon with spitter (e.g. a rectangle), it will fit the tiles into the polygon. If I got that right you use multiple splitter passes, each with a single polygon area. Later you try to combines the tiles to one map. You should instead run splitter with a polygon that contains the complete area. If that doesn't help, please post the polygon files and the splitter parms that you use.
Gerd
-- View this message in context: http://gis.19327.n5.nabble.com/issues-with-tile-boundaries-tp5753275p5753289... Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd,
1) According to Steve the alignment to 2048 units is not mandantory, the ony important point is that you don't have gaps. The value 2048 results from the default resolution 13 : 2 ^ (24-13) = 2048.
I see. In resolution 13 the overview map is generated, right? This emtpy polygon for this map is visible behind the OSM map and doesn't match the foreground tiles if they are not aligned to this 2048 units. This explains I think in this kind of artefacts at the corners: https://dl.dropbox.com/u/64716698/OSM/mkgmap/corners.jpg Another thing is that the map disappears (behind the background overview map?) and becomes unroutable when you zoom into this edges at very high zoom. Since this all happens at the edges it is not so important, but when I combine those maps, it becomes an issue.
Regarding improvements: If I got this right your problem is that you don't have enough memory to split Europe with option keep-complete, and the bottleneck is in the " handle-problem-list" phase.
That is a problem, but the main reason is that I try to divide Europe into a few logical areas (that fits together) which are small enough to make a gmapsupp.img to download for my map users. And I dont want to let the splitter decide those areas, but I want rectangular areas. https://dl.dropbox.com/u/64716698/OSM/mkgmap/EU_N1_GPS.jpg https://dl.dropbox.com/u/64716698/OSM/mkgmap/EU_N2_GPS.jpg Last try was to feed the splitter N1.poly and M1.poly, those polygons were aligned at the Garmin grid (dividable by 2048) but the splitter rounded the polygons differently, so the ressulting tiles of N1 and M1 didnt quite match (and their borders were not a multiple of 2048).
I see these options to help in your case: 1) Complex: Implement an algorithm in splitter which does something similar to your approach: Partition the input file into a few large areas and calculate each partition seperately.
Maybe you can use N1 and M1 poly's as example?
2) Simple: Implement a parm that tells splitter not to trim the tiles to the polygon boundaries. Since splitter initially generates tiles which are aligned this might help. is implemented in the attached patch. You have to add parm --no-trim-to-polygon to activate this. The binary is available here: http://files.mkgmap.org.uk/download/90/splitter.jar
Thanks Gerd, I'll give that a try and run the splitter on N1/M1 to see what the results are.
Hi Minko, Minko-2 wrote
1) According to Steve the alignment to 2048 units is not mandantory, the ony important point is that you don't have gaps. The value 2048 results from the default resolution 13 : 2 ^ (24-13) = 2048.
I see. In resolution 13 the overview map is generated, right? This emtpy polygon for this map is visible behind the OSM map and doesn't match the foreground tiles if they are not aligned to this 2048 units.
This explains I think in this kind of artefacts at the corners: https://dl.dropbox.com/u/64716698/OSM/mkgmap/corners.jpg
I meant the default resolution used in splitter, but I think you are right that 13 is used for the overview map. I am not aware that the value has an influence on mkgmap, but I maybe wrong. Gerd -- View this message in context: http://gis.19327.n5.nabble.com/issues-with-tile-boundaries-tp5753275p5753472... Sent from the Mkgmap Development mailing list archive at Nabble.com.
After run the first mapsets with the aligned tiles, it seems they don't show the misalignement of the background (overview?) map anymore :-) Also the gaps between the polygons disappeared, so the patch solved all the issues!
I meant the default resolution used in splitter, but I think you are right that 13 is used for the overview map. I am not aware that the value has an influence on mkgmap, but I maybe wrong.
Gerd
So yes, it does seem to have an influence, maybe --no-trim-to-polygon should be default (if a polygon is given)? Or the algignment of the overview map should be improved?
Hi Minko,
After run the first mapsets with the aligned tiles, it seems they don't show the misalignement of the background (overview?) map anymore :-) Also the gaps between the polygons disappeared, so the patch solved all the issues!
Fine :-)
I meant the default resolution used in splitter, but I think you are right that 13 is used for the overview map. I am not aware that the value has an influence on mkgmap, but I maybe wrong.
So yes, it does seem to have an influence, maybe --no-trim-to-polygon should be default (if a polygon is given)? Or the algignment of the overview map should be improved?
Ah, I see. The method TdbBuilder.addToOverviewMap() rounds the coods of the tile bboxes with the hardcoded resolution 13. @Steve: I don't know why that is done, maybe it can be changed ? Reg. --no-trim-to-polygon: I searched the mails to find out why I coded the default to be different. I only found your post: http://gis.19327.n5.nabble.com/splitter-r250-and-open-questions-reg-bounding... So, I think I should change splitter like this: rule 1: generated tile boundaries are always aligned to 2048 map units. rule 2: If a bounding polygon is given, trim the tiles to the bounding polygon but allow overlaps to follow rule 1 OK? Gerd
Gerd wrote
Ah, I see. The method TdbBuilder.addToOverviewMap() rounds the coods of the tile bboxes with the hardcoded resolution 13.
@Steve: I don't know why that is done, maybe it can be changed ?
Reg. --no-trim-to-polygon: I searched the mails to find out why I coded the default to be different. I only found your post: http://gis.19327.n5.nabble.com/splitter-r250-and-open-questions-reg-bounding...
So, I think I should change splitter like this: rule 1: generated tile boundaries are always aligned to 2048 map units. rule 2: If a bounding polygon is given, trim the tiles to the bounding polygon but allow overlaps to follow rule 1
OK? Gerd
You mean --trim-to-polygon is optional, and --no-trim-to-polygon default? That would be fine with me. About my former post, I was not aware that this would create gaps in the map, it makes more sense now why some people are complaining about holes between my germany and benelux map ;-) But maybe this can be corrected too, so trim-to-polygon wouldnt be an issue anymore.
Hi,
You mean --trim-to-polygon is optional, and --no-trim-to-polygon default? That would be fine with me.
I am not sure yet. If tiles must be aligned to 2048 map units I see no need for a parm. I also wonder if the resolution parameter in splitter makes any sense. I thought that a higher resolution value (e.g. 14) helps to solve issues regarding "Area too small to split at ..." messages, but that is probably not the case. Also the splitter messages "... already at the minimum size so can't be split further" are probably no longer an issue. A smaller resolution will save a bit of memory, but even with planet as input the gain is small, while a much larger value like 16 eats up huge amounts of heap. Gerd
On 18/03/13 07:44, Gerd Petermann wrote:
Ah, I see. The method TdbBuilder.addToOverviewMap() rounds the coods of the tile bboxes with the hardcoded resolution 13.
@Steve: I don't know why that is done, maybe it can be changed ?
Yes its worth trying to leave out the rounding and just let the normal fitting of the coordinates to the level later on. See what happens! ..Steve
Hi, I searched the archives and found that this is an old issue starting end of 2009, see e.g. http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2010q1/006477.html It is quite difficult to find out what effect the rounding has because the problems are only visible when you know where to look at. For now I can only say that the removal of the rounding in mkgmap fixes the problem with the gap. Here is what I tested: content of file minko_areas.list: #North tile 10131034: 2306867,4096 to 2344960,22528 # : 49.499996,0.087891 to 50.317383,0.483398 #South tile 10135076: 2301952,4096 to 2306867,40960 # : 49.394531,0.087891 to 49.499996,0.878906 Process with trunk versions of splitter r298 and mkgmap r2534: java -jar d:\splitter_trunk\dist\splitter.jar --split-file=minko_areas.list f:\osm\france.o5m java -Xmx3000m -jar d:\mkgmap_trunk\dist\mkgmap.jar --nsis --max-jobs -c template.args run installer start Basecamp Result: the gap is visible as described in Minkos first post The patched version of mkgmap doesn't show the gap, nor did I find other problems. My problem: I did not find any hints in the archive how the original problem looked like, so I am not sure if the old errors are back now :-( @Felix : You posted some test data for the original issue, maybe you can also have a look at this again? Attached is the patch, the compiled binary is available at http://files.mkgmap.org.uk/download/92/mkgmap.jar ciao, Gerd
Date: Wed, 20 Mar 2013 22:59:57 +0000 From: steve@parabola.me.uk To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] issues with tile boundaries
On 18/03/13 07:44, Gerd Petermann wrote:
Ah, I see. The method TdbBuilder.addToOverviewMap() rounds the coods of the tile bboxes with the hardcoded resolution 13.
@Steve: I don't know why that is done, maybe it can be changed ?
Yes its worth trying to leave out the rounding and just let the normal fitting of the coordinates to the level later on. See what happens!
..Steve _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Minko, Minko-2 wrote
Last try was to feed the splitter N1.poly and M1.poly, those polygons were aligned at the Garmin grid (dividable by 2048) but the splitter rounded the polygons differently, so the ressulting tiles of N1 and M1 didnt quite match (and their borders were not a multiple of 2048).
I see these options to help in your case: 1) Complex: Implement an algorithm in splitter which does something similar to your approach: Partition the input file into a few large areas and calculate each partition seperately.
Maybe you can use N1 and M1 poly's as example?
the polygons in N1 and M1 are not aligned, but with the new parameter --no-trim-to-polygon splitter writes the area.poly with the aligned coordinates. Reg. the complex algo : I think it will not help in your case, but it might be a solution for those that are running out of memory. I will not code that unless there is a real need, because the solution that I have in mind would add a lot of complexity. OK? Gerd -- View this message in context: http://gis.19327.n5.nabble.com/issues-with-tile-boundaries-tp5753275p5753477... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Gerd wrote:
I see these options to help in your case: 1) Complex: Implement an algorithm in splitter which does something similar to your approach: Partition the input file into a few large areas and calculate each partition seperately.
Maybe you can use N1 and M1 poly's as example?
the polygons in N1 and M1 are not aligned, but with the new parameter --no-trim-to-polygon splitter writes the area.poly with the aligned coordinates.
Reg. the complex algo : I think it will not help in your case, but it might be a solution for those that are running out of memory. I will not code that unless there is a real need, because the solution that I have in mind would add a lot of complexity. OK?
Hi Gerd, Yes thats fine. I found out that the --no-trim-to-polygon makes a good division of tiles if I split Europe step by stip, so first N1 until stop after split, use the area.poly to adjust M1.poly and then proceed with that M1.poly etc About the densities file I'm not sure what you mean with that. Do I have to copy it to densities_N1.txt and can I use it the next splitting step for N1 when I use --split-file=areas_N1.list (renamed back to densities.txt?)
Hi Minko,
About the densities file I'm not sure what you mean with that. Do I have to copy it to densities_N1.txt and can I use it the next splitting step for N1 when I use --split-file=areas_N1.list (renamed back to densities.txt?)
no, if you use the split-file parm then splitter doesn't need that info. I thought that you run splitter seven times with the different poly files and the same large Europe.osm.pbf. Each execution will do exactly the same work in the 1st phase, and the result will also be the same (you can compare the different densities files. So, a possible solution to speed up processing would be this: osmconvert --drop-version europe.osm.pbf -o=europe.o5m java -Xmx1000m -jar splitter.jar --stop-after=split europe.o5m move densities_out.txt densities.txt java -Xmx2G -jar splitter.jar --polygon-file=p1.poly ... europe.o5m java -Xmx2G -jar splitter.jar --polygon-file=p2.poly ... europe.o5m Whenever you update the europe.o5m you must create a new densities.txt. Gerd
Gerd wrote:
no, if you use the split-file parm then splitter doesn't need that info. I thought that you run splitter seven times with the different poly files and the same large Europe.osm.pbf. Each execution will do exactly the same work in the 1st phase, and the result will also be the same (you can compare the different densities files.
Thanks, I see what you mean, I never noticed what that file meant. I thought since I have created all areas.lists now, it would be faster to run the splitter on each areas.list file that I have created. For next update I can safely use the poly files, but before this --no-trim-to-polygon, I was never sure if the splitter created areas which would fit together.
Hi Gerd, I think the --no-trim-to-polygon patch works as expected! :-) Tile boundaries are now a multiple value of 2048, I only need to adjust each following polygon after I have done (or at least stop after split) a session, but the resulting areas.lists seem to match now. Next thing is to split the whole map and run mkgmap again to see if the artifacts are gone. To be continued...
2) Simple: Implement a parm that tells splitter not to trim the tiles to the polygon boundaries. Since splitter initially generates tiles which are aligned this might help. is implemented in the attached patch. You have to add parm --no-trim-to-polygon to activate this. The binary is available here: http://files.mkgmap.org.uk/download/90/splitter.jar
Gerd
Hi Minko, Minko-2 wrote
Hi Gerd, I think the --no-trim-to-polygon patch works as expected! :-) Tile boundaries are now a multiple value of 2048, I only need to adjust each following polygon after I have done (or at least stop after split) a session, but the resulting areas.lists seem to match now.
Next thing is to split the whole map and run mkgmap again to see if the artifacts are gone. To be continued...
good to hear. Maybe this is helpful for you: At the end of the 1st phase splitter writes the file densities-out.txt to the output directory. This was meant to be used as a debugging aid for me, but it may save some time for you as well. You can rename the file to densities.txt and copy it to the working directory of splitter. If splitter finds such a file, it will not read the OSM input for phase 1, instead it uses this file to calculate the split areas. A message like reading density data from D:\eclipse_workspace\splitter\densities.txt is printed to stderr to tell you this. Gerd -- View this message in context: http://gis.19327.n5.nabble.com/issues-with-tile-boundaries-tp5753275p5753473... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi On 16/03/13 09:09, Gerd Petermann wrote:
1) According to Steve the alignment to 2048 units is not mandantory, the ony important point is that you don't have gaps.
To be clear - I mean its not mandatory in the format. It may not work well with splitter/mkgmap without code changes. ..Steve
Hi Steve, Steve Ratcliffe wrote
On 16/03/13 09:09, Gerd Petermann wrote:
1) According to Steve the alignment to 2048 units is not mandantory, the ony important point is that you don't have gaps.
To be clear - I mean its not mandatory in the format. It may not work well with splitter/mkgmap without code changes.
do you think that we don't need any alignment in the tiles generated by splitter or is it only the value 2048 which might be changed? Gerd -- View this message in context: http://gis.19327.n5.nabble.com/issues-with-tile-boundaries-tp5753275p5753743... Sent from the Mkgmap Development mailing list archive at Nabble.com.
I mentioned this problem of rounding off with v small maps , ie area <5km^2 before as it causes the basemap not to match the min max of the map itself. However changing the values in the tdb has no effect I've had to match the values in the 'overview.img' to those found in the actual img . Then it works - the problem occurred about a year a go. ..Nick -- View this message in context: http://gis.19327.n5.nabble.com/issues-with-tile-boundaries-tp5753275p5754286... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi Nick, n Willink wrote
I've had to match the values in the 'overview.img' to those found in the actual img . Then it works - the problem occurred about a year a go.
I think this is what the patch does. Gerd -- View this message in context: http://gis.19327.n5.nabble.com/issues-with-tile-boundaries-tp5753275p5754291... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi Gerd, I have downloaded a small map.osm with openstreetmap.org (export tab) With mkgmap r2526 it looks like this: https://dl.dropbox.com/u/64716698/OSM/mkgmap/mkgmap2526.jpg The background/overview map is totally offset. With the patch, I only see the background map, nothing else. The overview map seems covering the whole map now, because I can see the details when I look at the img file with GPSmapedit.
Hi Minko, do you see the details when you zoom in? Gerd Minko-2 wrote
Hi Gerd, I have downloaded a small map.osm with openstreetmap.org (export tab) With mkgmap r2526 it looks like this: https://dl.dropbox.com/u/64716698/OSM/mkgmap/mkgmap2526.jpg
The background/overview map is totally offset.
With the patch, I only see the background map, nothing else. The overview map seems covering the whole map now, because I can see the details when I look at the img file with GPSmapedit. _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/issues-with-tile-boundaries-tp5753275p5754311... Sent from the Mkgmap Development mailing list archive at Nabble.com.
No there is nothing on the map... I tried it with the default style, no custom background, didnt use precomp-sea I cannot select and send the map to the device, too I placed your mkgmap.jar file into the mkgmap-r2526 folder and renamed it.
do you see the details when you zoom in?
Gerd
I tried it now with a bigger o5m file produced by the splitter, then it looks ok. So somehow it cannot process a small osm file exported from osm.org?
Hi Minko, Minko-2 wrote
I tried it now with a bigger o5m file produced by the splitter, then it looks ok. So somehow it cannot process a small osm file exported from osm.org? _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
yes, there seems to be a minimum tile size limit. I can reproduce your results, trying now to understand what happens... Gerd -- View this message in context: http://gis.19327.n5.nabble.com/issues-with-tile-boundaries-tp5753275p5754328... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi Gert What Minko is referring to has been happening for quite a while. As I said , the solution is quite simple, by taking the n s e w values of the map and use them to create an overview map. Some how these values are shifted with smaller maps. Unfortunately, I'm not a java man to help you ..Nick -- View this message in context: http://gis.19327.n5.nabble.com/issues-with-tile-boundaries-tp5753275p5754331... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi, okay, here is version two of the patch. The problem with the 1st version is that very small background polygons are simply dropped by the filters. TdbBuilder_v2.patch <http://gis.19327.n5.nabble.com/file/n5754335/TdbBuilder_v2.patch> It uses the unchanged bbox of the input file if that is large enough, else it places the bbox in the middle of a overview map that is just large enough. The patched binary is here: http://files.mkgmap.org.uk/download/93/mkgmap.jar Gerd -- View this message in context: http://gis.19327.n5.nabble.com/issues-with-tile-boundaries-tp5753275p5754335... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi Gerd, Looks better now: https://dl.dropbox.com/u/64716698/OSM/mkgmap/map.jpg Only the overview map is bigger than the tile, but the tile is at least within the overview map now.
okay, here is version two of the patch. The problem with the 1st version is that very small background polygons are simply dropped by the filters.
TdbBuilder_v2.patch <http://gis.19327.n5.nabble.com/file/n5754335/TdbBuilder_v2.patch>
Hi Gerd, I have another related (cosmetic) issue with tile borders which exists already some time (november 2011) but maybe you can have a look at it? You can see the issue on every map in Mapsource when you select the tiles. They get a yellow border, but not only in the outlines, but sometimes inside the tiles too. See https://dl.dropbox.com/u/64716698/OSM/mkgmap/tileborders1.jpg In Basecamp, you can see it as thin blue lines, when you browse a gmapsupp.img from micro Sd card or GPS: https://dl.dropbox.com/u/64716698/OSM/mkgmap/tileborders2.jpg When you zoom on it, sometimes the map disappears, but the maps are still routable. https://dl.dropbox.com/u/64716698/OSM/mkgmap/tileborders3.jpg As far as I know, it is not style or typ file related. It happened after this patch was committed: http://www.mail-archive.com/mkgmap-dev@lists.mkgmap.org.uk/msg10872.html It fixed the transparency of the gmapsupp.img and "ghost shading" of the overview map in mapsource.
Hi Minko, I looked at this and I think that I know the reason for these problems: A typical tile produced by splitter is split into several sub divisions. Each sub division has a bounding box, and the coords of the background polygon are saved as rounded offsets to the subdivision bbox. If I got this right, the problem occurs because sometimes the rounded values differ. I guess this could also explain the white lines in the sea. I don't know yet if or where this can be fixed... Gerd Minko-2 wrote
Hi Gerd,
I have another related (cosmetic) issue with tile borders which exists already some time (november 2011) but maybe you can have a look at it?
You can see the issue on every map in Mapsource when you select the tiles. They get a yellow border, but not only in the outlines, but sometimes inside the tiles too. See https://dl.dropbox.com/u/64716698/OSM/mkgmap/tileborders1.jpg
In Basecamp, you can see it as thin blue lines, when you browse a gmapsupp.img from micro Sd card or GPS: https://dl.dropbox.com/u/64716698/OSM/mkgmap/tileborders2.jpg
When you zoom on it, sometimes the map disappears, but the maps are still routable. https://dl.dropbox.com/u/64716698/OSM/mkgmap/tileborders3.jpg
As far as I know, it is not style or typ file related.
It happened after this patch was committed: http://www.mail-archive.com/
mkgmap-dev@.org
/msg10872.html
It fixed the transparency of the gmapsupp.img and "ghost shading" of the overview map in mapsource. _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/issues-with-tile-boundaries-tp5753275p5754449... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Thanks Gerd, at least good to know where it is caused by. It's a cosmetic problem not affecting the routing or visible on the GPS (as far as I know)
Hi, I think I found a good solution. The coordinates within a subdivision are encoded as rounded offsets to the center point of the bbox of the subdivision. The rounding problem occurs when a shape is divided so that one part is in one subdiv x and the other in y. If the coordinate of the line saved with x is rounded down and the same coordinate is rounded up for y, you see a gap (the blue line in BaseCamp). The attached patch moves the center points a little bit so that they are aligned. align_subdiv_center_v1.patch <http://gis.19327.n5.nabble.com/file/n5754516/align_subdiv_center_v1.patch> The compiled binary with both the TdbBuilder_v2.patch and align_subdiv_center_v1.patch can be downloaded here: http://files.mkgmap.org.uk/download/94/mkgmap.jar I tested it only for a part of Germany. Gerd Minko-2 wrote
Thanks Gerd, at least good to know where it is caused by. It's a cosmetic problem not affecting the routing or visible on the GPS (as far as I know) _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/issues-with-tile-boundaries-tp5753275p5754516... Sent from the Mkgmap Development mailing list archive at Nabble.com.
The maps are much better now Gerd! All the tile artefacts are gone :-)
The attached patch moves the center points a little bit so that they are aligned.
align_subdiv_center_v1.patch <http://gis.19327.n5.nabble.com/file/n5754516/align_subdiv_center_v1.patch>
The compiled binary with both the TdbBuilder_v2.patch and align_subdiv_center_v1.patch can be downloaded here: http://files.mkgmap.org.uk/download/94/mkgmap.jar
I tested it only for a part of Germany.
Gerd
Hi Gerd, I tested the patch now on my whole Benelux map -no white stripes in the sea anymore -no yellow lines within the tiles anymore when selecting the tiles -no blue lines in Basecamp anymore when viewing the gmapsupp.img in Basecamp -everything else is working as expected, on the pc as well on 3 tested units (Nuvi, Dakota, Etrex) So I think it is worth to commit. Do you think the other patch that fixes the aligning of the overview map is safe to commit too?
Hi Minko, thanks for the feedback. I want to check first if I have to change the checks in the split algo. The current checks use the dimensension of the bbox, but with the patch the value may be increased, so we may hit some edge cases now. Gerd Minko-2 wrote
Hi Gerd, I tested the patch now on my whole Benelux map -no white stripes in the sea anymore -no yellow lines within the tiles anymore when selecting the tiles -no blue lines in Basecamp anymore when viewing the gmapsupp.img in Basecamp -everything else is working as expected, on the pc as well on 3 tested units (Nuvi, Dakota, Etrex)
So I think it is worth to commit.
Do you think the other patch that fixes the aligning of the overview map is safe to commit too? _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/issues-with-tile-boundaries-tp5753275p5754578... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi Minko, both patches are committed now. I was not able to produce a test case where the patched version is more likely to cause problems and we know many cases where it works better. So let's see... Gerd Minko-2 wrote
Hi Gerd, I tested the patch now on my whole Benelux map -no white stripes in the sea anymore -no yellow lines within the tiles anymore when selecting the tiles -no blue lines in Basecamp anymore when viewing the gmapsupp.img in Basecamp -everything else is working as expected, on the pc as well on 3 tested units (Nuvi, Dakota, Etrex)
So I think it is worth to commit.
Do you think the other patch that fixes the aligning of the overview map is safe to commit too? _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/issues-with-tile-boundaries-tp5753275p5754601... Sent from the Mkgmap Development mailing list archive at Nabble.com.
participants (5)
-
Gerd Petermann -
GerdP
-
Minko -
n Willink -
Steve Ratcliffe