[mkgmap-dev] actual style rules
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 files but anyway. Frank Stinner___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] actual style rules
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-file a line like that
it matches and in the map i have a polygon with type 0x01 and the name 'my
home'.
The line
it matches and in the map i have a polygon with type 0x01 and the
housenumber or nothing as name.
With the actual mkgmap version (mkgmap-r4562) this not work. With v='' i
have no match. Is this a error or a feature ;) . How can i match this?
With best regards
Frank Stinner___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Garmin uses overlapping tiles
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 mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] My findings about the crash in MapSource
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 beiden poly-Varianten stürzen ab. Ich habe das nicht richtig verfolgt. Was genau bewirkt die Option --dem-poly? Werden da nur bestimmte Bereiche der DEM-Daten mit nodata gefüllt, also eine Art clipping? Oder passiert da noch irgendetwas anderes? Ich habe mir die Transalpin nochmal angesehen. An der Adria gibt es auch Bereiche mit Codingtype 2. Das Höhenprofil für eine Route wird angezeigt. Die TDB-Header sind, abgesehen von der Family-ID, identisch. Die bei mir als Unknown bezeichneten Bytes für eine Kartenkachel sind aber z.T. unterschiedlich: Transalpin Mapnumber (4 Byte): 16596754 / 0xFD3F12 Mapnumber (4 Byte): 63240001 / 0x3C4F741 ParentMapnumber (4 Byte): 16596991 / 0xFD3FFF ParentMapnumber (4 Byte): 6324 / 0x3C4F740 North (4 Byte): 544029184 / 0x206D3A00; 45,594277954° North (4 Byte): 624689152 / 0x253C; 52,36083984375° East(4 Byte): 150324224 / 0x8F5C400; 12,6000308990479° East (4 Byte): 129564672 / 0x7B9; 10,8599853515625° South (4 Byte): 539256832 / 0x20246800; 45,1999855041504° South (4 Byte): 622657536 / 0x251D; 52,1905517578125° West(4 Byte): 145551360 / 0x8ACF000; 12,1999740600586° West (4 Byte): 127074304 / 0x793; 10,6512451171875° Description (8 Byte): 'Venezia' Description (26 Byte): 'OSM street map (63240001)' Unknown1(2 Byte): 7 / 0x7 Unknown1(2 Byte): 7 / 0x7 SubCount(2 Byte): 6 / 0x6 SubCount(2 Byte): 6 / 0x6 Size: Size: (4 Byte): 159678 / 0x26FBE (4 Byte): 4307 / 0x10D3 (4 Byte): 767091 / 0xBB473 (4 Byte): 374556 / 0x5B71C (4 Byte): 50029 / 0xC36D (4 Byte): 25407 / 0x633F (4 Byte): 256693 / 0x3EAB5 (4 Byte): 52340 / 0xCC74 (4 Byte): 487497 / 0x77049 (4 Byte): 140926 / 0x2267E (4 Byte): 601379 / 0x92D23 (4 Byte): 11916 / 0x2E8C HasCopyright(1 Byte): 1 / 0x1 HasCopyright(1 Byte): 1 / 0x1 Unknown2(1 Byte): 1 / 0x1 Unknown2(1 Byte): 195 / 0xC3 Unknown3(1 Byte): 0 / 0x0 Unknown3(1 Byte): 0 / 0x0 Unknown4(1 Byte): 0 / 0x0 Unknown4(1 Byte): 255 / 0xFF Unknown5(1 Byte): 1 / 0x1 Unknown5(1 Byte): 0 / 0x0 Unknown6(1 Byte): 0 / 0x0 Unknown6(1 Byte): 0 / 0x0 Unknown7(1 Byte): 0 / 0x0 Unknown7(1 Byte): 0 / 0x0 Name: Name: (13 Byte): 'I0FD3F12.LBL' (13 Byte): '63240001.TRE' (13 Byte): 'I0FD3F12.RGN' (13 Byte): '63240001.RGN' (13 Byte): 'I0FD3F12.TRE' (13 Byte): '63240001.LBL' (13 Byte): 'I0FD3F12.NET' (13 Byte): '63240001.NET' (13 Byte): 'I0FD3F12.NOD' (13 Byte): '63240001.NOD' (13 Byte): 'I0FD3F12.DEM' (13 Byte): '63240001.DEM' Unknown8(8 Byte): 0 / 0x0 Unknown8(8 Byte): 0 / 0x0 Unknown9(9 Byte): 0 / 0x0 Unknown9(9 Byte): 0 / 0x0 Die Punkte links-oben sind immer Vielfache des Punktabstandes. Aber Garmin nimmt es offensichtlich nicht so ganz ernst damit, wirklich den zur TRE-Position nächstliegenden Punkt zu nehmen. DEM: PointDistance 3312 / 0xCF013248 / 0x33C0 26512 / 0x6790 53024 / 0xCF20 Left 145549152 / 0x8ACE760 145542528 / 0x8ACCD80 145524368 / 0x8AC8690 145497856 / 0x8AC1F00 Top544032432 / 0x206D46B0 544042368 / 0x206D6D80 544052752 / 0x20
Re: [mkgmap-dev] mkgmap r4048 seems to fix problem with hill shading
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,
semicolon or tab. If this file have q.e. 200 x 150 values, create BuildDEMFile
3 x 4 DEM-Tiles.
As next i extract with the simple perl-script extracttiles.pl a range of tiles,
encode this whith
BuildDEMFile --dem="%TESTMAPDIR%\Product1\99950001\99950001.DEM" -O
--data=dem.data --lastcolstd=false --left=0 --top=0.91893768310546875
--dlon=0.0003 --dlat=0.0003
and see on the testmap 99950001.osm, what's going on. It's only "trial and
error".
Frank
---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus
use strict;
my $x = 0;
my $y = 0;
my $x2 = 0;
my $y2 = 0;
if (@ARGV >= 0) { $x = shift @ARGV; }
if (@ARGV >= 0) { $y = shift @ARGV; }
if (@ARGV >= 0) { $x2 = shift @ARGV; }
if (@ARGV >= 0) { $y2 = shift @ARGV; }
print STDERR "lese Daten ...\n";
my @lines = ();
while () {
chomp $_;
my $l = $_;
push @lines, $l;
}
print STDERR "extrahiere Kachelbereich [$x, $y] ... [$x2, $y2]\n";
my $xstart = $x * 64;
my $ystart = $y * 64;
my $xend = $x2 * 64 + 64;
my $yend = $y2 * 64 + 64;
for (my $j = $ystart; $j < $yend && $j < @lines; $j++) {
my @cols = split /[\s;,]/, $lines[$j];
for (my $i = $xstart; $i < $xend && $i < @cols; $i++) {
if ($i > $xstart) {
print ",";
}
print $cols[$i];
}
print "\n";
}
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] mkgmap r4048 seems to fix problem with hill shading
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 have a strange hillshading. In worst case it looks like in the video or mapsource crashed. To find such an error we need exact the integer values for encoder. Keep in mind, that the values are depend on the exact left-top coordinate of the tile, the point distance and the interpolation algorithm. It is possible, that only one zoomlevel is out of order. Gerd, for such a case it would be a good idea, if mkgmap have a option to export this integer data as textfile or whatever. Then the coordinates are unnecessary. 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
Re: [mkgmap-dev] HGT - getElevation()
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 +-7m and i don't believe the technic was worse. That's why feets are overkill. The numbers are 3 times greater, that's why the dem's are greater. It's not worth it. 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
Re: [mkgmap-dev] HGT - getElevation()
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 - y * x) + h22 * y * x (h11 is left-bottom in coordinate origin, the horizontal and vertical distance is 1) If your java-class have to much overhead, you can use this formula. By the way, i would be very defensive with interpolation in the case of missing values. The hgt values are only interpolated values from original measurments. I would not interpolate values in the near of missing values. That give us a nice but unreliably picture. Frank___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] HGT - getElevation()
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): hlthrt (height right top) +---+ | /| | / | |/ | +---+ hlbhrb 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: hlthrt +---+ |\ /| | x | |/ \| +---+ hlbhrb 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 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Performance with zipped hgt files
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 vantage for mkgmap if the data are stored in an other form. It can only save disc space, no heap space. What speaks against a limitation for the extent of a maptile? This limited the count of hgt's for one maptile too. You have the option --max-areas for splitter. We need only an additional option like --maxextent or whatever. Perhaps we have then maptiles without points, lines or areas (on oceans, deserts or so), but why not? Frank___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] DEM-file generation from geo-tiff sources ?
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. Perhaps you have an to old gdal-version without lzw-compression? Or perhaps -co \"COMPRESS=LZW\" -co \"TILED=YES\" -co \"PREDICTOR=2\" should be better -co COMPRESS=LZW -co TILED=YES -co PREDICTOR=2 I have found hgt's with a few deep "holes" (< 0 m) but they seems to be ok (surface mining). 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
Re: [mkgmap-dev] DEM-file generation from geo-tiff sources ?
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 hgt's and only 3,54GB for the tif's with lzw compression (round about 68%). "container" means: only use 16-bit grayscale values, no metadata, no coordinate reference system or whatever. A "on-the-fly-conversion" is to expensive. You ask: Are the copernicus-files so much better compared to the viewfinder-hgt files? How we can decide this? I believe, there is no way. I have not found any information about the +- interval for SRTM or the viewfinder-data. I only know, that the copernicus-files have the 25m resolution from tanger up to the north cape in norway. 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
Re: [mkgmap-dev] DEM-file generation from geo-tiff sources ?
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_TRANSLATE_OPT=-multi -wo NUM_THREADS=ALL_CPUS -t_srs EPSG:4326 -r near -ot Int16 -dstnodata -32768 -of GTiff -co \"COMPRESS=LZW\" -co
\"TILED=YES\" -co \"PREDICTOR=2\" -ts 3601 3601\n";
for (my $lat = $latbottom; $lat != $lattop; $lat++) {
for (my $lon = $lonleft; $lon != $lonright; $lon++) {
printf "gdalwarp %%GDAL_TRANSLATE_OPT%% -te %.7f %.7f %.7f %.7f
$srcdir/all.vrt %s%02d%s%03d.tif\n",
$lon - $delta,
$lat - $delta,
$lon + 1 + $delta,
$lat + 1 + $delta,
'N',
$lat >= 0 ? $lat : -$lat,
$lon >= 0 ? 'E' : 'W',
$lon >= 0 ? $lon : -$lon;
}
}
Yes, i was very lazy with the huge area. That are 2740 1°x1° tiles. But my computer is very diligent ;) . Have in mind the $delta. Hgt's have not
exact 1° width/height. It's 1 pixel more, that means a half pixel on each side.
I have tested different interpolation methods. I believe "near" is the best
(and fastest) method.
My computer created in 65 min all the tif's. I'm sure, that is strong depend on
the hardware.
Surprisingly the new tif's have only round about 4 GB.
Then i create with
gdalbuildvrt all.vrt *.tif
gdal4hgt --raster=all.vrt --dstpath=..\hgt -O
the zipped hgt's. That is very easy but very slow (160 min). By the way, gdal4hgt create only hgt's with min. 1 non-nodata value. The resulting zipped
1001 hgt's need 5,2 GB!
You wrote: "gdal_translate -strict -q -eco -of SRTMHGT -outsize 3601 3601 "
should basically do the same job ...
The format SRTMHGT was new for me, but i think, you are right. I have not
tested the speed.
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
Re: [mkgmap-dev] DEM-file generation from geo-tiff sources ?
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 12 51 all.vrt N50E011.tif gdal4hgt --raster=N50E011.tif --dstpath=. The first command create a vrt file (virtual). This is only a xml file with links to the real tif's. It runs a few seconds. The second command cut a the area with longitude 11..12 and latitude 50..51 (in EPSG:4326) from all.vrt and write it with3601x3601 pixel as lzw compressed geotif. A pixel is saved as int16. The resampling method is lanczos. It also runs a few seconds. The last command is my own prog. It converts the tif in a few seconds to hgt. It seem's to be ok. If gdalwarp run in a loop, it create a lot of new tif's. With the new tif's can we create a new vrt. gdal4hgt should convert this new vrt to all nonempty hgt's in one run. 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
Re: [mkgmap-dev] DEM and "holes"
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.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] DEM and "holes"
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
Re: [mkgmap-dev] DEM and "holes"
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 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
Re: [mkgmap-dev] r4006: 1st alpha version to write DEM data
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 "maxheight". Then we can limit the size of areas like deserts. On my "explorations" i have see, that a defective 64x64 tile most troubling the whole maptile. It is not easy to find the cause of that. Perhaps the decoder in mapsource don't stop automaticly at the end of the data range for a 64x64 tile. By the way, if you save the input int-data for your encoder in a textfile, you can "feed" builddemfile with this int-data (option --data). Or you can test this data with the prog input2. 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
Re: [mkgmap-dev] r4006: 1st alpha version to write DEM data
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 and 0.0025. The relations are rounded 1.8, 1.5, 1.4, 1.6, 1.5. With such relations we don't have an easy way to calculate one DEM level from another. I think, it's better to use ever the original data for calculating and interpolating a level. 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
Re: [mkgmap-dev] Maps in *.gmap format installation directory
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 mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] DEM File Format and mkgmap
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 the ?TOPO Deutschland v3?. Please see the pages 3 and 4. There are a few "unknown values". For example see "Codierungstyp" (coding type) for a 64x64 tile. I found in different garmin maps values from 0 to 6. 0 is the standard. It seems to be, that the coding type have no influence of the algorithm, but i'm not sure. Presumable is this type only important for different interpretations of the height values. BuildDEMFile use type 1 for areas with "unknown height". This is in this case the interpretation for height=maxvalue. Unknown is also the byte on position 0x25 in the dem header. In the ?TOPO Deutschland v3? there we have 0x1 but i have also seen in other maps 0x0. Interesting is also the word in 0x12 in everey zoomlevel definition (see page 26 in the pdf). In the ?TOPO Deutschland v3? thats all 0. But i have also found 0x100, 0x200, 0x400. Perhaps a kind of multiplier for heights? Very important is the bytes 0x0 (and 0x1) in everey zoomlevel definition. In the ?TOPO Deutschland v3? 0x0 is ever 0. 0x1 seems to be a number as "link" to a maplevel. But i don't really understand the sense ot that. We can have 6 maplevels and we can say the maplevel 2 and 4 are without dem's? In a little demo map from garmin i have see "twins" of zoomlevelnumbers, one with value 0 on 0x0 and one with 1 on 0x0. Perhaps 0x0 is for different and optimized output on pc and gps? I think, a decompiler with the algo from my pdf is working only for this special case: 0x15 in dem header should be 0 (meter) 0x25 in dem header should be 1 0x0 and 0x12 in every zoomlevel should 0 By the way, have anybody see a dem with values in foot? The values in such a dem should be greater then for a dem in meter. Have anybody height values with a precision of foot? The conversion from foot to meter would be a first compression step. If garmin really use "foot", then a different/better compression algo make sense. Frank___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] gmtool and TDB
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\Openfietsmap\versions\test\Openfietsmap (BNL).gmap\Product1" this is ok. Then you also don't need the full path for your old TDB. -o defined the output path, in this case only for the new TDB. Frank___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] too many restrictions
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 empty tag values, e.g. way 148796438 has line_path3="" That means a way with type "line_path3" and without a name. The rule for mkgmap is defined in inc\inc\lines_smallway and mkgmap should take "type 0x11406 level 2". Frank___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] too many restrictions
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 problem for me. For hiking i don't need routing. I'm looking for nice ways, not short ways.) Is shrinking the tile size also an option? I use splitter with dummy values, but with --num-tiles=x or better with --max-nodes < 160 should i have smaller tiles (?). In this case it could be a good idea, if mkgmap show an additional error message like this: "x% of roads successfull handled ...". Then we have a idea for a better value for --max-nodes. Frank___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] too many restrictions
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.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] too many restrictions
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 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] too many restrictions
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
[mkgmap-dev] too many restrictions
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 have this a little bit simplified. I use only 1 tile
(63240045.osm.pbf). My test-style is:
# lines
line_motorway=* [0x01 level 6 road_class=4 continue]
line_motorway=* | line_motorway_link=* [0x01 level 6 road_class=4
continue]
line_trunk=* [0x02 level 6 road_class=4 continue]
line_trunk=* | line_trunk_link=* [0x02 level 6 road_class=4 continue]
line_primary=* [0x03 level 5 road_class=3 continue]
line_primary=* | line_primary_link=* [0x03 level 5 road_class=3 continue]
line_secondary=* [0x04 level 4 road_class=2 continue]
line_secondary=* | line_secondary_link=* [0x04 level 4 road_class=2
continue]
line_tertiary=* [0x05 level 3 road_class=1 continue]
The points-, polygons- and relations-file are empty.
Don't worry about this style. I use a pre-process for the classification
of objects. And "line_secondary=*" and "line_secondary=* |
line_secondary_link=*" is necessary. Original i use this:
line_secondary=* & line_secondary!='' {
name '${line_secondary|highway-symbol:box:5:5}';
} [0x04 level 4 road_class=2 continue]
line_secondary_link=* & line_secondary_link!='' {
name '${line_secondary_link|highway-symbol:box:5:5}';
} [0x04 level 4 road_class=2 continue]
line_secondary=* | line_secondary_link=* [0x04 level 4 road_class=2
continue]
The 1. and 2. condition is for the case, that i have a name in
line_secondary / line_secondary_link. The 3. condition is, when the street
is without a name.
When i remove in the simple style the condition "line_secondary=*", it
seem to be ok.
I hope the style is not to creazy.
My command-line is:
java.exe -Xmx6G -jar mkgmap.jar -c mkgmap.opt ..\63240045.osm.pbf
My java-version is jre1.8.0_151.
The option-file mkgmap.opt contains only:
family-id=7006
mapname=7006
output-dir=test
style-file=style_test
route
If i don't use "route", there is no error!
Frank___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] gmtool and TDB
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 have additional DEM's can we do: gmtool -i old.tdb -i . --mapsource=new.tdb;noov;notyp;nomdx;nomdr;noinst --hasdem=1 -o . This should be enough for a map with IMG's. If we have a gmap-style map, we need the subfiles in the subdirectorys and we can do: gmtool -i old.tdb -i . --withsubdirs --mapsource=new.tdb;noov;notyp;nomdx;nomdr;noinst --hasdem=1 -o . Hope it worked. Frank___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Issues generating DEM
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
Re: [mkgmap-dev] Issues generating DEM
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 mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Issues generating DEM
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 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Issues generating DEM
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 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
Re: [mkgmap-dev] Issues generating DEM
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 for short also 4 byte). 200 HGT's need 1,1 GB. Hard to estimate is the size for DEM-Data. The prog is compiled as "any cpu" and "prefer 32-bit". If "prefer 32-bit" not set, run the prog in 64-bit-win as 64-bit-prog and can use more memory. But it runs slower. If you self compiled the prog, unset the option and try to use a xml-file BuildDEMFile.exe.config like this: But you are allright, downsizesing the HGT's "on the fly" should not to be a problem. Let me a little bit think about that. 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
Re: [mkgmap-dev] BuildDEMFile problem
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 is lon 0° and lat 50°). Builddemfile use only dummy values ("nur Dummywerte"),
because there was no such HGT file.
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
Re: [mkgmap-dev] BuildDEMFile problem
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 --dem=87827699.dem --tre=87827699.tre --dlon=0.0002;0.0005;0.0010;0.0021;0.0084 create a DEM file with 23781 Byte. #2: Like Andrzej wrote: you need also a new TDB. I have used a quick but very dirty method: I have only for TDB-build temporary created the Tile IMG's ov.img and 87827699.img. gmtool -i mapdem\*.* --join=tile -o ov.img gmtool -i 87827699\*.* --join=tile -o 87827699.img gmtool -i *.img --mapsource=pid:1;fid:3927;cp:1252;ov:ov.img;tdb:neu.tdb;noov;notyp;nomdx;nomdr;noinst --mapfamilyname=mapdem --mapseriesname=mapdem --description="Test preview map" --routable=1 --highestroutable=24 --maxbits4overview=18 --hasdem=1 --hasprofile=1 --copyright=*I* -o . --overwrite ren mapdem.tdb mapdem.tdb_ ren neu.tdb mapdem.tdb del *.img Of course, in your little demo we can not see a shading. But we can see the values for N, E and height in the basecamp status line. By the way, be careful wit --usedummydata. It's only interest for sea-areas, where don't exist a HGT. But if a HGT for land is absent, we have a hole in our map without an error message! Frank___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] BuildDEMFile problem
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 your map? Frank___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] BuildDEMFile
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 points. Frank___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] BuildDEMFile
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.0067 --dlon=0.013 BuildDEMFile, Version vom 9.11.2017b, Copyright © FSofT 2017 HGT-Daten lesen ... Höhen für 23° .. 24° / 52° .. 53° eingelesen, Werte 97 .. 215 Höhen für 23° .. 24° / 51° .. 52° eingelesen, Werte 130 .. 293 Höhen für 22° .. 23° / 53° .. 54° eingelesen, Werte 69 .. 230 Höhen für 22° .. 23° / 52° .. 53° eingelesen, Werte 77 .. 219 Höhen für 23° .. 24° / 53° .. 54° eingelesen, Werte 74 .. 246 Höhen für 22° .. 23° / 51° .. 52° eingelesen, Werte 112 .. 304 Einlesezeit 0,3s 3 Zoomlevel Kachelanzahl 8 x 10 (rechte Spalte 121 breit, untere Zeile 25 hoch) Rand links 22,208450317°, oben 53,638961792°, 0,946884155273438° breit, 1,9918212891° hoch Pixelgröße 0,0017° x 0,0017° Kachelanzahl 2 x 3 (rechte Spalte 79 breit, untere Zeile 23 hoch) Rand links 22,208450317°, oben 53,638961792°, 0,946884155273438° breit, 1,9918212891° hoch Pixelgröße 0,0067° x 0,0067° Kachelanzahl 1 x 2 (rechte Spalte 72 breit, untere Zeile 12 hoch) Rand links 22,208450317°, oben 53,638961792°, 0,946884155273438° breit, 1,9918212891° hoch Pixelgröße 0,013° x 0,013° encodiere 88 Subtiles . 88 Kacheln encodiert Laufzeit 0,8s The option --mt is not allright. Have you see the runtime? It's the same or a little more then without the option. I haven't still found the cause ot this. I belief, your --xlon idea is not useful. Yes, the point-distance in the hgt's is 1/1200 or 1/3600 degree. But the corner left-top of the TRE can have any value and not only in this grid. Therefore we have normaly to interpolate the value for this corner and for all other points. That means, we nearly ever use interpolated values. Of course, interpolation make the values not better! If you interested you find interpolation algorithm in the function InterpolatedHeight() in HGTReader.cs. It is not necessary, to double the values. Try out and use distances, that looks good for you. 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
Re: [mkgmap-dev] DEM format Questions
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 garmin programmers done, they have found a very good compression for this special case. They don't waste a bit. But perhaps they think also to confuse all the snoopy guys on the world. Perhaps they say: hey let us take a special case, if the compression is not worse. I have no idea for the 158. I belief, we can see this as parameter. Perhaps garmin have found with trial and error, that 158 give smallest DEM's for a lot of areas on earth. Then it is more a "statistical" reason. By the way, the worst thing in my opinion is the rule for "Längencodierung". It is rather a "descriptiv" solution. Perhaps behind this is a more "mathematical theory", but i don't found it. Frank___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] DEM format Questions
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
Re: [mkgmap-dev] hgt2osm questions
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/lon. Using --HgtPath is easier for me. 3) Unfortunately i can't reproduce this effekt. You have probably do that (?): hgt2osm --HgtPath=E:\Dem\All_UK_HGT_Data\ --Mergefile=e:\devonall2.osm The prog take then all HGT's in the hgt-path, produce files like clN40W006.osm.gz and at last e:\devonall2.osm. I see "==> Lese Ausgangsdaten 49° -4° ...". Have you really a file N49W004.hgt.zip or S04E049.hgt.zip? I think, that's all water between france and GB or eastwards from africa. I have updated the prog. Frank___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] problems with gmtool
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 gmt.TDB -I 3 > info_tdb.txt a info file for this TDB. It should looking like this: TDBVersion: 407 CodePage:1252 (0x04E4) Family-ID: 7026 (0x1B72) Product-ID: 1 (0x0001) ProductVersion: 100 (0x0064) FamilyName: OSM, Austria SeriesName: Austria, aio, 5.6.2017 Routingfähig:1 (0x01) größter Routing-Typ: 24 (0x18) mit Contourlinien: 1 (0x01) DEM: 1 (0x01) niedrigster MapLevel:18 (0x12) Beschreibung:AUT Unknown1:0 (0x00) Unknown2:1 (0x01) Unknown3:1 (0x01) Unknown4:1 (0x01) Unknown5:0 (0x00) Unknown29: 1 (0x2710) Copyright: [CopyrightInformation, ProductInformationAndPrinting] created by gmtool Overviewmap: Kartenummer: 7026 (0x04301520) übergeordnet: 0 (0x) Beschreibung: AUT, (7026) Anzeigebereich:Lon 9,492188°..17,182617°, Lat 46,318359°..49,042969° Detailkarten:53 Kartenummer: 70260001 (0x04301521) übergeordnet:7026 (0x04301520) Beschreibung:DE-Muenchen, (70260001) Anzeigebereich: Lon 9,492188°..13,315430°, Lat 47,900391°..49,042969° Dateien: 70260001.TRE (110159 Byte), 70260001.LBL (165626 Byte), 70260001.RGN (7789597 Byte), 70260001.NET (702298 Byte), 70260001.NOD (1082548 Byte), 70260001.DEM (24354388 Byte) HasCopyright:1 (0x01) Unknown1:0 (0x) Unknown2:195 (0xC3) Unknown3:0 (0x00) Unknown4:255 (0xFF) Look, if the overviewmap have the right ID and the other maps this ID as "übergeordnet". Look, that all the subfiles are listed. If the properties like Family-ID are false, you change it with gmtool. The unknown bytes are really unknown. The values above are used in mkgmap. BTw, there is a newer prog version, but i don't belief, they going better. 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
Re: [mkgmap-dev] DEM format Questions
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) (horizontal difference, see at the end of "Datenberechnung"). max is highest possible value in this 64x64-subtile. #2: We have to decide, is it "Längencodierung", "Hybride Codierung" or if they are not possible, "Binärcodierung für große Zahlen". But we have no choice, we have to use that kind, that the algorithms say (see " Umschaltung der Codierart"). That do in TileEncoder.cs the class CodingType and the derived classes. I'm sorry, but TileEncoder.cs is not written for speed or good understanding. It is only for exploring DEM and, in Input2, for showing, what's going on. There is much place for optimizing. ;) Frank___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] DEM format Questions
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/Input2/bin/Input2.exe ) show us: MaxHeigth=158, Codingtype=0, TileSize=64x64, BaseHeigthUnit=1, HeigthUnit=0, ActualMode=notdefined, ActualHeigth=0 Line 0 Idx=0, Plateau Length=0 TableIdx=0 Bits=0 [.] <> Idx=0, PlateauFollower ActualHeigth=4, Value=4 PlateauFollower0 [...11] Hybrid1 ddiff=0 Idx=1, ActualHeigth=4, Value=0 Standard [1.] Hybrid1 ... Idx=62, ActualHeigth=7, Value=0 Standard [1] Length0 Idx=63, ActualHeigth=7, Value=0 Standard [1] Length0 Line 1 Idx=0, Plateau Length=0 TableIdx=0 Bits=0 [.] <> Idx=0, PlateauFollower ActualHeigth=8, Value=4 PlateauFollower0 [.111] Hybrid2 ddiff=0 Idx=1, ActualHeigth=8, Value=0 Standard [1] Length0 Idx=2, ActualHeigth=5, Value=-3 Standard [..1] Length0 Idx=3, Plateau Length=4 TableIdx=3 Bits=1 [..] <111a> Idx=7, PlateauFollower ActualHeigth=8, Value=-1 PlateauFollower1 [.1.] Hybrid1 ddiff=2 Between the brackets [ and ] are the bits (. means 0). There is no special case. If a plateau have to begin, we have as first the plateau-length (see "Codierung der Plateaulänge"). There is ever a 0-Bit between the 2 parts of length-coding, also when plateau-length=0 (often on start of a line). As next we have the height-coding for the follower. Frank___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] BuildDEMFile
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
[mkgmap-dev] BuildDEMFile
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 linux mint 18.2 and mono. Main options: -d, --dem=arg name of DEM-file, (e.g. 70210001.DEM) --hgtpath=arg directory for HGT's (zipped or not) --tre=arg name of TRE-file (e.g. 70210001.TRE) -o, --dlon=argdistance between DEM-Point (multiple usage for more zoomlevels) --usedummydata=arguse 'without-value' (0x8000), if one or more HGT's not present --lastcolstd=arg last subtile column has ever a width of 64 (need a little bit more memory on disk) -O, --overwrite=arg overwrite existing destination files or not -f, --foot=argDEM data in foot or meter 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
Re: [mkgmap-dev] a new DEM-File Option ---> MDR-Problem
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 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] a new DEM-File Option
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 and include they in the map like the TRE's, RGN's and so on. 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
Re: [mkgmap-dev] a new DEM-File Option
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 gps because on gps every zoomlevel is visible for a few zoom's. I think, you should have for every maplevel (see options-file in mkgmap-style) its own zoomlevel. --dlon and --dlat is the distance between the points. Normally --dlon == --dlat, thats why you can omit --dlat. --dlon=0 is senseless, that means: no distance between the points. For more zoomlevels use multiple --dlon. The values are experimental: BuildDEMFile ... --dlon=0.00027761 --dlon=0.00049 --dlon=0.00075 --dlon=0.00106 --dlon=0.0017 --dlon=0.0025 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
Re: [mkgmap-dev] Issues generating DEM
"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 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
Re: [mkgmap-dev] a new DEM-File Option
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\OpenFietsMap\1001.tdb' 21729 Bytes (21,2 kB, 0,0 MB), letzter Schreibzugriff 28.10.2017 01:43:28 TDBVersion: 407 CodePage:1252 (0x04E4) Family-ID: 10010 (0x271A) Product-ID: 1 (0x0001) ProductVersion: 1710 (0x06AE) FamilyName: OpenFietsMap (BNL) SeriesName: OpenFietsMap (Benelux_v28-10-2017) Routingfähig:1 (0x01) größter Routing-Typ: 24 (0x18) mit Contourlinien: 1 (0x01) DEM: 0 (0x00) niedrigster MapLevel:18 (0x12) Beschreibung:Test preview map Unknown29: 1 (0x2710) Copyright: [CopyrightInformation, ProductInformationAndPrinting] Map created with mkgmap-r3908 [CopyrightInformation, ProductInformationAndPrinting] PROGRAM LICENCED UNDER GPL V2 [CopyrightInformation, ProductInformationAndPrinting] MAP DATA © OPENSTREETMAP.ORG, MAP LAYOUT © OPENFIETSMAP.NL, SRTM DATA © U.S. GEOLOGICAL SURVEY [CopyrightInformation, ProductInformationAndPrinting] OPENSTREETMAP.ORG CONTRIBUTORS|SEE: HTTP://WIKI.OPENSTREETMAP.ORG/INDEX.PHP/ATTRIBUTION Overviewmap: Kartenummer: 1001 (0x0098BD90) übergeordnet: 0 (0x) Beschreibung: OFM_BNL(28-10-2017) Anzeigebereich:Lon 2,373047°..7,382920°, Lat 49,350586°..55,264900° Detailkarten:145 Kartenummer: 10010001 (0x0098BD91) übergeordnet:1001 (0x0098BD90) Beschreibung:BE-Ieper (10010001) Anzeigebereich: Lon 2,373047°..2,900391°, Lat 50,668945°..50,888672° Dateien: 10010001.TRE (38603 Byte), 10010001.RGN (3909498 Byte), 10010001.LBL (175026 Byte), 10010001.NET (428039 Byte), 10010001.NOD (714739 Byte) The main-part is a long list of all mapnumbers/files with the subfiles. It is necessary to rebuild this list with the DEM-files with their filesize. That's why use the NEW IMG's for this. 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
Re: [mkgmap-dev] a new DEM-File Option
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 temporarly move to another directory. Then you can use the mask *.img. Another way is using a namelist in a texfile with the option --inputlist. By the way: "tdb:1001.tdb.tdb" is probably not really that what you want. 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
Re: [mkgmap-dev] Issues generating DEM
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 only valid, if your machine have enough memory. I'm not shure, but i believe on a 32-bit-machine/windows is the object-size only 1 GByte. By the way, a .NET-program should be run with linux/mono. I cannot test that, but a command-line program should be easy enough. Can you try that? At second, i have used your TRE file with this output: BuildDEMFile, Version vom 30.10.2017, Copyright © FSofT 2017 Daten aus der TRE-Datei '55113002.TRE' gelesen Höhen für -8° .. -7° / 37° .. 38° eingelesen Höhen für -5° .. -4° / 40° .. 41° eingelesen 1 Zoomlevel erzeuge 10560 x 9339 interpolierte Höhenwerte für den Abstand 0,00027761° x 0,00027761°... Daten 10560 x 9339, Min. 70, Max. 2531 für Zoomlevel 0 Kachelanzahl 165 x 146 (rechte Spalte 64 breit, untere Zeile 59 hoch) Rand links -7,56333589553833°, oben 40,498673915863° Pixelgröße 0,00027761° x 0,00027761° 24090 Kacheln encodiert It is mysterious. 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
Re: [mkgmap-dev] Issues generating DEM
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 in program. I need the area size to debug the program. Please look at the file areas.list (generated from splitter). 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
Re: [mkgmap-dev] a new DEM-File Option
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://github.com/FSofTlpz/GmTool/blob/master/bin/Release/GarminCore.dll gmtool --overwrite --input .img --output . --mapsource=pid:1;fid:10010;cp:1252;ov:osmmap.img;tdb:osmmap.tdb;noov;notyp;nomdx;nomdr;noinst --version=1710 --mapfamilyname="Test" --mapseriesname="Test" --description="Test" --routable=1 --highestroutable=24 --maxbits4overview=18 --hasdem=1 --hasprofile=1 --copyright=*I* This use infos from all IMG-files with 8 characters in the actual directory and create a new osmmap.tdb. (See also the (german) help with gmtool --help) If anybody want to patch a few bytes in a TDB-file and test the result of this, he can read and then rewrite this file with gmtool. This should update the crc. 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
Re: [mkgmap-dev] a new DEM-File Option
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. If you use DEM on gps device, then you should have one DEM-zoomlevel for every Maplevel (see option-file in your mkgmap-style). Use --dlong multiple with higher values, for example "--dlon=0.00027761 --dlon=0.00049 --dlon=0.00075 --dlon=0.00106 --dlon=0.0017 --dlon=0.0025" for 6 maplevels. Best values are to check out. 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
Re: [mkgmap-dev] a new DEM-File Option
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 overlaps the DEM from the IMG a little bit with the next right IMG. That need a little bit more space but with other subtile-widths the algo have sometimes problems. 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
Re: [mkgmap-dev] a new DEM-File Option
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 faultily subtile and i hope, i find a solution for that issue. 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
Re: [mkgmap-dev] a new DEM-File Option
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 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] BuildDEMFile : false error
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, then use option --usedummydata: builddemfile --dem=test.dem --hgtpath=%OSM_DATA%\srtm_zip --lastcolstd --usedummydata --overwrite --dlon=0.0003 --left=54.9 --top=-20.1 --width=1.2 --height=1.2 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
Re: [mkgmap-dev] a new DEM-File Option
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 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
Re: [mkgmap-dev] a new DEM-File Option
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 gps-device (oregon 600) are more zoomlevels necessary. 1 zoomlevel is only enough for max. 800m-zoom. Maybe, we need maplevel - 1 zoomlevels for all zooms (?). When i build direkt a device-IMG with DEM-files with more zoomlevels, my oregon shows them all. (I add simply to all tile-IMG's the DEM-files and then i pack all files together.) But the reason for the senseless error-message from mapsource is obscure. I will make some further tests in the next days. 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
Re: [mkgmap-dev] a new DEM-File Option
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 "Community"-Version von MS Visual 2015. Als Zwischenlösung könnte die Aufnahme einer zusätzlichen Option dienen. Es wird, hoffentlich, sowieso noch weitere Erkenntnisse zur Verwendung mehrerer Zoom-Level für GPS-Geräte geben. Im Moment ist es deshalb einfacher, an einem Programm wie builddemfile weiter zu testen. 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
Re: [mkgmap-dev] a new DEM-File Option
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 workaround is, to use a normal tile with 64 points width. That's why, the DEM is at most a little bit widend then the TRE. The data in a sub-tile are organized as a bitstream. That's why, we can not split a subtile in parts. I belive, we must "compile" a DEM for anything TRE new. at third: Yes, the best way is, to build in the algorithm in mkgmap. But i'm not familiar with java. It would be useful, if anybody translate my description (my german is a little bit better than my english :). For easy test: builddemfile --dem=12345678.dem --hgtpath=path2zipped_hgt_files --tre=12345678.tre --dlon=0.00027761 I build the program with the MS-Visual-Studio 2015. at fourthly: I build also a DEM-file for the overview-map, but with --dlon=0.005. at fifthly: Probably can a DEM-file several Zoomlevel. But for Mapsourec/Basecamp it is not necessary. It seems, we need that for a GPS-Device. My Oregon show DEM only for Zoom <= 800m. 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
Re: [mkgmap-dev] Polygons deformed [Antwort]
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 is the minimal distance. What means that for example for the equator? 360° stands for around 40.075 km circumference of the earth. The minimal distance is for a latitude of 0° around 2,4m! For higher latitude it is of course higher. I think, there is no way. 24 Bit for longitude/latitude is to less. But more Bits are more memory consumption and bigger maps. See also on my web-page "Linien- und Polygonvereinfachung" http://technik.stinnerweb.de/Gps/garmin1.html. It is in german, but the pictures are language-independed ;) Frank___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Option --index but no "Find Place" in Mapsource [Antwort]
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,int_name,name:en,name index route net tdbfile nsis area-name=Germany road-name-pois=0x2f15 draw-priority=20 reduce-point-density=2.6 reduce-point-density-polygon=1.2 merge-lines remove-short-arcs latin1 levels=0:24,1:23,2:22,3:21,4:20,5:19,6:17 max-jobs I think, the Registry is ok: Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Garmin\Mapsource\Families\FAMILY_6324] "ID"=hex:B4,18 "IDX"="j:\\Gps\\Projekte\\DB-Test\\org_mkgmap\\osmmap.mdx" "MDR"="j:\\Gps\\Projekte\\DB-Test\\org_mkgmap\\osmmap_mdr.mdx" [HKEY_LOCAL_MACHINE\SOFTWARE\Garmin\Mapsource\Families\FAMILY_6324\1] "Loc"="j:\\Gps\\Projekte\\DB-Test\\org_mkgmap\\" "Bmap"="j:\\Gps\\Projekte\\DB-Test\\org_mkgmap\\osmmap.img" "Tdb"="j:\\Gps\\Projekte\\DB-Test\\org_mkgmap\\osmmap.tdb" Maybe the order of the options is important???___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Option --index but no "Find Place" in Mapsource [Antwort]
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_20121019.zip" is an absolute path (beginning at the root). "Gps\Data\bounds_20121019.zip" is an relativ path (beginning at the current directory). The first path is real that what i mean. By the way, the Java-File-class accepts all this variants (on a windows-machine): bounds=\Gps\Data\bounds_20121019.zip bounds=j:\Gps\Data\bounds_20121019.zip bounds=/Gps/Data/bounds_20121019.zip bounds=j:/Gps/Data/bounds_20121019.zip ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Option --index but no "Find Place" in Mapsource
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 area-name=Germany road-name-pois=0x2f15 draw-priority=20 reduce-point-density=2.6 reduce-point-density-polygon=1.2 merge-lines remove-short-arcs latin1 levels=0:24,1:23,2:22,3:21,4:20,5:19,6:17 max-jobs The Commandline is: java -Xmx1500M -jar p:\gps\bin\mkgmap\mkgmap.jar -c mkgmap.opt -c input-files OSM-Data are a little part from the germany_20121118.osm.pbf (splitted in 63240001.img ... 63240008.img) All is fine but i expected, that in Mapsource the Menu "Find place" (in german "Orte suchen") is usable. But this is greyed out. I don't find my mistake. Have you everywhere a simple example for that or is that an error in mkgmap? With best regards___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
