from:"franco

Hi Gerd,
some more test results:
I switched back to the unpatched mkgmap-r4506.
Instead I added some POIs to the boundary style (all fuel stations).
This helped, now POI search is still fast.
this file gives no problems, includes fuel stations
<http://files.mkgmap.org.uk/download/476/dach_boundary_gmapsupp.img>  

the previous file (see below) triggers the problem. 

Ciao,
Franco


franco_bez wrote
> Hi Gerd,
> thanks for the binary.
> I did a lot of testing. I do not get any difference. As soon as I have a
> transparent layer, like housenumbers or bundaries the POI search is slow.
> not matter if I have "route" and "index" in the options or not.
> I also tried with and without "--x-center-poi-type=0x3200".
> 
> I also can not find a POI named "center of map" do I have to add an
> additional option?
> a sample layer built with the patched mkgmap: dach_boundary_gmapsupp.img
> http://files.mkgmap.org.uk/download/475/dach_boundary_gmapsupp.img;  
> 
> Ciao,
> Franco
> 
> 
> Gerd Petermann wrote
>> Hi Franco,
>> 
>> here is a quick hack to add a POI in the center of a map at resolution
>> 24.
>> If the source contains no POI. Default type is 0x6601.
>> You can use e.g. --x-center-poi-type=0x3200 to change the type to a
>> bollard. The name of the POI is "center of map"
>> 
>> I've only tested that the POI is added to the map and to the index of
>> POIs.
>> 
>> The binary is here:
>> http://files.mkgmap.org.uk/download/474/mkgmap.jar
>> 
>> Gerd
> 
> 
> 
> 
> 
> --
> Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html
> ___
> mkgmap-dev mailing list

> mkgmap-dev@.org

> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev





--
Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Performance of POI search on the Device

Hi Gerd,
thanks for the binary.
I did a lot of testing. I do not get any difference. As soon as I have a
transparent layer, like housenumbers or bundaries the POI search is slow.
not matter if I have "route" and "index" in the options or not.
I also tried with and without "--x-center-poi-type=0x3200".

I also can not find a POI named "center of map" do I have to add an
additional option?
a sample layer built with the patched mkgmap: dach_boundary_gmapsupp.img
  

Ciao,
Franco


Gerd Petermann wrote
> Hi Franco,
> 
> here is a quick hack to add a POI in the center of a map at resolution 24.
> If the source contains no POI. Default type is 0x6601.
> You can use e.g. --x-center-poi-type=0x3200 to change the type to a
> bollard. The name of the POI is "center of map"
> 
> I've only tested that the POI is added to the map and to the index of
> POIs.
> 
> The binary is here:
> http://files.mkgmap.org.uk/download/474/mkgmap.jar
> 
> Gerd





--
Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Performance of POI search on the Device

Hi Gerd,

I'm a little lost. I don't know how to proceed with the testing.

I just tried a small map of the offensive "housenumber" layer. This makes no
measurable difference in POI search.
When I use a large "housenumber" map (covering DACH) the effect is
significant. So I assume a single tile would not be useful for testing.

If I could somehow add a few POIs to my existing offensive map this would
help.

Ciao,
Franco





--
Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Performance of POI search on the Device

Gerd Petermann wrote
> I also thought that the missing index of the overlay map might cause the
> problem. I added an (empty) index to that map but that didn't help.
> Maybe it helps to add a single (invisible) named POI to each tile. If that
> helps it would prove that the bug is in the Oregon firmware.
> I don't think that contour lines are the problem. The TK-Europe-Bicycling
> map doesn't contain contourlines, only cycle routes as non-routable lines.
> 
> 
> Gerd

Hi Gerd,
I tried to rebuild one of my layers with the options "index" and "route".
That didn't make any difference.
I have used my "housenumbers" layer, it does not contain contourlines
neither.

How can I build a map with one POI per tile?

Ciao,
  Franco




--
Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Performance of POI search on the Device

Joris Bo wrote
> Same for me. Even indexes of maps not 'enabed' are searched and if
> covering the same area even displays duplicate results.
> Where I first copied big maps to my Oregon just because there was space
> enough on the 32GB SSD, now I build smaller maps and rename them if not
> used that (holi)day(s)
> 
>  Kind Regards
> Joris

Hi Joris,
I remember having had POIs in the search list that came from disabled maps.
That's why I renamed the pre-installed GARMIN maps instead of just
diasbaling them.

-

I made a few tests just now.
If I enable all my routable maps for all of Europe (some 7 GiB total) the
POI search still is incredibly fast, roundabout 1 second.
But if I have one of my non-routable, transparent overlay maps (contourlines
for instance) on the SD Card the search speed is going down significantly. 

I will try if this is triggerd by the "route" option and let you know.

Ciao,
  Franco





--
Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Performance of POI search on the Device

Hi Gerd,

thank you so much.

That did the trick. 
If I only have the one map file on my SD Card the POI search is incredibly
fast.
Now I try to identify the offending map(s)

Ciao,
 Franco



--
Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] Performance of POI search on the Device

2020-05-31 Thread franco_bez

Hi all,

searching for POIs on my Oregon often is very frustrating. It virtually
takes forever.
Yesterday I noticed that some POI types are reasonably fast, while others
are 10 times slower.

I assume that this is some sort of index Problem.

For example 
using my DACH map, built with mkgmap-r4506, map size 2.7GiB on my Oregon
750t
- searching for Gas Stations takes some 5 seconds
- searching for Bank/ATM takes some 50 seconds
- searching for Any-/All Poi types also takes some 50 seconds for the first
Elements to appear in the list.

If I can trust my memory, in the past, maybe some 2 years ago, searching for
Gas Stations was just as slow as any other POI type.

What can I do to get the POI search fast for any POI type in the map ?
I tried --make-poi-index but this didn't make any noticeable difference.

Ciao,
 Franco



--
Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Creating a map with contour lines and DEM

2018-02-13 Thread franco_bez

the easiest way to create a contourlines map is   phyghtmap
  

this tool is for creating osm Files containing the contourlines.

In a second step you build the Garmin map with mkgmap

like this:

phyghtmap --start-node-id=1  -start-way-id=1 --max-nodes-per-tile=100 
--max-nodes-per-way=250  --jobs=4  --o5m --no-zero-contour -s 50 -c 500,100 
hgt_files/*.hgt

java  -jar mkgmap.jar --keep-going --max-jobs  --read-config=options
--style-file=contourlines_style --mapname=65188001
--description=contourlines --family-name=Contourlines --draw-priority=16
--gmapsupp *.o5m


options file:
levels = 0:24, 1:23, 2:22, 3:21, 4:20, 5:18, 6:17, 7:16
reduce-point-density=20
transparent
latin1

Ciao,
  Franco




--
Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Strange error in mkgmap

2018-02-13 Thread franco_bez

Hi Steve and Andrzej,

now it works as intended again.

Thanks for the fix :-)

Ciao,
  Franco



--
Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Strange error in mkgmap

2018-02-12 Thread franco_bez

a resulting bad map : bad_gmapsupp.img
  

Just one tile less - no problem - good_gmapsupp.img
  



--
Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Strange error in mkgmap

2018-02-12 Thread franco_bez

now hrer's the link to the data:
test_cases.tar.gz
  

No, the map is not that big at all, some 200 tiles. 
I build several maps from the same tiles, and only two of them have issues.
One that is drawing the administrative boundaries as an overlay, and the
cycleroute-highlights. 
as the boundaries layer is bigger in size I chose the bikeroute for the
example.



--
Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] Strange error in mkgmap

2018-02-12 Thread franco_bez

Hi all,
I stumbled over a problem in mkgmap
when I build a map with my bikeroute style (an overlay-map to highlight
bicycle routes)
I get a non-functional map for bigger areas.
There is no error message during the build process, just the resulting map
file is faulty.
When I remove some tiles the map is OK.
It seems to be related to the size of the map, not the data itself.

I composed a sample that produces a good and a bad map.
Unfortunately the files are rather big. The smallest example I could build
is ~600MB.
I will provide a link to the example once the upload has finished.
 
 
The faulty map get displayed in the Garmin's map list as "Map data (c)
OpenStreetmap" while the good map get displayed correctly as "Bikeroute"

When I remove one tile from the build the map is OK. It does not matter
which one I remove. So there is no error in one single tile. It has to be a
more complex problem.

Ciao,
  Franco




--
Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html
___
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 ?

2018-01-07 Thread franco_bez

Frank Stinner-2 wrote
> 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.

OK

> Perhaps you have an to old gdal-version without lzw-compression? Or
> perhaps

It's the current version of gdal

> -co \"COMPRESS=LZW\" -co \"TILED=YES\" -co \"PREDICTOR=2\"
> 
> should be better
> 
> -co COMPRESS=LZW -co TILED=YES -co PREDICTOR=2

That did the trick :-) 

Thanks a lot.

now this is the new perl script for Ubuntu
---

use strict;

my $lonleft = -24;
my $lonright = 50;
my $latbottom = 27;
my $lattop = 70;

my $srcdir = "..";

my $delta = 1 / 3600 / 2; # half pixel

print "#!/bin/sh\n";
print "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;
}
}

---

Ciao,
  Franco



--
Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html
___
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 ?

2018-01-07 Thread franco_bez

Hi Frank,
so these are the steps I used on my ubuntu machine:

1. Download the Copernicus Data and unzip
2. create the virtual tif-image gdalbuildvrt all.vrt *.TIF 
3. cut the 1°x1° tiles with the perl script
this results in almost 65GB of uncompressed tif tiles

4. convert every tif-tile to hgt using the following loop

for i in N*.tif ; do
gdal_translate -strict -q -eco -of SRTMHGT $i hgt/`basename $i tif`hgt ;
done ;
rm -f *.hgt.aux.xml ;

5. I found out that the file N27W000.hgt is completely empty, so all tiles
with the identical content are empty also.
with the following commands I removed the empty tiles

mv N27W000.hgt EMPTY.hgt;
for i in N*.hgt ; do
if diff EMPTY.hgt $i ; then 
rm -f $i;
fi
done ;
rm -F EMPTY.hgt;

Now I got 25GB in 1001 hgt tiles



--
Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html
___
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 ?

2018-01-06 Thread franco_bez

I don't know why my "raw-text" blocks got eaten by the nabble.com web
interface

franco_bez wrote
> I got the following warnings

 gdalwarp $GDAL_TRANSLATE_OPT -te -24.0001389 26.9998611 -22.9998611
28.0001389 ../all.vrt N27W024.tif
Creating output file that is 3601P x 3601L.
Warning 6: Driver GTiff does not support "COMPRESS creation option
Warning 6: Driver GTiff does not support "TILED creation option
Warning 6: Driver GTiff does not support "PREDICTOR creation option


> Here's my Ubuntu-script

use strict;

my $lonleft = -24;
my $lonright = 50;
my $latbottom = 27;
my $lattop = 64;

my $srcdir = "..";

my $delta = 1 / 3600 / 2; # half pixel

print "#!/bin/sh\n";
#print "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";
print "GDAL_TRANSLATE_OPT='-multi -wo NUM_THREADS=ALL_CPUS -t_srs EPSG:4326
-r near -ot Int16 -dstnodata -32768 -of GTiff -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;
}
}




--
Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html
___
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 ?

2018-01-06 Thread franco_bez

Hi Frank,

I tried to adapt your perl script to my Ubuntu System

I got the following warnings


Here's my Ubuntu-script


Frank Stinner-2 wrote
> Hi Franco,
> 
> i have little bit "played" with copernicus-files.
> 
> I have build a win-command-file with this perl-file:
> 
> -- cut ---
> 
> 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.

Let's see how fast my machine will be -- still running

> 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

Now I will have to find a way to identify the empty Tif-Files. 
I think gdal_translate will also create empty tiles, so I will have to
remove the empty Tifs before converting them to hgt

Ciao, Franco




--
Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html
___
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 ?

2018-01-04 Thread franco_bez

Hi Frank,

thanks for the new hints, this sounds much simpler than my approach.

Especially the "virtual" tif-File should save a lot of time and disk space.

But anyway there will be more than 1000 tiles for all the copernicus data.
1000 times a few seconds - it's still over one hour. But converting 37GB of
data just takes it's time.

for the last step you use your own program. Is it faster than gdal_translate
?
 "gdal_translate -strict -q -eco -of SRTMHGT -outsize 3601 3601 "  should 
basically do the same job, right?

Ciao,
  Franco



--
Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Any examples for routing with DEM data ? Anyone ?

2018-01-03 Thread franco_bez

I had a discussion on the Garmin Forum about this topic.

It seems that DEM data is never used for routing on the Oregon.

"minimal ascent" will only work together with commercial Topo-Pro maps.

Most likely they contain additional information.

thread on Garmin Forum

  



--
Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html
___
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 ?

2018-01-03 Thread franco_bez

Frank Stinner wrote
> At the moment we have to translate the tiffs from EPSG:3035 to EPSG:4326, 
> then the segmentation in 1°x1° tiffs an at last the conversion to hgt 
> files. This should not be a very great problem with gdal-tools or so, but 
> it is additional work.

Hi Frank,

thanks for the hint 

It was a long process (some hours), but in the end I succeeded in converting
4 of the giant copernicus tiff-tiles to 627 small (1°x1°) hgt files.

1. I joined the 4 tiles to one monster-file using gdal_merge
2. I converted the coordiante system with "gdalwarp -s_srs EPSG:3035 -t_srs
EPSG:4326"
3. with a small shell script the file got cut to 1°x1° tiles using
gdal_translate
   i.e.  "gdal_translate -strict -q -eco -projwin 10 48 11 47 "  for the
N47E010 tile
4. with another script the tiles were converted from tif to hgt format also
using gdal_translate
   "gdal_translate -strict -q -eco -of SRTMHGT -outsize 3601 3601 "

the scripts I used are only "quick 'n' dirty" hacks.

a few notes:
There were a few problems to work around
the coordinate system in use by copernicus does not follow the
latitude/longitude degrees
Corner Coordinates of the eu_dem_v11_E30N30.TIF:
Upper Left  ( 300.000, 400.000) ( 12°15'58.58"W, 57°13'49.19"N)
Lower Left  ( 300.000, 300.000) (  8° 7'39.52"W, 48°38'23.47"N)
Upper Right ( 400.000, 400.000) (  4°25'17.11"E, 58°59'15.42"N)
Lower Right ( 400.000, 300.000) (  5°31' 4.07"E, 50° 1'26.83"N)

in  EPSG:3035 coordinate it's a perfect square, but in  EPSG:4326 it's a
wedge.
I decided to join the copernicus tiles before converting the coordinate
system in order not to run into any problems at the original tile borders.

the hgt files must start precisely at the degree borders, so the tiles need
to be cut at the precise "projwin" coordinates

last the hgt tiles must be 3601x3601 pixel

Ciao,
  Franco




--
Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html
___
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"

2018-01-01 Thread franco_bez

See this tutorial for converting tif to hgt
http://www.oruxmaps.com/foro/viewtopic.php?t=3612#
  

I just created a linux shell script to replace the "tif2hgt.bat"
tif2hgt.sh   

PS: Just note the "holes" are usually called "voids"



--
Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] DEM-file generation from geo-tiff sources ?

2018-01-01 Thread franco_bez

I'm using phygtmap  http://katze.tfiu.de/projects/phyghtmap/
   for the creation of
contourlines maps.

phygtmap automatically downloads the elevation data from several sources.
Some sources provide the data in the geo-tiff format, others in the hgt
format.
phygtmap can handle both formats.

Are there any plans for mkgmap to also support the geo-tiff format ?

Sources for geo-tiff elevation data
https://land.copernicus.eu/pan-european/satellite-derived-products/eu-dem/eu-dem-v1.1

  
https://earthexplorer.usgs.gov/   



--
Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] Any examples for routing with DEM data ? Anyone ?

2018-01-01 Thread franco_bez

happy GNU year !
now that we have the possibility to build maps with dem-data I wanted to
find out how the Oregon makes use of this data for routing.

I tried very hard to find an example where the Oregon would calculate a
different route for "minimal ascent" and  "minimal distance". 
I did not succeed :-(
I tried routing with several modes (bicycle, mountain bike, tour-cycling);
I just cannot find any prove that the Oregon considers the dem-data at all
:-(

Can anyone give me an example route that shows a difference between routing
"minimal ascent" or  "minimal distance" ?

Ciao,
  Franco



--
Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Recent Garmin Firmware "cannot authenticate maps" when they are unicode

2017-09-13 Thread franco_bez

One last thought:

maybe it's not a bug in mkgmap, and maybe there is no way to fix this on our
side.
But in any way there will be more and more people affected as the number of
new Garmin devices increases.

So we should issue a warning message when maps are built with the unicode
option.

Something like:

"The use of the option unicode will cause problems on recent Garmin devices.
Consider using another encoding instead."

What do You think ?

Ciao,
 Franco 



--
Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Recent Garmin Firmware "cannot authenticate maps" when they are unicode

2017-08-29 Thread franco_bez

Waxy wrote
> Hi,
> 
> I tested the dach_boundary_gmapsupp_error.img…
> 
> On a etrex 30 : no message "cannot authenticate maps" and boundaries are
> visible.
> On a GPSMAP64s : error message "cannot authenticate maps" and the map is
> not listed.
> 
> Steph

Hi Steph,

this is exactly what happens on recent firmware with any map built with the
option unicode.

Ciao,
 Franco



--
View this message in context: 
http://gis.19327.n8.nabble.com/Recent-Garmin-Firmware-cannot-authenticate-maps-when-they-are-unicode-tp5901399p5901700.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Recent Garmin Firmware "cannot authenticate maps" when they are unicode

2017-08-26 Thread franco_bez

Hi Gerd and Andrzej,

I do not see any reason why GARMIN should only require UNICODE maps to be
signed, while LATIN1 maps can remain unsigned.

I suspect that there is a flag in the file header, maybe a new and
undocumented one, that marks the file as "check for signature".
When the Oregon checks the signature, and finds out that there is none, it
states that the check failed.

Maybe mkgmap accidentally marks the file as "to be checked for signature"
when it writes out a unicode map.

Does this soud plausible to you ?

I uploaded a sample map that produces the error, it just contains
administrative border lines as an overlay layer. I'm not sure whether it
contains an index or not .
http://files.mkgmap.org.uk/download/356/dach_boundary_gmapsupp_error.img

I can do a little testing if you can provide me with test cases.

Ciao,
  Franco


Am 26.08.2017 um 06:59 schrieb Gerd Petermann:
> Hi Franco,
>
> my understanding is that this is not a bug, but a limitation implemented
> by Garmin.
> My mothers Nüvi also doesn't load unicode maps.
> One reason might be that some indexes don't work with unicode and mkgmap
> doesn't
> write the needed ones. I cannot try that now.
> If the 750 loads a unicode map without an index we may have a chance by
> doing more reverse
> engeneering of old maps.
> On the other hand, I wonder how long they will the support the old img
> format written by mkgmap,
> maybe this is the first step to drop this support.
>
> Gerd
>
> 
Am 26.08.2017 um 11:51 schrieb Andrzej Popowski:
> Hi,
>
> > my understanding is that this is not a bug, but a limitation
> > implemented by Garmin.
>
> This is true. Garmin maps can be digitally signed. Many new GPS require,
> that Unicode map include signature. Signature is a protection against
> tampering, which is reasonable for commercial maps, but it exclude support
> for 3-rd party maps.
>





--
View this message in context: 
http://gis.19327.n8.nabble.com/Recent-Garmin-Firmware-cannot-authenticate-maps-when-they-are-unicode-tp5901399p5901449.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] Recent Garmin Firmware "cannot authenticate maps" when they are unicode

2017-08-25 Thread franco_bez

Hi all,

maybe it's already a know bug. 
I just stumbled over this one:

On a new Oregon750 I got the Error "cannot authenticate maps", while on the
old Oregon550 the maps worked like always.

I found out that changing the option "unicode" to "latin1" in my style did
the trick, the resulting maps work on both devices.

Over here in Germany I have no problem with latin1, but I suspect that in
Russia or in the middle east or far east countries this will be a real
problem.

I attached the Error Screenshots.

Ciao,
  Franco
 
 



--
View this message in context: 
http://gis.19327.n8.nabble.com/Recent-Garmin-Firmware-cannot-authenticate-maps-when-they-are-unicode-tp5901399.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Question about the overview map

2016-04-19 Thread franco_bez

Hi Andrzej,

my map reaches up to zoom level 16.

I just tested, and you are right, starting from a certain Zoom level the
Basemap takes over if enabled.
With my map the 50km Zoom still shows my map, no basemap visible. Beginning
from 80km there is only the Basemap, and the device becomes reactive again.

Thanks again for the hint :-)

Ciao,
  Franco



--
View this message in context: 
http://gis.19327.n5.nabble.com/Question-about-the-overview-map-tp5872108p5872169.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Question about the overview map

2016-04-19 Thread franco_bez

popej wrote
> have you enabled base map in GPS? It should be item like "Worldwide DEM 
> Basemap" in menu of your GPS.

Hi Andrzej,

No I do not have the Basemap enabled, anyway it's really old. 
Maybe it would show up in the blank spaces, maybe not.
But even if I enable the GARMIN Basemap my OSM map will still not perform
well in these extreme Zoom Levels. 
It slows down reactiveness of my device and almost crashes the system trying
to render the OSM map in 120km Zoom.

I think that best practice is to avoid these Zoom Levels.

Ciao,
  Franco




--
View this message in context: 
http://gis.19327.n5.nabble.com/Question-about-the-overview-map-tp5872108p5872146.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Question about the overview map

2016-04-19 Thread franco_bez

Hi Thorsten and Andrzej,

thanks for the feedback.

In the map style I use there are no details on the top level.
Only Motorways and Major Cities.

Zooming out to the scale "30km" works  fine, but zooming further out does
not really work.

Here's a sample:
 

So I think I will have to live with the limitation of my old Oregon.

Ciao,
 Franco



--
View this message in context: 
http://gis.19327.n5.nabble.com/Question-about-the-overview-map-tp5872108p5872144.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] Question about the overview map

2016-04-18 Thread franco_bez

Is it true that the overview map is only used by Mapsource and Bascamp on the
PC, but does not work on the mobile devices themselves ?

I'm looking for a solution for the following problem:

When you zoom out to a really big scale ( 100km for instance ) the Oregon
will not be able to render all of the display area. Of course  the map is
large enough ( DACH ) , but if you zoom out to show all of Germany at once
the Oregon can not handle this.

I suspect that it has to scan all the 3.8GB of my dach.img for elements to
display and this is simply too much.

I thought that an overview map might fix this problem.

Is there any way to get an overview map working on the mobile device, or do
we have to avoid zooming out too far?

Ciao,
  Franco



--
View this message in context: 
http://gis.19327.n5.nabble.com/Question-about-the-overview-map-tp5872108.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Occasional header corruption in gmapsupp.img

2014-12-04 Thread franco_bez

Hi Steve,

Could you occasionally commit this fix to svn ?

Ciao,
  Franco



--
View this message in context: 
http://gis.19327.n5.nabble.com/Occasional-header-corruption-in-gmapsupp-img-tp5825759p5826271.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Occasional header corruption in gmapsupp.img

2014-11-30 Thread franco_bez

Hi Steve,

 good work :-)

using your pre-built mkgmak.jar both my test-cases produce error-free
gmapsupp.img files.

seems fixed to me.

Ciao,
   Franco


Steve Ratcliffe wrote
 Hi
 
 once again I stumbled over a really weird problem:
 
 I have a patch for this problem.  A size calculation was wrong
 leading to the first file entry being overridden.
 
 Patch attached and pre-built jar file at:
  http://files.mkgmap.org.uk/download/234/mkgmap.jar
 
 Thanks,
 ..Steve
 
 ___
 mkgmap-dev mailing list

 mkgmap-dev@.org

 http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
 
 Sometimes_mps_file_not_present_in_gmapsupp.patch (1K)
 lt;http://gis.19327.n5.nabble.com/attachment/5825897/0/Sometimes_mps_file_not_present_in_gmapsupp.patchgt;





--
View this message in context: 
http://gis.19327.n5.nabble.com/Occasional-header-corruption-in-gmapsupp-img-tp5825759p5825909.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Occasional header corruption in gmapsupp.img

2014-11-29 Thread franco_bez

Hi Steve,

sounds great :-)
Just in case you need any further information or files, just let me know.
I'll try my best to provide them.

---

The procedure of creating the to samples was identical save to the slightly
different italy-extracts ( one or two days appart ) .
So if the MPS file is missing in the image, either mkgmap failed to create
it ( but no error message was issued ), or mkgmap failed to include it in
the image.

Ciao,
  Franco


Steve Ratcliffe wrote
 Thanks for the test case.  I can see that the 'bad' one is missing the 
 MPS file.  If I pull apart the gmapsupp into the separate .img files
 and then re-make the gmapsupp I can reproduce the missing component. So
 I should be able to track down the cause.
 
 Thanks
 ..Steve





--
View this message in context: 
http://gis.19327.n5.nabble.com/Occasional-header-corruption-in-gmapsupp-img-tp5825759p5825783.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] Occasional header corruption in gmapsupp.img

2014-11-28 Thread franco_bez

Hi all,

once again I stumbled over a really weird problem:

In rare cases mkgmap produces a gmasupp.img that shows up as Map data (c)
OpenSt in the list of maps on my Oregon 550.
Screenshots:
http://gis.19327.n5.nabble.com/file/n5825759/bad_01.png

http://gis.19327.n5.nabble.com/file/n5825759/bad03.png

http://gis.19327.n5.nabble.com/file/n5825759/bad04.png

http://gis.19327.n5.nabble.com/file/n5825759/good_01.png

http://gis.19327.n5.nabble.com/file/n5825759/good03.png

http://gis.19327.n5.nabble.com/file/n5825759/good04.png

There is no error message or warning when building the gmapsupp.img,

I observe this problem for some 4 month now and I can 100% reproduce the
bug.

It seems to be triggered by the OSM-inputdata although the OSM-data itself
is OK.

The problem occurred on a DACH-extract with my bikeroute-highlights-overlay
style a few months ago,
now I have it with a ITALY-extract and my housenumbers-overlay style.

Usually I build 6 different gamapsupp.img files for 6 different styles from
the same tiles.
Only one of them, if any, has the buggy header.

The problem usually disappears after an update of the OSM-data, just to
reappear a few days or weeks later.

I kept 2 versions of the ITALY-extract for reference and with those I can
100% reproduce a faulty gmapsupp.img.

I often update the versions of splitter and mkgmap I use for building the
maps.
mkgmap-r3356 and splitter-r414 still produce the same bug.

The problem assembling a test-case is that the ITALY-extract has a size of
1.2 GB .
When I remove just one tile from the split extract the gmapsupp.img is OK.
I cannot produce a small testcase.

I uploaded a sample of a gmapsupp.img with the bug, and one that is error
free.
http://files.mkgmap.org.uk/download/233/maps.tgz

Ciao,
Franco

--
View this message in context:
http://gis.19327.n5.nabble.com/Occasional-header-corruption-in-gmapsupp-img-tp5825759.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] delete name not working

2014-04-25 Thread franco_bez

Hi all,

I'm facing a very strange problem with the style function delete.

in the points file I have the following rule



In the past this removed unwanted labels on post boxes in the map.

Since quite some time, I assume since the change to the new style rules a
few month ago, the labels re-appeared in the map.

I tried many different things to get rid of them but I always failed.

Any Idea what's going wrong here ?

I composed a testcase for the bug, sample osm data and style is included:

happens everywhere but my testcase is located here
http://www.openstreetmap.org/?mlat=47.87609mlon=10.62906#map=19/47.87609/10.62906
  

Download Testcase
http://files.mkgmap.org.uk/download/205/delete_name_bug_testcase.tgz  

here's a screenshot of a points only map from the testcase

http://gis.19327.n5.nabble.com/file/n5804145/102.bmp 



--
View this message in context: 
http://gis.19327.n5.nabble.com/delete-name-not-working-tp5804145.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] delete name not working

2014-04-25 Thread franco_bez

Just a question for my understanding of the problem:

This rule not only sets the name but also mkgmap:label:1 ?



I thought that calling -  delete name - would erase the name, no matter what
it was assigned before.

would it make any difference having a rule with the set command instead ?



would - delete name - then work as expected ?



--
View this message in context: 
http://gis.19327.n5.nabble.com/delete-name-not-working-tp5804145p5804164.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] delete name not working

2014-04-25 Thread franco_bez

Hi Gerd,
thank you very much for the clarification. 



--
View this message in context: 
http://gis.19327.n5.nabble.com/delete-name-not-working-tp5804145p5804196.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Finalize section not working as expected

2014-03-24 Thread franco_bez

the xx.o5m is not in the test_case. I just sent it to Bernd directly.

But in the test case there is a very small osm file that contains just the
problematic area.

On my Oregon this produced the bug in 100% of the cases.



--
View this message in context: 
http://gis.19327.n5.nabble.com/Finalize-section-not-working-as-expected-tp5800737p5800818.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Finalize section not working as expected

2014-03-24 Thread franco_bez

I just made a few more tests.

Steve Ratcliffe wrote
On 24/03/14 11:42, Gerd Petermann wrote:
@Steve: Can you have a look at it?

I used each set of rules with the file test_area_irsee.osm

The resulting files were identical apart from the timestamps.

So I am unable to replicate any actual difference with those files.

..Steve

using the original styles from my test_case you should have had differences
in the img files.
But it is now obvious to me that the include of inc/compat_access should
have been *before* inc/access not *after*

So I changed the order of the includes and for me it seems to work, at least
with the test_area_irsee.osm.

I found no difference in routing if I include inc/compat_access right
before inc/access or if I just paste it's content to the beginning of
inc/access .

The rules had to remain setting *bicycle=no* and *NOT mkgmap:bicycle=no*
though, but it's also obvious why:
inc/access reads
/# set (override) specific restrictions
bicycle=*{ set mkgmap:bicycle='${bicycle}' }
/
that's why it's overriding any mkgmap:bicycle value previously set.

I will do a few more tests, but currently I consider it beeing a bug in my
style rather than a bug in mkgmap.

Thanks for all the help :-)

--
View this message in context:
http://gis.19327.n5.nabble.com/Finalize-section-not-working-as-expected-tp5800737p5800892.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] Finalize section not working as expected

2014-03-23 Thread franco_bez

I got a very nasty bug here.
IMHO it must be somehow related to the finalize section in the lines file of
the style.

http://www.openstreetmap.org/#map=16/47.9114/10.5862

When routing along the bicycleway along the OAL12 from the roundabout to
Irsee.
Choosing Mountainbike or Tourbike as Activity and shortest distance as
Calculating method always leads me on a heavy Trail.

I have rules in the style that set bicycle=no for this trail, but they do
not seem to have any effect unless I include them BEFORE the garmin type
gets assigned.
In the finalize section they seem to be ignored.

At least on my OREGON 550 with latest Firmware.

A few screenshots:
http://gis.19327.n5.nabble.com/file/n5800737/Roundabout82.bmp 
http://gis.19327.n5.nabble.com/file/n5800737/2-Target_in_Irsee127.bmp 
http://gis.19327.n5.nabble.com/file/n5800737/3-Choose_Tourbike_or_Mountainbike137.bmp
 
http://gis.19327.n5.nabble.com/file/n5800737/4-Choose_short_distance141.bmp 
http://gis.19327.n5.nabble.com/file/n5800737/5-Routing_broken_why_182.bmp 
http://gis.19327.n5.nabble.com/file/n5800737/6-Routing_correct_with_hacked_style167.bmp
 

I composed a test case
http://files.mkgmap.org.uk/download/188/test_case.tgz

this is the only change in the style that makes routing work:
/
test_cases/mystyles$ diff -uws bikemap_style_hacked/ bikemap_style
Gemeinsame Unterverzeichnisse: bikemap_style_hacked/inc und
bikemap_style/inc.
Dateien bikemap_style_hacked/info und bikemap_style/info sind identisch.
diff -uws bikemap_style_hacked/lines bikemap_style/lines
--- bikemap_style_hacked/lines  2014-03-23 13:08:03.295102817 +0100
+++ bikemap_style/lines 2014-03-22 19:20:03.0 +0100
@@ -534,8 +534,6 @@
 

#--
 # path
-# HACK include access rules before path rules
-include 'inc/compat_access' ;
 
 highway=path | highway=trail | highway=byway   

[0x11012 resolution 24 continue]
 
Dateien bikemap_style_hacked/options und bikemap_style/options sind
identisch.
Dateien bikemap_style_hacked/points und bikemap_style/points sind identisch.
Dateien bikemap_style_hacked/polygons und bikemap_style/polygons sind
identisch.
Dateien bikemap_style_hacked/README und bikemap_style/README sind identisch.
Dateien bikemap_style_hacked/relations und bikemap_style/relations sind
identisch.
Dateien bikemap_style_hacked/version und bikemap_style/version sind
identisch.
/



--
View this message in context: 
http://gis.19327.n5.nabble.com/Finalize-section-not-working-as-expected-tp5800737.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Finalize section not working as expected

2014-03-23 Thread franco_bez

Some additional hints:

I get this problem in 100% of the cases I tested, on ORGON 550.
Did not matter what map was built.
Bernd tried to reproduce the bug with a bayern map but did not get the bug
neither on his OREGON 650 nor in BASECAMP.

For faster testing I created a test-area called xx, and with this area
Bernd was able to reproduce the bug.
He thinks it might be related to a tile boundary problem.

Polygon of the test area: xx.poly
http://gis.19327.n5.nabble.com/file/n5800742/xx.poly
Tile-boundaries produced by splitter: xx.kml
http://gis.19327.n5.nabble.com/file/n5800742/xx.kml
Test areas.list: xx_areas.list
http://gis.19327.n5.nabble.com/file/n5800742/xx_areas.list

---

Somehow the notes for my screenshots got lost.
1st shows the starting point - does not really matter - just somewhere on
the cycleway
2nd shows the target - does not really matter - just somewhere in Irsee or
beyond
3rd shows Activity selection - IMPORTANT chosse Tourbike or Mountainbike
4th shows the calculation method - IMPORTANT choose short distance
5th shows the wrong route with the unmodified style
6th shows the correct route with the hacked style

It is also important to go uphill - routing in the opposite direction works.

--
View this message in context:
http://gis.19327.n5.nabble.com/Finalize-section-not-working-as-expected-tp5800737p5800742.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Finalize section not working as expected

2014-03-23 Thread franco_bez

the rules in question are:
/
highway=path
(
  smoothness~'.*(horrible|impassable)' |
  smoothness=very_bad |
  mtb:scale0 | 
  mtb:scale:imba0
  )
{ set bicycle=no }
highway=path
 (
   sac_scale~'.*(mountain|alpine)_hiking' |
   smoothness=bad
   )
{ add bicycle=no; }
/

When I put then directly in the lines file, before the path definition
rules, routing works as expected.

But when I put them in a separate file included in the finalize section it
does not work reliably.

We tried some diagnosis with echo and found that the rules get called in
any case.
Just that on the GARMIN Device they do not apply when called in the finalize
section !?!

There must be some difference in the generated img file that should not be
there.
I suspect that the path gets written to the img before the set bicycle=no
is applied.




--
View this message in context: 
http://gis.19327.n5.nabble.com/Finalize-section-not-working-as-expected-tp5800737p5800798.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] mergeroads sometimes breaks routing

2014-02-17 Thread franco_bez

The problem still persists, just switched from a bayern map to dach map.

just yesterday I built a dach map with mkgmap-r2998 withe the strange
routing.

I could provide a new tile if this helps.



--
View this message in context: 
http://gis.19327.n5.nabble.com/mergeroads-sometimes-breaks-routing-tp5791132p5796612.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] mergeroads sometimes breaks routing

2014-01-03 Thread franco_bez

GerdP wrote
 Hi,
 I forgot to report that changing the order of nodes did not change the 
 result in MapSource, so this is a different problem.
 
 Gerd

The case is really strange.

When I build a DACH map - the routing is OK

When I try a data extract from JOSM with just this part of Kaufbeuren - the
routing is OK

Anytime I build a BAYERN map - the routing is BAD.

So only the tile generated by splitter for the BAYERN map provokes the bad
routing.

I suppose that the tile containing Kaufbeuren generated for the DACH map
does not start at the same coordinates as the one generated for BAYERN.

This is the only difference I can imagine.

I uploaded the splitter-generated area information in the hope it might be
helpful.

http://files.mkgmap.org.uk/download/167/bayern_areas.tgz

The tile in question is 65020003.

Ciao,
  Franco




--
View this message in context: 
http://gis.19327.n5.nabble.com/mergeroads-sometimes-breaks-routing-tp5791132p5791546.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] mergeroads sometimes breaks routing

2014-01-03 Thread franco_bez

Hi Gerd,

the KML files were generated while splitting, just forgot to put them in the
archive.

just in case they might be helpful

http://files.mkgmap.org.uk/download/168/bayern.kml

http://files.mkgmap.org.uk/download/169/dach.kml



--
View this message in context: 
http://gis.19327.n5.nabble.com/mergeroads-sometimes-breaks-routing-tp5791132p5791567.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] mergeroads sometimes breaks routing

2013-12-31 Thread franco_bez

Hi Gerd and WanMil,

the bug really is NOT related to mergeroads.

I joined the Beuthener Straße and the Allensteiner Straße in OSM as they
were split in several ways for no reason.

Now the routing has changed, not for the better I'm affraid ;-) ( see
screenshots )

But anyway now both mergeroads and no-mergeroads agree in how to route.

I compressed the new tile with bzip2 so you have new sample data here:
http://files.mkgmap.org.uk/download/163/65020003.osm.bz

with mergeroads active:

http://gis.19327.n5.nabble.com/file/n5791269/mergeroads-9350.bmp 

with --x-no-mergeroads:

http://gis.19327.n5.nabble.com/file/n5791269/no-mergeroads-17698.bmp 



--
View this message in context: 
http://gis.19327.n5.nabble.com/mergeroads-sometimes-breaks-routing-tp5791132p5791269.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] mergeroads sometimes breaks routing

2013-12-29 Thread franco_bez

I found a very strange routing behaviour connected to the mergeroads-patch.
The Problem area is here:
http://www.openstreetmap.org/#map=17/47.89307/10.63390

When I try to route ( Automobile-mode, minimize-time ) from corner
Liegnitzer-Straße/Glogauer-Straße to Beuthener-Straße Nr. 11, I get routed
all the way round the block.

Using --x-no-mergeroads the routing is fine.

Even stranger, when I tried to assemble a small testcase with an
data-extract from JOSM, the routing is fine, even when using mergeroads.

So the error seems to be triggered by something specific to the tile that
was generated when building a map of Bayern.

See screenshots:

Bad Routing with mergeroads:

http://gis.19327.n5.nabble.com/file/n5791132/mergeroads-9452.bmp 


Routing OK with --x-no-mergeroads:

http://gis.19327.n5.nabble.com/file/n5791132/no-mergeroads-19995.bmp 



--
View this message in context: 
http://gis.19327.n5.nabble.com/mergeroads-sometimes-breaks-routing-tp5791132.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] mergeroads sometimes breaks routing

2013-12-29 Thread franco_bez

here's the testcase:

http://files.mkgmap.org.uk/download/162/mergeroads_routing_bug.tgz

Test case for mergeroads routing bug containing build-script and osm
Sample-Data.




--
View this message in context: 
http://gis.19327.n5.nabble.com/mergeroads-sometimes-breaks-routing-tp5791132p5791133.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] New filter function trim

2013-04-23 Thread franco_bez

Hi all,

has anyone yet had the time to do a little testing.

Any, comments or change requests ?

With my tests everything worked fine.

@WanMil if you think the patch is OK and the new part filter function is
useful, would you commit it ? Me myself, I do not have write access to the
svn.

Ciao,
  Franco



--
View this message in context: 
http://gis.19327.n5.nabble.com/New-filter-function-trim-tp5757768p5758281.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] New filter function trim

2013-04-20 Thread franco_bez

franco_bez wrote
 so ${destination|part} 

must be
 ${destination|part:} 
i missed the colon ;-)




--
View this message in context: 
http://gis.19327.n5.nabble.com/New-filter-function-trim-tp5757768p5757838.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] New filter function trim

2013-04-20 Thread franco_bez

Also in the rule-filters.txt I missed the colon in the example.
Here's the new diff:
part_filter_src.diff
http://gis.19327.n5.nabble.com/file/n5757839/part_filter_src.diff  



--
View this message in context: 
http://gis.19327.n5.nabble.com/New-filter-function-trim-tp5757768p5757839.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] New filter function trim

2013-04-20 Thread franco_bez

Sorry for all this confusion.

I need to do more debugging.

This java languague is a little strange to me.

I'll post the Filter once I have it thoroughly tested.

Ciao,
  Franco



--
View this message in context: 
http://gis.19327.n5.nabble.com/New-filter-function-trim-tp5757768p5757847.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] highway=track with no road_class and road_speed set breaks routing ## was ## No roads near target bug in Schwabmünchen

2013-04-19 Thread franco_bez

GerdP wrote
 Hi all,
 
 today I've committed routable_types_v6.patch + a few small mods.
 
 I would really like to know if a routable map from Garmin contains lines
 with routable types in resolution 24 which do not appear in the NOD
 section.
 I don't own any City Navigator map, so I can't check it. 
 The only (legal) free map that I know of is the TopoD2012pro_Testversion,
 but it seems the current display tool cannot read it. 
 
 Gerd

Hi Gerd,
it's probably a NT-map.
I have a CN_CentralEurope_NT map that came with the Nüvi, but I think that
will be useless also.
Or, are there any tools that can read NT-maps?

Ciao,
  Franco




--
View this message in context: 
http://gis.19327.n5.nabble.com/No-roads-near-target-bug-in-Schwabmunchen-tp5753364p5757766.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] highway=track with no road_class and road_speed set breaks routing ## was ## No roads near target bug in Schwabmünchen

2013-04-18 Thread franco_bez

GerdP wrote
 Hi,
 
 I noticed that type 0x00 is a valid line type, so it's not a good idea to
 use this as a flag for delete the line.
 Also I was not able to get the unit tests running when the --list-styles
 option performs the checks.
 Therefore I've added a new option --check-styles.
 
 Attached is v6 of the patch. The binary is 
 
 If you want to delete the unconnected road, use 
  add mkgmap:set_unconnected_type = none
 instead of 
  add mkgmap:set_unconnected_type = 0x00
 
 I found no easy way to implement a check that warns the user when he uses
 a routable type here, so this
 is done only at runtime and will produce multiple messages like this:
 SCHWERWIEGEND (StyledConverter): e:\bayern\63240001.o5m: type value in
 mkgmap:set_unconnected_type should not be a routable type: 0x02
 
 and the corresponding way is ignored. I hope this makes sense?
 
 Gerd

Hi Gerd,
this sounds good to me.
I tested it with my example and it works fine.
You even changed the error's and the warning's texts so that now I get 
Non-routable way with routable type *0x0f* and no longer type *0xf*
Thanks a lot.
Ciao,
 Franco



--
View this message in context: 
http://gis.19327.n5.nabble.com/No-roads-near-target-bug-in-Schwabmunchen-tp5753364p5757615.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] highway=track with no road_class and road_speed set breaks routing ## was ## No roads near target bug in Schwabmünchen

2013-04-15 Thread franco_bez

GerdP wrote
I've used Bernds style to reproduce the problem:
https://github.com/berndw1960/aiostyles

Attached is a patch that replaces the mkgmap:check_connected feature
with
a mkgmap:set_unconnected_type feature.
routable_types_v3.patch
http://gis.19327.n5.nabble.com/file/n5757151/routable_types_v3.patch

Old version was:
highway=service | highway=estate | highway=living_street
{
add mkgmap:dead-end-check=false;
add mkgmap:check_connected = true
}

the new rule should look similar to this:

highway=service | highway=estate | highway=living_street
{
add mkgmap:dead-end-check=false;
add mkgmap:set_unconnected_type = 0x12007
}

The meaning is: If the highway is not connected to any road , change the
type
to 0x12007 and add it as a line instead of a road.

Now I am a little lost.
In the lines file, just below the lines you mention above, there are already
rules that draw the
highway=service, highway=estate and highway=living_street with
non-routable-types.
It's some kind of overlay if I understand that right (continue with
actions).
Then there is a line that adds the routable-type 0x07, which is made
invisible in the TYP file.
I suspect this line is only there for routing.

Now how does mkgmap decide which of rules it has to change or even drop if
not connected ?

Wouldn't it be much more straightforward to make check_connected add a
variable, let's say is_connected that could be used later on in the rules?

For a beginner like me the rules would be far more easy to read and
understand.

Besides that the patch implements the changes of routable_types_v2.patch.
The compiled binary is here:
http://files.mkgmap.org.uk/download/107/mkgmap.jar

Gerd

I tested your binary with the proposed change on the Style, and now I still
get precisely 1 Error Message in my test case. Before there were plenty
(maybe 100) of them.

Ciao,
Franco

--
View this message in context:
http://gis.19327.n5.nabble.com/No-roads-near-target-bug-in-Schwabmunchen-tp5753364p5757237.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] highway=track with no road_class and road_speed set breaks routing ## was ## No roads near target bug in Schwabmünchen

2013-04-15 Thread franco_bez

franco_bez wrote
 I tested your binary with the proposed change on the Style, and now I
 still get precisely 1 Error Message in my test case. Before there were
 plenty (maybe 100) of them.

The message confuses me its:

 SEVERE (MapBuilder): /home/franco/map_build/test_cases/tiles/63360004.o5m:
 Non-routable way with routable type 0xf is used for a routable map. This
 leads to routing errors. Use --list-styles to check the style.

In all the style files I find no 0xf at all.
Where ever this may come from ?



--
View this message in context: 
http://gis.19327.n5.nabble.com/No-roads-near-target-bug-in-Schwabmunchen-tp5753364p5757242.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] highway=track with no road_class and road_speed set breaks routing ## was ## No roads near target bug in Schwabmünchen

Hi Gerd,

I tested your binary.
With the old style files, the buggy ones, I get the warnings during
--list-styles and the errors during buid.

With the new style Bernd has composed there are neither warnings nor errors
about Non-routable way with routable type.

So far it looks good to me.

thanks a lot.

Ciao,
Franco

GerdP wrote
Hi all,

I did some more debugging regarding the routing problem to
Robert-Bosch-Strasse 14. Since this works with the default style
I tried to find out why the HousenumberGenerator produces other results
with
Francos style. I found no difference.

So, it really seems that we should not allow to use
routable types for non-routable ways when creating a map with --route.

Attached is a patch that does two things:
1) Add checks to --list-styles to warn for such potential problems
2) Produce an error message if such a case is found when creating a map
with --route
routable_types_v2.patch
http://gis.19327.n5.nabble.com/file/n5757000/routable_types_v2.patch

I am not sure what types the test should check. The wiki says that
0x01-0x13 and 0x1a-0x1b are routable, so I used these.

A compiled binary based on trunk version r2570 is here:
http://files.mkgmap.org.uk/download/106/mkgmap.jar

Please let me know if this works with your style(s).

Gerd

--
View this message in context:
http://gis.19327.n5.nabble.com/No-roads-near-target-bug-in-Schwabmunchen-tp5753364p5757092.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] highway=track with no road_class and road_speed set breaks routing ## was ## No roads near target bug in Schwabmünchen

Hi Gerd,
build takes a while on my slow machine.
I have to make a correction of my previous post while
--list-styles isuues NO warnings

 java -ea -Xmx1500M  -jar
 /home/franco/map_build/mkgmap-r2570_patched/mkgmap.jar 
 --style-file=/home/franco/map_build/mystyles/basemap_style 
 --list-stylesTime started: Sun Apr 14 21:50:24 CEST 2013
 The following styles are available:
 basemap_style  1.0: The default AIO-basemap-style
 Time finished: Sun Apr 14 21:50:24 CEST 2013
 Total time taken: 901ms

I get lots of errors during build

 Non-routable way with routable type is used for a routable map. This leads
 to routing errors. Use --list-styles to check the style.

Ciao,
  Franco


franco_bez wrote
 Hi Gerd,
 
 I tested your binary.
 With the old style files, the buggy ones, I get the warnings during
 --list-styles and the errors during buid.
 
 With the new style Bernd has composed there are neither warnings nor
 errors about  Non-routable way with routable type.
 
 So far it looks good to me.
 
 thanks a lot.
 
 Ciao,
  Franco





--
View this message in context: 
http://gis.19327.n5.nabble.com/No-roads-near-target-bug-in-Schwabmunchen-tp5753364p5757097.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] highway=track with no road_class and road_speed set breaks routing ## was ## No roads near target bug in Schwabmünchen

Hi Gerd,
I compiled another tgz archive to demonstrate the bug, in case you need it.

http://francobez.bplaced.net/files/mkgmap/test_cases_errors.tgz

Ciao,
  Franco



--
View this message in context: 
http://gis.19327.n5.nabble.com/No-roads-near-target-bug-in-Schwabmunchen-tp5753364p5757102.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] highway=track with no road_class and road_speed set breaks routing ## was ## No roads near target bug in Schwabmünchen

Minko-2 wrote
 I got the same warnings, probably because 0x16 is not considered as
 routable (which should be)?

In the basemap_style I used the type 0x16 isn't used at all.

The strange thing is that --list-styles tells me everything OK, while
building a map throws the Errors.
Now what's right ?

Ciao,
 Franco



--
View this message in context: 
http://gis.19327.n5.nabble.com/No-roads-near-target-bug-in-Schwabmunchen-tp5753364p5757115.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Translation system proposal

2013-04-11 Thread franco_bez

Marko Mäkelä wrote
 On Wed, Apr 10, 2013 at 10:04:20PM -0700, franco_bez wrote:
I was wondering if it weren't possible to use the built-in translations 
of the Garmin Device itself.
I mean the translations in the *.gtt Files from the GARMIN/Text 
directory on the Garmin device.
Exit would be TXT_Exit_STR_M
 
 Is the GARMIN/Text a feature of newer devices? I do not remember seeing 
 anything like that on my Edge 705.

I have this on the Oregon 550 and the Nüvi 40, I don't know about older
devices.
This is a set of xml Files where the Firmware gets the translations when you
change the language setting.

Has anyone ever tried whether or not we can use GARMIN Text Constants  
in the map ?
 
 As far as I understand, the 'default name' of unnamed things can be 
 defined in the TYP file, for every supported language code. In NT maps 
 (which mkgmap cannot generate) you could represent object names in 
 multiple languages (say, street names in French or Dutch in Belgium, 
 selectable on the device).

I noticed that when there is no name at all in the map, then the firmware
uses a (translated) default, probably based on the typ-id of the Object.

Ciao,
 Franco



--
View this message in context: 
http://gis.19327.n5.nabble.com/Translation-system-proposal-tp5756506p5756591.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] highway=track with no road_class and road_speed set breaks routing ## was ## No roads near target bug in Schwabmünchen

GerdP wrote
 Hi,
 
 yes, I can confirm that mkgmap works as you describe it, my understanding
 of the code was wrong.
 I've coded an additional test for this with the list-styles method, it
 issues
 Warning: routable type 0x00c06 is used for non-routable line with
 resolution 24. This may break routing. Style file lines, line 442. Type is
 overlaid with 0x6 which is used for adding the non-routable copy of the
 way.
 
 Is that helpful?
 
 Gerd

I personally think these warnings are very helpful, especially for beginners
like me.
I also think that they should be displayed not only in --list-styles but
also when a routeable map is being build.



--
View this message in context: 
http://gis.19327.n5.nabble.com/No-roads-near-target-bug-in-Schwabmunchen-tp5753364p5756543.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] process-exits vs process-destination

Hi WanMil,

thank you very much.
This is really good news.

i will try this as soon as possible.

Ciao,
  Franco



--
View this message in context: 
http://gis.19327.n5.nabble.com/process-exits-vs-process-destination-tp5756464p5756549.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] highway=track with no road_class and road_speed set breaks routing ## was ## No roads near target bug in Schwabmünchen

GerdP wrote
Hi Franco,

I did a few more tests now. I am able to reproduce the problem with a
small input file:
franco1.osm.pbf
http://gis.19327.n5.nabble.com/file/n5756490/franco1.osm.pbf

My result with an Oregon 450t , software version 5.50:
version 2447: routing to POI Schönwetter Automobile works, but
address Robert-Bosch-Straße 14 doesn't work.

in all later versions both did not work.

The change in r2448 was the remove-short-arc patch.
One effect of this patch was that the order of roads and other ways did
change,
esp. the other ways were written first, roads later.
In r2447, they were written in order of appearance in the osm data
(because
preserve-element-order=true is used)
I've coded a small patch that changes the logic so that roads are always
placed before other ways,
and that seems to solve the problem for the POI search.
roads_first_v1.patch
http://gis.19327.n5.nabble.com/file/n5756490/roads_first_v1.patch

The compiled binary is here:
http://files.mkgmap.org.uk/download/103/mkgmap.jar

With --x-housenumbers this version supports searching for addresses a
little bit:
If you type housenumber 1 instead of 14, it shows you a list with two
numbers (3 and 5),
and routing to these works. It works also if you directly type 3 or 5 in
the search dialog.

I did not yet look at the overlay problem, maybe tomorrow.

Ciao,
Gerd

Hi Gerd,
I can confirm that the routing to the POI works perfectly with your patched
Version.

I can also confirm that the routing to the address is still broken.

Ciao,
Franco

--
View this message in context:
http://gis.19327.n5.nabble.com/No-roads-near-target-bug-in-Schwabmunchen-tp5753364p5756551.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Translation system proposal

Hi Carlos,

Carlos Dávila-2 wrote
 Currently we have the English word Exit in the default lines style 
 file, which is used by the exit_hint option. Obviously it isn't 
 appropriate for all languages, 

This already bothered me too.
I was wondering if it weren't possible to use the built-in translations of
the Garmin Device itself.
I mean the translations in the *.gtt Files from the GARMIN/Text directory on
the Garmin device.
Exit would be TXT_Exit_STR_M

Has anyone ever tried whether or not we can use GARMIN Text Constants  in
the map ?

Ciao,
  Franco



--
View this message in context: 
http://gis.19327.n5.nabble.com/Translation-system-proposal-tp5756506p5756577.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] highway=track with no road_class and road_speed set breaks routing ## was ## No roads near target bug in Schwabmünchen

Minko-2 wrote
How can I do this with the Oregon?

Hi Gerd, there are two ways to do this.
See http://gpsinformation.info/penrod/oregon/oregon.html

When you are in Demo Mode (simulator) you can change your simulated
location. We discovered this on our own, as there is no tab to press on
the screen and no documentation from Garmin. Simply press the lower right
hand corner of the satellite page while in Demo Mode and it will bring up
a map. Move the cursor to your desired location and then press the USE
tab on the map page. Garmin's documented way to set location in Demo
mode, is to select a point and hit 'go' to navigate to it. You will then
be prompted whether you want to move to this location.
___
mkgmap-dev mailing list

mkgmap-dev@.org

http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

If you are using a recent firmware on the Oregon (with activity routing) the
simplest way to set your current position is to set the GPS to demo mode
in System Settings, then select a target in any way you like (adress search,
POI, tap on screnn does not matter) then hit GO and chosse Luftlinien
routing (maybe direkt line or so in English) you will be promted
Simulate travel on route? - answer goto position.

Ciao,
Franco

--
View this message in context:
http://gis.19327.n5.nabble.com/No-roads-near-target-bug-in-Schwabmunchen-tp5753364p5756317.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] highway=track with no road_class and road_speed set breaks routing ## was ## No roads near target bug in Schwabmünchen

GerdP wrote
Reg. r2460: Maybe I got you wrong. In SVN, r2460 existed only in the
exit_hints
branch, so I compiled the sources contained in that branch.
Maybe you did not use r2460, but the trunk version that was available when
r2460 was committed, which was probably r2459.

It was 2460 - I compiled it from the sources.

Please try also the two versions 2447 and 2459 in
http://files.mkgmap.org.uk/download/101/mkmap_versions2.zip

I will, tonight.

You may also post a link to the osm file that you use to create the map.
When I try it with my data, I found no difference between r2460 and r2544,
but I am not sure what you mean with
put your current position somewhere nearby, maybe on the
Gottlieb-Daimler-Straße,
How can I do this with the Oregon?
When I test, I create a route between somewhere in Mittelstetten and the
targets that you mention,
and then I display the route on the map. The device first shows a straight
line which is then replaced by a route that looks correct. When I hit the
GO button, the device tries to calculate a route to the
start of the route, and that fails because my actual position is 500km
away.

Gerd

I didn't try the create route function on the Garmin yet. My cheap Nüvi 40
even doesn't have this feature at all, I could only try on the Oregon.
I always used the GPS-demo mode - in the test cases I set the current
position to intersection in Mittelstetten Jägerweg/Dorfstraße and then
selected the POI from the POI search All POI, or the address from the
address search - Oregon: Germany - Schwabmünchen - 14 -
Robert-Bosch-Straße
then I hit GO - Automobile - little time

I can compose a set of screenshots if you like.
I will compose a zip file containing the osm file, the style files and
map.conf file in use for the tests, and the mkgmap command line in use and
see if I can find a place where I can put them for you to download, sometime
tonight.

Ciao,
Franco

--
View this message in context:
http://gis.19327.n5.nabble.com/No-roads-near-target-bug-in-Schwabmunchen-tp5753364p5756321.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] highway=track with no road_class and road_speed set breaks routing ## was ## No roads near target bug in Schwabmünchen

Hi Gerd,
the actual tests I will do tonight, but I prepared the tgz archive
containing my test environment for you.
You can get it here
http://francobez.bplaced.net/files/mkgmap/test_cases.tgz
Ciao,
  Franco



--
View this message in context: 
http://gis.19327.n5.nabble.com/No-roads-near-target-bug-in-Schwabmunchen-tp5753364p5756333.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] highway=track with no road_class and road_speed set breaks routing ## was ## No roads near target bug in Schwabmünchen

Hi Gerd,

I assume that I can skip the tests with the two versions 2447 and 2459 ?

I tested with the patched binary you provided.
with the bogus style there is no big difference
On the Oregon I get no roads near target both for the POI and for the
address, just like before.
On the Nüvi I get calculating xx% forever also for both targets. At least
it does no longer propose an impossible route over non existant ways.

In the mean time Bernd eliminated all routeable types without road_speed
and road_class in the real style.
Also in this style there is no noticeable change using your patched Version.
Both on the Nüvi and the Oregon routing to the POI is OK in the real
style, both with and without your patched version.
Routing to the address is still broken, both the Nüvi and the Oregon show an
impossible route over a non existant way, both with and without your patched
version.
http://gis.19327.n5.nabble.com/file/n5756442/5_OREGON_ROUTE.png

I'm not sure if your patched binary contains the warnings you implemented
for routeable lines without road_speed ?
this is the output of --list-styles using your patched version on the real
stlye
java -jar mkgmap.jar
--style-file=/home/franco/map_build/mystyles/basemap_style/ --list-styles
Time started: Tue Apr 09 21:29:47 CEST 2013
The following styles are available:
basemap_style 1.0: The default AIO-basemap-style
Time finished: Tue Apr 09 21:29:47 CEST 2013
Total time taken: 472ms

I assume that the routing Problem to the POI can be avoided by using a style
where all routable types have the road_speed and road_class attributes.
But routing to the address must have a second trigger in the style.

I will now start the search for the offending lines in the real style.

Ciao,
Franco

GerdP wrote
Hi all,

attached is routable_types_v1.patch which (hopefully) corrects the last
routing problems introduced with r2448.
A compiled binary of trunk version r2562 (svnversion says 2564m) with this
patch is here:
http://files.mkgmap.org.uk/download/102/mkgmap.jar

Please try it f your style assigns routable types (0x01-0x13, 0x1a,0x1b)
to lines without
setting road_class or road_speed, else you should see no difference.

Gerd
GerdP wrote
Hi,

thanks for the package and the hints regarding the test. I finally was
able to reproduce the problem and found that the
last version which worked with the bogus style file was probably r2447.
r2248 contained my removeShortArcs patch, so it seems that there might
be a need to remove short arcs not only from
roads but maybe from all lines with routable types. I'll try to implement
that now.

Gerd

--
View this message in context:
http://gis.19327.n5.nabble.com/No-roads-near-target-bug-in-Schwabmunchen-tp5753364p5756442.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] highway=track with no road_class and road_speed set breaks routing ## was ## No roads near target bug in Schwabmünchen