splitter r586 still doesn't always align properly with --align-for-dem option
Hi all, I don't know yet why but alignment doesn't always work well. One problem is that we keep bbox data only with 24 bit resolution, but there must be more to it. I'll try to find out more but I have not much time until monday. Gerd
Hi Gerd, my current opinion is, that aligning to HGT won't work. The way Garmin sets coordinates in DEM suggests, that all DEM is aligned to coordinates 0;0. Since pixel distance for DEM can be set exactly as in HGT, the farther form 0;0 the bigger misalignment. Then at some point could appear a shift of DEM, like we have already observed for unaligned versions. I estimate, that for dem-dists=9942 this could be above 80 degree. -- Best regards, Andrzej
Hi Andrzej, I agree that it makes no sense to align to hgt when Garmin uses 0,0 as base and data is far away from this point. Probably it is a good idea to think about the way how the Garmin software can determine what data it has to read to render a given rectangle. What makes you think that 0,0 is used instead of the upper left cornen given in the DEM section header(s)? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Andrzej Popowski <popej@poczta.onet.pl> Gesendet: Freitag, 19. Januar 2018 17:06:42 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] splitter r586 still doesn't always align properly with --align-for-dem option Hi Gerd, my current opinion is, that aligning to HGT won't work. The way Garmin sets coordinates in DEM suggests, that all DEM is aligned to coordinates 0;0. Since pixel distance for DEM can be set exactly as in HGT, the farther form 0;0 the bigger misalignment. Then at some point could appear a shift of DEM, like we have already observed for unaligned versions. I estimate, that for dem-dists=9942 this could be above 80 degree. -- Best regards, Andrzej _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd,
What makes you think that 0,0 is used instead of the upper left cornen given in the DEM section header(s)?
In Garmin's DEM coordinates are always a multiple of DEM pixel size (dem-dists). The result is, that all DEMs data are aligned with 0;0. It makes easy to join different tiles, since all tiles share the same alignment. Garmin uses DEM pixel size, which is not optimal for HGT. Looks like they don't care about HGT alignment, while obviously they use SRTM data. There should be no shifting of DEM, if DEM coordinates are strictly respected by Mapsource od BaseCamp. But there could be artifacts on tile borders. Anyway, it is just a guess. We can make some test with Mapsource, but would be difficult to test all different devices. That is why I would prefer to make DEM exactly like Garmin, which means, that we can't get good alignment with HGT. -- Best regards, Andrzej
Hi Andrzej, too sad, this all sounds very reasonable :( Besides that I found only one very small problem in splitter: It uses a slightly different method to convert degrees to map units compared to mkgmap. I think the one used in mkgmap is good, the one in splitter is only close to correct. mkgmap: public static int toMapUnit(double l) { double DELTA = 360.0D / (1 << 24) / 2; // Correct rounding if (l > 0) return (int) ((l + DELTA) * (1 << 24) / 360); return (int) ((l - DELTA) * (1 << 24) / 360); } splitter uses nearly the same code but double DELTA = 0.000001; // TODO check if we really mean this The value in mkgmap is 1.0728836059570312E-5 which is much closer to the exact value 0,0000107288360595703125 The real problem is what you already described: A 32 bit DEM value that is far from 0,0 and perfectly aligned to 1/1200° degress is also perfectly aligned to 2^32 / (360 * 1200) which is ~ 9942,0539259259259259259259259259 but it is never aligned to 9942. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Andrzej Popowski <popej@poczta.onet.pl> Gesendet: Freitag, 19. Januar 2018 23:35:00 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] splitter r586 still doesn't always align properly with --align-for-dem option Hi Gerd,
What makes you think that 0,0 is used instead of the upper left cornen given in the DEM section header(s)?
In Garmin's DEM coordinates are always a multiple of DEM pixel size (dem-dists). The result is, that all DEMs data are aligned with 0;0. It makes easy to join different tiles, since all tiles share the same alignment. Garmin uses DEM pixel size, which is not optimal for HGT. Looks like they don't care about HGT alignment, while obviously they use SRTM data. There should be no shifting of DEM, if DEM coordinates are strictly respected by Mapsource od BaseCamp. But there could be artifacts on tile borders. Anyway, it is just a guess. We can make some test with Mapsource, but would be difficult to test all different devices. That is why I would prefer to make DEM exactly like Garmin, which means, that we can't get good alignment with HGT. -- Best regards, Andrzej _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
participants (3)
-
Andrzej Popowski -
Gerd Petermann -
Gerd Petermann