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 -
Am 10.01.2018 um 18:15 schrieb Gerd Petermann:
Hi Peter,
I think the only alternative to interpolation is to use the height of the
nearest hgt point for a given DEM point.
That is my theory, but I can't prove
lg Peter
One may minimize this distance by chosing proper dem-dist values
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
Hi Peter,
I think the only alternative to interpolation is to use the height of the
nearest hgt point for a given DEM point.
One may minimize this distance by chosing proper dem-dist values and by
aligning the tiles to the raster
given by hgt. Example:
If the upper left corner of your img file i
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 the mountains, between 2 points
may be a big wall with some 100m
height-difference.
So if you have small deviations
Hi Andrzej,
if you want to try this:
you can easily change the code in interpolatedHeight to return the height in
feet, just make sure that you don't convert UNDEF.
The only other change that is needed is in this line in DemHeader:
writer.putInt(0); // 0: elevation in metres, 1: foot
well, the
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/
Hi Andrzej,
I can easily change the code to support feet. I think Franks program already
supports that.
But what would be the benefit ? Even with 1'' hgt data we have only one data
point every ~25 metres (in western europe) giving the height in metres,
I can't believe that we would improve quali
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-
Hi all,
FYI:
Today I've coded a quick+dirty solution to use Garmins DEM format to compress
hgt files.
The compression ratio is much better than that of zip, on average the file is <
50% of the zip file, and the format should allow nearly random access,
so maybe it would be the better input for m
Hi Andrzej,
sorry for my stupid error and thanks for the patch. I kept the double because I
compared the results with those from class InterpolationBilinear,
but I agree this should not be used in the final code.
See http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4043
Maybe I s
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
Hi Henning,
hgt files contain voids, and we don't write 0 height for such a void, instead
we write a value that
is considered to be invalid. When you hover over such a point MapSource doesn't
display a height.
I did not yet try to find out how this influences the ele values in calculated
gpx tr
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 all,
see http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4042
Details are discussed here:
http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2018q1/027628.html
Thanks to Andrzej for this patch, I think it is another good improvement.
A nice side effect of the better interpolation i
21 matches
Mail list logo
