Hi, I have looked at code and get some doubts. File HGTConverter.java, function getElevation(). Shouldn't conversion double -> int use Math.floor? I mean these lines: int row = (int) ((lat32 - minLat32) * FACTOR); int col = (int) ((lon32 - minLon32) * FACTOR); int xLeft = (int) x1; int yBottom = (int) y1; I'm not sure, but I think, you won't get left/bottom value of coordinate for negative number. -- Best regards, Andrzej
Hi, correction - these values never are negative? -- Best regards, Andrzej
Hi Andrzej, thanks for reviewing the code. Yes, they should never be negative. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Andrzej Popowski <popej@poczta.onet.pl> Gesendet: Dienstag, 9. Januar 2018 13:30:35 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] HGT - getElevation() Hi, correction - these values never are negative? -- Best regards, Andrzej _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd, I'm trying to find if resolution can be better. I think current interpolation is not good. Imagine two combination of 4-points heights from HGT with values like: 1 0 0 7 and 0 1 7 0 For a point in the middle of rectangle, current interpolation would give result 0 in first case and 4 in second, while I would expect 2 in both cases. I think the code, which calculates interpolation based on 3 points, should be used only if the forth is void. There could be 3 combinations of triangles in this case. But if all 4 points are valid, there should be applied standard bilinear interpolation. Something like: if (hlb == HGTReader.UNDEF) { return triangle(... } if (hrb == HGTReader.UNDEF) { return triangle(... } if (hlt == HGTReader.UNDEF) { return triangle(... } if (hrt == HGTReader.UNDEF) { return triangle(... } // 4 points valid return bilinear(... -- Best regards, Andrzej
Hi Andrzej, to be honest I did not understand the math, that's why I've copied the code from Frank. Maybe I've done something wrong with the calculation of dx and dy. Do you think that Franks code has the same problem? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Andrzej Popowski <popej@poczta.onet.pl> Gesendet: Dienstag, 9. Januar 2018 15:45:14 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] HGT - getElevation() Hi Gerd, I'm trying to find if resolution can be better. I think current interpolation is not good. Imagine two combination of 4-points heights from HGT with values like: 1 0 0 7 and 0 1 7 0 For a point in the middle of rectangle, current interpolation would give result 0 in first case and 4 in second, while I would expect 2 in both cases. I think the code, which calculates interpolation based on 3 points, should be used only if the forth is void. There could be 3 combinations of triangles in this case. But if all 4 points are valid, there should be applied standard bilinear interpolation. Something like: if (hlb == HGTReader.UNDEF) { return triangle(... } if (hrb == HGTReader.UNDEF) { return triangle(... } if (hlt == HGTReader.UNDEF) { return triangle(... } if (hrt == HGTReader.UNDEF) { return triangle(... } // 4 points valid return bilinear(... -- Best regards, Andrzej _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Andrzej, Frank, I found class InterpolationBilinear http://download.java.net/media/jai/javadoc/1.1.3/jai-apidocs/javax/media/jai... which seems to do exactly what you propose when all four values are valid. I found no code for triangular interpolation yet, but I assume we can use the existing code in interpolatedHeightInNormatedRectangle with some more math. We just have to "rotate" the values and xchange qx and qy so that interpolatedHeightInNormatedRectangle never returns UNDEF if three values are valid. Right? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Andrzej Popowski <popej@poczta.onet.pl> Gesendet: Dienstag, 9. Januar 2018 15:45:14 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] HGT - getElevation() Hi Gerd, I'm trying to find if resolution can be better. I think current interpolation is not good. Imagine two combination of 4-points heights from HGT with values like: 1 0 0 7 and 0 1 7 0 For a point in the middle of rectangle, current interpolation would give result 0 in first case and 4 in second, while I would expect 2 in both cases. I think the code, which calculates interpolation based on 3 points, should be used only if the forth is void. There could be 3 combinations of triangles in this case. But if all 4 points are valid, there should be applied standard bilinear interpolation. Something like: if (hlb == HGTReader.UNDEF) { return triangle(... } if (hrb == HGTReader.UNDEF) { return triangle(... } if (hlt == HGTReader.UNDEF) { return triangle(... } if (hrt == HGTReader.UNDEF) { return triangle(... } // 4 points valid return bilinear(... -- Best regards, Andrzej _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd, I have prepared a patch with bilinear interpolation, which supports missing values. It can restore single missing value, but if more values are missing it simply returns the nearest value without interpolation. -- Best regards, Andrzej
Hi Andrzej, the patch keeps my simple code for an arithmetic mean if interpolatedHeight returns UNDEF: if (rc == HGTReader.UNDEF) { int sum = 0; int valid = 0; int[] heights = { hLT, hRT, hLB, hRB }; for (int h : heights) { if (h == HGTReader.UNDEF) continue; valid++; sum += h; } if(valid >= 2) rc = Math.round((double)sum/valid); } I think this should be removed? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Andrzej Popowski <popej@poczta.onet.pl> Gesendet: Dienstag, 9. Januar 2018 19:10:15 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] HGT - getElevation() Hi Gerd, I have prepared a patch with bilinear interpolation, which supports missing values. It can restore single missing value, but if more values are missing it simply returns the nearest value without interpolation. -- Best regards, Andrzej
Hi, Gerd, your additional interpolation would be redundant. Side note: comparison of double and integer doesn't look safe. Maybe would be better if interpolateHeight() returned integer? Frank, I understand your idea, but please note, that your choice of triangle is arbitrary. There are 2 ways of dividing a square and if you would choose the other way, results would be different and not only for the middle point. This suggest that the solution isn't complete. Classic bilinear interpolation seems better, but differences are small and actual map looks more or less the same. I have attached second patch, which apply interpolation when only 2 values on any edge are present. Another topic. I observe some DEM artifacts, when displaying area near the border of dem-poly. There are small rectangles without shading within a bigger tile. They appear at random, when scrolling or zooming map in BaseCamp or Mapsource. Ctrl-G doesn't help. See attached img. I haven't noticed the problem, when compiling a map without dem-poly. Maybe it is a result of slanted edge of DEM clipped by poly. -- Best regards, Andrzej
Hi Andrzej, the patch is based on r4040. Do you see those artifacts with r4041? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Andrzej Popowski <popej@poczta.onet.pl> Gesendet: Dienstag, 9. Januar 2018 21:04:20 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] HGT - getElevation() Hi, Gerd, your additional interpolation would be redundant. Side note: comparison of double and integer doesn't look safe. Maybe would be better if interpolateHeight() returned integer? Frank, I understand your idea, but please note, that your choice of triangle is arbitrary. There are 2 ways of dividing a square and if you would choose the other way, results would be different and not only for the middle point. This suggest that the solution isn't complete. Classic bilinear interpolation seems better, but differences are small and actual map looks more or less the same. I have attached second patch, which apply interpolation when only 2 values on any edge are present. Another topic. I observe some DEM artifacts, when displaying area near the border of dem-poly. There are small rectangles without shading within a bigger tile. They appear at random, when scrolling or zooming map in BaseCamp or Mapsource. Ctrl-G doesn't help. See attached img. I haven't noticed the problem, when compiling a map without dem-poly. Maybe it is a result of slanted edge of DEM clipped by poly. -- Best regards, Andrzej
Hi Andrzej, please post some data so that we can reproduce the problem. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Andrzej Popowski <popej@poczta.onet.pl> Gesendet: Dienstag, 9. Januar 2018 22:11:12 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] HGT - getElevation() Hi Gerd, yes, the problem is still present in 4041. -- Best regards, Andrzej _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Andrzej, please let us know how to reproduce the problem maybe post the problem tile. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Andrzej Popowski <popej@poczta.onet.pl> Gesendet: Dienstag, 9. Januar 2018 22:11:12 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] HGT - getElevation() Hi Gerd, yes, the problem is still present in 4041. -- Best regards, Andrzej _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd, I have uploaded at http://files.mkgmap.org.uk/ data for compilation, which gives me a map with shading errors. Mkgmap version 4045. -- Best regards, Andrzej
Hi Andrzej, yes, that looks strange. I've added option --show-profiles=1 to yours so that MapSource displays height values even in those areas where hill shading is not working. For all: The problem is near N49.19004 E20.07117 Mapsource displays no hill shading at zoom 500m, the wrong area changes when you zoom in and out or press 2xStrg+G to clear the cache. Not sure if this is a problem in the DEM data or in the hill shading algo. Will try to find out more tomorrow. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Andrzej Popowski <popej@poczta.onet.pl> Gesendet: Donnerstag, 11. Januar 2018 16:50:13 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] HGT - getElevation() Hi Gerd, I have uploaded at http://files.mkgmap.org.uk/ data for compilation, which gives me a map with shading errors. Mkgmap version 4045. -- Best regards, Andrzej _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Andrzej and Gerd, for your examples 1 0 0 7 0 1 7 0 is 2 for the middlepoint mathematical correct: (h1 + h2 + h3 + h4) / 4. My interpolation is the that: We live in a world with "triangular" surface (like in a computergame). We looking for a point p for the "surrounding" 4 points from the hgt. They form a rectangle (or square). The 4 point form 2 triangles (for me): hlt hrt (height right top) +---+ | /| | / | |/ | +---+ hlb hrb We looking in which triangle our point p is. A triangle define a plane and we can use a "3-Punkt-Gleichung" (don't know the english word). For the left triangle: use hlt as coordinate origin hrt -= hlt; hlb -= hlt; qy -= 1; and calculate hlt + qx * hrt - qy * hlb For the right triangle: use hrb as coordinate origin hrt -= hrb; hlb -= hrb; qx -= 1; and calculate hrb - qx * hlb + qy * hrt This principle can be a little extend: hlt hrt +---+ |\ /| | x | |/ \| +---+ hlb hrb It's easy to calculate the middlepoint and then we have 4 triangles. Then we have to decide, which triangle we need. Just we have 4 triangles. (So we have our "triangular" surface.) And so on ... Frank --- Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft. https://www.avast.com/antivirus
participants (3)
-
Andrzej Popowski -
Frank Stinner -
Gerd Petermann