Hi,
I'm attaching a next patch for bicubic interpolation. It include
following changes:
- some errors corrected,
- more statistic of interpolation,
- changed condition for applying bicubic interpolation.
In this version bicubic interpolation is applied, when required DEM
resolution is not low
Hi Gerd,
> Bicubic expects grid [-1,0,1,2] X [-1,0,1,2]
> fillArray uses [0,1,2,3]X[0,1,2,3]
That's the reason for "-1" in following code:
h = rdr.ele(xLeft + x - 1, yBottom + y - 1);
eleArray[x][y] = h;
I have corrected some errors, will post a new patch soon.
--
Best regards,
Andrzej
_
:50:19
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] HGT - getElevation()
Hi Gerd,
I have included bicubic interpolation created by Ken Perlin:
https://github.com/mlevans/pretty-heatmaps/blob/master/DensityArrayCreation/src/DensityArrayCreation/Bicubic.java
Bicubic interpolation is
Hi,
here is my version of mkgmap for tests:
http://files.mkgmap.org.uk/download/403/mkgmap-dem-tdb-r4071-bicubic.zip
Changes are following:
- dem-dists values are rounded to 16,
- DEM coordinates are multiples of dem-dists,
- DEM values are calculated with bicubic interpolation for layers with
Hi Gerd,
> Maybe you can create a 2nd branch so that others can try the
> different results?
I hardly know java, have no IDE for work or any experience in SVN.
Basically I can tweak your code and compile it with ant. I could post
compiled version if there is any interest.
--
Best regards,
ea is
calculated in a large tile spanning multiple degrees. I am working on that.
Gerd
Von: mkgmap-dev im Auftrag von Andrzej
Popowski
Gesendet: Samstag, 20. Januar 2018 00:50:19
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] HGT - getElev
Hi,
quick comparison between r4068 original and r4070 with bicubic
interpolation. Both use pbf aligned to HGT and the same 3 arc degree HGT
with many voids.
http://files.mkgmap.org.uk/download/401/orig-aligned.png
http://files.mkgmap.org.uk/download/402/bicu-aligned.png
DEM shading moved aga
Hi Gerd,
I have included bicubic interpolation created by Ken Perlin:
https://github.com/mlevans/pretty-heatmaps/blob/master/DensityArrayCreation/src/DensityArrayCreation/Bicubic.java
Bicubic interpolation is used only for layers with good resolution (3
arc seconds or better). For other cases b
Hi Gerd,
> I'd prefer to use unmodified dem-dist values for now, besides that the
> unit tests don't compile with it.
I'm trying to get DEM looking like in Garmins img. The actual rounding
in code can be disabled, but then it would be up to user, to set correct
distances. I don't know, if roun
shows that this is a bad idea.
Gerd
Von: mkgmap-dev im Auftrag von Andrzej
Popowski
Gesendet: Freitag, 19. Januar 2018 02:59:14
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] HGT - getElevation()
Hi Gerd,
I have prepared patch accordin
Hi Gerd,
I have prepared patch according to these guessed rules. It rounds
dem-dist and shift coordinates of top-left corner of DEM areas. Since
dem-dist doesn't correspond exactly to HGT, interpolation is always active.
I think there could be 2 ways to improve DEM quality. Interpolation
cou
Hi Gerd,
I have executed your script and looked at maps. I have tested them with
artificial HGT too. Only the original-unaligned map has DEM at wrong
position. It is moved by about 0.00033 degree right and down.
I looked at offset calculated as (DEM coordinate)%(dem-dist) and only
for this m
mkgmap-dev im Auftrag von Andrzej
Popowski
Gesendet: Donnerstag, 18. Januar 2018 03:08:48
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] HGT - getElevation()
Hi Gerd,
I have looked a bit at Garmin's DEM and I have some guesses.
* Coordinate resolution for DEM is 28 bits. Since
Andrzej
Popowski
Gesendet: Mittwoch, 17. Januar 2018 23:24:35
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] HGT - getElevation()
Hi Gerd,
I have tried to verify, if aligned DEM is correct. I think algorithm
have passed positively 2 tests:
- reading height from map gives correct values
Hi Gerd,
I have looked a bit at Garmin's DEM and I have some guesses.
* Coordinate resolution for DEM is 28 bits. Since it is shifted to the
left, 4 lower bits are always 0.
* The same goes for pixel distance, lower 4 bits should be 0. This is
the reason, why Garmin uses 3312 (CF0) instead o
Hi Gerd,
I have tried to verify, if aligned DEM is correct. I think algorithm
have passed positively 2 tests:
- reading height from map gives correct values,
- changing bbox of source data doesn't change resulting map, even if it
changes offset applied for aligning.
The aligning changes a bi
: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] HGT - getElevation()
Hi Gerd,
I have compiled my 2 tiles and the one you found as a problematic. Now
with SRTM 3 seconds. I have used mkgmap 4068 with your patch. It all
looks good. Shading is the same on all maps, peak DEM height for a
Hi Gerd,
I have compiled my 2 tiles and the one you found as a problematic. Now
with SRTM 3 seconds. I have used mkgmap 4068 with your patch. It all
looks good. Shading is the same on all maps, peak DEM height for a
mountain is the same and nearly on the same position, which is at HGT node.
Hi Gerd,
I have prepared artificial HGT with both resolution and tested both. I
haven't tested with real HGT 3". I will check this too.
--
Best regards,
Andrzej
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailm
Hi Andrzej,
note that I used 3'' hgt files. Did you try that as well?
Gerd
Von: mkgmap-dev im Auftrag von Andrzej
Popowski
Gesendet: Mittwoch, 17. Januar 2018 20:21:35
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] HGT - ge
Hi Gerd,
> So I tried other bboxes, and found this one:
> 2902: 2291022,918105 to 2297489,946049
I have compiled this tile and found no difference, it looks the same as
my tiles. DEM heights are the same.
I have prepared dummy HGT with checkerboard patter. It makes quite easy
to verify,
value(s).
Gerd
Von: mkgmap-dev im Auftrag von Andrzej
Popowski
Gesendet: Dienstag, 16. Januar 2018 22:30:21
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] HGT - getElevation()
Hi Gerd,
I have done 2 kind of tests, both with mkgmap patched with your patch
for aligned HGT
Hi Gerd,
I have done 2 kind of tests, both with mkgmap patched with your patch
for aligned HGT.
Fist test is more or less the same what you propose. I looked for a
round peak on a map and then searched for the highest value of DEM on a
peak, moving cursor around. With zoom 20m, I tried to es
Von: mkgmap-dev im Auftrag von Andrzej
Popowski
Gesendet: Dienstag, 16. Januar 2018 16:36:22
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] HGT - getElevation()
Hi Gerd,
I have tried to align pbf bbox with HGT. I have ceated 2 maps, one with
god
need some
rest now ;-)
Gerd
Von: mkgmap-dev im Auftrag von Gerd
Petermann
Gesendet: Dienstag, 16. Januar 2018 17:40:54
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] HGT - getElevation()
Hi Andrzej,
reg. screen shots:
I created my two s
mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] HGT - getElevation()
Hi Gerd,
I have tried to align pbf bbox with HGT. I have ceated 2 maps, one with
god alignment and second with left and top edge moved by 1/2 HGT pixel
size. I have used HGT with resolution 3600, so the movement was a
Hi Gerd,
I have tried to align pbf bbox with HGT. I have ceated 2 maps, one with
god alignment and second with left and top edge moved by 1/2 HGT pixel
size. I have used HGT with resolution 3600, so the movement was about
15m. I think shading is the same on both maps. There is no obvious
chan
on: mkgmap-dev im Auftrag von Andrzej
Popowski
Gesendet: Montag, 15. Januar 2018 23:33:03
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] HGT - getElevation()
Hi Gerd,
I use SRTM3 v3, so map can be different, but I'm surprised by difference
in details. That's why I wanted
Hi Gerd,
I use SRTM3 v3, so map can be different, but I'm surprised by difference
in details. That's why I wanted to recompile map.
I can see shift in shading when aligning DEM, I told so in my first
post. But I rather don't notice that shading doesn't fit map features.
Probably this becomes
existing
DEM data.
Do you want to say that you don't see a movement in your tests?
Gerd
Von: mkgmap-dev im Auftrag von Andrzej
Popowski
Gesendet: Montag, 15. Januar 2018 21:41:48
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] HGT
Hi Gerd,
on your pictures it looks like shading form extended DEM doesn't match
map features. Is it HGT with resolution 1200? Shading looks more
detailed than on my map, which uses DEM created by BuidDemFile. I have
to recompile my map to compare.
I have done different test. I have analyzed
Gesendet: Montag, 15. Januar 2018 14:57:17
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] HGT - getElevation()
Hi Andrzej,
ooops , just noticed that I did not update my patch. See new version attached.
I am now playing with a version that moves all corners into the same direction.
BTW: I&#x
kgmap-dev im Auftrag von Andrzej
Popowski
Gesendet: Montag, 15. Januar 2018 12:51:00
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] HGT - getElevation()
Hi Gerd,
I guess your code already makes sure, that whole area is covered by DEM.
So yes, extending bottom/right is not nece
Hi Gerd
On 15.01.2018 15:05, Gerd Petermann wrote:
> Wouldn't it be better to change splitter so that it aligns tiles to HGT
> raster?
As long as we have rectangle map tiles, it would be a possible solution.
But in future we might have non-rectangle tiles or even tiles, not
splitted by splitter.
Hi Gerd,
I guess your code already makes sure, that whole area is covered by DEM.
So yes, extending bottom/right is not necessary.
--
Best regards,
Andrzej
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/li
ter?
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 ar
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 sa
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
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
__
rg.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 bi
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 differen
rstag, 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,
An
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/
Hi Gerd,
I will try to prepare a simple example.
--
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 im Auftrag von Andrzej
Popowski
Gesendet: Dienstag, 9. Januar 2018 22:11:12
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] HGT
solution.
Gerd
Von: mkgmap-dev im Auftrag von Peter
Danninger
Gesendet: Mittwoch, 10. Januar 2018 17:53:46
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] HGT - getElevation()
I don't think rounding or interpolating
will deliver any better results.
If yo
Hi,
> If you interpolate altitude-values, you calculate wrong values
> by design :-(
Would it be possible, to create first layer without interpolation? On my
maps I'm trying to set DEM resolution equal to HGT, but I can't control
offset and I'm not sure if settings are precise enough to mainta
anuar 2018 17:53:46
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] HGT - getElevation()
I don't think rounding or interpolating
will deliver any better results.
If you have 1" .hgt files, you get
an altitude value every 30m.
With 3" .hgt files much worse, every 90m.
In
say feet , not foot
Gerd
Von: mkgmap-dev im Auftrag von Frank Stinner
Gesendet: Mittwoch, 10. Januar 2018 17:27:22
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] HGT - getElevation()
Hi Gerd and Andrzej,
i think "overkill" is a good word.
For alg
well, the comment should say feet , not foot
Gerd
Von: mkgmap-dev im Auftrag von Frank
Stinner
Gesendet: Mittwoch, 10. Januar 2018 17:27:22
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] HGT - getElevation()
Hi Gerd and Andrzej,
i think &quo
Hi Gerd and Andrzej,
i think "overkill" is a good word.
For algorithm that'a only numbers, it does not matter. The questions is, how exact are the hgt-values. We don't know that, but i don't believe it is
+-1m or so. I'm not wondering, when the hgt's have +-5m or +-10m. The copernicus-data have
Hi Gerd,
height precision is 3 times better in feet and rounding errors smaller.
It is probably overkill, but might be handy with good data.
--
Best regards,
Andrzej
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/
ates ~105 M *.dem files.
Gerd
Von: mkgmap-dev im Auftrag von Andrzej
Popowski
Gesendet: Mittwoch, 10. Januar 2018 16:14:15
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] HGT - getElevation()
Hi Gerd,
no idea about int vs. short, but I wouldn't expect any
Hi Gerd,
no idea about int vs. short, but I wouldn't expect any differences on
Intel CPU.
I think it could be interesting to return interpolated values in feet,
assuming that you can encode whole DEM in feet.
--
Best regards,
Andrzej
___
mkgmap-
be I should change all values to int, maybe that is a bit faster.
Gerd
Von: mkgmap-dev im Auftrag von Andrzej
Popowski
Gesendet: Mittwoch, 10. Januar 2018 14:33:40
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] HGT - getElevation()
Hi Gerd
Hi Gerd,
forgotten patch here.
--
Best regards,
Andrzej
Index: src/uk/me/parabola/mkgmap/reader/hgt/HGTConverter.java
===
--- src/uk/me/parabola/mkgmap/reader/hgt/HGTConverter.java (revision 4042)
+++ src/uk/me/parabola/mkgmap/
Hi Gerd,
I see you have introduced NO_VAL constant in recent code. Please note,
then my interpolation code can return (double)HGTReader.UNDEF too, when
it returns nearest HGT value, which happened to be void.
I think more clear would be to move Math.round() to
interpolatedHeight(), see attac
lated
gpx tracks.
I assume that a gpx point without ele attribute is created.
Gerd
Von: mkgmap-dev im Auftrag von Henning
Scholland
Gesendet: Mittwoch, 10. Januar 2018 13:48:11
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] HGT - getEleva
On 10.01.2018 20:33, Andrzej Popowski wrote:
> > i would be very defensive with interpolation in the case of
> > missing values.
>
> I got the same feeling. The best way to fill voids is to process whole
> HGT. And I believe that DEM providers already have done it, so any
> attempt at simple extrap
Hi Frank and Gerd,
> It's a little bit more to calculate
The actual code is quite simple, it is 3 times linear interpolation:
double hxt = (1.0D - qx)*hlt + qx*hrt;
double hxb = (1.0D - qx)*hlb + qx*hrb;
return (1.0D - qy)*hxb + qy*hxt;
> i would be very defensive with interpolation in the cas
Hi Frank
what problem do you see when we interpolate data? What is the advantage of
voids?
Gerd
Von: mkgmap-dev im Auftrag von Frank
Stinner
Gesendet: Mittwoch, 10. Januar 2018 10:53:44
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] HGT
Hi Gerd and Andrzej,
> your choice of triangle is arbitrary.
of course, but the version with 4 triangles isn't.
> bilinear interpolation seems better
Yes. It's a little bit more to calculate, but better. For our special case
it is:
h = h11 * (1 + y * x - x - y) + h21 * (x - y * x) + h12 * (y
Hi Andrzej,
please post some data so that we can reproduce the problem.
Gerd
Von: mkgmap-dev im Auftrag von Andrzej
Popowski
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,
the patch is based on r4040. Do you see those artifacts with r4041?
Gerd
Von: mkgmap-dev im Auftrag von Andrzej
Popowski
Gesendet: Dienstag, 9. Januar 2018 21:04:20
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] HGT
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
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 t
eff: 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,
Andr
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
Index: src/uk/me/parabola/mkgmap/reader/hgt/HGTC
ght?
Gerd
Von: mkgmap-dev im Auftrag von Andrzej
Popowski
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
dev im Auftrag von Andrzej
Popowski
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
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 an
Hi Andrzej,
thanks for reviewing the code.
Yes, they should never be negative.
Gerd
Von: mkgmap-dev im Auftrag von Andrzej
Popowski
Gesendet: Dienstag, 9. Januar 2018 13:30:35
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] HGT
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
74 matches
Mail list logo
