[mkgmap-dev] How to handle missing hgt files or files with voids?
Hi all, 1) The current code (only) writes a log message with severity WARNING for a missing hgt file: "file xxx.hgt not found. Is expected to cover sea." I wonder if we can create a list of files that can exist or maybe a polygon that can be tested so that tiles which are knwon to cover land are reported as errors. When you look at http://viewfinderpanoramas.org/Coverage%20map%20viewfinderpanoramas_org3.htm you can see that such a polygon would be quite complex. Did anybody already try to define such a polygon or list of files that would cover only ocean? 2) Should mkgmap print a warning when voids in the hgt file(s) have an influence on the DEM data? I think yes, but it is a bit more complex to measure the real effect. Reason: We read the 4 hgt values next to the wanted DEM point and use interpolation to calculate the height that is stored in the DEM file. If one or two of the 4 points are voids they may still have no influence if the wanted point is very close to one that is not a void. Another problem is that a single void might be used several times. So, another option would be to add an option like --dem-check-hgt which could read all existing hgt files and report the number of voids for each. I'd prefer this because it would have no impact on performance for normal processing. Or maybe there is already a tool for this that works on all platforms (win,linux,mac) ? Comments? Gerd ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] HGT - getElevation()
Hi Andrzej, I think your patch increases the box too much. I think we only need an aligned upper left corner. See my attached version. Still, even with my patch DEM size can increase quite a lot. I've created a map of bolivia with without --dem-dists option. Size of gmap folder: 223.511k with r4061 238.940k with r4061 + your patch 238.882k with r4061 + my patch So, we have +15 MB for DEM with this alignment. I assume that the increase depends on the areas.list, so maybe my one is a worse case. Wouldn't it be better to change splitter so that it aligns tiles to HGT raster? Gerd Von: mkgmap-dev im Auftrag von Andrzej Popowski Gesendet: Sonntag, 14. Januar 2018 16:46:29 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] HGT - getElevation() Hi Gerd, > you just want to achive that the calculated postions are as close as > possible to the positions in the hgt file Yes. Linear interpolation is averaging too. If DEM can use exact values form HGT, then there will be no averaging. Even interpolated values near HGT node should be the same, because of rounding to 1m. I have limited aligning to resolution better or equal 1200 and prepared HGT area for worst case, which would be 1200. Patch attached. -- Best regards, Andrzej dem-align-2b.patch Description: dem-align-2b.patch areas.list Description: areas.list ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] v4058 dem-tdb crashes
Hi Andrzej, thanks, fixed with r4061: http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4061 Gerd Von: mkgmap-dev im Auftrag von Andrzej Popowski Gesendet: Montag, 15. Januar 2018 00:28:45 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] v4058 dem-tdb crashes Hi, addition: mkgmap compiles this example, if I remove --dem-dists. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] v4058 dem-tdb crashes
Hi, addition: mkgmap compiles this example, if I remove --dem-dists. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] v4058 dem-tdb crashes
Hi Gerd, I have uploaded example at http://files.mkgmap.org.uk/download/392/test-crash.7z. java.lang.IndexOutOfBoundsException at java.nio.Buffer.checkIndex(Unknown Source) at java.nio.DirectByteBuffer.getShort(Unknown Source) at uk.me.parabola.mkgmap.reader.hgt.HGTReader.ele(HGTReader.java:203) at uk.me.parabola.mkgmap.reader.hgt.HGTConverter.getElevation(HGTConverter.java:108) at uk.me.parabola.mkgmap.reader.hgt.HGTConverter.getHeights(HGTConverter.java:302) at uk.me.parabola.imgfmt.app.dem.DEMSection.calcTiles(DEMSection.java:127) at uk.me.parabola.imgfmt.app.dem.DEMSection.(DEMSection.java:74) at uk.me.parabola.imgfmt.app.dem.DEMFile.calc(DEMFile.java:96) at uk.me.parabola.mkgmap.build.MapBuilder.makeMap(MapBuilder.java:322) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:107) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:69) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:263) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:259) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) Exiting - if you want to carry on regardless, use the --keep-going option -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] r4046: new algo for background (0x4b) in overview map
Canary Islands contains a single tile, that's why I saw no effect:-[ Spain map now has non-rectangular overview covering only map tiles. No mouse hover, as reported by Henning. El 14/01/18 a las 19:12, Gerd Petermann escribió: Hi Carlos, if your map contains multiple tiles that form a rectangular shape than the 0x4b polygons are combined again into one rectangle by ShapeMerger. Your map of spain looked different (empty area in part of portugal), so in that map you should see a different 0x4b polygon. Gerd Von: mkgmap-dev im Auftrag von Carlos Dávila Gesendet: Sonntag, 14. Januar 2018 18:45:09 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] r4046: new algo for background (0x4b) in overview map MapEdit shows a rectangular map coverage area polygon from r4056, see attached screenshot. May be I'm doing something wrong. El 14/01/18 a las 18:23, Gerd Petermann escribió: Hi all, thanks for testing. Size changes can be caused by block-size change, but also a non-rectangular shape requires a few more bytes. You can use GpsMapEdit to check this. I'll continue experimenting with non-rectangular 0x4a an d0x4b shapes during the next days. Gerd Von: mkgmap-dev im Auftrag von Carlos Dávila Gesendet: Sonntag, 14. Januar 2018 17:57:42 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] r4046: new algo for background (0x4b) in overview map I have tested single layer map and also OSM layer+contour (transparent) layer, and I don't see any difference in MapSource. Contour lines are cut with the same poly than OSM data. Only difference is that overview img is slightly larger with r4056 vs r4051 in my test map (Canary Islands), but I guess it's due to commit 4054. El 14/01/18 a las 12:54, Gerd Petermann escribió: Hi Henning, I would expect differences when you combine a normal map with transparent tiles containing contour lines and those tiles overlap the normal tiles. Gerd Von: mkgmap-dev im Auftrag von Henning Scholland Gesendet: Sonntag, 14. Januar 2018 12:52:04 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] r4046: new algo for background (0x4b) in overview map With using --transparent I can't see any differences compared to older mkgmap versions. Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] r4046: new algo for background (0x4b) in overview map
Hi Carlos, if your map contains multiple tiles that form a rectangular shape than the 0x4b polygons are combined again into one rectangle by ShapeMerger. Your map of spain looked different (empty area in part of portugal), so in that map you should see a different 0x4b polygon. Gerd Von: mkgmap-dev im Auftrag von Carlos Dávila Gesendet: Sonntag, 14. Januar 2018 18:45:09 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] r4046: new algo for background (0x4b) in overview map MapEdit shows a rectangular map coverage area polygon from r4056, see attached screenshot. May be I'm doing something wrong. El 14/01/18 a las 18:23, Gerd Petermann escribió: > Hi all, > > thanks for testing. Size changes can be caused by block-size change, but also > a non-rectangular shape requires a few more bytes. > You can use GpsMapEdit to check this. > I'll continue experimenting with non-rectangular 0x4a an d0x4b shapes during > the next days. > > Gerd > > > Von: mkgmap-dev im Auftrag von > Carlos Dávila > Gesendet: Sonntag, 14. Januar 2018 17:57:42 > An: mkgmap-dev@lists.mkgmap.org.uk > Betreff: Re: [mkgmap-dev] r4046: new algo for background (0x4b) in overview > map > > I have tested single layer map and also OSM layer+contour (transparent) > layer, and I don't see any difference in MapSource. Contour lines are > cut with the same poly than OSM data. Only difference is that overview > img is slightly larger with r4056 vs r4051 in my test map (Canary > Islands), but I guess it's due to commit 4054. > > El 14/01/18 a las 12:54, Gerd Petermann escribió: >> Hi Henning, >> >> I would expect differences when you combine a normal map with transparent >> tiles containing contour lines >> and those tiles overlap the normal tiles. >> >> Gerd >> >> >> Von: mkgmap-dev im Auftrag von >> Henning Scholland >> Gesendet: Sonntag, 14. Januar 2018 12:52:04 >> An: mkgmap-dev@lists.mkgmap.org.uk >> Betreff: Re: [mkgmap-dev] r4046: new algo for background (0x4b) in overview >> map >> >> With using --transparent I can't see any differences compared to older >> mkgmap versions. >> >> Henning >> > ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] r4046: new algo for background (0x4b) in overview map
MapEdit shows a rectangular map coverage area polygon from r4056, see attached screenshot. May be I'm doing something wrong. El 14/01/18 a las 18:23, Gerd Petermann escribió: Hi all, thanks for testing. Size changes can be caused by block-size change, but also a non-rectangular shape requires a few more bytes. You can use GpsMapEdit to check this. I'll continue experimenting with non-rectangular 0x4a an d0x4b shapes during the next days. Gerd Von: mkgmap-dev im Auftrag von Carlos Dávila Gesendet: Sonntag, 14. Januar 2018 17:57:42 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] r4046: new algo for background (0x4b) in overview map I have tested single layer map and also OSM layer+contour (transparent) layer, and I don't see any difference in MapSource. Contour lines are cut with the same poly than OSM data. Only difference is that overview img is slightly larger with r4056 vs r4051 in my test map (Canary Islands), but I guess it's due to commit 4054. El 14/01/18 a las 12:54, Gerd Petermann escribió: Hi Henning, I would expect differences when you combine a normal map with transparent tiles containing contour lines and those tiles overlap the normal tiles. Gerd Von: mkgmap-dev im Auftrag von Henning Scholland Gesendet: Sonntag, 14. Januar 2018 12:52:04 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] r4046: new algo for background (0x4b) in overview map With using --transparent I can't see any differences compared to older mkgmap versions. Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] r4046: new algo for background (0x4b) in overview map
Hi all, thanks for testing. Size changes can be caused by block-size change, but also a non-rectangular shape requires a few more bytes. You can use GpsMapEdit to check this. I'll continue experimenting with non-rectangular 0x4a an d0x4b shapes during the next days. Gerd Von: mkgmap-dev im Auftrag von Carlos Dávila Gesendet: Sonntag, 14. Januar 2018 17:57:42 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] r4046: new algo for background (0x4b) in overview map I have tested single layer map and also OSM layer+contour (transparent) layer, and I don't see any difference in MapSource. Contour lines are cut with the same poly than OSM data. Only difference is that overview img is slightly larger with r4056 vs r4051 in my test map (Canary Islands), but I guess it's due to commit 4054. El 14/01/18 a las 12:54, Gerd Petermann escribió: > Hi Henning, > > I would expect differences when you combine a normal map with transparent > tiles containing contour lines > and those tiles overlap the normal tiles. > > Gerd > > > Von: mkgmap-dev im Auftrag von > Henning Scholland > Gesendet: Sonntag, 14. Januar 2018 12:52:04 > An: mkgmap-dev@lists.mkgmap.org.uk > Betreff: Re: [mkgmap-dev] r4046: new algo for background (0x4b) in overview > map > > With using --transparent I can't see any differences compared to older > mkgmap versions. > > Henning > ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] r4046: new algo for background (0x4b) in overview map
I have tested single layer map and also OSM layer+contour (transparent) layer, and I don't see any difference in MapSource. Contour lines are cut with the same poly than OSM data. Only difference is that overview img is slightly larger with r4056 vs r4051 in my test map (Canary Islands), but I guess it's due to commit 4054. El 14/01/18 a las 12:54, Gerd Petermann escribió: Hi Henning, I would expect differences when you combine a normal map with transparent tiles containing contour lines and those tiles overlap the normal tiles. Gerd Von: mkgmap-dev im Auftrag von Henning Scholland Gesendet: Sonntag, 14. Januar 2018 12:52:04 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] r4046: new algo for background (0x4b) in overview map With using --transparent I can't see any differences compared to older mkgmap versions. Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] HGT - getElevation()
Hi Gerd,
> you just want to achive that the calculated postions are as close as
> possible to the positions in the hgt file
Yes. Linear interpolation is averaging too. If DEM can use exact values
form HGT, then there will be no averaging. Even interpolated values near
HGT node should be the same, because of rounding to 1m.
I have limited aligning to resolution better or equal 1200 and prepared
HGT area for worst case, which would be 1200. Patch attached.
--
Best regards,
Andrzej
Index: src/uk/me/parabola/imgfmt/app/dem/DEMFile.java
===
--- src/uk/me/parabola/imgfmt/app/dem/DEMFile.java (revision 4056)
+++ src/uk/me/parabola/imgfmt/app/dem/DEMFile.java (working copy)
@@ -22,6 +22,7 @@
import uk.me.parabola.imgfmt.app.ImgFileWriter;
import uk.me.parabola.imgfmt.fs.ImgChannel;
import uk.me.parabola.mkgmap.reader.hgt.HGTConverter;
+import uk.me.parabola.imgfmt.Utils;
/**
* The DEM file. This consists of information about elevation. It is used for
hill shading
@@ -52,9 +53,43 @@
* @param outsidePolygonHeight the height value that should be used for
points outside of the bounding polygon
*/
public void calc(Area area, java.awt.geom.Area demPolygonMapUnits,
String pathToHGT, List pointDistances, short outsidePolygonHeight) {
- HGTConverter hgtConverter = new HGTConverter(pathToHGT, area,
demPolygonMapUnits);
+ double top = Utils.toDegrees(area.getMaxLat());
+ double bottom = Utils.toDegrees(area.getMinLat());
+ double left = Utils.toDegrees(area.getMinLong());
+ double right = Utils.toDegrees(area.getMaxLong());
+
+ // expand HGT area for aligning with resolution 1200
+ double hgtDis = 1.0D/1200;
+ double hgtTop = Math.ceil(top/hgtDis)*hgtDis;
+ double hgtBottom = Math.floor(bottom/hgtDis)*hgtDis;
+ double hgtLeft = Math.floor(left/hgtDis)*hgtDis;
+ double hgtRight = Math.ceil(right/hgtDis)*hgtDis;
+ Area hgtArea = new Area(hgtBottom, hgtLeft, hgtTop, hgtRight);
+
+ HGTConverter hgtConverter = new HGTConverter(pathToHGT,
hgtArea, demPolygonMapUnits);
hgtConverter.setOutsidePolygonHeight(outsidePolygonHeight);
+ int res = hgtConverter.getHighestRes();
+ if (res >= 1200) {
+ if (pointDistances.get(0) == -1 ||
pointDistances.get(0) == (int) ((1 << 29) / (res * 45))) {
+ // align area with HGT raster
+ if (res == 1200) {
+ // already calculated
+ area = hgtArea;
+ }
+ else {
+ hgtDis = 1.0D/res;
+ top = Math.ceil(top/hgtDis)*hgtDis;
+ bottom =
Math.floor(bottom/hgtDis)*hgtDis;
+ left = Math.floor(left/hgtDis)*hgtDis;
+ right = Math.ceil(right/hgtDis)*hgtDis;
+
+ area = new Area(bottom, left, top,
right);
+ }
+ System.out.println("DEM aligned to HGT,
resolution " + res);
+ }
+ }
+
int zoom = 0;
int lastDist = pointDistances.get(pointDistances.size()-1);
for (int pointDist : pointDistances) {
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] HGT - getElevation()
Hi Andrzej, If I got that right you just want to achive that the calculated postions are as close as possible to the positions in the hgt file. If you request a point that is not within the original area I would expect trouble (either NPE or wrong height 0). If that can happen, you should create a new hgtConverter. Gerd Von: mkgmap-dev im Auftrag von Andrzej Popowski Gesendet: Sonntag, 14. Januar 2018 16:10:36 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] HGT - getElevation() Hi Gerd, > why you don't use the modified area for the hgtConverter as well? I need HGT resolution first. I guess resolution comes after initialization of hgtConverter. Probably area for hgtConverter should be expanded, or maybe initialized with a bit bigger area? -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] HGT - getElevation()
Hi Gerd, > why you don't use the modified area for the hgtConverter as well? I need HGT resolution first. I guess resolution comes after initialization of hgtConverter. Probably area for hgtConverter should be expanded, or maybe initialized with a bit bigger area? -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] HGT - getElevation()
Hi Andrzej, did not try the patch but I wonder why you don't use the modified area for the hgtConverter as well? Gerd Von: mkgmap-dev im Auftrag von Andrzej Popowski Gesendet: Sonntag, 14. Januar 2018 14:29:57 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] HGT - getElevation() Hi Gerd, I have attempted to reduce interpolation, when DEM pixel size is the same as HGT pixel. I have stretched a bit area of DEM, so edges are aligned with HGT. I'm attaching a patch. Resulting map looks similar, only shading has moved a bit. I'm not sure if this is the result of differences in interpolation or maybe change introduced by moving DEM borders. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] HGT - getElevation()
Hi Gerd,
I have attempted to reduce interpolation, when DEM pixel size is the
same as HGT pixel. I have stretched a bit area of DEM, so edges are
aligned with HGT. I'm attaching a patch.
Resulting map looks similar, only shading has moved a bit. I'm not sure
if this is the result of differences in interpolation or maybe change
introduced by moving DEM borders.
--
Best regards,
Andrzej
Index: src/uk/me/parabola/imgfmt/app/dem/DEMFile.java
===
--- src/uk/me/parabola/imgfmt/app/dem/DEMFile.java (revision 4056)
+++ src/uk/me/parabola/imgfmt/app/dem/DEMFile.java (working copy)
@@ -22,6 +22,7 @@
import uk.me.parabola.imgfmt.app.ImgFileWriter;
import uk.me.parabola.imgfmt.fs.ImgChannel;
import uk.me.parabola.mkgmap.reader.hgt.HGTConverter;
+import uk.me.parabola.imgfmt.Utils;
/**
* The DEM file. This consists of information about elevation. It is used for
hill shading
@@ -55,6 +56,26 @@
HGTConverter hgtConverter = new HGTConverter(pathToHGT, area,
demPolygonMapUnits);
hgtConverter.setOutsidePolygonHeight(outsidePolygonHeight);
+ int res = hgtConverter.getHighestRes();
+ if (res > 0) {
+ if (pointDistances.get(0) == -1 ||
pointDistances.get(0) == (int) ((1 << 29) / (res * 45))) {
+ // align area with HGT raster
+ double hgtDis = 1.0D/res;
+ double top = Utils.toDegrees(area.getMaxLat());
+ double bottom =
Utils.toDegrees(area.getMinLat());
+ double left =
Utils.toDegrees(area.getMinLong());
+ double right =
Utils.toDegrees(area.getMaxLong());
+
+ top = Math.ceil(top/hgtDis)*hgtDis;
+ bottom = Math.floor(bottom/hgtDis)*hgtDis;
+ left = Math.floor(left/hgtDis)*hgtDis;
+ right = Math.ceil(right/hgtDis)*hgtDis;
+
+ area = new Area(bottom, left, top, right);
+ //System.out.println("DEM aligned to HGT");
+ }
+ }
+
int zoom = 0;
int lastDist = pointDistances.get(pointDistances.size()-1);
for (int pointDist : pointDistances) {
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] r4046: new algo for background (0x4b) in overview map
Hi Henning, I would expect differences when you combine a normal map with transparent tiles containing contour lines and those tiles overlap the normal tiles. Gerd Von: mkgmap-dev im Auftrag von Henning Scholland Gesendet: Sonntag, 14. Januar 2018 12:52:04 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] r4046: new algo for background (0x4b) in overview map With using --transparent I can't see any differences compared to older mkgmap versions. Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] r4046: new algo for background (0x4b) in overview map
With using --transparent I can't see any differences compared to older mkgmap versions. Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] r4046: new algo for background (0x4b) in overview map
Hi Gerd, seems to work for me, but I also don't know what I should expect to see. In BaseCamp/MapSource the map is still in rectangle shape with light yellow coloured back ground in the area without data. Only difference is, that there is no more mouse over, indicating the mouse is in 'Unbekanntem Gebiet' (unknown area). I'm not using --transparent option, as I remember there was a recommendation to don't use it. I will also try again with --transparent option and let you know later. Henning On 14.01.2018 15:19, Gerd Petermann wrote: > Hi all, > > see http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4056 > > I am not sure how this works when you combine tiles that were created with > the --transparent option > with tiles that have a background, esp. if they cover different areas. > Please test and report . > > Gerd > ___ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] what do the 0x4a polygon in the mean?
Hi Andrzej, ah, okay, so I looked at the DEM data created by GMapTool. I already wondered where this came from ;-) So forget those findings for Winter Activity Map. Still, Adria map seems to use the same trick, just not so strange values. Gerd Von: mkgmap-dev im Auftrag von Andrzej Popowski Gesendet: Sonntag, 14. Januar 2018 11:49:24 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] what do the 0x4a polygon in the mean? Hi Gerd, do you have overview for Winter Activity Map? I have never seen Winter map for PC, only gmapsupp.img. Maybe it is an overview created by GMapTool, check copyright in TRE. I have included procedure for creating empty DEM in GMapTool, which is using different distances. Actually it used to create too big area of DEM, I have just released correction. You shouldn't use it as reference. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] what do the 0x4a polygon in the mean?
Hi Gerd, do you have overview for Winter Activity Map? I have never seen Winter map for PC, only gmapsupp.img. Maybe it is an overview created by GMapTool, check copyright in TRE. I have included procedure for creating empty DEM in GMapTool, which is using different distances. Actually it used to create too big area of DEM, I have just released correction. You shouldn't use it as reference. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] what do the 0x4a polygon in the mean?
Hi Andrzej, thanks for the hints. It seems indeed to be an alternative to use a very large overview-dem-dist value in combination with no DEM data. Garmin uses this in the "Winterkarte" and in the Adria Map. Also, the overview map of "Winterkarte" is the first map that I found in which dem-dist for lat and lon ar different: map units between points (latitude): 86517760 map units between points (longitude): 205701120 Maybe I change meaning of option --overview-dem-dist=0 to produce this special small DEM file instead of no DEM. Gerd Von: mkgmap-dev im Auftrag von Andrzej Popowski Gesendet: Samstag, 13. Januar 2018 17:24:35 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] what do the 0x4a polygon in the mean? Hi Gerd, > 1) don't add DEM to overview map (a work around) Maybe it would work, but I remember getting problems with overview without DEM (I forgot what it was, maybe even not because of DEM?). I think it would be better to add what I call "empty DEM" instead. The empty DEM layer contains 4 bytes of data: 0 0 0 2 Header of a layer is the same, tiles are 64*64, but there is no tiles, only extra rows and columns. Word defining structure (recordDesc) is 0x10 00. Number of rows and columns is small, like for example 4, and distance between points is big. You can see this in Adria Topo. There is update here, which can be installed on PC (including Mapsource): http://www.garminbh.ba/Default.aspx?sifraStranica=354&kultura=en Link to map doesn't work because of redirections, but you can extract final address from link and download map. You can even browse map in Mapsource, if you provide unlock key: DEMO > 2) use a slightly smaller polygon This is other solution of Garmin, but they use bigger polygon in overview, increased by about 700m outside. So jaggies are far from map details. > 3) Find a flag or something else that tells the PC program that it should stop rendering the overview DEM at some level. I doubt it is possible. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
