Hi Gerd,
thanks for the version r4565. The option --x-keep-empty-value-tags works
like expected.
Perhaps it would be better, i change my classification process a little
bit and generate for my "private" tags additional name tags (LINE_MOTORWAY
-> LINE_MOTORWAY_NAME). That increase the osm file
Hi,
with a old mkgmap version (mkgmap-r4286) i use a rule like that (i use my
own classification for polygons):
area_building=""{ name '${addr:housenumber}' } [0x01
level 1]
area_building=* { name '${area_building}' } [0x01
level 2]
If in the OSM-fi
Hi Gerd,
i have only picked 1 IMG from the "Garmin TransAlpin v2" (Immenstadt im
Allgau / 16596679.img). The TRE-borders are overlapping with 2 units with
all the 4 neighbors. Perhaps a border-value is ever even (?).
Frank___
mkgmap-dev mailing list
Hi Gerd,
ich versuche es jetzt auf diesem Weg. Dein Mail-Provider scheint ein Problem zu haben. Jedenfalls meckert hotmail-com.olc.protection.outlook.com immer
bei meiner Mail.
ich habe gerade das Beispiel 6b (ohne BuildDEMFile) ausprobiert. Die Varianten
mod und org funktionieren, die beid
Hi Gerd,
yes, at first we have to identify the maptile. Perhaps can Minko help. Thats a
"trial and error" play. Perhaps with comment out in areas.list?
You ask for the input format? It's an ordinary textfile. One text-line for one
data-line. The values in a line are separated by space, comma,
Hi all,
i have not seen the problem with the map from Andrzejs, but with Minkos it
looks unfortunally for me like an error in dem-encoder.
I'm sure, that garmin software not good work with unexpected data, perhaps buffer overflows and so on. The consequence is not predictable. In best
case we
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 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 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
Hi Gerd,
at last you need the data uncompressed in a buffer, right? That's why i
see no difference between using compressed or uncompressed hgt files.
Compressed files need a little bit more time for uncompressing, but after
that the data need the same size in memory. That's why i see no vantag
Hi Franco,
i have seen an silly error in my area. Europa is a little bit greater ;)
Just i have "$lattop = 70". The split create 3608 tif's with 4,5 GB in 85 min.
gdal4hgt create 1171 zipped hgt's with 5,8 GB in 3 h :((
And then i rebuild the tif's from the hgt's in 20 min. That are 4 GB.
Perha
Hi Henning,
yes, we have specialized tools for this work, they make a good job and we
should use this tools.
A little interesting idea is: If we can use additional use tif's a "container" for dem data, we can safe space on the hd. My little test with the
copernicus files show: 5.2GB for zipped
Hi Franco,
i have little bit "played" with copernicus-files.
I have build a win-command-file with this perl-file:
use strict;
my $lonleft = -24;
my $lonright = 50;
my $latbottom = 27;
my $lattop = 64;
my $srcdir = "../org";
my $delta = 1 / 3600 / 2; # half pixel
print "set GDAL_TRANSLAT
Hi Franco,
i have just downloaded all copernicus tiffs. The pure tiff data are round about
37GB. My short test was:
gdalbuildvrt all.vrt *.tif
gdalwarp -t_srs EPSG:4326 -r lanczos -ot Int16 -dstnodata -32768 -of GTiff -co "COMPRESS=LZW" -co "TILED=YES" -co "PREDICTOR=2" -ts 3601 3601 -te 11
50
This is my tool:
https://github.com/FSofTlpz/gdal4hgt
https://github.com/FSofTlpz/gdal4hgt/blob/master/bin/Release/Gdal4Hgt.exe
It also need gdal-tools like tif2hgt.
Frank___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.or
Sorry, here is the jpeg.
Frank
---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
A short test with the geo-tiffs from https://earthexplorer.usgs.gov/ (see mail from franco_bez) for nepal show fewer holes. And we have 1" distance!
But a login is necessary.
I have a little c#-prog based on the gdal-lib for translating between hgt and
16-bit geotiff.
Frank
---
Diese E-Mail
Hi Gerd and Henning,
the count of nodes haven't influence to creation of dem, only the size (and the surface) of the area. I haven't see a problem with the size of dem
file, but perhaps it is a good idea if we had a additional restriction for splitter. Not only maxnode, but a "maxwidth" and/or "
Hi Gerd,
my first idea was, 1 bit less for resolution means doubling the distance. Or in other words, then we use simply only every second point. But for me it
don't looks like good.
I use "levels=0:24, 1:23, 2:22, 3:21, 4:20, 5:19" and for --dlon 0.00027761, 0.00049, 0.00075, 0.00106, 0.0017
Or you use %PROGRAMDATA%\GARMIN\Maps\. That should ever be the right place and
undependent from language or OS.
Frank
---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus
___
mkgmap-dev mailing list
Hi,
i must confess, i have never tried to decompile a garmin dem map. I have
only playing with bit-patterns and then looking for the result in
mapsource. But i'm sure, that we have different algorithms or one
algorithm with different special cases.
My description in the pdf is (only) valid for
Hi,
i hope, the error message was "unbekanntes Argument: new.tdb".
It's a stupid error from me in the description: please change from
"--mapsource=new.tdb; ..." to "--mapsource=tdb:new.tdb; ...".
The dot after -i means the actual working directory. If you start gmtool
in directory "g:\mkgmap\O
Hi Gerd,
my test-style was only a strong simplified style.
> The lines file you posted ignores all lies with line_minorstreet=*
If you are interesting for the original style:
http://files.mkgmap.org.uk/download/360/style.zip
In inc\lines_... are a lot of roads, path and so on.
> ... ways with
Hi Gerd,
thank you for your answer.
>add more minor roads in your style
Let us build more roads! ;)
I use every road and also every small and bad visible trail for my maps,
all for hiking and bicycle.
>use --ignore-turn-restrictions
But then i have propably "false" routing? (That's not a probl
Hi Gerd,
http://files.mkgmap.org.uk/download/359/63240045.osm.pfb
Frank
---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkg
Hi Gerd,
i have no idea, where i can save the file. It has round about 14 MB. Or can i send the
file as "attached file" to mkgmap-dev@lists.mkgmap.org.uk?
Frank
---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus
___
Hi Andrzej,
it's same.
Frank
---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi,
can anybody help me?
I become from mkgmap this message:
Bad file format: ..\63240045.osm.gz
too many restrictions
Number of MapFailedExceptions: 0
Number of ExitExceptions: 0
The IMG for this tile is empty. The other tiles are ok. What means this
error and how can i prevent this?
Just i h
Hi all,
i have gmtool a little bit extended in the hope of simpler creation of
TDB's.
The main point is, that we have to register a old TDB as input file BEFORE
all other files. Then take gmtool all possible properties from the old
file and remove or complete the old subfilelist. If we only ha
Hi builddemfile users,
in the versions from 23. and 26.11.2017 was an error in the encoder. I
have it amended.
Frank___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi all,
a short test show me, that there is a change in DEM's since the version from
23.11. I will look for the error.
Frank
---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus
___
mkgmap-dev maili
Hi Andrzej,
is this a overviewmap? Can you send me TRE or the exact boundary for this tile
and the your command line? I will see what's going wrong in debugger.
Frank
---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus
_
Hi Andrzej,
mea culpa. I have overlooked that. It's changed.
There is a new option --changehgtsize=x. You can for special cases give a new size x. After reading a HGT runs a interpolation and set a new size.
Hope that helps.
Frank
---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren
Hi Andrzej,
there is no predefined size for HGT's. I use 1201-HGT's mixed with 3601'HGT's. It should not to be a problem to use any other size. The only
restriction is: height==widht.
The memory consumption is a problem. A HGT with 1201x1201 need in memory 1201*1201*4 Byte = 5,5 MB (.NET use f
Hi Nick,
the output say all (sorry, it's still in german ;) ):
HGT-Daten lesen ...
Höhen für 0° .. 1° / 50° .. 51° eingelesen, (nur Dummywerte)
Höhen für 1° .. 2° / 51° .. 52° eingelesen, Werte -10 .. 190
Einlesezeit 0.7s
"0° .. 1° / 50° .. 51°" is the HGT N50E000.hgt (south-west-corner i
Hi Nick,
there are 2 little problems in your map mapdem.gmap.
#1:
I have rebuild your DEM file. Maybe, builddemfile had the N50E000.hgt.zip
or N50E000.hgt not found and you have only "dummydata" in your file.
"dummydata" means a valid DEM with "no data"-points.
builddemfile --hgtpath=yourpath
Hi Nick,
it's a really small piece. But 0,157° x 0,0685° and dlon=0,00027761 are
about 565 x 246 points. That are a lot of 64x64 DEM tiles. I don't think,
that's a problem.
Can you put the ready card (still without DEM's) to
http://www.pinns.co.uk/errs/ or whereever?
What say mapsource to you
Hi Andrzej,
i have the prog a little bit changed. Just it should be run.
I don't know, what's going on with only 1 subtile column and a width < 64.
If this not worked, i change it, so that we have in this case 64 points.
If you have -w 0.90 and --dlon=0.0264, than there are only 34
Hi Andrzej,
please try the last version. The version info is the same, but false! It's from
10.11.2017
I get with
builddemfile -O --dem=x.dem --hgtpath=%OSM_DATA%\srtm_zip -l 22.208450317 -t 53.638961792 -w 0.946884155273438 -h 1.9918212891
--dlon=0.0017 --dlon=0.00
Hi Gerd,
at first the good news. In the meantime i have build maps for Czech
Republik, Germany, Austria, Switzerland and Italy, ever with 6 zoomlevels.
I don't found an error. Of course, this is no evidence for the algorithm.
And yes, there are a few mysterious things. I'm sure, what ever the g
Hi Gerd,
yes this is an error. Fortunately is the copy-constructor not in use.
Frank___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi,
1) It's a mistake. You can use lat/lon multiple. Only this tiles you can
merge. But i think, that's useless. It's better to take the necessary
results and merge this with osmosis (see
https://github.com/FSofTlpz/Hgt2Osm2/blob/master/README.md)
2) Oops, a stupid error. Usual i don't use lat
Hi Thomas,
it's a stupid error message. If i can get the IMG, then can i run it in the
debugger und looking what's going wrong.
Perhaps is an error in IMG file? Try please also
gmtool -i 30007501.IMG -I 1 > info_img.txt
A second possibility is, you use gmt and then create with
gmtool -i
Hi Gerd,
we have ever 2 problems: how to calculate the next value and how we have
to encoding this value.
#1: If we have not a plateau, then we have a "Standardwert". For the
calculation of a "Standardwert" we have to 3 differend cases depend on the
value hdiff(n, m-1) = h(n, m) - h(n-1, m) (h
Hi Gerd,
which 0-Bit you mean? Let us take this example:
4,4,4,5,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7
8,8,5,5,5,5,5,8
The detailview from my prog "Input2" (
https://github.com/FSofTlpz/Garmin-DEM-Build/blob/master
Sorry, this version is catching on negativ values the false HGT's. It is
just rectified.
Frank___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi,
there is a new version (8.11.2017),
https://github.com/FSofTlpz/Garmin-DEM-Build/blob/master/BuildDEMFile/bin/BuildDEMFile.exe.
This version should be assume less memory.
Reading HGT's should be faster.
It seems, --lastcolstd isn't more necessary (?).
By the way, the programm runs also with
Hi Thomas,
i have tested that with few adresses with my germany-map and i have no problem. I use the original osmmap_mdr.img from mkgmap. Perhaps still a problem
with TDB?
Frank
---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus
__
What a pity.
I'm afraid, the implementation in mkgmap takes a few days ;). It's not a easy
job.
That's why i preferred for a transitional period a special DEM option for mkgmap. We can build the DEM's before and then say with this option: please
mkgmap, take the ready DEM's from this directory
Hi Nick,
i believe there is no way to change the shading. DEM files include only the strong compressed height data. That means, we have only coordinates for
that points and their height. The shading makes the software on pc or gps.
2) yes, you can create more zoomlevels. That is necessary for
"BuildDEMFile.exe is not a valid win32 application"?
Yes and no. It's a .NET program and need the .NET-library >= 4.5.2. The .NET-library ist part of a "normal" Windows. Perhaps the library ist not part
of your virtual machine?
Frank
---
Diese E-Mail wurde von Avast Antivirus-Software auf Vire
Hi,
i don't now your build-process. But i have installed your original map (without the DEM's). After you include the DEM's in this IMG files, create with
gmtool with this NEW IMG's a new TDB.
For the old TDB you get with
gmtool -i 1001.tdb -I 2
the following output:
Datei 'd:\tmp\Op
Hi,
I believe, the problem is the msdos-mask "1001.img". Don't ask me
why, but for microsoft matches this mask also the file 1001_mdr.img
(see also: dir 1001.img). Unfortunately is it the same with the mask
.img. I think, the best way is, the file 1001_mdr.img
temporar
Sorry, there is a intern limitation of .NET. The maximal size of a
"object" on a 64-bit-machine/windows is near by 2 GByte. That means in
this case, we can have maximal about 532.000.000 height values. 31503 x
25646 = 807.925.938 is too much. You have to split the area in 2 tiles.
This all is o
I suppose, the process can't manage more memory. It runs on a
Win32-machine? When you can tell me the size of the area (see
areas.list), i will try to run it on my machine.
If the memory is the reason, then you can only split this IMG area in
smaller IMG's.
The 2. issue seems to be an error
Hi,
if you don't find another tool for processing TDB-file, have a look to
my gmtool. This is only a experimental tool but it do the job. I use
only this tool for creating my test-maps.
Don't forget the GarminCore.dll.
https://github.com/FSofTlpz/GmTool/blob/master/bin/Release/GmTool.exe
https
Hi,
i have build a "germany"-map only directly, without mapsource and
without problems.
If mapsource make problems, then probaly the TDB is the reason.
By the way, have you recreate the TDB after including the DEM-files?
That is very important. The TDB need the right filesize of all subfiles
Hi Minko,
unfortunately i dont' identify the faultily IMG file. I thought it is
the 10010087.img, but it seems to be allright.
Anyway. I see, that you don't use the option --lastcolstd. Please try
--lastcolstd or --lastcolstd=true. Then the most-right subtile becomes
also the witdt 64. Then
Hi fietser.
that's looking like a unknown special case for my DEM-algorithm.
If possible, please let me know the coordinates of the IMG-Tile (left,
top, widht, height) and the point distance (--dlon) or the hex-output
for the zoomlevels at the end of the DEM file.
I try to isolate the faulti
Have in mind that the TRE-boundery can include areas without existing
HGT data!
In this case please use the actual program-version with the option
--usedummydata.
Frank
---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus
__
Hi David,
there is a new version. Normal is a call like that:
builddemfile --dem=test.dem --hgtpath=%OSM_DATA%\srtm_zip --lastcolstd
--overwrite --dlon=0.0003 --left=55.1 --top=-20.5 --width=0.4 --height=0.8
But if one or more HGT files being absent / not exist and you now what
you are doing
Hi,
it is like andrzej wrote: after including the DEM files re-create the
TDB file. I have had forgotten this in my test.
In the TDB file is a list of all IMG-Files, the subfiles and the
filesize of the subfiles. It is necessary to update this list.
Frank
---
Diese E-Mail wurde von Avast A
Hi Gerd,
i have seen this strange message today too. If i have only 1 Zoomlevel
(it's enough for mapsource/basecamp), there is no message. That's why, i
believe that is not a problem with the TDB. (Of course, in the TDB need
set the DEM-flag and list the DEM-files.)
I see today, that for my
Hi Gerd,
mit builddemfile.exe (z.Z.
https://github.com/FSofTlpz/Garmin-DEM-Build/blob/master/BuildDEMFile/bin/BuildDEMFile.exe)
kann man sich beliebige DEM-Dateien erzeugen. Diese werden genauso wie
TRE-, RGN- usw. Dateien in die IMG-Datei eingebunden.
Ich verwende die frei verwendbare "Comm
Hi,
at first:
yes i mean the DEM-flag in TDB-file like Andrzej Popowski wrote.
at second:
unfortunally it seems, that the corner left-top for TRE-file and
DEM-file should be the same. The height-data organized in subtiles with
64x64 points. The most right sub-tile is a problem, but my workarou
The problem is the Garmin-Data-Format.
Garmin use only 24 Bit for longitude/latitude. This is for the highest
zoom. If you reduce the zoom, then use garmin internaly only 23, 22, ...
Bit.
The biggest number with 24 Bit is 16.777.215. Use this for 360°. From this
it follows that 360°/16.777.215
Sorry, but i have no success
Just I use mkgmap 2379 with the default-style. My Optionfile is:
family-name=TEST
series-name=TEST
description=TEST
bounds=\Gps\Data\bounds_20121019.zip
country-name=Deutschland
country-abbr=DEU
region-name=Deutschland
region-abbr=DEU
name-tag-list=name:de,in
No success:
SCHWERWIEGEND (BoundaryUtil): .\63240001.osm.pbf: boundary directory/zip
does not exist: Gps\Data\bounds_20121019.zip
SCHWERWIEGEND (LocationHook): .\63240001.osm.pbf: LocationHook is disabled
because no bounds files are available. Dir: Gps\Data\bounds_20121019.zip
"\Gps\Data\bounds
I use mkgmap 2373 with the default-style. My Optionfile is:
family-name=TEST
series-name=TEST
description=TEST
bounds=\Gps\Data\bounds_20121019.zip
country-name=Deutschland
country-abbr=DEU
region-name=Deutschland
region-abbr=DEU
name-tag-list=name:de,int_name,name:en,name
index
route
net
nsis
are
69 matches
Mail list logo
