from:"Thomas Morgenstern"


Supplement :
I have looked in original Garmin CityNavigator NT 2018 and Topo Espania: in 
both maps the layers are rendered wrong. Always the 0x1 is toplevel

thomas

--
Von: "Gerd Petermann" <gpetermann_muenc...@hotmail.com>
Datum: Sonntag, 25. Februar 2018 19:03
An: "Thomas Morgenstern" <webmas...@img2ms.de>; "Development list for 
mkgmap" <mkgmap-dev@lists.mkgmap.org.uk>

Betreff: Re: [mkgmap-dev] Wrong rendering Layer=1


Hi Thomas,

what I wanted to suggest is to use --preserve-element-order and change the 
order of the two ways in the osm file.
Without --preserve-element-order the order is not predictable, but might 
be the same as with

the option.

Gerd


Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von 
Thomas Morgenstern <webmas...@img2ms.de>

Gesendet: Sonntag, 25. Februar 2018 19:48:50
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Wrong rendering Layer=1

Hi Gerd, i have tested now --preserve-element-order . You are right. This
does not help. The result is similar to without --preserve-element-order.
thomas

--
Von: "Gerd Petermann" <gpetermann_muenc...@hotmail.com>
Datum: Sonntag, 25. Februar 2018 18:17
An: "Thomas Morgenstern" <webmas...@img2ms.de>; "Development list for
mkgmap" <mkgmap-dev@lists.mkgmap.org.uk>
Betreff: Re: [mkgmap-dev] Wrong rendering Layer=1


Hi Thomas,

my understanding is that this was already tried in the past, without
success.
You can test it with a test osm file containing only two ways. When you
use
--preserve-element-order mkgmap should write them in the order of
the OSM file. It is better to use a small file for those tests so that 
all

data
fits into one sub division.

It might well be possible that Garmin software has a hard coded draw 
order

for
specific line types. As Arndt already mentioned this is the case for
0x01..0x03.

Gerd

________
Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von
Thomas Morgenstern <webmas...@img2ms.de>
Gesendet: Sonntag, 25. Februar 2018 18:10:24
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Wrong rendering Layer=1

Some time ago we have introduced the teature 'order-by-decreasing-area'.
Maybee a similar arangement  helps. Order all  lines ,(related to 
streets)

in range of layer . Highest layer at last ?
thomas

----------
Von: "Gerd Petermann" <gpetermann_muenc...@hotmail.com>
Datum: Sonntag, 25. Februar 2018 16:50
An: "Thomas Morgenstern" <webmas...@img2ms.de>; "Development list for
mkgmap" <mkgmap-dev@lists.mkgmap.org.uk>
Betreff: Re: [mkgmap-dev] Wrong rendering Layer=1


Hi Arndt,

many OSM applications evaluate tags like bridge and layer.
The default style doesn't even evaluate bridge or layer, since we don't
know a way to tell Garmin software a draw order
of lines. This is just a special problem with the (old) Garmin img
format.
Maybe there is a way to change the draw order, if you have an idea,
please
let us know.

Gerd


Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von
Thomas Morgenstern <webmas...@img2ms.de>
Gesendet: Sonntag, 25. Februar 2018 17:25:08
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Wrong rendering Layer=1

I am wondering, why we write tag=bridge and tag layer=anywhat, when
mkgamp
does ignore bridge=yes and layer=1. All the work, to tset this tag is
seenless.?
thomas

Von: Arndt Röhrig<mailto:ar...@speichenkarte.de>
Datum: Sonntag, 25. Februar 2018 14:52
An: Development list for mkgmap<mailto:mkgmap-dev@lists.mkgmap.org.uk>
Betreff: Re: [mkgmap-dev] Wrong rendering Layer=1


Hi,

imho there is no draw prio possible with lines. Solid has no effect. 
Only

typ 0x01, 0x02, 0x03 and perhaps 0x04 will be draw always over the other
lines. I used it for one-way-arrows.

Arndt

"osm@pinns<mailto:osm@pinns>" <o...@pinns.co.uk<mailto:o...@pinns.co.uk>>
hat am 25. Februar 2018 um 15:21 geschrieben:


Hi

Layering of lines does not seem to be supported by Garmin - I have seen
many Topos where bridges are completely ignored.

Using a TYP file you can often force lines to have a draworder by making
them solid - solid has often a higher draworder than lines with bitmaps.

I'm not sure whether placing a line  at  the end of a 'lines' block in
the
RGN would ensure it will be parsed last.

Nick

On 25/02/2018 13:15, Thomas Morgenstern wrote:


Hi , maybee I found a bug in rendering layer's. I have prepared a small
SanIsidro.osm.pbf  and the resulting gmap with FID 982, created with
mkgmap-r4127, Download :
http:\\img2ms.de/Downloads\WrongLayerSanIsidro

Re: [mkgmap-dev] Wrong rendering Layer=1

Yes I have understand your suggestion. And created a small SanIsidro.osm. 
Inside are only 2 ways, tagged as bridge=yes and layer=1. This 2 ways are 
placed at the end of osm.file. Then created a map with option 
--preserve-element-order .  But it looks wrong. I maked 2. test : have changed 
the 0x1 and 0xc. Result is : 0x1 is drawn over 0xc.
So I assume , it is hardcoded.
 
  Thomas 


--
Von: "Gerd Petermann" <gpetermann_muenc...@hotmail.com>
Datum: Sonntag, 25. Februar 2018 19:03
An: "Thomas Morgenstern" <webmas...@img2ms.de>; "Development list for mkgmap" 
<mkgmap-dev@lists.mkgmap.org.uk>
Betreff: Re: [mkgmap-dev] Wrong rendering Layer=1

> Hi Thomas,
> 
> what I wanted to suggest is to use --preserve-element-order and change the 
> order of the two ways in the osm file.
> Without --preserve-element-order the order is not predictable, but might be 
> the same as with
> the option.
> 
> Gerd
> 
> ____
> Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von 
> Thomas Morgenstern <webmas...@img2ms.de>
> Gesendet: Sonntag, 25. Februar 2018 19:48:50
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Wrong rendering Layer=1
> 
> Hi Gerd, i have tested now --preserve-element-order . You are right. This
> does not help. The result is similar to without --preserve-element-order.
> thomas
> 
> ----------
> Von: "Gerd Petermann" <gpetermann_muenc...@hotmail.com>
> Datum: Sonntag, 25. Februar 2018 18:17
> An: "Thomas Morgenstern" <webmas...@img2ms.de>; "Development list for
> mkgmap" <mkgmap-dev@lists.mkgmap.org.uk>
> Betreff: Re: [mkgmap-dev] Wrong rendering Layer=1
> 
>> Hi Thomas,
>>
>> my understanding is that this was already tried in the past, without
>> success.
>> You can test it with a test osm file containing only two ways. When you
>> use
>> --preserve-element-order mkgmap should write them in the order of
>> the OSM file. It is better to use a small file for those tests so that all
>> data
>> fits into one sub division.
>>
>> It might well be possible that Garmin software has a hard coded draw order
>> for
>> specific line types. As Arndt already mentioned this is the case for
>> 0x01..0x03.
>>
>> Gerd
>>
>> 
>> Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von
>> Thomas Morgenstern <webmas...@img2ms.de>
>> Gesendet: Sonntag, 25. Februar 2018 18:10:24
>> An: Development list for mkgmap
>> Betreff: Re: [mkgmap-dev] Wrong rendering Layer=1
>>
>> Some time ago we have introduced the teature 'order-by-decreasing-area'.
>> Maybee a similar arangement  helps. Order all  lines ,(related to streets)
>> in range of layer . Highest layer at last ?
>> thomas
>>
>> --
>> Von: "Gerd Petermann" <gpetermann_muenc...@hotmail.com>
>> Datum: Sonntag, 25. Februar 2018 16:50
>> An: "Thomas Morgenstern" <webmas...@img2ms.de>; "Development list for
>> mkgmap" <mkgmap-dev@lists.mkgmap.org.uk>
>> Betreff: Re: [mkgmap-dev] Wrong rendering Layer=1
>>
>>> Hi Arndt,
>>>
>>> many OSM applications evaluate tags like bridge and layer.
>>> The default style doesn't even evaluate bridge or layer, since we don't
>>> know a way to tell Garmin software a draw order
>>> of lines. This is just a special problem with the (old) Garmin img
>>> format.
>>> Maybe there is a way to change the draw order, if you have an idea,
>>> please
>>> let us know.
>>>
>>> Gerd
>>>
>>> 
>>> Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von
>>> Thomas Morgenstern <webmas...@img2ms.de>
>>> Gesendet: Sonntag, 25. Februar 2018 17:25:08
>>> An: Development list for mkgmap
>>> Betreff: Re: [mkgmap-dev] Wrong rendering Layer=1
>>>
>>> I am wondering, why we write tag=bridge and tag layer=anywhat, when
>>> mkgamp
>>> does ignore bridge=yes and layer=1. All the work, to tset this tag is
>>> seenless.?
>>> thomas
>>>
>>> Von: Arndt Röhrig<mailto:ar...@speichenkarte.de>
>>> Datum: Sonntag, 25. Februar 2018 14:52
>>> An: Development list for mkgmap<mailto:mkgmap-dev@lists.mkgmap.org.uk>
>&g

Re: [mkgmap-dev] Wrong rendering Layer=1

Hi Gerd, i have tested now --preserve-element-order . You are right. This 
does not help. The result is similar to without --preserve-element-order.

thomas

--
Von: "Gerd Petermann" <gpetermann_muenc...@hotmail.com>
Datum: Sonntag, 25. Februar 2018 18:17
An: "Thomas Morgenstern" <webmas...@img2ms.de>; "Development list for 
mkgmap" <mkgmap-dev@lists.mkgmap.org.uk>

Betreff: Re: [mkgmap-dev] Wrong rendering Layer=1


Hi Thomas,

my understanding is that this was already tried in the past, without 
success.
You can test it with a test osm file containing only two ways. When you 
use

--preserve-element-order mkgmap should write them in the order of
the OSM file. It is better to use a small file for those tests so that all 
data

fits into one sub division.

It might well be possible that Garmin software has a hard coded draw order 
for
specific line types. As Arndt already mentioned this is the case for 
0x01..0x03.


Gerd


Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von 
Thomas Morgenstern <webmas...@img2ms.de>

Gesendet: Sonntag, 25. Februar 2018 18:10:24
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Wrong rendering Layer=1

Some time ago we have introduced the teature 'order-by-decreasing-area'.
Maybee a similar arangement  helps. Order all  lines ,(related to streets)
in range of layer . Highest layer at last ?
thomas

--
Von: "Gerd Petermann" <gpetermann_muenc...@hotmail.com>
Datum: Sonntag, 25. Februar 2018 16:50
An: "Thomas Morgenstern" <webmas...@img2ms.de>; "Development list for
mkgmap" <mkgmap-dev@lists.mkgmap.org.uk>
Betreff: Re: [mkgmap-dev] Wrong rendering Layer=1


Hi Arndt,

many OSM applications evaluate tags like bridge and layer.
The default style doesn't even evaluate bridge or layer, since we don't
know a way to tell Garmin software a draw order
of lines. This is just a special problem with the (old) Garmin img 
format.
Maybe there is a way to change the draw order, if you have an idea, 
please

let us know.

Gerd

________
Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von
Thomas Morgenstern <webmas...@img2ms.de>
Gesendet: Sonntag, 25. Februar 2018 17:25:08
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Wrong rendering Layer=1

I am wondering, why we write tag=bridge and tag layer=anywhat, when 
mkgamp

does ignore bridge=yes and layer=1. All the work, to tset this tag is
seenless.?
thomas

Von: Arndt Röhrig<mailto:ar...@speichenkarte.de>
Datum: Sonntag, 25. Februar 2018 14:52
An: Development list for mkgmap<mailto:mkgmap-dev@lists.mkgmap.org.uk>
Betreff: Re: [mkgmap-dev] Wrong rendering Layer=1


Hi,

imho there is no draw prio possible with lines. Solid has no effect. Only
typ 0x01, 0x02, 0x03 and perhaps 0x04 will be draw always over the other
lines. I used it for one-way-arrows.

Arndt

"osm@pinns<mailto:osm@pinns>" <o...@pinns.co.uk<mailto:o...@pinns.co.uk>>
hat am 25. Februar 2018 um 15:21 geschrieben:


Hi

Layering of lines does not seem to be supported by Garmin - I have seen
many Topos where bridges are completely ignored.

Using a TYP file you can often force lines to have a draworder by making
them solid - solid has often a higher draworder than lines with bitmaps.

I'm not sure whether placing a line  at  the end of a 'lines' block in 
the

RGN would ensure it will be parsed last.

Nick

On 25/02/2018 13:15, Thomas Morgenstern wrote:


Hi , maybee I found a bug in rendering layer's. I have prepared a small
SanIsidro.osm.pbf  and the resulting gmap with FID 982, created with
mkgmap-r4127, Download :
http:\\img2ms.de/Downloads\WrongLayerSanIsidro.rar .
The error is, that the highway ID=217.806.076 is rendered over the bridge
ID=65.208.316. Bridge has tag bridge=yes and originaly layer=1. I tried
layer=2, but it makes  no different, it should bee rendered  over the
highway,  This wrong rendering happens in may cases related to TF-1 in
tenerife.
[cid:793096B291174F75AFA2407BB062C915@dell]

any idees to resolve this in stylefile ?
thomas



___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev



___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev



___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev



_

Re: [mkgmap-dev] Wrong rendering Layer=1

Some time ago we have introduced the teature 'order-by-decreasing-area'. 
Maybee a similar arangement  helps. Order all  lines ,(related to streets) 
in range of layer . Highest layer at last ?

thomas

--
Von: "Gerd Petermann" <gpetermann_muenc...@hotmail.com>
Datum: Sonntag, 25. Februar 2018 16:50
An: "Thomas Morgenstern" <webmas...@img2ms.de>; "Development list for 
mkgmap" <mkgmap-dev@lists.mkgmap.org.uk>

Betreff: Re: [mkgmap-dev] Wrong rendering Layer=1


Hi Arndt,

many OSM applications evaluate tags like bridge and layer.
The default style doesn't even evaluate bridge or layer, since we don't 
know a way to tell Garmin software a draw order

of lines. This is just a special problem with the (old) Garmin img format.
Maybe there is a way to change the draw order, if you have an idea, please 
let us know.


Gerd


Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von 
Thomas Morgenstern <webmas...@img2ms.de>

Gesendet: Sonntag, 25. Februar 2018 17:25:08
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Wrong rendering Layer=1

I am wondering, why we write tag=bridge and tag layer=anywhat, when mkgamp 
does ignore bridge=yes and layer=1. All the work, to tset this tag is 
seenless.?

thomas

Von: Arndt Röhrig<mailto:ar...@speichenkarte.de>
Datum: Sonntag, 25. Februar 2018 14:52
An: Development list for mkgmap<mailto:mkgmap-dev@lists.mkgmap.org.uk>
Betreff: Re: [mkgmap-dev] Wrong rendering Layer=1


Hi,

imho there is no draw prio possible with lines. Solid has no effect. Only 
typ 0x01, 0x02, 0x03 and perhaps 0x04 will be draw always over the other 
lines. I used it for one-way-arrows.


Arndt

"osm@pinns<mailto:osm@pinns>" <o...@pinns.co.uk<mailto:o...@pinns.co.uk>> 
hat am 25. Februar 2018 um 15:21 geschrieben:



Hi

Layering of lines does not seem to be supported by Garmin - I have seen 
many Topos where bridges are completely ignored.


Using a TYP file you can often force lines to have a draworder by making 
them solid - solid has often a higher draworder than lines with bitmaps.


I'm not sure whether placing a line  at  the end of a 'lines' block in the 
RGN would ensure it will be parsed last.


Nick

On 25/02/2018 13:15, Thomas Morgenstern wrote:


Hi , maybee I found a bug in rendering layer's. I have prepared a small 
SanIsidro.osm.pbf  and the resulting gmap with FID 982, created with 
mkgmap-r4127, Download : 
http:\\img2ms.de/Downloads\WrongLayerSanIsidro.rar .
The error is, that the highway ID=217.806.076 is rendered over the bridge 
ID=65.208.316. Bridge has tag bridge=yes and originaly layer=1. I tried 
layer=2, but it makes  no different, it should bee rendered  over the 
highway,  This wrong rendering happens in may cases related to TF-1 in 
tenerife.

[cid:793096B291174F75AFA2407BB062C915@dell]

any idees to resolve this in stylefile ?
thomas



___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev



___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev



___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev





___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev






___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev 


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Wrong rendering Layer=1

I am wondering, why we write tag=bridge and tag layer=anywhat, when mkgamp does 
ignore bridge=yes and layer=1. All the work, to tset this tag is seenless.?
thomas


Von: Arndt Röhrig 
Datum: Sonntag, 25. Februar 2018 14:52
An: Development list for mkgmap 
Betreff: Re: [mkgmap-dev] Wrong rendering Layer=1


Hi,

imho there is no draw prio possible with lines. Solid has no effect. Only typ 
0x01, 0x02, 0x03 and perhaps 0x04 will be draw always over the other lines. I 
used it for one-way-arrows.

Arndt



  "osm@pinns" <o...@pinns.co.uk> hat am 25. Februar 2018 um 15:21 geschrieben: 


  Hi

  Layering of lines does not seem to be supported by Garmin - I have seen many 
Topos where bridges are completely ignored.

  Using a TYP file you can often force lines to have a draworder by making them 
solid - solid has often a higher draworder than lines with bitmaps.

  I'm not sure whether placing a line  at  the end of a 'lines' block in the 
RGN would ensure it will be parsed last.

  Nick




  On 25/02/2018 13:15, Thomas Morgenstern wrote: 




Hi , maybee I found a bug in rendering layer's. I have prepared a small 
SanIsidro.osm.pbf  and the resulting gmap with FID 982, created with 
mkgmap-r4127, Download : http:\\img2ms.de/Downloads\WrongLayerSanIsidro.rar .
The error is, that the highway ID=217.806.076 is rendered over the bridge 
ID=65.208.316. Bridge has tag bridge=yes and originaly layer=1. I tried 
layer=2, but it makes  no different, it should bee rendered  over the highway,  
This wrong rendering happens in may cases related to TF-1 in tenerife.
 
  any idees to resolve this in stylefile ?
  thomas 





___ 
mkgmap-dev mailing list 
mkgmap-dev@lists.mkgmap.org.uk 
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev



___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


  
  ___ 
  mkgmap-dev mailing list 
  mkgmap-dev@lists.mkgmap.org.uk 
  http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

  





___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] Wrong rendering Layer=1




Hi , maybee I found a bug in rendering layer's. I have prepared a small 
SanIsidro.osm.pbf  and the resulting gmap with FID 982, created with 
mkgmap-r4127, Download : http:\\img2ms.de/Downloads\WrongLayerSanIsidro.rar .
The error is, that the highway ID=217.806.076 is rendered over the bridge 
ID=65.208.316. Bridge has tag bridge=yes and originaly layer=1. I tried 
layer=2, but it makes  no different, it should bee rendered  over the highway,  
This wrong rendering happens in may cases related to TF-1 in tenerife. 
  any idees to resolve this in stylefile ?
  thomas 





___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Line TYP Collision between two different maps

2018-02-21 Thread Thomas Morgenstern

Each Typfile is designed for only one FID, not for a (map-)name. The FID is 
stored inside at Byte 48 and 49. It is irregular, if 2 different typfiles with 
the same FID exists. If you use Mapsource or MapInstall to send the map's to 
GPS, this can never occur, because Mapsource shows only 1 map per FID. The PID 
is not interesting. 
Thomas


Von: scott taggart 
Datum: Mittwoch, 21. Februar 2018 18:36
An: mkgmap-dev@lists.mkgmap.org.uk 
Betreff: [mkgmap-dev] Line TYP Collision between two different maps


Hello,

I am seeing a collision between custom line TYPs when I generate two different 
.img files (different Map IDs (--mapname= parameter to mkgmap)).  Here is what 
I am seeing and was wondering if anyone could offer ideas:

Map 1 : TYP file : Type=0x11 (solid red), contains a single line
Map 2 : TYP file : Type=0x11 (solid green), contains a single line

Both .img files get loaded into my gps (montana) and are enabled and both lines 
show, however, map 2's lines shows as red, not green, as expected.  If I 
disable map 1, map 2's line still shows incorrectly.  If I delete map 1 form 
the gps, then map 2's line shows correctly.  I thought that each map had its 
own TYPs and the GPS would sort out which TYP to display for each map's line.  
It seems that the gps unit is getting confused or caching the line TYPs from 
the "first loaded" map and using those for subsequent maps.  If it were true 
that an earlier loaded map's custom TYPs override later loaded maps, how would 
it be possible to sort out custom types across different maps?

Another thought I had is that since both my maps share the same family id and 
product id, could this be causing the collision?  I cannot find any decent 
documentation on what family id and product ID are supposed to be.

Thanks for your help,

Scott








___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] patch for crash in MapSource

2018-02-08 Thread Thomas Morgenstern

Hi, sorry forgot my posting. i have solved this problem. But: in 
mkgmap-r4107\examples\styles\default\inc\compat_lines  Line 124 is the old 
error existing, diskused at 3.feb.2018. Quote # > mkgmap:carpool_compat=yes  { 
set access=no; set mkgmap:bus=yes; set mkgmap:emergency=yes; set 
mkgmap:carpool=yes } Ha.. yes it could be either.  My guess would be that
it should be 'setaccess no' as it is followed by some
of the access flags.#end quote

following command gives no error :
mkgmap:carpool_compat=yes  { setaccess no; set mkgmap:bus=yes; set 
mkgmap:emergency=yes; set mkgmap:carpool=yes ;}  
the Equal sign after setaccess must bee replaced with space.
thomas


Von: Thomas Morgenstern 
Datum: Donnerstag, 8. Februar 2018 18:49
An: Development list for mkgmap 
Betreff: Re: [mkgmap-dev] patch for crash in MapSource


This version has a problem reading stylefile. It gives me the following error 
:Error in style:Error: (points:240): quoted word found where command expected. 
Could not open style. 
Line 240 is : 
amenity=guidepost | amenity=signpost | (tourism=information & 
information=guidepost) {add name=('$(name:de')|'$(name)'|'Wegweiser')} [0x4c01 
resolution 24]

this error never occured with older versions. like  mkgmap- r3997.  what is 
wrong ?

thomas
--
Von: "Gerd Petermann" <gpetermann_muenc...@hotmail.com>
Datum: Donnerstag, 8. Februar 2018 17:40
An: "Development list for mkgmap" <mkgmap-dev@lists.mkgmap.org.uk>
Betreff: Re: [mkgmap-dev] patch for crash in MapSource

> Hi all,
> 
> I've created patches for splitter and mkgmap.
> The binaries are here:
> http://files.mkgmap.org.uk/download/417/splitter.jar
> http://files.mkgmap.org.uk/detail/416
> 
> Please try splitter with align-for-dem=360. I found no more crashes as long
> as used only one dem level, e.g. dem-dists=3312 or dem-dists=9936
> 
> Maybe you find a combination of  align-for-dem and dem-dists with more than 
> one value
> that still works, I'll try again tomorrow.
> 
> Gerd
> 
> 
> Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Gerd 
> Petermann <gpetermann_muenc...@hotmail.com>
> Gesendet: Donnerstag, 8. Februar 2018 13:16
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] patch for crash in MapSource
> 
> Hi all,
> 
> the patch contained a stupid bug, but there is more to this:
> 1) the effect of the patch depends on the dem-dists value (I assume only the 
> one
> that gives the highest resolution). The higher the resolution the better it 
> works.
> 2) it probably also depends on the boundaries (areas.list)
> 
> I assume now that the tile boundary from areas.list should be a certain 
> multiples of degrees,
> probably different multiples for lat and lon and that the overlap simply makes
> sure that this boundary is within the overlapped area.
> Maybe the preferred multiples also depend on the dem-dist.
> 
> I'll try to find out more ...
> 
> Gerd
> 
> 
> Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von 
> osm@pinns <o...@pinns.co.uk>
> Gesendet: Donnerstag, 8. Februar 2018 10:33
> An: mkgmap-dev@lists.mkgmap.org.uk
> Betreff: Re: [mkgmap-dev] patch for crash in MapSource
> 
> Hi Gerd
> 
> I think you are right ,ie
> 
> start and finishing point  at same level seems OK eventhough the route
> turns south 20miles then up again
> 
> r
> 
> Nick
> 
> 
> On 08/02/2018 09:27, Gerd Petermann wrote:
>> Hi all,
>>
>> okay, thanks for testing. I'll try to find a better patch.
>> Please check: I think the patch works fine for routes which cross tile 
>> borders in horizontal direction
>> direction but I still see problems with vertical crossing. Can you confirm 
>> that?
>>
>> Gerd
>>
>> 
>> Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von 
>> Henning Scholland <o...@hscholland.de>
>> Gesendet: Donnerstag, 8. Februar 2018 09:59
>> An: Development list for mkgmap
>> Betreff: Re: [mkgmap-dev] patch for crash in MapSource
>>
>> Same for me, but just did quick test. Will try on the weekend more detailed
>> Henning
>> On 8 Feb 2018, at 16:57, lig fietser 
>> <ligfiet...@hotmail.com<mailto:ligfiet...@hotmail.com>> wrote:
>>
>> Hi Gerd,
>>
>> I tested your patch but I still see frequent crashes near tile borders.
>>
>>
>> 
>> Van: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> namens Gerd 
>> Petermann <gpeterm

Re: [mkgmap-dev] patch for crash in MapSource

2018-02-08 Thread Thomas Morgenstern

This version has a problem reading stylefile. It gives me the following error 
:Error in style:Error: (points:240): quoted word found where command expected. 
Could not open style. 
Line 240 is : 
amenity=guidepost | amenity=signpost | (tourism=information & 
information=guidepost) {add name=('$(name:de')|'$(name)'|'Wegweiser')} [0x4c01 
resolution 24]

this error never occured with older versions. like  mkgmap- r3997.  what is 
wrong ?

thomas
--
Von: "Gerd Petermann" 
Datum: Donnerstag, 8. Februar 2018 17:40
An: "Development list for mkgmap" 
Betreff: Re: [mkgmap-dev] patch for crash in MapSource

> Hi all,
> 
> I've created patches for splitter and mkgmap.
> The binaries are here:
> http://files.mkgmap.org.uk/download/417/splitter.jar
> http://files.mkgmap.org.uk/detail/416
> 
> Please try splitter with align-for-dem=360. I found no more crashes as long
> as used only one dem level, e.g. dem-dists=3312 or dem-dists=9936
> 
> Maybe you find a combination of  align-for-dem and dem-dists with more than 
> one value
> that still works, I'll try again tomorrow.
> 
> Gerd
> 
> 
> Von: mkgmap-dev  im Auftrag von Gerd 
> Petermann 
> Gesendet: Donnerstag, 8. Februar 2018 13:16
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] patch for crash in MapSource
> 
> Hi all,
> 
> the patch contained a stupid bug, but there is more to this:
> 1) the effect of the patch depends on the dem-dists value (I assume only the 
> one
> that gives the highest resolution). The higher the resolution the better it 
> works.
> 2) it probably also depends on the boundaries (areas.list)
> 
> I assume now that the tile boundary from areas.list should be a certain 
> multiples of degrees,
> probably different multiples for lat and lon and that the overlap simply makes
> sure that this boundary is within the overlapped area.
> Maybe the preferred multiples also depend on the dem-dist.
> 
> I'll try to find out more ...
> 
> Gerd
> 
> 
> Von: mkgmap-dev  im Auftrag von 
> osm@pinns 
> Gesendet: Donnerstag, 8. Februar 2018 10:33
> An: mkgmap-dev@lists.mkgmap.org.uk
> Betreff: Re: [mkgmap-dev] patch for crash in MapSource
> 
> Hi Gerd
> 
> I think you are right ,ie
> 
> start and finishing point  at same level seems OK eventhough the route
> turns south 20miles then up again
> 
> r
> 
> Nick
> 
> 
> On 08/02/2018 09:27, Gerd Petermann wrote:
>> Hi all,
>>
>> okay, thanks for testing. I'll try to find a better patch.
>> Please check: I think the patch works fine for routes which cross tile 
>> borders in horizontal direction
>> direction but I still see problems with vertical crossing. Can you confirm 
>> that?
>>
>> Gerd
>>
>> 
>> Von: mkgmap-dev  im Auftrag von 
>> Henning Scholland 
>> Gesendet: Donnerstag, 8. Februar 2018 09:59
>> An: Development list for mkgmap
>> Betreff: Re: [mkgmap-dev] patch for crash in MapSource
>>
>> Same for me, but just did quick test. Will try on the weekend more detailed
>> Henning
>> On 8 Feb 2018, at 16:57, lig fietser 
>> > wrote:
>>
>> Hi Gerd,
>>
>> I tested your patch but I still see frequent crashes near tile borders.
>>
>>
>> 
>> Van: mkgmap-dev  namens Gerd 
>> Petermann 
>> Verzonden: woensdag 7 februari 2018 02:45:27
>> Aan: mkgmap-dev@lists.mkgmap.org.uk
>> Onderwerp: [mkgmap-dev] patch for crash in MapSource
>>
>> Hi all,
>>
>> attached is a patch that seems to help in many cases where --dem-poly causes 
>> crashes in MapSource "Show Profile..."
>> A binary is here:
>> http://files.mkgmap.org.uk/download/414/mkgmap.jar
>>
>> It changes the TRE file and the *.tdb file.
>> I still see a few crashes but maybe those are caused by other problems.
>>
>> Please try and let me know your results. I found no bad impact so far,
>> long distance routing still seems to work, but I've not tested much.
>>
>> @Steve: Maybe we have to make sure that the areas in *.tdb do not overlap.
>> In this case this patch is not yet okay.
>>
>> Gerd
>>
>> 
>>
>> mkgmap-dev mailing list
>> mkgmap-dev@lists.mkgmap.org.uk
>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>> ___
>> mkgmap-dev mailing list
>> mkgmap-dev@lists.mkgmap.org.uk
>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> 
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>

Re: [mkgmap-dev] splitter r590,wrong handling of relations

2018-02-07 Thread Thomas Morgenstern

Thank you :-).  Yesterday I had send a message to the Author Javier Sanchez 
.

thomas

--
Von: "Gerd Petermann" <gpetermann_muenc...@hotmail.com>
Datum: Mittwoch, 7. Februar 2018 06:24
An: "Development list for mkgmap" <mkgmap-dev@lists.mkgmap.org.uk>
Betreff: Re: [mkgmap-dev] splitter r590,wrong handling of relations


Hi Thomas,

I've just fixed the relation [1], so please try again with a fresh 
download tomorrow.


Gerd
[1] https://www.openstreetmap.org/changeset/56139020


Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von 
Gerd Petermann <gpetermann_muenc...@hotmail.com>

Gesendet: Dienstag, 6. Februar 2018 14:47
An: Thomas Morgenstern; Development list for mkgmap
Betreff: Re: [mkgmap-dev] splitter r590,wrong handling of relations

Hi Thomas,

the relation is broken. Use JOSM validator and it will report 2 errors.
I think this way
https://www.openstreetmap.org/way/556302821
should not belong to it and a few nodes should be merged to repiar it:
node 4298102908
node 4298102907
node 655141348

Gerd


Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von 
Thomas Morgenstern <webmas...@img2ms.de>

Gesendet: Dienstag, 6. Februar 2018 14:35
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] splitter r590,wrong handling of relations

Hi Gerd, i have now made a different split, so that 1 tile contains the
whole isle. In this case it looks good. I assume, that the relation is 
okay.
No idea what should be changed in data. Also i have looked before with 
JOSM

in the old split and  confirm, that in the left tile the relation also
exists, but not rendered from mkgmap. I can't judge, if the relation is
broken or not. Therefore the problem is in mkgmap ? I
thomas

--
Von: "Gerd Petermann" <gpetermann_muenc...@hotmail.com>
Datum: Dienstag, 6. Februar 2018 12:15
An: "Thomas Morgenstern" <webmas...@img2ms.de>; "Development list for
mkgmap" <mkgmap-dev@lists.mkgmap.org.uk>
Betreff: Re: [mkgmap-dev] splitter r590,wrong handling of relations


Hi Thomas,

I think the problem is that the relation is broken. Splitter writes it to
both tiles, but
mkgmap seems to have problems with it.
Anyway, the problem is in the data and should be fixed in OSM.

Gerd


________
Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von
Thomas Morgenstern <webmas...@img2ms.de>
Gesendet: Dienstag, 6. Februar 2018 12:50
An: Development list for mkgmap
Betreff: [mkgmap-dev] splitter r590,wrong handling of relations

Hi Gerd, i found out, that splitter r590 can not proper handle the
relation
2.691.138. I can reproduce the problem. It makes no different, if I 
splitt

the canary-islands-latest.osm.pbf with the default-option or with my own
splitt.list. If I move the tileborder by changing the nord-south border,
also the problem is moved. See picture at
http://img2ms.de/OSM/ErrorInSplitter-r590.jpg. At the tile-boundary
splitter
creates only for the rightsite tile the polygon for  tag
boundary=protected_area , respektive leisure=nature_reserve. In the
leftsite-tile this tags are missing.
maybee you can have a look at that ?

regards thomas



___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] splitter r590,wrong handling of relations

2018-02-06 Thread Thomas Morgenstern

Hi Gerd, i have now made a different split, so that 1 tile contains the 
whole isle. In this case it looks good. I assume, that the relation is okay. 
No idea what should be changed in data. Also i have looked before with JOSM 
in the old split and  confirm, that in the left tile the relation also 
exists, but not rendered from mkgmap. I can't judge, if the relation is 
broken or not. Therefore the problem is in mkgmap ? I

thomas

--
Von: "Gerd Petermann" <gpetermann_muenc...@hotmail.com>
Datum: Dienstag, 6. Februar 2018 12:15
An: "Thomas Morgenstern" <webmas...@img2ms.de>; "Development list for 
mkgmap" <mkgmap-dev@lists.mkgmap.org.uk>

Betreff: Re: [mkgmap-dev] splitter r590,wrong handling of relations


Hi Thomas,

I think the problem is that the relation is broken. Splitter writes it to 
both tiles, but

mkgmap seems to have problems with it.
Anyway, the problem is in the data and should be fixed in OSM.

Gerd



Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von 
Thomas Morgenstern <webmas...@img2ms.de>

Gesendet: Dienstag, 6. Februar 2018 12:50
An: Development list for mkgmap
Betreff: [mkgmap-dev] splitter r590,wrong handling of relations

Hi Gerd, i found out, that splitter r590 can not proper handle the 
relation

2.691.138. I can reproduce the problem. It makes no different, if I splitt
the canary-islands-latest.osm.pbf with the default-option or with my own
splitt.list. If I move the tileborder by changing the nord-south border,
also the problem is moved. See picture at
http://img2ms.de/OSM/ErrorInSplitter-r590.jpg. At the tile-boundary 
splitter

creates only for the rightsite tile the polygon for  tag
boundary=protected_area , respektive leisure=nature_reserve. In the
leftsite-tile this tags are missing.
maybee you can have a look at that ?

regards thomas



___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] splitter r590,wrong handling of relations

2018-02-06 Thread Thomas Morgenstern

Hi Gerd, i found out, that splitter r590 can not proper handle the relation 
2.691.138. I can reproduce the problem. It makes no different, if I splitt 
the canary-islands-latest.osm.pbf with the default-option or with my own 
splitt.list. If I move the tileborder by changing the nord-south border, 
also the problem is moved. See picture at 
http://img2ms.de/OSM/ErrorInSplitter-r590.jpg. At the tile-boundary splitter 
creates only for the rightsite tile the polygon for  tag 
boundary=protected_area , respektive leisure=nature_reserve. In the 
leftsite-tile this tags are missing.

maybee you can have a look at that ?

regards thomas



___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Is dem-tdb branch ready for trunk ?

2018-01-27 Thread Thomas Morgenstern

Maybee we can create a ready to use DEM-model, store it like the bounds.zip 
and see.zip ? The user can download it and mkgmap reads the DEM from 
downloaded #DEM.ZIP# ?
This method would be a graet advantage for users, who not so familiar with 
the DEM .

Regards Thomas
--
Von: "Gerd Petermann" 
Datum: Samstag, 27. Januar 2018 08:54
An: 
Betreff: [mkgmap-dev] Is dem-tdb branch ready for trunk ?


Hi all,

I am not aware of any erros in r4091, so I think it is time to merge it 
into trunk.


I see only one problem: HGT data changes rarely, so I'd prefer to do the 
costly DEM calculations

only once and be able to store the results.
I've already described how to do this here [1] but I'd prefer to have a 
container format that allows
mkgmap to extract the Garmin DEM bitstream data for a given lat/lon pair 
from a file.
Such a container could contain the DEM data for one or more dem-dist 
values. It could be empty first
and grow each time you calculate DEM for a new area. In subsequent 
executions of mkgmap it would

check if the container already contains the data for the wanted area.
Advantage would be a faster tile compilation and less power consumption, 
disadvantage would be the

additional disk space and higher complexity.

[1] 
http://gis.19327.n8.nabble.com/Performance-with-zipped-hgt-files-tp5909756p5909801.html


Gerd



___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] splitter r585 ; dem-dist 3342 or 3314 ?

2018-01-18 Thread Thomas Morgenstern

Hi Gerd, in some posts are written different -dem-dist . Which is the right, 
3314 or 3342 ? For using with --align-for-dem  1" hgt ?

thomas

--
Von: "Gerd Petermann" 
Datum: Mittwoch, 17. Januar 2018 17:42
An: 
Betreff: [mkgmap-dev] splitter r585 implements new option align-for-dem


Hi all,

see http://www.mkgmap.org.uk/websvn/revision.php?repname=splitter=585

If I got that right you can use dem-dist 9942 for level 0 if hgt files are 
in 3'' resolution and splitter

was executed with --align-for-dem=1200.
For hgt 1'' files use dem-dist 3342 for level 0 and --align-for-dem=3600.

This should reduce DEM size a lot AND increase precision.

Gerd
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] How to handle missing hgt files or fileswith voids?

2018-01-15 Thread Thomas Morgenstern

For Europe is a good source for 1 sec. hgt  EPSG 4326 : 
http://opendem.info/opendemeu_download_4326.html .

Thomas

--
Von: "Gerd Petermann" 
Datum: Montag, 15. Januar 2018 08:55
An: "Development list for mkgmap" 
Betreff: Re: [mkgmap-dev] How to handle missing hgt files or fileswithvoids?> 
Hi Henning,


checking data is not that easy, but I'll think about that option.

I'd like to add a short howto that describes ways to get good hgt data, 
but I don't know any method for Windows users.
phyghtmap is good, but installation on Win is complex and doc for that 
looks out-aged.

Srtm2Osm seems out-dated, as well as Groundtruth.

So, up to now I try to guess what areas I have to download from 
viewfinder.

Any hints ?

Gerd


Von: mkgmap-dev  im Auftrag von 
Henning Scholland 

Gesendet: Montag, 15. Januar 2018 09:05:24
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] How to handle missing hgt files or files with 
voids?


Hi Gerd,

regarding 1) I can create a list of existing tiles of Viewfinder (which 
covers all land area so far I see). But it will be a long list. I remember 
it's about 25000 files in total. So maybe it's easier to create a polygon 
or at least take the list and let software create the polygon. An easier 
way can be to check if data is available. No data might be sea. Of course 
it's not 100% sure, as there are deserts and ferries.


Another idea I had during the weekend was to output a osm-file with 
missing areas. So then user can check. But I came to conclusion, that it's 
easily visible in the map later. So I'm not sure it's useful at all.


Henning

On 2018-01-15 15:45, Gerd Petermann wrote:

Hi all,

1) The current code (only) writes a log message with severity WARNING for 
a missing hgt file:

"file xxx.hgt not found. Is expected to cover sea."
I wonder if we can create a list of files that can exist or maybe a 
polygon that can be tested so that

tiles which are knwon to cover land are reported as errors.
When you look at 
http://viewfinderpanoramas.org/Coverage%20map%20viewfinderpanoramas_org3.htm

you can see that such a polygon would be quite complex.
Did anybody already try to define such a polygon or list of files that 
would cover only ocean?


2) Should mkgmap print a warning when voids in the hgt file(s) have an 
influence on the DEM data?

I think yes, but it is a bit more complex to measure the real effect.
Reason: We read the 4 hgt values next to the wanted DEM point and use 
interpolation to calculate the height

that is stored in the DEM file.
If one or two of the 4 points are voids they may still have no influence 
if the wanted point is very close to one that
is not a void. Another problem is that a single void might be used several 
times.
So, another option would be to add an option like --dem-check-hgt which 
could read all existing hgt files and
report the number of voids for each. I'd prefer this because it would have 
no impact on performance for normal
processing. Or maybe there is already a tool for this that works on all 
platforms (win,linux,mac) ?


Comments?

Gerd





___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev




___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


___
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 Thomas Morgenstern

Hi Frank, can you give us a compiled version for windows for the 
geotiff > hgt converter ?

thomas

--
Von: "Frank Stinner" 
Datum: Montag, 1. Januar 2018 18:28
An: 
Betreff: 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 


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] mkgmap r4010

2017-12-22 Thread Thomas Morgenstern

Hi , which hgt will mkgmap use, if multipath for hgt is definied and in both 
paths are the same areas?. which hgt-file is used? The first found and the 
second is ignored? Or the second is used?.


Thomas

--
Von: "Gerd Petermann" 
Datum: Freitag, 22. Dezember 2017 07:56
An: "Development list for mkgmap" 
Betreff: Re: [mkgmap-dev] mkgmap r4010


Hi Nick,

sure, look at the bottom of http://www.mkgmap.org.uk/download/mkgmap.html
to find the latest branch builds.

Gerd


Von: mkgmap-dev  im Auftrag von 
garmin tools 

Gesendet: Freitag, 22. Dezember 2017 08:38:15
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] mkgmap r4010

Hi Gerd

Would it be possible to have a compiled version of r4011 so I can do
further testing?

Regards


Nick


On 22/12/2017 08:35, Gerd Petermann wrote:

Hi Arndt,

In r4011 you can specify multiple paths in a comma separated list.

Sample : --x-dem=f:\osm\phyghtmap\hgt\SRTM1,f:\osm\phyghtmap\hgt\SRTM3
If there are blanks in the path make sure to use quotes, e.g. (on 
Windows):
--x-dem="f:\my owm data\phyghtmap\hgt\SRTM1","f:\my owm 
data\phyghtmap\hgt\SRTM3"

Don't add blanks before or after the comma.

Gerd


Von: mkgmap-dev  im Auftrag von 
Gerd Petermann 

Gesendet: Donnerstag, 21. Dezember 2017 20:33:32
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] mkgmap r4010

Hi Arndt,

Good point. I think I can add code to search in multiple directories, for 
now you have to put them into one dir.
Note that 1'' files and 3'' files have the same name, so if you want to 
use the 1'' files make sure

that you don't replace them by 3'' files.

Gerd


Von: mkgmap-dev  im Auftrag von 
Arndt Röhrig 

Gesendet: Donnerstag, 21. Dezember 2017 20:00:44
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] mkgmap r4010

Hi,

This is fantastic, thank you for this work!

I don´t understand anything what you do, but it works and my maps looks 
much better.


I use phyghtmap to get the hgt Files. phyghtmap stores the files in 4 
folders, view3, view1, srtm3 and srtm1. Can i tell x-dem to look in all 4 
folders? Or must i copy all hgts in one folder?


Arndt

Gerd Petermann hat am 21. Dezember 2017 um 18:10 geschrieben:


Hi,

I've just committed r4010. I think I found the bug that caused the wrong 
reliefs or empty rectangles.

Next step is to calculate multiple levels.

@Frank: I forgot to make the number of zero bits depended on the 
previously calculated plateau length.

The corresponding code in your program
if (iPlateauLengthBinBits >= 0) // bei Plateaufollower weniger Bit 
erlaubt

lbits -= iPlateauLengthBinBits + 1;

I think that this makes only sense if a BigBin value changes something, 
e.g. resets a flag or increases/decreases
a counter. Else it would just be a waste of space. I think you mentioned 
something like that in the pdf as well.


Gerd
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


___
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

2017-12-18 Thread Thomas Morgenstern

using XP the right path is on a german-layout machine : :C:\Dokumente und 
Einstellungen\All Users\Anwendungsdaten\Garmin\Maps.


W7,W8,W10 : C:\ProgramData\GARMIN\Maps\

regards thomas

--
Von: "Carlos Dávila" 
Datum: Montag, 18. Dezember 2017 16:34
An: "Development list for mkgmap" 
Betreff: [mkgmap-dev] Maps in *.gmap format installation directory

Is there a unique directory where maps in *.gmap format can be installed? 
I would like to change my current installers to use gmap format instead of 
the old format, but I don't know what is the right directory to install 
them. In my XP virtual box if I copy gmap folder in c:\archivos de 
programa(program files)\Garmin\Maps maps are read by MapSource, but not by 
BaseCamp. If I copy gmap folder in C:\Archivos de 
programa\Garmin\Basecamp\Maps then they are read by BaseCamp, but not by 
MapSource. And what about more recent versions of Windows?

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] problems with gmtool

2017-11-11 Thread Thomas Morgenstern

Hi Frank, i have succesfull added DEM files and then all subfiles joined 
with gmtool to <12345678>.img. After that i will create a new tdb using 
cmd. It gives me the following :


D:\Kartensoftware\mkgmap\BuildDEM>gmtool --overwrite --input 
\\64BIT\64bitDaten\OSMKarten\Kan
ren\3???.img --output \\64BIT\64bitDaten\OSMKarten\Kanaren. 
--mapsource=pid:1;fid:1918;cp
1252;ov:TopoKana.img;tdb:TopoKana.tdb;notyp;nomdx;nomdr;noinst 
--version=1710 --mapfamilyname
"Test" --mapseriesname="TopoKanDEM" --description="DEMTest" --routable=1 
--highestroutable=24

--maxbits4overview=18 --hasdem=1 --hasprofile=1 --copyright=*I*
GMTool, Version vom 1.11.2017, Copyright © FSofT 2016
   Clipper Library 6.4.0 von Angus Johnson 
(http://sourceforge.net/projects/polyclipping)

GarminCore-DLL, Version vom 27.10.2017, Copyright © FSofT 2011

Anzahl der Eingabedateien: 2
untersuche Datei \\64BIT\64bitDaten\OSMKarten\Kanaren\30007501.IMG ...
untersuche Datei \\64BIT\64bitDaten\OSMKarten\Kanaren\30007502.IMG ...
werte Kachel '30007501' aus ... Fehler: Der angegebene Schlüssel war 
nicht im Wörterbuch ange

eben.

Wie kann ich den Fehler vermeiden oder was mache ich falsch ? Wenn ich 
als input direkt die TRE-subfiles nehme, kommt  ..Die Mapnummer kann 
nicht ermittelt werden
Alternativ habe ich gmt benutzt um eine neue TDB +preview zu schreiben. 
Aber damit stürzt Mapsource ab.
Gar keine neue TDB zu schreiben geht nur mit Mapsource. Die selbe Karte 
im Basecamp bewirkt, dass BC nach Adresssuche total einfriert und nur im 
Taskmanager zu killen ist.

 thomas

Am 08.11.2017 um 20:02 schrieb Frank Stinner:

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=arg    distance between DEM-Point (multiple usage for 
more zoomlevels)
--usedummydata=arg    use '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=arg    DEM 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


___
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

2017-11-06 Thread Thomas Morgenstern



hi  all,
there is another problem:  the old mdr-file, created from IMG-files 
without DEM-subfiles do not work when try to search adresses.  Mapsource 
and Basecamp crashes . gmt can produce only valide tdb, but not mdr. If 
i add in  gmap-folder -->Product1\\the DEM-subfile , 
after that create a new tdb using gmt, remove the  name_mdr 
in info.xml, the map appear fine  in Basecamp. But address-searching 
fails. Any hints to solve the problem? How to produce a valid mdr ?

thomas


Am 04.11.2017 um 12:20 schrieb Steve Ratcliffe:

Hi Gerd


I hoped that Steve would jump on this;-)



OK I shall give it a go.  I've just added printing out the DEM entries
in the TdbDisplay.

Steve
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev





___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Basecamp crashes with my map

2017-08-05 Thread Thomas Morgenstern

Die Grenzen im split-file (areas.list) sollten in *G*armin*U*nits 
geschrieben werden. 1GU =~0,214576... (exact : 360°/2^ 24). Und die 
GU sollen ohne Rest durch 4 teilbar sein.
Beispiel: 47 ° /0,214576=2.190.366,117 *GU* .Die nächste durch 4 
teilbare Zahl ist : 2190368. Mit diesem Verfahren gab es noch nie 
Probleme. Routing funktioniert. Die Abweichung zu 47° ist 0,4039...° 
(weil 2190368*0,214576 = 47,403968°). Weniger als 5m .Kannst 
praktisch vergessen.

thomas

Am 05.08.2017 um 20:54 schrieb thesurve...@wolke7.net:

Hi all,
I've a question about splitting a map.
I'm using splitter to split a large pbf-file with contourlines to 
about 300 tiles. This works fine. But now I have the requirement to 
support a process
with two parts of the whole map, splitted exactly at a given latitude. 
So I've written a simple tool that reads the tile-list from splitter ( 
--write-kml),
searches for the tiles which are north or south of the given latitude 
and writes them to a file. For the tiles which are divided by the given
latitude the tool divides the tile in two parts and writes the parts 
as new tiles to the file.
As the next step splitter is called again with the file as a 
parameter  (--split-file) and mkgmap is used to create the two maps.
All this works wonderful, but yesterday I've seen that Basecamp 
crashes when I install those tiles.
I'm doing this since several years now, but never noticed that 
behaviour. Maybe I didn't see it, because I'm not using Basecamp very 
often.
So today I spent some hours to look deeper into that problem. I could 
eliminate one tile. Then I noticed that size of this tile is just 
about 8 kB.
And when I deleted the tile from the map Basecamp doesn't crash 
anymore. Of course the map should have a hole now :-)
Ok, so far so good, but what's the reason for that behaviour. This 
tile was splitted by my tool. So maybe I'm doing something wrong.

But I have splitted a lot more tiles which seem to work.
So I have some questions:
1) I'm splitting the tiles into two parts, at full or half degrees, 
e,g. 47.0 or 47.5.

2) The mentioned tile is less than 1 degree in north to south direction.
Could one ot those questions lead to that behaviour?
Do you have another idea what could be wrong with a tile that crashes 
Basecamp. Or do you have an idea what to check?

The map is working well on different Garmin devices (Oregon, etrex hcx).
Many thanks for your support.
Best regards,
Gert


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Missing sea and coastline while using Splitter

2017-04-12 Thread Thomas Morgenstern


Hi,

My way is more easy, and changes or experiments are easy to run :

1. rename the template.args (produced from splitter) to 
alaska_template.args, to avoid overwriting  by the next run.
2. write all options in the alaska_template.args. Each option is one 
line.  use a texteditor (not Word ) to do so. save in .txt format.


It looks for example like this :

/latin1//
//family-id=24983//
//name-tag-list=name:en,int_name,name//
//gmapsupp//
//description="Alaska"//
//country-name=USA//
//country-abbr=USA//
//series-name=MyOwnAlaskaMap//
//index//
//location-autofill="is_in,nearest" //
//copyright-message="Dave //Swarthout"//
//link-pois-to-ways//
//add-pois-to-areas//
//reduce-point-density=4//
//reduce-point-density-polygon=8//
//merge-lines//
//route//
//drive-on=right//
//net//
//housenumbers//
//x-split-name-index//
//check-roundabouts//
//check-roundabout-flares//
//process-destination//
//process-exits//
//poi-address//
//style-file="C:\Users\alask\Dropbox\Mapping\DJS_styles"
//precomp-sea="C:\Users\alask\Downloads\Maps\sea.zip"
//bounds="C:\Users\alask\Downloads\Maps\bounds"
/#   C:\Users\alask\Dropbox\Mapping\24983djs.TYP"  #  i don't know  
how  to include typfiles/

#max-jobs reduces runtime on 2 cores prozessors
//max-jobs=//
//output-dir=//C:\Users\alask\Downloads\Maps\//
//
//# Following is a list of map tiles.  Add a suitable description//
//# for each one.//
//
//mapname= 63240001//
//#give it a usefull name//
//description= Nord//
//# adjust your path here !! Fullpath is recommended //
//input-file=D:\splitter\63240001.osm.pbf //
//
//mapname= 63240002//
//description= Middle//
//input-file=\splitter\63240002.osm.pbf//
//
//mapname= 63240003//
//description= South//
//input-file=\splitter\63240003osm.pbf/

3: start mkgmap  : java -Xmx1000m -jar mkgmap.jar *-c 
"C:\Users\Alask\Documents\splitter\alaska_template.args"  .

*that is all .*
*
regards Thomas

Am 12.04.2017 um 01:37 schrieb Dave Swarthout:


java -Xmx1000m -jar mkgmap.jar *-c 
"C:\Users\Alask\Documents\splitter\template.args"* --latin1 
--family-id=24983 --name-tag-list=name:en,int_name,name --gmapsupp 
--description="Alaska" --country-name=USA --country-abbr=USA --index 
--location-autofill="is_in,nearest" --copyright-message="ODbL by OSM 
contributors" --link-pois-to-ways  --add-pois-to-areas 
 --reduce-point-density=4 --reduce-point-density-polygon=8 
--merge-lines --route --drive-on=right --net --housenumbers 
--x-split-name-index --check-roundabouts --check-roundabout-flares 
--process-destination --process-exits --poi-address 
*--generate-sea=land-tag=natural=background 
--style-file="C:\Users\alask\Dropbox\Mapping\DJS_styles" 
--precomp-sea="C:\Users\alask\Downloads\Maps\sea.zip" 
--bounds="C:\Users\alask\Downloads\Maps\bounds" 
"C:\Users\alask\Dropbox\Mapping\24983djs.TYP"*

*
*
Is the placement or order of the arguments important? Any other ideas 
or suggestions much appreciated.*

*

Thanks for your help,

Dave

--
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] tag landuse=residential produced false areas

2017-04-09 Thread Thomas Morgenstern

Danke, da muss ich mir was einfallen lassen im Stylefile, wie ich die 
Kombination aus admin_level und place=village entferne. Muss noch mal 
nachdenken, was da sinnvoll ist. Die Ursache ist ja jetzt klar. Habe 
auch die Relation in JOSM gefunden.


mfg thomas


Am 09.04.2017 um 19:40 schrieb Gerd Petermann:

Hi Thomas,

I've changed the default style to contain echotags like this:
place=village {echotags "p=v"} [0x03 resolution 19]

and used your input file. The output is
JoinedWay generated from 87213118 [admin_level=9, boundary=administrative, 
mkgmap:cache_area_size=2224558.0389404297, mkgmap:label:1=47 Klaffenbach, 
mkgmap:mp_created=true, mkgmap:stylefilter=polygon, name=Klaffenbach, 
place=village, ref=47] p=v

The message is a bit missleading, the source is the type=boundary relation 
414890
which also has the tag place=village.
This is treated like a type=multipolygon relation.

I am not 100% sure but I think all is correct.
Gerd

Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Thomas 
Morgenstern <webmas...@img2ms.de>
Gesendet: Sonntag, 9. April 2017 17:57:30
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] tag landuse=residential produced false areas

I use for test the 'buildin-style'. But it makes no differenzes, if I
use my own style. Own style is based on defaultstyle older relase
mkgmap. Only small differenzes. But is is the 0x3 . See
img2ms.de/bilder/Mapedit_0x3.jpg. My .args -file and the java
mkgmap-call : img2ms.de/bilder/mkgmap_args+bat.rar

thomas


Am 09.04.2017 um 17:12 schrieb Gerd Petermann:

Hi Thomas,

what do you mean with "it is the default style" ?
I don't see the line
place=village | landuse= residential [0x03 resolution 18]
in the default style that is shipped with r3890.
That uses 0x10 for landuse=residential and 0x03 for place=village
So, I assume it is a modified version of a default style which may contain
other changes as well. Maybe you use type 0x03 for more polygons or the 
ShapeMerger
merges them because they have no name?
If that doesn't help already please post a link to your style and options.

Gerd

Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Thomas 
Morgenstern <webmas...@img2ms.de>
Gesendet: Sonntag, 9. April 2017 14:52:25
An: Development list for mkgmap
Betreff: [mkgmap-dev] tag landuse=residential produced false areas

Hi all, i have testet a few mkgmap-release, included the new r-3890. But the 
wrong polygons comes with all releases. What i did.:
in stylefile polygons is the line : place=village | landuse= residential [0x03 
resolution 18].  It is the defaultstyle.
and in lines : boundary=administrative & admin_level=8 [0x1c resolution 18]  It 
is the defaultstyle.

I have looked in the OSM-source with JOSM and see , that all polygons 
landuse=residential are proper configured.

But the output of mkgmap create a malformed polygon 0x3 in some cases. The 0x3 
boundaries are not identical with OSM -sourcedata, but the are following the Line 
boundary=administrative  & admin_level=8 [0x1c ].
This is my testequipment:  Osm-sourcedata : 
www.img2ms.de/bilder/Neukirchen.osm.pbf<http://www.img2ms.de/bilder/Neukirchen.osm.pbf>
 . Have a look at id=13689494  landuse=forest ...
nearby is the line 51529384 boundary=administrative.
   after mkgamp has compiled the osm.pbf to 6706.img 
(www.img2ms.de/bilder/compiled_img.jpg<http://www.img2ms.de/bilder/compiled_img.jpg>
 and img2ms.de/bilder/6706.img) there is a big area 0x3 (residential) as layer 
and overlapping under the wood. the borders of this wrong 0x3 follow the line 0x1c.
To see this in a grafical way, i have wrote in oldfashion VB6 a small tool 
www.img2ms.de/bilder/Elemente<http://www.img2ms.de/bilder/Elemente> 
Selektieren.exe (for mp-files only). And open the created 6706_extract.mp using 
GPSMapedit.
the output in GPSMapedit shows me, that the outline of polygon 0x3 follows the line 
0x1c.( 
www.img2ms.de/bilder/6706_extract.mp<http://www.img2ms.de/bilder/6706_extract.mp>
 )
I assume, the stylefile has a bug ? or bug in mkgmap?
   What can i do ? Thomas


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev




___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev





___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] tag landuse=residential produced false areas

2017-04-09 Thread Thomas Morgenstern

I use for test the 'buildin-style'. But it makes no differenzes, if I 
use my own style. Own style is based on defaultstyle older relase 
mkgmap. Only small differenzes. But is is the 0x3 . See 
img2ms.de/bilder/Mapedit_0x3.jpg. My .args -file and the java 
mkgmap-call : img2ms.de/bilder/mkgmap_args+bat.rar


thomas


Am 09.04.2017 um 17:12 schrieb Gerd Petermann:

Hi Thomas,

what do you mean with "it is the default style" ?
I don't see the line
place=village | landuse= residential [0x03 resolution 18]
in the default style that is shipped with r3890.
That uses 0x10 for landuse=residential and 0x03 for place=village
So, I assume it is a modified version of a default style which may contain
other changes as well. Maybe you use type 0x03 for more polygons or the 
ShapeMerger
merges them because they have no name?
If that doesn't help already please post a link to your style and options.

Gerd

Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Thomas 
Morgenstern <webmas...@img2ms.de>
Gesendet: Sonntag, 9. April 2017 14:52:25
An: Development list for mkgmap
Betreff: [mkgmap-dev] tag landuse=residential produced false areas

Hi all, i have testet a few mkgmap-release, included the new r-3890. But the 
wrong polygons comes with all releases. What i did.:
in stylefile polygons is the line : place=village | landuse= residential [0x03 
resolution 18].  It is the defaultstyle.
and in lines : boundary=administrative & admin_level=8 [0x1c resolution 18]  It 
is the defaultstyle.

I have looked in the OSM-source with JOSM and see , that all polygons 
landuse=residential are proper configured.

But the output of mkgmap create a malformed polygon 0x3 in some cases. The 0x3 
boundaries are not identical with OSM -sourcedata, but the are following the Line 
boundary=administrative  & admin_level=8 [0x1c ].
This is my testequipment:  Osm-sourcedata : 
www.img2ms.de/bilder/Neukirchen.osm.pbf<http://www.img2ms.de/bilder/Neukirchen.osm.pbf>
 . Have a look at id=13689494  landuse=forest ...
nearby is the line 51529384 boundary=administrative.
  after mkgamp has compiled the osm.pbf to 6706.img 
(www.img2ms.de/bilder/compiled_img.jpg<http://www.img2ms.de/bilder/compiled_img.jpg>
 and img2ms.de/bilder/6706.img) there is a big area 0x3 (residential) as layer 
and overlapping under the wood. the borders of this wrong 0x3 follow the line 0x1c.
To see this in a grafical way, i have wrote in oldfashion VB6 a small tool 
www.img2ms.de/bilder/Elemente<http://www.img2ms.de/bilder/Elemente> 
Selektieren.exe (for mp-files only). And open the created 6706_extract.mp using 
GPSMapedit.
the output in GPSMapedit shows me, that the outline of polygon 0x3 follows the line 
0x1c.( 
www.img2ms.de/bilder/6706_extract.mp<http://www.img2ms.de/bilder/6706_extract.mp>
 )
I assume, the stylefile has a bug ? or bug in mkgmap?
  What can i do ? Thomas


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev





___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] tag landuse=residential produced false areas

2017-04-09 Thread Thomas Morgenstern



Hi all, i have testet a few mkgmap-release, included the new r-3890. But 
the wrong polygons comes with all releases. What i did.:
in stylefile polygons is the line : /place=village | landuse= 
residential [0x03 resolution 18]. / It is the defaultstyle.
and in lines : /boundary=administrative & admin_level=8 [0x1c resolution 
18] /It is the defaultstyle.

/
/I have looked in the OSM-source with JOSM and see , that all polygons 
landuse=residential are proper configured.


But the output of mkgmap create a malformed polygon 0x3 in some cases. 
The 0x3 boundaries are not identical with OSM -sourcedata, but the are 
following the Line boundary=administrative  & admin_level=8 [0x1c ].
This is my testequipment:  Osm-sourcedata : 
www.img2ms.de/bilder/Neukirchen.osm.pbf . Have a look at id=13689494  
landuse=forest ...

nearby is the line 51529384 boundary=administrative.
 after mkgamp has compiled the osm.pbf to 6706.img 
(www.img2ms.de/bilder/compiled_img.jpg and 
img2ms.de/bilder/6706.img) there is a big area 0x3 (residential) as 
layer and overlapping under the wood. the borders of this wrong 0x3 
follow the line 0x1c.
To see this in a grafical way, i have wrote in oldfashion VB6 a small 
tool www.img2ms.de/bilder/Elemente Selektieren.exe (for mp-files only). 
And open the created 6706_extract.mp using GPSMapedit.
the output in GPSMapedit shows me, that the outline of polygon 0x3 
follows the line 0x1c.( www.img2ms.de/bilder/6706_extract.mp )

I assume, the stylefile has a bug ? or bug in mkgmap?
 What can i do ? Thomas


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] new option shutdown_pc ?

2017-04-02 Thread Thomas Morgenstern


Hi all,

maybee it is a good feature, to have the ability to shutdown the 
computer, after splitter and/or mkgmap is ready . But only , if 
splitter/mkgmap not ended with a error. I will read the error.


something like this : new option - shutdown_pcdefault=false

If shutdown_pc=true and splitter/mkgmap ended succesfull without error then

shutdown /s

else  do nothing
endif
 splitter and mkgmap have often a long runtime till late night
regards thomas
_

mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev





___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] splitter and josm problem


Thanks, i will fix the overlapping tomorrow and test again...

thomas


Am 01.04.2017 um 17:02 schrieb Gerd Petermann:

Hi Thomas,

I've changed splitter to print better information about the overlapping areas, 
please try r583,
it is now also able to parse the file http://img2ms.de/bilder/areasEuropa.list
With r583 I see these messages for that file:
...
Waring: The areas given in --split-file are overlapping.
overlapping areas 5002 and 5751 : (2848768,-1536000 to 3788800,-868352) 
and (2482176,-1536000 to 3149533,-868352)
overlapping areas 5353 and 5786 : (2125824,671744 to 2125825,727040) 
and (2125824,671744 to 2164736,727040)
overlapping areas 5657 and 5658 : (2478080,671744 to 2544552,727074) 
and (2428928,727040 to 2490368,819200)
overlapping areas 5657 and 5660 : (2478080,671744 to 2544552,727074) 
and (2490368,727040 to 2584576,858112)
overlapping areas 5660 and 5756 : (2490368,727040 to 2584576,858112) 
and (2544552,671744 to 2584576,727074)
Overlaping tiles: [5002, 5353, 5657, 5658, 5660, 5751, 
5756, 5786]

(the first one is a huge overlap)
It doesn't report 5707, so I assume that you are looking at old data in 
that case.

Besides that overlaps are not forbidden by splitter, you just have to make sure 
that you don't put overlapping areas
into the same gmapsupp as that will cause routing problems.

Gerd

Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Gerd 
Petermann <gpetermann_muenc...@hotmail.com>
Gesendet: Samstag, 1. April 2017 13:39:46
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] splitter and josm problem

Hi Thomas,

splitter r580 cannot read this file without a few small changes (blanks 
added/removed).
After these changes it complains that there are overlaps.
Seems you are using a different file or a different program.

Gerd

Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Thomas 
Morgenstern <webmas...@img2ms.de>
Gesendet: Samstag, 1. April 2017 13:02:53
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] splitter and josm problem

I have controled my areasEuropa.list (download
:img2ms.de/bilder/areasEuropa.list). I found no overlapping around the
5707. All neighbours 5705; 5709; 5728; 5729;
5708 ;5706; 5705) have identical borders without any
overlapping. Or shout it have a overlapping ? how many Garmin-units ?

thomas



Am 01.04.2017 um 12:25 schrieb Gerd Petermann:

Hi Thomas,

the problem was caused by your manually changed split file which contained 
small overlaps. Do you still use that one?
I think I fixed the problems with that one in r440.
Or maybe you created a new one which causes new problems?

Gerd


Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Thomas 
Morgenstern <webmas...@img2ms.de>
Gesendet: Samstag, 1. April 2017 12:08:03
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] splitter and josm problem

Hi Gerd, the old problem exists till now. I splitt europa-latest-osm.pbf using splitter 
r-580. But splitterr-580  do not proper splitt the multipolygon ("Schloßteich", 
3 Elemente) [Kennung: 59.766] . The mp has tags: name=Schloßteich; natural=water, 
type=multipolygon. This mp has element Rolle=outer; 23387723 (86 Punkte) [Kennung : 
23.387.723]. The error ist : all 86 nodes has no tags , but it should have the tags 
natural=water and name= Schloßteich from the multipolygon. See picture : 
img2ms.de/bilder/wrongsplit.jpg

split.list for this file : 5707: 2367488, 593920 to 2390016, 634880

maybee you can have a look at that ? center of map is at lat 50.8419209  lon 
12.914752

thomas

Am 13.11.2016 um 12:19 schrieb Thomas Morgenstern:
Hi gerd thanks for your tests. I am waiting for your solution...

Thomas


Am 13.11.2016 um 12:03 schrieb Gerd Petermann:
Hi Thomas,

I can open the big file in JOSM with JRE option -Xmx6G.
Besides that the mp relation is 59766, the id 233877233 belongs to the outer
way.
And yes, splitter seems to drop the relation in the large file. I'll try to
find out
why.

Gerd

Thomas Morgenstern wrote
Hi at all, i am using splitter r429 and mkgmap r3695. Normally it works
perfekt. But now  it gives me a problem with multipolygons. I downloaded
and splitt latest-europe.osm.pbf from geofabrik, ---> splitt it with
splitter r429 for testing to 2 tiles, a big tile 8707.osm.pbf and a
small tile 8011.osm.pbf. The small tile is inner the big tile. Both
tiles contains the area with the multipolgon ID 23387723. Then compile
it for testing  separatly with mkgmap r3695. If the input is the small
tile 8011.osm.pbf, it compile the img correct, *spezially the
multipolygon ID 233877233 (tags : name=Schloßteich; natural=water;
type=multipolygon) is present as 0x3c in

Re: [mkgmap-dev] splitter and josm problem

Hi, I have maked a new split with splitter r-440. And splitter r-440 
worked without error. Espacially all nodes of multipolygons have the 
tag=value like as expected.


thomas
Am 01.04.2017 um 13:39 schrieb Gerd Petermann:

Hi Thomas,

splitter r580 cannot read this file without a few small changes (blanks 
added/removed).
After these changes it complains that there are overlaps.
Seems you are using a different file or a different program.

Gerd

Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Thomas 
Morgenstern <webmas...@img2ms.de>
Gesendet: Samstag, 1. April 2017 13:02:53
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] splitter and josm problem

I have controled my areasEuropa.list (download
:img2ms.de/bilder/areasEuropa.list). I found no overlapping around the
5707. All neighbours 5705; 5709; 5728; 5729;
5708 ;5706; 5705) have identical borders without any
overlapping. Or shout it have a overlapping ? how many Garmin-units ?

thomas



Am 01.04.2017 um 12:25 schrieb Gerd Petermann:

Hi Thomas,

the problem was caused by your manually changed split file which contained 
small overlaps. Do you still use that one?
I think I fixed the problems with that one in r440.
Or maybe you created a new one which causes new problems?

Gerd


Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Thomas 
Morgenstern <webmas...@img2ms.de>
Gesendet: Samstag, 1. April 2017 12:08:03
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] splitter and josm problem

Hi Gerd, the old problem exists till now. I splitt europa-latest-osm.pbf using splitter 
r-580. But splitterr-580  do not proper splitt the multipolygon ("Schloßteich", 
3 Elemente) [Kennung: 59.766] . The mp has tags: name=Schloßteich; natural=water, 
type=multipolygon. This mp has element Rolle=outer; 23387723 (86 Punkte) [Kennung : 
23.387.723]. The error ist : all 86 nodes has no tags , but it should have the tags 
natural=water and name= Schloßteich from the multipolygon. See picture : 
img2ms.de/bilder/wrongsplit.jpg

split.list for this file : 5707: 2367488, 593920 to 2390016, 634880

maybee you can have a look at that ? center of map is at lat 50.8419209  lon 
12.914752

thomas

Am 13.11.2016 um 12:19 schrieb Thomas Morgenstern:
Hi gerd thanks for your tests. I am waiting for your solution...

Thomas


Am 13.11.2016 um 12:03 schrieb Gerd Petermann:
Hi Thomas,

I can open the big file in JOSM with JRE option -Xmx6G.
Besides that the mp relation is 59766, the id 233877233 belongs to the outer
way.
And yes, splitter seems to drop the relation in the large file. I'll try to
find out
why.

Gerd

Thomas Morgenstern wrote
Hi at all, i am using splitter r429 and mkgmap r3695. Normally it works
perfekt. But now  it gives me a problem with multipolygons. I downloaded
and splitt latest-europe.osm.pbf from geofabrik, ---> splitt it with
splitter r429 for testing to 2 tiles, a big tile 8707.osm.pbf and a
small tile 8011.osm.pbf. The small tile is inner the big tile. Both
tiles contains the area with the multipolgon ID 23387723. Then compile
it for testing  separatly with mkgmap r3695. If the input is the small
tile 8011.osm.pbf, it compile the img correct, *spezially the
multipolygon ID 233877233 (tags : name=Schloßteich; natural=water;
type=multipolygon) is present as 0x3c in resulting img. *See
img2ms.de/bilder/multipolygon-good.jpg. It is the blue lake name
='Schlossteich'

If i compile the big 8707.osm.pbf, the resulting img has not this
area . *It seems for me, as if the multipolygon ID 23387723 is ignored*.
See img2ms.de/bilder/multipolygon-wrong.jpg. In both cases i use ident
style. It makes no different, if the default style or my own style is
used.

I tried to found out, if the splitter produce the multipolygon in the
big 8707.osm.pbf, but JOSM v11223  can not load the big (~25MB)
8707.osm.pbf. : JOSM --> open file 8707.osm.pbf--> 'Lese
OSM-Daten...'--> and a few minutes later the MessageBox close, but the
osm.pbf shows not on the screen. Has the JOSM-plugin 'pbf: Version
32865' any limitations ? My PC has 6 GB RAM, 64 bit Windows10.
Any hints are welcome. Download for both 8*.osm.pbf :
img2ms.de/bilder/8000osm-pbf.rar:  Splittfile for splitter r429   :
img2ms.de/bilder/areas.list
regards Thomas


___
mkgmap-dev mailing list
mkgmap-dev@.org<mailto:mkgmap-dev@.org>
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev




--
View this message in context: 
http://gis.19327.n8.nabble.com/max-nodes-in-splitter-tp5885774p5885820.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.u

Re: [mkgmap-dev] splitter and josm problem

I have controled my areasEuropa.list (download 
:img2ms.de/bilder/areasEuropa.list). I found no overlapping around the 
5707. All neighbours 5705; 5709; 5728; 5729; 
5708 ;5706; 5705) have identical borders without any 
overlapping. Or shout it have a overlapping ? how many Garmin-units ?


thomas



Am 01.04.2017 um 12:25 schrieb Gerd Petermann:

Hi Thomas,

the problem was caused by your manually changed split file which contained 
small overlaps. Do you still use that one?
I think I fixed the problems with that one in r440.
Or maybe you created a new one which causes new problems?

Gerd


Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Thomas 
Morgenstern <webmas...@img2ms.de>
Gesendet: Samstag, 1. April 2017 12:08:03
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] splitter and josm problem

Hi Gerd, the old problem exists till now. I splitt europa-latest-osm.pbf using splitter 
r-580. But splitterr-580  do not proper splitt the multipolygon ("Schloßteich", 
3 Elemente) [Kennung: 59.766] . The mp has tags: name=Schloßteich; natural=water, 
type=multipolygon. This mp has element Rolle=outer; 23387723 (86 Punkte) [Kennung : 
23.387.723]. The error ist : all 86 nodes has no tags , but it should have the tags 
natural=water and name= Schloßteich from the multipolygon. See picture : 
img2ms.de/bilder/wrongsplit.jpg

split.list for this file : 5707: 2367488, 593920 to 2390016, 634880

maybee you can have a look at that ? center of map is at lat 50.8419209  lon 
12.914752

thomas

Am 13.11.2016 um 12:19 schrieb Thomas Morgenstern:
Hi gerd thanks for your tests. I am waiting for your solution...

Thomas


Am 13.11.2016 um 12:03 schrieb Gerd Petermann:
Hi Thomas,

I can open the big file in JOSM with JRE option -Xmx6G.
Besides that the mp relation is 59766, the id 233877233 belongs to the outer
way.
And yes, splitter seems to drop the relation in the large file. I'll try to
find out
why.

Gerd

Thomas Morgenstern wrote
Hi at all, i am using splitter r429 and mkgmap r3695. Normally it works
perfekt. But now  it gives me a problem with multipolygons. I downloaded
and splitt latest-europe.osm.pbf from geofabrik, ---> splitt it with
splitter r429 for testing to 2 tiles, a big tile 8707.osm.pbf and a
small tile 8011.osm.pbf. The small tile is inner the big tile. Both
tiles contains the area with the multipolgon ID 23387723. Then compile
it for testing  separatly with mkgmap r3695. If the input is the small
tile 8011.osm.pbf, it compile the img correct, *spezially the
multipolygon ID 233877233 (tags : name=Schloßteich; natural=water;
type=multipolygon) is present as 0x3c in resulting img. *See
img2ms.de/bilder/multipolygon-good.jpg. It is the blue lake name
='Schlossteich'

If i compile the big 8707.osm.pbf, the resulting img has not this
area . *It seems for me, as if the multipolygon ID 23387723 is ignored*.
See img2ms.de/bilder/multipolygon-wrong.jpg. In both cases i use ident
style. It makes no different, if the default style or my own style is
used.

I tried to found out, if the splitter produce the multipolygon in the
big 8707.osm.pbf, but JOSM v11223  can not load the big (~25MB)
8707.osm.pbf. : JOSM --> open file 8707.osm.pbf--> 'Lese
OSM-Daten...'--> and a few minutes later the MessageBox close, but the
osm.pbf shows not on the screen. Has the JOSM-plugin 'pbf: Version
32865' any limitations ? My PC has 6 GB RAM, 64 bit Windows10.
Any hints are welcome. Download for both 8*.osm.pbf :
img2ms.de/bilder/8000osm-pbf.rar:  Splittfile for splitter r429   :
img2ms.de/bilder/areas.list
regards Thomas


___
mkgmap-dev mailing list
mkgmap-dev@.org<mailto:mkgmap-dev@.org>
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev




--
View this message in context: 
http://gis.19327.n8.nabble.com/max-nodes-in-splitter-tp5885774p5885820.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev





___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] splitter and josm problem

Hi Gerd, the old problem exists till now. I splitt europa-latest-osm.pbf 
using splitter r-580. But splitterr-580  do not proper splitt the 
multipolygon /("Schloßteich", 3 Elemente) [Kennung: 59.766]/ . The mp 
has tags: /name=Schloßteich; natural=water, type=multipolygon/. This mp 
has element/Rolle=outer; 23387723 (86 Punkte) [Kennung : 23.387.723]/. 
The error ist : all 86 nodes has no tags , but it should have the tags 
natural=water and name= Schloßteich from the multipolygon. See picture : 
img2ms.de/bilder/wrongsplit.jpg


split.list for this file : 5707: 2367488, 593920 to 2390016, 634880

maybee you can have a look at that ? center of map is at lat 50.8419209  
lon 12.914752


thomas


Am 13.11.2016 um 12:19 schrieb Thomas Morgenstern:

Hi gerd thanks for your tests. I am waiting for your solution...

Thomas


Am 13.11.2016 um 12:03 schrieb Gerd Petermann:

Hi Thomas,

I can open the big file in JOSM with JRE option -Xmx6G.
Besides that the mp relation is 59766, the id 233877233 belongs to 
the outer

way.
And yes, splitter seems to drop the relation in the large file. I'll 
try to

find out
why.

Gerd

Thomas Morgenstern wrote

Hi at all, i am using splitter r429 and mkgmap r3695. Normally it works
perfekt. But now  it gives me a problem with multipolygons. I 
downloaded

and splitt latest-europe.osm.pbf from geofabrik, ---> splitt it with
splitter r429 for testing to 2 tiles, a big tile 8707.osm.pbf and a
small tile 8011.osm.pbf. The small tile is inner the big tile. Both
tiles contains the area with the multipolgon ID 23387723. Then compile
it for testing  separatly with mkgmap r3695. If the input is the small
tile 8011.osm.pbf, it compile the img correct, *spezially the
multipolygon ID 233877233 (tags : name=Schloßteich; natural=water;
type=multipolygon) is present as 0x3c in resulting img. *See
img2ms.de/bilder/multipolygon-good.jpg. It is the blue lake name
='Schlossteich'

If i compile the big 8707.osm.pbf, the resulting img has not this
area . *It seems for me, as if the multipolygon ID 23387723 is 
ignored*.

See img2ms.de/bilder/multipolygon-wrong.jpg. In both cases i use ident
style. It makes no different, if the default style or my own style is
used.

I tried to found out, if the splitter produce the multipolygon in the
big 8707.osm.pbf, but JOSM v11223  can not load the big (~25MB)
8707.osm.pbf. : JOSM --> open file 8707.osm.pbf--> 'Lese
OSM-Daten...'--> and a few minutes later the MessageBox close, but the
osm.pbf shows not on the screen. Has the JOSM-plugin 'pbf: Version
32865' any limitations ? My PC has 6 GB RAM, 64 bit Windows10.
Any hints are welcome. Download for both 8*.osm.pbf :
img2ms.de/bilder/8000osm-pbf.rar:  Splittfile for splitter r429   :
img2ms.de/bilder/areas.list
regards Thomas


___
mkgmap-dev mailing list
mkgmap-dev@.org
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev





--
View this message in context: 
http://gis.19327.n8.nabble.com/max-nodes-in-splitter-tp5885774p5885820.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 mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] [Partch v2] reduce peak memory usage for global index

2017-03-30 Thread Thomas Morgenstern

Hi Gerd, Thanks for your work. Now i have  created the whole Europa -mdr 
with my limited 10 GB RAM and option x-split-name-index.


thomas


Am 30.03.2017 um 21:54 schrieb Thomas Morgenstern:


Sorry for my mail, i forgot to use the /lib- folder

thomas


Am 30.03.2017 um 18:12 schrieb Gerd Petermann:

Hi all,

attached is an improved version which also implements the new option 
--x-mdr7-excl.
It also has some debug messages which will print Strings which appear very 
often, something like this:
Street index (Mdr7) 'Service' : 11.09%
Street index (Mdr7) 'Straße' : 7.09%
Street index (Mdr7) 'CyW' : 1.66%
Street index (Mdr7) 'Pth' : 3.81%
Street index (Mdr7) 'Weg' : 1.13%
Street index (Mdr7) 'Foot' : 9.17%
Street index (Mdr7) 'Steps' : 1.58%
(sample from Arndts "Speichenkarte" style which adds osm tags to the street 
name.

The idea is to use Option --x-mdr7-excl="Service,Straße,Foot,Pth" to exclude 
some strings from the global index.
This will esp. reduce heap memory usage , but it will also reduce the size of 
the index.

The search will still find roads like "Abc Straße" when you search for abc, but 
it will not display all the streets containing
Straße when you just type Straße. It should also still display "Straße des 17. 
Juni" if you type
"Straße des" or just "Juni" in case you use --x-split-name-index.

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

Gerd






___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev




___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] [Partch v2] reduce peak memory usage for global index

2017-03-30 Thread Thomas Morgenstern


Sorry for my mail, i forgot to use the /lib- folder

thomas


Am 30.03.2017 um 18:12 schrieb Gerd Petermann:

Hi all,

attached is an improved version which also implements the new option 
--x-mdr7-excl.
It also has some debug messages which will print Strings which appear very 
often, something like this:
Street index (Mdr7) 'Service' : 11.09%
Street index (Mdr7) 'Straße' : 7.09%
Street index (Mdr7) 'CyW' : 1.66%
Street index (Mdr7) 'Pth' : 3.81%
Street index (Mdr7) 'Weg' : 1.13%
Street index (Mdr7) 'Foot' : 9.17%
Street index (Mdr7) 'Steps' : 1.58%
(sample from Arndts "Speichenkarte" style which adds osm tags to the street 
name.

The idea is to use Option --x-mdr7-excl="Service,Straße,Foot,Pth" to exclude 
some strings from the global index.
This will esp. reduce heap memory usage , but it will also reduce the size of 
the index.

The search will still find roads like "Abc Straße" when you search for abc, but 
it will not display all the streets containing
Straße when you just type Straße. It should also still display "Straße des 17. 
Juni" if you type
"Straße des" or just "Juni" in case you use --x-split-name-index.

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

Gerd






___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] [Partch v2] reduce peak memory usage for global index

2017-03-30 Thread Thomas Morgenstern

Hi Gerd, something goes wrong with the compiled mkgmap.jar. i have 
downloaded it . but it gives me a error.  Mybee the error is reladed to 
the compilation ?  See screenshot :





thomas

Am 30.03.2017 um 18:12 schrieb Gerd Petermann:

Hi all,

attached is an improved version which also implements the new option 
--x-mdr7-excl.
It also has some debug messages which will print Strings which appear very 
often, something like this:
Street index (Mdr7) 'Service' : 11.09%
Street index (Mdr7) 'Straße' : 7.09%
Street index (Mdr7) 'CyW' : 1.66%
Street index (Mdr7) 'Pth' : 3.81%
Street index (Mdr7) 'Weg' : 1.13%
Street index (Mdr7) 'Foot' : 9.17%
Street index (Mdr7) 'Steps' : 1.58%
(sample from Arndts "Speichenkarte" style which adds osm tags to the street 
name.

The idea is to use Option --x-mdr7-excl="Service,Straße,Foot,Pth" to exclude 
some strings from the global index.
This will esp. reduce heap memory usage , but it will also reduce the size of 
the index.

The search will still find roads like "Abc Straße" when you search for abc, but 
it will not display all the streets containing
Straße when you just type Straße. It should also still display "Straße des 17. 
Juni" if you type
"Straße des" or just "Juni" in case you use --x-split-name-index.

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

Gerd






___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] RAM and mdr Europa ?

2017-03-29 Thread Thomas Morgenstern

I agree, it is not a really solution. But it is the only thing i can do
with my 10 GB RAM. I will bee happy, if you found a algorythmus, which
can use -x-split-name-index and works with my limited RAM, and avoids
the OutOfMemory java heapspace error. By the way: With a smaller
inputarea (Easteuropa or Skandinavia), 10 GB RAM is enough to use
x-split-name-index, no error occurs.

regards thomas

Am 29.03.2017 um 18:08 schrieb Gerd Petermann:

Hi Thomas,

I already understood that but I don't call this a solution ;-)
My understanding is that the option is really helpfull in countries like Spain
were many street names start with Rua.

Gerd

Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Thomas
Morgenstern <webmas...@img2ms.de>
Gesendet: Mittwoch, 29. März 2017 17:21:01
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] RAM and mdr Europa ?

Hi Gerd,

I have solved the problem. i do not longer use -x-split-name-index, but only
-index. This decrease the RAM and my java heap space is great enough or that
option.

Rgeards Thomas

Am 29.03.2017 um 09:27 schrieb Gerd Petermann:

Hi Thomas,

maybe it helps:
The problem occured while sorting the index entries for streets names. With
option --x-split-name-index
you have one entry for each word in the street name. I think this option can
easily dup the number of entries and
aso the required memory for the entries is higher.

We've once tried to fix this partially with Mdr7.patch but it turned out to
produce wrong entries in the index.
I'll try again to find a better solution.

In the mean time you may check how your style handles street names. Maybe you
often use addlabel or you
add words to the road names ? I've seen styles which add a default name for
each unnamed object.

Gerd

Von: mkgmap-dev
<mkgmap-dev-boun...@lists.mkgmap.org.uk><mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk> im
Auftrag von Thomas Morgenstern <webmas...@img2ms.de><mailto:webmas...@img2ms.de>
Gesendet: Freitag, 24. März 2017 17:07:22
An: Development list for mkgmap
Betreff: [mkgmap-dev] RAM and mdr Europa ?

Hi, I have a W10, 64 bit machine and 10 GB RAM. Since a few months i can not generate the
mdr-file for Europa from
www.Download.Geofabrik.de<http://www.Download.Geofabrik.de><http://www.Download.Geofabrik.de><http://www.Download.Geofabrik.de>
In a first run i generate only all the maptiles. No Problem. in a second i will generate the
overview, tdb and mdr. I start java -Xmx9800m -XX:-UseGCOverheadLimit jar mkgmap.jar
code-page=1252 -family-id=1901 -x-split-name-index -index D:\Karten\Europa\*.img.

and get the error.

[cid:part1.6A605C7E.D89F4F60@img2ms.de]

with mkgmap-r3864 it get the same error.

How many RAM must i have for Europa complete ?. In august 2016 it was possible
to create the mdr with 6 GB RAM. But the filesize is growm ...

thomas

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] RAM and mdr Europa ?

2017-03-29 Thread Thomas Morgenstern


Hi Gerd,

I have solved the problem. i do not longer  use -x-split-name-index, but 
only -index. This decrease the RAM and my java heap space is great 
enough or that option.


Rgeards Thomas



Am 29.03.2017 um 09:27 schrieb Gerd Petermann:

Hi Thomas,

maybe it helps:
The problem occured while sorting the index entries for streets names. With 
option  --x-split-name-index
you have one entry for each word in the street name. I think this option can 
easily dup the number of entries and
aso the required memory for the entries is higher.

We've once tried to fix this partially with Mdr7.patch but it turned out to 
produce wrong entries in the index.
I'll try again to find a better solution.

In the mean time you may check how your style handles street names. Maybe you 
often use addlabel or you
add words to the road names ? I've seen styles which add a default name for 
each unnamed object.

Gerd

Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Thomas 
Morgenstern <webmas...@img2ms.de>
Gesendet: Freitag, 24. März 2017 17:07:22
An: Development list for mkgmap
Betreff: [mkgmap-dev] RAM and mdr Europa ?

Hi, I have a W10, 64 bit machine  and 10 GB RAM. Since  a few months i can not 
generate the mdr-file for Europa from 
www.Download.Geofabrik.de<http://www.Download.Geofabrik.de> In a first run i 
generate only all the maptiles. No Problem. in a second i will generate the overview, 
tdb and mdr. I start java -Xmx9800m -XX:-UseGCOverheadLimit jar mkgmap.jar 
code-page=1252 -family-id=1901 -x-split-name-index -index  D:\Karten\Europa\*.img.

and get the error.

[cid:part1.6A605C7E.D89F4F60@img2ms.de]

with mkgmap-r3864 it get the same error.

How many RAM must i have for Europa complete ?. In august 2016 it was possible 
to create the mdr with 6 GB RAM. But the filesize is growm ...

thomas





___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] RAM and mdr Europa ?

2017-03-24 Thread Thomas Morgenstern

Hi, I found a solution for me:  Now i use only the option -index and  
removed the option -x-splitt-name-index.


in this configuration is 9800 MB RAM enough.


thomas


Am 24.03.2017 um 19:18 schrieb Bernhard Hiller:

Hi Thomas,
since you have 10 GB of RAM for all of the tasks running on your 
computer, I doubt that 9800 MB for Java/mkgmap is actually feasable. 
With Win 7, I put away some 1200-1500 MB for the operating system.
If a process gets more memory, swapping to disk will occur, which is a 
slow process, and the garbage collection might fail in such situations 
(well, not sure for Java, but I saw such situations with .Net).
I do not know how much RAM will be used up by WIN 10, but I think 
replacing "/-Xmx9800m/" by "/-Xmx8500m/" could be worth a test; you 
could also (additionally) set the initial heap size to that amount 
("/-Xms8500m/") .

Bernhard

Am 24.03.2017 um 17:07 schrieb Thomas Morgenstern:


Hi, I have a W10, 64 bit machine  and 10 GB RAM. Since  a few months 
i can not generate the mdr-file for Europa from 
www.Download.Geofabrik.de In a first run i generate only all the 
maptiles. No Problem. in a second i will generate the overview, tdb 
and mdr. I start j/ava -Xmx9800m -XX:-UseGCOverheadLimit jar 
mkgmap.jar code-page=1252 -family-id=1901 -x-split-name-index -index 
D:\Karten\Europa\*.img./


and get the error.


with mkgmap-r3864 it get the same error.

How many RAM must i have for Europa complete ?. In august 2016 it was 
possible to create the mdr with 6 GB RAM. But the filesize is growm ...


thomas





mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Stylefile : Rule for delete all proposed features ?

okay, die allgemeine Regel ist nicht erforderlich. es reicht, wenn ich 
die Regel für konkrete Objecte anwende. Und konkret  bin ich bisher nur 
auf building und amenity=parking gestoßen.


mfg thomas


Am 12.03.2017 um 10:30 schrieb Gerd Petermann:

Hallo Thomas,

das macht aus meiner Sicht keinen Sinn. Nimm mein Beispiel
http://www.openstreetmap.org/way/58422569

Das Gebäude existiert, du willst es aber nicht rendern, weil jemand vorhat, 
darin einen Baumarkt zu eröffnen.
Ich würde verstehen, wenn Du das tag shop=proposed automatisch löschen willst, 
aber warum gleich das ganze Objekt?

Gerd


Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Thomas 
Morgenstern <webmas...@img2ms.de>
Gesendet: Sonntag, 12. März 2017 10:23:55
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Stylefile : Rule for delete all proposed features ?

Hallo, ich habe polygone gefunden mit dem tag =proposed. Und
diese will ich nicht rendern. Ich will eine allgemeine stylerule in mein
Stylefile einbauen, wo alle objecte mit =proposed gelöscht
bzw. nicht gerendert werden. Mit einzelnen lines ist das kein Problem .
z.B. highway=proposed {delete highway}. Da ich nicht weis, welche
Objecte im osm.pbf den tag proposed haben, will ich vorbeugend alle
objecte = proposed löschen bzw. nicht rendern. Aber *=proposed {delete *
} wäre sicherlich falsch !

Thomas


Am 12.03.2017 um 10:10 schrieb Gerd Petermann:

Hi Thomas,

I still don't understand how that would work. My first example probably wasn't 
good because
the tag key sidewalk:both is never evaluated with the default style.

Consider also this way http://www.openstreetmap.org/way/323342627
with
highway=residential
surface=proposed
My understanding is that the highway exists and is usable but the surface tag 
is more or less useless.

or
way http://www.openstreetmap.org/way/58422569
with
building = retail
shop = proposed
My understanding is that the building exists and someone plans to open a shop.

Now, what should happen with this new function in "first line of Style"?

I assume you don't want to remove the object, only the tags with the value 
"proposed". Is that right?
If so, this could be done while reading the OSM data.

Gerd



Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Thomas 
Morgenstern <webmas...@img2ms.de>
Gesendet: Sonntag, 12. März 2017 09:44:34
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Stylefile : Rule for delete all proposed features ?

I want not drop before styleproccessing. For example : the object 346
400 898 has the tag 'building=proposed' . I want drop the whole objekt.
Near by are another objects (amenity=parking ; parking=proposed). The
obcekt is in tenerife, near Adeje. I want not render generelly all
objects, which are proposed. Because the do not realy exists today. I
need a generelly rule for my own style, to drop all polygon-, POI- and
line-objects = proposed. May bee in the first line of Style ?

thomas


Am 12.03.2017 um 09:17 schrieb Gerd Petermann:

Hi Thomas,

that is not possible with the current version.
Not sure what you want to achive.
If a way has the tags
highway=residential,sidewalk:both=proposed,name=A-road
do you want to drop the single tag sidewalk:both=proposed before style 
processing
or do you want to drop the complete way ?

Gerd

Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Thomas 
Morgenstern <webmas...@img2ms.de>
Gesendet: Sonntag, 12. März 2017 09:10:14
An: Development list for mkgmap
Betreff: [mkgmap-dev] Stylefile : Rule for delete all proposed features ?

Hi , can someone give me a hint for a proper rule in stylefile . I want
delete all objects (line, polygon, poi) which have tag =
proposed.  I do not want to write individuall rules for each object ;
example : parking=propose {delete parking} separate.
thanks thomas

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev




___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev




___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev





__

Re: [mkgmap-dev] Stylefile : Rule for delete all proposed features ?

Hallo, ich habe polygone gefunden mit dem tag =proposed. Und 
diese will ich nicht rendern. Ich will eine allgemeine stylerule in mein 
Stylefile einbauen, wo alle objecte mit =proposed gelöscht 
bzw. nicht gerendert werden. Mit einzelnen lines ist das kein Problem . 
z.B. highway=proposed {delete highway}. Da ich nicht weis, welche 
Objecte im osm.pbf den tag proposed haben, will ich vorbeugend alle 
objecte = proposed löschen bzw. nicht rendern. Aber *=proposed {delete * 
} wäre sicherlich falsch !


Thomas


Am 12.03.2017 um 10:10 schrieb Gerd Petermann:

Hi Thomas,

I still don't understand how that would work. My first example probably wasn't 
good because
the tag key sidewalk:both is never evaluated with the default style.

Consider also this way http://www.openstreetmap.org/way/323342627
with
highway=residential
surface=proposed
My understanding is that the highway exists and is usable but the surface tag 
is more or less useless.

or
way http://www.openstreetmap.org/way/58422569
with
building = retail
shop = proposed
My understanding is that the building exists and someone plans to open a shop.

Now, what should happen with this new function in "first line of Style"?

I assume you don't want to remove the object, only the tags with the value 
"proposed". Is that right?
If so, this could be done while reading the OSM data.

Gerd



Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Thomas 
Morgenstern <webmas...@img2ms.de>
Gesendet: Sonntag, 12. März 2017 09:44:34
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Stylefile : Rule for delete all proposed features ?

I want not drop before styleproccessing. For example : the object 346
400 898 has the tag 'building=proposed' . I want drop the whole objekt.
Near by are another objects (amenity=parking ; parking=proposed). The
obcekt is in tenerife, near Adeje. I want not render generelly all
objects, which are proposed. Because the do not realy exists today. I
need a generelly rule for my own style, to drop all polygon-, POI- and
line-objects = proposed. May bee in the first line of Style ?

thomas


Am 12.03.2017 um 09:17 schrieb Gerd Petermann:

Hi Thomas,

that is not possible with the current version.
Not sure what you want to achive.
If a way has the tags
highway=residential,sidewalk:both=proposed,name=A-road
do you want to drop the single tag sidewalk:both=proposed before style 
processing
or do you want to drop the complete way ?

Gerd

Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Thomas 
Morgenstern <webmas...@img2ms.de>
Gesendet: Sonntag, 12. März 2017 09:10:14
An: Development list for mkgmap
Betreff: [mkgmap-dev] Stylefile : Rule for delete all proposed features ?

Hi , can someone give me a hint for a proper rule in stylefile . I want
delete all objects (line, polygon, poi) which have tag =
proposed.  I do not want to write individuall rules for each object ;
example : parking=propose {delete parking} separate.
thanks thomas

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev




___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev





___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Stylefile : Rule for delete all proposed features ?

I want not drop before styleproccessing. For example : the object 346 
400 898 has the tag 'building=proposed' . I want drop the whole objekt. 
Near by are another objects (amenity=parking ; parking=proposed). The 
obcekt is in tenerife, near Adeje. I want not render generelly all 
objects, which are proposed. Because the do not realy exists today. I 
need a generelly rule for my own style, to drop all polygon-, POI- and 
line-objects = proposed. May bee in the first line of Style ?


thomas


Am 12.03.2017 um 09:17 schrieb Gerd Petermann:

Hi Thomas,

that is not possible with the current version.
Not sure what you want to achive.
If a way has the tags
highway=residential,sidewalk:both=proposed,name=A-road
do you want to drop the single tag sidewalk:both=proposed before style 
processing
or do you want to drop the complete way ?

Gerd

Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Thomas 
Morgenstern <webmas...@img2ms.de>
Gesendet: Sonntag, 12. März 2017 09:10:14
An: Development list for mkgmap
Betreff: [mkgmap-dev] Stylefile : Rule for delete all proposed features ?

Hi , can someone give me a hint for a proper rule in stylefile . I want
delete all objects (line, polygon, poi) which have tag =
proposed.  I do not want to write individuall rules for each object ;
example : parking=propose {delete parking} separate.
thanks thomas

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev





___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] Stylefile : Rule for delete all proposed features ?

Hi , can someone give me a hint for a proper rule in stylefile . I want 
delete all objects (line, polygon, poi) which have tag = 
proposed.  I do not want to write individuall rules for each object ;  
example : parking=propose {delete parking} separate.

thanks thomas

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Feature Request: mkgmap able to create gmap archive (BaseCamp)

2016-12-04 Thread Thomas Morgenstern

In tdb file exists such block 0x54. And it must have 20 byte. in your 
example i see only 18 byte ? Block 0x54 contains  CRC sum of the tdb 
file ( without the 0x54 block) the crc is stored in byte 0x54+5, 
0x54+12, 0x54+15, 0x54+20.


0x54+5=Int(nCRCSum / 16777216)  'vByteD

0x54+12=Int((nCRCSum - vByteD * 16777216) / 65536) ' vByteC

0x54+15=Int((nCRCSum - vByteD * 16777216 - vByteC * 65536) / 256)'vByteB

0x54+20=Int(nCRCSum - vByteD * 16777216 - vByteC * 65536 - vByteB * 256)

all other bytes=0

thomas


Am 04.12.2016 um 10:40 schrieb Patrik Brunner:

Steve,

I've downloaded both versions of gmapi-builder.py, the one from 
bitbucket and the one from the mkgmap code base. They're bit different 
and I couldn't find a version number when checking quickly, but only 
the mkgmap version supports -i for mdx files. Therefore I continued 
with the mkgmap codebase version only.


The tool runs through and creates a loadable gmap directory for 
BaseCamp (tested only on Windows).


But it also give out an 'error' or 'warning' about an unknown block, 
possibly to be checked further when implementing in mkgmap:


Unknown Block: 54, length: 20,
'\x00\x00\xf7\x00\x00\x00\x00\x00\x00j\x00\x00\x99\x00\x00\x00\x00`\x00\x00'

Attached the complete command output ran with -v please ignore the 
copyright/license output... the strange content is testing stuff from 
another construction area, as you know... license information and 
unicode  ;-)


Testing inside this construction area will be next on my list for today...

Thanks and regards
Patrik

On 03.12.2016 23:26, Steve Ratcliffe wrote:

Hi


I'm wondering if it would be possible that mkgmap is able to
create/convert maps also in the gmap (gmapi) format used for 
BaseCamp on

Windows and Macintosh.


Yes, this seems a reasonable thing to do.

In the mkgmap code base there is a python program called
gmapi-builder.py in the scripts directory.

See also https://bitbucket.org/berteun/gmapibuilder/overview
and http://wiki.openstreetmap.org/wiki/Gmapibuilder.

This is a converter, but should work on all platforms with python
installed, or could be made to do so...
The first step is to verify that it works; then it should
be easy enough to implement within mkgmap itself.

..Steve
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev




___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] Housenumber's missing in _mdr.img, bug ?

2016-11-21 Thread Thomas Morgenstern


Hi ,
maybee the index-files hold not all existing housenumbers from 
osm-database. Exampel : In the  very small area min lat=46.959; max lat= 
46.971; min long = 10.0579; max long = 10.081  exists Kennung: 
85.800.951 =  'Hausnummer 24 in Montafonerstraße'.  Tag's : addr:city= 
Gaschurn ; addr:housenumber=24; addr:street= Montafonerstraße; 
building=yes; addr:postcode=6794 . This housenumber and e few other 
(number 22; 23; 24a, 42 ) nearby are not searchable in  resulting 
img. I have tested with mkgmap- r3695 an r3703, default style. What goes 
wrong ?  For evaluation you can download this small osm 
:http://img2ms.de/bilder/Montafon.rar


Thomas
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] splitter and josm problem

2016-11-15 Thread Thomas Morgenstern

Danke für Deine Bemühungen, ich selbst bin leider nicht schlau genug, um 
da mitreden zu können. Wundere mich nur, dass Anderen der Fehler bisher 
nicht aufgefallen ist..


Thanks for your hint related  java option  - Xmx5000m.  It is possible, 
to load a 25 MB osm.pbf in JOSM. I see in JOSM, that all nodes exist, 
but the nodes has no tags! .That is the problem: splitter does not write 
the tags to that nodes. It is curios, if the splittfile covers a big 
area, then comes that error. But if the splittfile covers a small area, 
all nodes has the tags. Thomas



Am 15.11.2016 um 17:00 schrieb Gerd Petermann:

Hi Thomas,

Thomas Morgenstern wrote

Hi gerd thanks for your tests. I am waiting for your solution...

I've found a few errors in splitter until now, but no solution so far. The
support of overlapping areas in split-file
is quite a brain teaser...

Gerd



--
View this message in context: 
http://gis.19327.n8.nabble.com/max-nodes-in-splitter-tp5885774p5885939.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 mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] splitter and josm problem

2016-11-13 Thread Thomas Morgenstern


Gerd,

for your information : i use splitter with this option's : 
--split-file=D:\OSMKarten\OSMEuropa\areasEuropa.list --max-nodes=200 
--max-areas=400 . Maybee i should change this option's  ?


thomas


Am 13.11.2016 um 12:03 schrieb Gerd Petermann:

Hi Thomas,

I can open the big file in JOSM with JRE option -Xmx6G.
Besides that the mp relation is 59766, the id 233877233 belongs to the outer
way.
And yes, splitter seems to drop the relation in the large file. I'll try to
find out
why.

Gerd

Thomas Morgenstern wrote

Hi at all, i am using splitter r429 and mkgmap r3695. Normally it works
perfekt. But now  it gives me a problem with multipolygons. I downloaded
and splitt latest-europe.osm.pbf from geofabrik, ---> splitt it with
splitter r429 for testing to 2 tiles, a big tile 8707.osm.pbf and a
small tile 8011.osm.pbf. The small tile is inner the big tile. Both
tiles contains the area with the multipolgon ID 23387723. Then compile
it for testing  separatly with mkgmap r3695. If the input is the small
tile 8011.osm.pbf, it compile the img correct, *spezially the
multipolygon ID 233877233 (tags : name=Schloßteich; natural=water;
type=multipolygon) is present as 0x3c in resulting img. *See
img2ms.de/bilder/multipolygon-good.jpg. It is the blue lake name
='Schlossteich'

If i compile the big 8707.osm.pbf, the resulting img has not this
area . *It seems for me, as if the multipolygon ID 23387723 is ignored*.
See img2ms.de/bilder/multipolygon-wrong.jpg. In both cases i use ident
style. It makes no different, if the default style or my own style is
used.

I tried to found out, if the splitter produce the multipolygon in the
big 8707.osm.pbf, but JOSM v11223  can not load the big (~25MB)
8707.osm.pbf. : JOSM --> open file 8707.osm.pbf--> 'Lese
OSM-Daten...'--> and a few minutes later the MessageBox close, but the
osm.pbf shows not on the screen. Has the JOSM-plugin 'pbf: Version
32865' any limitations ? My PC has 6 GB RAM, 64 bit Windows10.
Any hints are welcome. Download for both 8*.osm.pbf :
img2ms.de/bilder/8000osm-pbf.rar:  Splittfile for splitter r429   :
img2ms.de/bilder/areas.list
regards Thomas


___
mkgmap-dev mailing list
mkgmap-dev@.org
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev





--
View this message in context: 
http://gis.19327.n8.nabble.com/max-nodes-in-splitter-tp5885774p5885820.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 mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] splitter and josm problem

2016-11-13 Thread Thomas Morgenstern


Hi gerd thanks for your tests. I am waiting for your solution...

Thomas


Am 13.11.2016 um 12:03 schrieb Gerd Petermann:

Hi Thomas,

I can open the big file in JOSM with JRE option -Xmx6G.
Besides that the mp relation is 59766, the id 233877233 belongs to the outer
way.
And yes, splitter seems to drop the relation in the large file. I'll try to
find out
why.

Gerd

Thomas Morgenstern wrote

Hi at all, i am using splitter r429 and mkgmap r3695. Normally it works
perfekt. But now  it gives me a problem with multipolygons. I downloaded
and splitt latest-europe.osm.pbf from geofabrik, ---> splitt it with
splitter r429 for testing to 2 tiles, a big tile 8707.osm.pbf and a
small tile 8011.osm.pbf. The small tile is inner the big tile. Both
tiles contains the area with the multipolgon ID 23387723. Then compile
it for testing  separatly with mkgmap r3695. If the input is the small
tile 8011.osm.pbf, it compile the img correct, *spezially the
multipolygon ID 233877233 (tags : name=Schloßteich; natural=water;
type=multipolygon) is present as 0x3c in resulting img. *See
img2ms.de/bilder/multipolygon-good.jpg. It is the blue lake name
='Schlossteich'

If i compile the big 8707.osm.pbf, the resulting img has not this
area . *It seems for me, as if the multipolygon ID 23387723 is ignored*.
See img2ms.de/bilder/multipolygon-wrong.jpg. In both cases i use ident
style. It makes no different, if the default style or my own style is
used.

I tried to found out, if the splitter produce the multipolygon in the
big 8707.osm.pbf, but JOSM v11223  can not load the big (~25MB)
8707.osm.pbf. : JOSM --> open file 8707.osm.pbf--> 'Lese
OSM-Daten...'--> and a few minutes later the MessageBox close, but the
osm.pbf shows not on the screen. Has the JOSM-plugin 'pbf: Version
32865' any limitations ? My PC has 6 GB RAM, 64 bit Windows10.
Any hints are welcome. Download for both 8*.osm.pbf :
img2ms.de/bilder/8000osm-pbf.rar:  Splittfile for splitter r429   :
img2ms.de/bilder/areas.list
regards Thomas


___
mkgmap-dev mailing list
mkgmap-dev@.org
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev





--
View this message in context: 
http://gis.19327.n8.nabble.com/max-nodes-in-splitter-tp5885774p5885820.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 mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] splitter and josm problem

2016-11-13 Thread Thomas Morgenstern

Hi at all, i am using splitter r429 and mkgmap r3695. Normally it works 
perfekt. But now  it gives me a problem with multipolygons. I downloaded 
and splitt latest-europe.osm.pbf from geofabrik, ---> splitt it with 
splitter r429 for testing to 2 tiles, a big tile 8707.osm.pbf and a 
small tile 8011.osm.pbf. The small tile is inner the big tile. Both  
tiles contains the area with the multipolgon ID 23387723. Then compile 
it for testing  separatly with mkgmap r3695. If the input is the small 
tile 8011.osm.pbf, it compile the img correct, *spezially the 
multipolygon ID 233877233 (tags : name=Schloßteich; natural=water; 
type=multipolygon) is present as 0x3c in resulting img. *See 
img2ms.de/bilder/multipolygon-good.jpg. It is the blue lake name 
='Schlossteich'


If i compile the big 8707.osm.pbf, the resulting img has not this 
area . *It seems for me, as if the multipolygon ID 23387723 is ignored*. 
See img2ms.de/bilder/multipolygon-wrong.jpg. In both cases i use ident 
style. It makes no different, if the default style or my own style is used.


I tried to found out, if the splitter produce the multipolygon in the 
big 8707.osm.pbf, but JOSM v11223  can not load the big (~25MB)  
8707.osm.pbf. : JOSM --> open file 8707.osm.pbf--> 'Lese 
OSM-Daten...'--> and a few minutes later the MessageBox close, but the 
osm.pbf shows not on the screen. Has the JOSM-plugin 'pbf: Version 
32865' any limitations ? My PC has 6 GB RAM, 64 bit Windows10.
Any hints are welcome. Download for both 8*.osm.pbf : 
img2ms.de/bilder/8000osm-pbf.rar:  Splittfile for splitter r429   : 
img2ms.de/bilder/areas.list

regards Thomas

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] eTrex Vista

2016-09-10 Thread Thomas Morgenstern

Hallo, ich hatte das ziemlich baugleiche GPSMAP60, und da ging das  mit 
seriell. Damals war Mapsource 6.13.3 aktuell. Und mit sendmap20 von 
www.cgpsmapper.com geht es garantiert. Momentan ist die website nicht 
erreichbar. Eine Kopie von sendmap20 kannst bei Bedarf von mir direkt 
bekommen. Das von mkgmap erzeugte Fileformat ist identisch mit dem 
originalen Garmin-format (non -NT, non -NTU)


thomas
--
Von: "Jakob Mühldorfer" 
Datum: Samstag, 10. September 2016 03:24
An: 
Betreff: [mkgmap-dev] eTrex Vista


Hi,

sorry to ask this here, but I have a device question.
Does someone here use an ancient eTrex Vista (non c, non cx, non Hcx), and 
knows if mkgmap files can be transferred via serial port and be used on 
it?

All information is highly welcome

Jakob
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] mkgmap add poi2areas

2016-08-28 Thread Thomas Morgenstern


thank#s now I understand´the concept


thomas


Am 28.08.2016 um 17:09 schrieb Gerd Petermann:


Hi Thomas,


it is more or less the other way round :)

When you use option --add-pois-to-area then mkgmap creates a point for 
each OSM object that describes an area.


You decide what to do with this artifical point in style file points.

The default style contains e.g.

highway=services & mkgmap:area2poi!=true [0x210f resolution 24 
default_name 'Services']



OK?


*Von:* mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag 
von Thomas Morgenstern <webmas...@img2ms.de>

*Gesendet:* Sonntag, 28. August 2016 16:49:42
*An:* mkgmap-dev@lists.mkgmap.org.uk
*Betreff:* [mkgmap-dev] mkgmap add poi2areas
Hi all,
my intention is to add a POI to some spezific polygons. But not to all 
polygons. How must i use the option /--add-pois-to-areas ?
/In Stylefile 'polygons' ? For exempel : if /sport=free_flying, /then 
I want a POI and {set mkgmap:area2poi=true }. Is this right ? Any 
hint's are welcome.


Thomas


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] mkgmap add poi2areas

2016-08-28 Thread Thomas Morgenstern


Hi all,
my intention is to add a POI to some spezific polygons. But not to all 
polygons. How must i use the option /--add-pois-to-areas ?
/In Stylefile 'polygons' ? For exempel : if /sport=free_flying, /then I 
want a POI and {set mkgmap:area2poi=true }. Is this right ? Any hint's 
are welcome.


Thomas
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Problems with routing on Etrek 20 with latest firmware

2016-07-28 Thread Thomas Morgenstern

Basecamp is available also for MAC, not only windows. Your problems are 
dependent from the map. I would try other map. here: 
http://wiki.openstreetmap.org/wiki/DE:OSM_Map_On_Garmin/Download are many 
other sources.

thomas

--
Von: "ael" 
Datum: Donnerstag, 28. Juli 2016 16:24
An: 
Betreff: Re: [mkgmap-dev] Problems with routing on Etrek 20 with latest 
firmware



On Thu, Jul 28, 2016 at 01:05:40PM +, Gary Bamford wrote:

Hi Ael.


That's a strange on, I have no experience with the Etrek 20, but my 
starting point would be to load the map up into Basecamp, I would do this 
by putting the sd micro into a reader that way basecamp sees exactly the 
same map as the Garmin device.


Thanks for the reply, but AIUI basecamp is a windows program and I don't 
have

access to that operating system. In extremis, I might try using Wine if
that would throw any light.

ael

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] r3678 and overview map problems

2016-07-15 Thread Thomas Morgenstern


I have tested a few more mapset's, I found no problem. thank you

Thomas

Am 15.07.2016 um 07:34 schrieb Gerd Petermann:

Hi all,

I assume Thomas did not find any problems. I'd like to commit the patch.
Any complains?

Gerd


Thomas Morgenstern wrote

Hi Gerd, thank's for the solution. I have testet the patched r-3678.jar
binary for two examples. It works  well.  But i must make a few more
test's. Till now, all is okay..
   Thomas
Am 09.07.2016 um 08:14 schrieb Gerd Petermann:

Hi Thomas,


okay, I have now checked your test case as well.

I think Steve has already explained why the change in r3674 introduced
the problem,

the newer versions read the input files in sorted order when creating
the overview map,

older releases used the order given in the command line.


A simple work-around would be to use higher numbers for the tiles
which should be processed later,

e.g.  instead of 4000 for the contour tiles.


A better solution would be to detect the needed resolution. The
problem here:

mkgmap has to read all input tiles (completely) to find out which one
uses the lowest resolution,

current code doesn't allow to read only the levels info. So one has to
accept a longer run time.

I don't know if that is really needed, maybe an empty overview map can
always use a low resoltion

like 12?


Another solution would be to evaluate the overview-levels option as
suggested by Steve.


In your case the overview map is empty, it contains only the 0x4a
polygons, so it is quite simple.


I have no idea what mkgmap should do when a user tries to combine
ovm*.img files which were

created with different overview-level options, I leave that open.


I've impemented both alternatives in the attached patch, a binary
based on r3678 is here:

http://files.mkgmap.org.uk/download/299/mkgmap.jar


The patch solves your problem, but I'd prefer to avoid the additional
reading of all input files

before the overview map is produced.

@all : What do you think about the alternative to use a fixed
resolution of 12 for an overview map

that contains only the tile boundary infos?


Gerd




*Von:* mkgmap-dev 

mkgmap-dev-bounces@.org
 im Auftrag

von Thomas Morgenstern 

webmaster@


*Gesendet:* Freitag, 8. Juli 2016 20:41:08
*An:* Development list for mkgmap
*Betreff:* Re: [mkgmap-dev] r3678 and overview map problems
Hi Gerd , Update:

r-3778 create now 1 0x4a like expected. This is a good news. But in my
testenvironment are 2 osm-tiles and 1 contourtile. One of the osmtile
has a wrong position. it is shifted to east ~22 degrees. The tile
itself has 25.4 degreees east-west .
thomas

Am 08.07.2016 um 16:49 schrieb Thomas Morgenstern:





--
View this message in context: 
http://gis.19327.n5.nabble.com/r3678-and-overview-map-problems-tp5877609p5878424.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 mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] Country index in MDR-; Search shows up double Contry name 's

2016-07-11 Thread Thomas Morgenstern


Hi all,
When I search in Mapource or in Nüvi for any city and  use the 
countryfilter,somecountriesaredisplayedin2spellings.Example : 'DEU 
(Deutschland)' and 'Deutschland (DEU)'. The same is for Estland, 
Finnland, Griechenland, Egypt,  Färoer, Dänemark, Italy. Kosova and 
Kosovo. France has 3 spelling's .Why are this  entrys doubled. ? It is 
not a great problem ,but is confusing. The problem existis a long time ago.


thomas
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] r3678 and overview map problems

2016-07-09 Thread Thomas Morgenstern

Hi Gerd, thank's for the solution. I have testet the patched r-3678.jar
binary for two examples. It works well. But i must make a few more
test's. Till now, all is okay..

Thomas
Am 09.07.2016 um 08:14 schrieb Gerd Petermann:

Hi Thomas,

okay, I have now checked your test case as well.

I think Steve has already explained why the change in r3674 introduced
the problem,

the newer versions read the input files in sorted order when creating
the overview map,

older releases used the order given in the command line.

A simple work-around would be to use higher numbers for the tiles
which should be processed later,

e.g. instead of 4000 for the contour tiles.

A better solution would be to detect the needed resolution. The
problem here:

mkgmap has to read all input tiles (completely) to find out which one
uses the lowest resolution,

current code doesn't allow to read only the levels info. So one has to
accept a longer run time.

I don't know if that is really needed, maybe an empty overview map can
always use a low resoltion

like 12?

Another solution would be to evaluate the overview-levels option as
suggested by Steve.

In your case the overview map is empty, it contains only the 0x4a
polygons, so it is quite simple.

I have no idea what mkgmap should do when a user tries to combine
ovm*.img files which were

created with different overview-level options, I leave that open.

I've impemented both alternatives in the attached patch, a binary
based on r3678 is here:

http://files.mkgmap.org.uk/download/299/mkgmap.jar

The patch solves your problem, but I'd prefer to avoid the additional
reading of all input files

before the overview map is produced.

@all : What do you think about the alternative to use a fixed
resolution of 12 for an overview map

that contains only the tile boundary infos?

Gerd

*Von:* mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag
von Thomas Morgenstern <webmas...@img2ms.de>

*Gesendet:* Freitag, 8. Juli 2016 20:41:08
*An:* Development list for mkgmap
*Betreff:* Re: [mkgmap-dev] r3678 and overview map problems
Hi Gerd , Update:

r-3778 create now 1 0x4a like expected. This is a good news. But in my
testenvironment are 2 osm-tiles and 1 contourtile. One of the osmtile
has a wrong position. it is shifted to east ~22 degrees. The tile
itself has 25.4 degreees east-west .

thomas

Am 08.07.2016 um 16:49 schrieb Thomas Morgenstern:

Hi Gerd,
i have tested r-3677 and the preview in my case is wrong.
Ithinktheerroris notduetotheTileSize.Theerroroccurs,ifthe2OSM-
tilesbeusedand 1ormoreContourline tilesin
addition.ThetransparentcontourlinetilesliewithintheOSM tiles(1degree
squaregrid). If only used the OSM-Tiles, then the preview is okay and
has the expectedsize with one Mapselectionarea. You can download my
test-environment from http\img2ms.de\Downloads\Test.rar. Inside the
rar are 3 tiles and my mkgmap -bat.

thomas

Am 08.07.2016 um 09:54 schrieb Gerd Petermann:

Hi all,

I got no feedback on the do_not_split_0x4a_polygon.patch which I
provided to fix the problems reported by

Thomas and Andrzej, see

http://gis.19327.n5.nabble.com/How-do-I-transform-the-name-of-all-Ways-tp5875326p5875519.html

I checked older versions of the source and

found out that older versions of the code did contain a special
treatment for the 0x4a polygons, I removed those

in the overview2 branch and I don't exactly remember why, so I've
reverted that part of the change.

I have the feeling that the code should be changed somewere else,
the tests in PolygonSubdivSizeSplitterFilter.java

were introduced by WanMil long before we changed the split algo in
MapSplitter.

Both sources use diverse hard coded limits, and I have no idea why
these are not relevant for 0x4a polygons.

I assume that there is a maximum tile size (at least we have it in
splitter) so maybe mkgmap should stop with an error

message when one tries to create a map with larger tiles?

Gerd

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] r3678 and overview map problems

2016-07-08 Thread Thomas Morgenstern

Hi Gerd , Update:

thomas

Am 08.07.2016 um 16:49 schrieb Thomas Morgenstern:

thomas

Am 08.07.2016 um 09:54 schrieb Gerd Petermann:

Hi all,

I got no feedback on the do_not_split_0x4a_polygon.patch which I
provided to fix the problems reported by

Thomas and Andrzej, see

http://gis.19327.n5.nabble.com/How-do-I-transform-the-name-of-all-Ways-tp5875326p5875519.html

I checked older versions of the source and

found out that older versions of the code did contain a special
treatment for the 0x4a polygons, I removed those

in the overview2 branch and I don't exactly remember why, so I've
reverted that part of the change.

I have the feeling that the code should be changed somewere else, the
tests in PolygonSubdivSizeSplitterFilter.java

were introduced by WanMil long before we changed the split algo in
MapSplitter.

Both sources use diverse hard coded limits, and I have no idea why
these are not relevant for 0x4a polygons.

I assume that there is a maximum tile size (at least we have it in
splitter) so maybe mkgmap should stop with an error

message when one tries to create a map with larger tiles?

Gerd

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] r3678 and overview map problems

2016-07-08 Thread Thomas Morgenstern


Hi Gerd,
i have tested r-3677 and the preview in my case is  wrong.
Ithinktheerroris notduetotheTileSize.Theerroroccurs,ifthe2OSM- 
tilesbeusedand 1ormoreContourline tilesin 
addition.ThetransparentcontourlinetilesliewithintheOSM tiles(1degree 
squaregrid). If only used the OSM-Tiles, then the preview is okay and 
has the expectedsize with one Mapselectionarea. You can download my 
test-environment from http\img2ms.de\Downloads\Test.rar. Inside the rar 
are 3 tiles  and my mkgmap -bat.



thomas

Am 08.07.2016 um 09:54 schrieb Gerd Petermann:


Hi all,


I got no feedback on the do_not_split_0x4a_polygon.patch which I 
provided to fix the problems reported by


Thomas and Andrzej, see

http://gis.19327.n5.nabble.com/How-do-I-transform-the-name-of-all-Ways-tp5875326p5875519.html


I checked older versions of the source and

found out that older versions of the code did contain a special 
treatment for the 0x4a polygons, I removed those


in the overview2 branch and I don't exactly remember why, so I've 
reverted that part of the change.



I have the feeling that the code should be changed somewere else, the 
tests in PolygonSubdivSizeSplitterFilter.java


were introduced by WanMil long before we changed the split algo in 
MapSplitter.


Both sources use diverse hard coded limits, and I have no idea why 
these are not relevant for 0x4a polygons.



I assume that there is a maximum tile size (at least we have it in 
splitter) so maybe mkgmap should stop with an error


message when one tries to create a map with larger tiles?


Gerd





___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Error in mkgmap r-3676, wrong preview generation

2016-07-02 Thread Thomas Morgenstern


Hi Gerd,

please make a really solution of the error or untouch the code. No error 
mesasage ! Maybee a error message prevent mkgmap to create the _mdr.ing. 
I use a workaround with cgpsmapper to create the preview.img. I am 
angry, that my workaround wil lnot longer work, if mkgamp gives me error 
message.thank you.

thomas

by the way... : the problem is: mkgmap creates many 0x4a for one 
maptile. it should creates only one 0x4a with the tile-boundaries, like 
in the corrresponding tdb. Maybee is the solution, to use the same 
algorythmus for writing 0x4a in preview like in tdb ?


Am 01.07.2016 um 10:57 schrieb Gerd Petermann:

Hi,

I am back from a nice cycle trip to Sicilia. I did not yet investigate the 
problem in detail,
but I can for sure say that I did not think about this situation when I wrote 
the code for the
overview map creation.
If nobody claims that mkgmap should support this I would also prefer to print 
an error
message and stop processing.

Gerd




Von: mkgmap-dev  im Auftrag von Steve 
Ratcliffe 
Gesendet: Samstag, 18. Juni 2016 18:19
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] Error in mkgmap r-3676, wrong preview generation

Hi

An update on the problem.

The contour line tiles have the levels 0:24,1:23,2:22,3:20,4:18
whereas the content tiles have levels of 0:24,1:22,2:20,3:18,4:16,5:15

The first tile encountered determines the levels in the overview map
and so the overview maps are different.  It is surely a bug that the
map outlines are wrong and so I will look at this next.

However I am not sure what the full solution is though as there are
other noticable problems, as the overview map is going to be wrong for
one set of tiles whatever is done.  Perhaps mixing tiles with
different levels should not be allowed?

..Steve
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev




___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Error in mkgmap r-3676, wrong preview generation

2016-06-19 Thread Thomas Morgenstern

The overview levels are defined in options as -overview-levels=5:17 , 
6:15, 7:12 and the contentfile-levels are defined in \STYLE\options as 
levels= 0:24, 1:22 , 2:20, 3:18, 4:16


Thomas

Am 18.06.2016 um 23:08 schrieb Andrzej Popowski:

Hi Steve,

aren't overview levels defined by options or style?



___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Error in mkgmap r-3676, wrong preview generation

2016-06-16 Thread Thomas Morgenstern


Hi Steve, thanks for your investigation. I hope you will find a solution...

Thomas
Am 16.06.2016 um 23:22 schrieb Steve Ratcliffe:

Hi Thomas


in some cases r-3676 (and also earlier releases) generate a wrong
preview.img. But tdb-file is always okay.


Thanks for the bug report.  I have found that the problem was
introduced in version r3674, so it is a change I made...

I am investigating the problem and don't know why this is happening
yet.

Best wishes
..Steve
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev




___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] Error in mkgmap r-3676, wrong preview generation

2016-06-14 Thread Thomas Morgenstern


Hallo at all,
in some cases r-3676 (and also earlier releases) generate a wrong 
preview.img. But tdb-file is always okay.
My way is : first i generate all tiles from the europe-latest.osm.pbf . 
This makes  no problems; and second i arrangiere some tiles to countries 
and for those contry-tiles and additionally Contourline-tiles I run a 
batch to generate the preview and tdb.
My example : first i use 2 tiles 5002.img and 5779.img (Island) 
; r-3676 generate the preview+tdb, all okay.
second : this 2 tiles and additionally a third tile(Contourlines) : 
r-3676 generate a wrong preview. This wrong preview is in Mapsource and 
also in Mapinstall . It makes no different, if the contourline-tile is 
inside or ouside the other tiles. What is wrong with mkgmap ?  All 
sourcefiles for evaluation can you download : 
http:\\img2ms.de\Downloads\Test.rar. I assume  the reason is the actual 
see.zip or bounds.zip ? 4 months ago with older see and bounds was not 
this error.

Screenshot preview okay :

Screenshot wrong preview.img :

regards thomas

___
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 Thomas Morgenstern

Hallo, ich habe die WW Autoroute DEM Basemap 3.0 auf meinem Nüvi. Bei 
Bedarf kannst mich privat unter tho...@img2ms.de kontaktieren. ~50 MB 
Dateigröße

mfg

Am 19.04.2016 um 21:13 schrieb Jakob Mühldorfer:

Can one get these basemaps somewhere?
The one on my Nüvi 205 is gone (yes that was my fault, i admit)

Am 19.04.2016 um 20:57 schrieb 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


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev





___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] mkgmap (StyledConverter) Tile contains both drive-on-left an drive-on right

2016-03-13 Thread Thomas Morgenstern


Hi,
i am converting africa from http:\\download-geofabrik.de. mkgmap r-3671 
( and  any older versions too ) give me a warrning : 'Schwerwiegend 
(StyledConverter): file xyz.osm.pbf :Attention: Tile contains both 
drive-on left (104037) and drive-on right roads (6443) '. in my 
STYLEFILE i have the option --drive-on=detect,right. The img-file is 
successfull created and routing works in Mapsource. But is the routing 
correct ? Tiles contains many different countries. What con i do to 
prevent the warning ?


Thomas
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Is there a program I can use to see mkgmap tags (mkgmap:) ?

2016-03-09 Thread Thomas Morgenstern

the program 'JOSM' show's all tag's in the osm -database. It download a 
small area from OSM-Database. Do not choose a great area!

thomas

Am 09.03.2016 um 20:12 schrieb greg crago:
I can use GPSMapEdit to see contents of my .img file, but I would like 
to see the mkgmap:(variables) listed on each way and poi. How can I 
see these tags?


Greg


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] TYPViewer

2016-02-07 Thread Thomas Morgenstern

This website
http://www.naviboard.de/vb/showthread.php?t=58613=typviewer  contains 
links to many versions of typviewer.
  thomas


Von: Dave Swarthout 
Datum: Sonntag, 7. Februar 2016 07:42
An: Development list for mkgmap 
Betreff: Re: [mkgmap-dev] TYPViewer


I had that same issue with Win 8.1 and the latest version of TYPViewer.  I went 
round and round until I decided to cut my losses and use an older version. I'm 
using 4.5.24 successfully but YMMV with Win 10. Sorry, but I cannot recall from 
where I downloaded it. It's only 3 MB so if you wish I can put it in my Dropbox 
and you can get it from there. 


Let me know


On Sun, Feb 7, 2016 at 11:48 AM, Mark Bradley  
wrote:

  I decided to download TYPViewer.  Following the link in the wiki took me to 
sites.google.com/site/sherco40/.  This page states the latest version is 4.5 
20.  Yet in a blog on a separate website the writers were referring to newer 
versions, such as 4.5.35.  I cannot find any site that offers anything newer 
than 4.5.20.  Is the Google site the correct site for the latest version?



  When I try to run the program, I get this error message:



  Error 50003 (Unexpected error) in procedure Main of Module Demarrage, at 
line: 340



  I’m running Windows 10.  Is TYPViewer incompatible?  I would appreciate input 
from anyone who has successfully used the program.



  Mark Bradley








  ___
  mkgmap-dev mailing list
  mkgmap-dev@lists.mkgmap.org.uk
  http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev






-- 

Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com





___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Index with little ram?

2016-01-24 Thread Thomas Morgenstern

Hallo Arndt, ich nutze einen PC mit 6 GB RAM, und weise in der Commandline zum 
start von mkgmap java 5500MB zu .Damit mit kann ich den europai_mdr.img 
erstellen. Habe aber die x-splitt-name-index  nicht benutzt. Auch die 
gmapsupp-option nutze ich nicht. 

mfg thomas


Von: Arndt 
Datum: Samstag, 23. Januar 2016 22:25
An: list for mkgmap, Development 
Betreff: [mkgmap-dev] Index with little ram?


Hello together,

mkgmap needs a lot of RAM to build the index for the adress search.  Also for 
the gmapsupp.
My computer has 4 GB and it´s not possible to build the index for a germany 
map. It works, when i not use the "x-split-name-index" Option. But I want to 
use this.
The map has 2,21GB (only the mapfiles)
The Computer from my son has 12 GB. This machine has no problem with germany, 
but failed, when it builds the index for an europe map (12,1GB).

Is it possible to change the index-build process so, that also a little 
computer is able to build the index?

By the wy, the x-split-name-index works fine by street names. Is it possible, 
that it also works by town-names?

Best regards
Arndt










___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Index with little ram?

2016-01-24 Thread Thomas Morgenstern

ich have on my  64 bit Windowsmachine and 5500 MB for java no problem. I also 
use the geofabrik europa-extraxt; aktually ~ 16 GB osm.pbf.  1. step : Splitter 
creates ~ 570 .osm.pbf files and as  2.step mkgmap makes  the img-files. 
But in this 2. step i create not a _mdr.img ! As  3. step i run mkgmap 
with this options  : --index --tdbfile  --area-name=Europa  *.img. I never 
create a gmapsupp; only PC -Installation. This method has additionally 
advantages: you can create many country-spezific-maps with option --index 
--tdbfile  --area-name=Poland  poland*.img

thomas


Von: Arndt 
Datum: Sonntag, 24. Januar 2016 18:47
An: Development list for mkgmap ; Gerd Petermann 
Betreff: Re: [mkgmap-dev] Index with little ram?


6GB for Europa? I use the extract "Europa" from the geofabrik. With my style a 
12GB Machine failed.
I make a Test with the "Balearen". With my style the mdr-file has 6,5MB. With 
the default style only 5 MB. 
In my style some ways exists more than one time. For example a street with 
surface=cobblestone. There are 3 lines, one invisibel for routing, one for the 
look and one for a marker, that the surface is bad.
Is it right, that only lines with highway=* use for adresses? Perhaps its 
possibel to use only one highway Tag for the ways and for the other infos i use 
a custom word.
Why it is necessary that the mdr build in only one step? Perhaps it ist 
possibel, that this run a few rounds.
x-split towns:
Bad Honnef
El Paso
El Arenal
Wildbad Kreuth
Arndt
___
Steve Sgalowski:
yet it works for me just takes some fidleing around with some  variables  

doeing dach map now 


Thomas Morgenstern:
Hallo Arndt, ich nutze einen PC mit 6 GB RAM, und weise in der Commandline zum 
start von mkgmap java 5500MB zu .Damit mit kann ich den europai_mdr.img 
erstellen. Habe aber die x-splitt-name-index  nicht benutzt. Auch die 
gmapsupp-option nutze ich nicht.
  Gerd Petermann <gpetermann_muenc...@hotmail.com> hat am 24. Januar 2016 um 
10:10 geschrieben:


  Reg. memory: If you have a 64 bit system it is probably better to buy more 
memory. I think Steven did already

  try to reduce the memory usage so I guess there is not much room for 
improvements.



  reg. city index: I assume it is possible, not sure if it makes sense.

  I guess you have names like "Samtgemeinde Harpstedt" instead of "Harpstedt" ?

  In that case I think it would be better to use subst like we do for 
"Gemeinde".

  Do you have positive examples ?



  Gerd






--

  Von: mkgmap-dev-boun...@lists.mkgmap.org.uk 
<mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Arndt 
<ar...@speichenkarte.de>
  Gesendet: Samstag, 23. Januar 2016 22:25
  An: list for mkgmap, Development
  Betreff: [mkgmap-dev] Index with little ram? 

  Hello together,

  mkgmap needs a lot of RAM to build the index for the adress search.  Also for 
the gmapsupp.
  My computer has 4 GB and it´s not possible to build the index for a germany 
map. It works, when i not use the "x-split-name-index" Option. But I want to 
use this.
  The map has 2,21GB (only the mapfiles)
  The Computer from my son has 12 GB. This machine has no problem with germany, 
but failed, when it builds the index for an europe map (12,1GB).

  Is it possible to change the index-build process so, that also a little 
computer is able to build the index?

  By the wy, the x-split-name-index works fine by street names. Is it possible, 
that it also works by town-names?

  Best regards
  Arndt






 
  ___
  mkgmap-dev mailing list
  mkgmap-dev@lists.mkgmap.org.uk
  http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

 





___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Address search index questions.

2015-12-31 Thread Thomas Morgenstern

Hi, the option --x-splitt-name-index is new for me. Is  a documentation 
for this option available ?. In ..\mkgmap-r3650\doc\options.txt it is 
not descripted. Can i use both options  --index and 
--x-splitt-name-index togehter ? or only solo 1 option ?


regards thomas

On Dec 30, 2015, at 18:25, Gerd Petermann  
wrote:

Hi Diego,

I think --x-split-name-index  is the option you are looking for.

ciao,
Gerd



___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Address search index questions.

2015-12-31 Thread Thomas Morgenstern

Hi, yes we can read the options using /java -jar mkgmap.jar 
-help=options > options.txt./


But it is a good idee, this actuall option.txt-version to includ in the 
download http://www.mkgmap.org.uk/download/mkgmap-r3656.zip. I this zip-file is 
only a old version without the new --x-split-name-index.

regards thomas

Am 31.12.2015 um 14:57 schrieb Gerd Petermann:

Hmm, no idea why you have that problem.

You can use
java -jar mkgmap.jar -help=options > options.txt
Line 129 should contain the option. If that is not the case
you probably don't use r3656.

Gerd



Von: mkgmap-dev-boun...@lists.mkgmap.org.uk <mkgmap-dev-boun...@lists.mkgmap.org.uk> 
im Auftrag von Paco Tyson <paco.ty...@free.fr>
Gesendet: Donnerstag, 31. Dezember 2015 14:19
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Address search index questions.

Hi Gerd,

I can’t find this option in the latest mkgmap version 3656, neither in the 
accepted options nor in the options.txt file.
Is this still in a branch ?

Thanks,
Paco


Le 31 déc. 2015 à 09:35, Gerd Petermann <gpetermann_muenc...@hotmail.com> a 
écrit :

Hi Thomas,

options.txt contains:
--x-split-name-index
   A temporary option to enable indexing each part of a street name separately.
   So for example if the street is "Aleksandra Gryglewskiego" then you will be 
able to
   search for it as both "Aleksandra" and "Gryglewskiego".  It will also 
increase the
   size of the index.  Useful in countries where searching for the first word 
in name
   is not the right thing to do.

   Note that this option is still experimental and there may be problems. If 
you find
   any let us know!

I guess you did not find it because of a typo (--x-splitt-name-index has  two 
't' )

Gerd


Von: mkgmap-dev-boun...@lists.mkgmap.org.uk <mkgmap-dev-boun...@lists.mkgmap.org.uk> 
im Auftrag von Thomas Morgenstern <webmas...@img2ms.de>
Gesendet: Donnerstag, 31. Dezember 2015 09:30
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Address search index questions.

Hi, the option --x-splitt-name-index is new for me. Is  a documentation
for this option available ?. In ..\mkgmap-r3650\doc\options.txt it is
not descripted. Can i use both options  --index and
--x-splitt-name-index togehter ? or only solo 1 option ?

regards thomas

On Dec 30, 2015, at 18:25, Gerd Petermann <gpetermann_muenc...@hotmail.com> 
wrote:

Hi Diego,

I think --x-split-name-index  is the option you are looking for.

ciao,
Gerd



___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev





___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] question for tdb-file record 0x52; option in mkgmap ?

So i have newly downloaded mkgmap-r3650 and run it again. The resulting 
tdb-file is available at : http://img2ms.de/Downloads/TopoCeuta.tdb. 
Look  self in it with hexeditor. At dezimalposition 950 you will find  
'mkgmap-r3336'. Hex-position is 0x3ac.

maybee is the problem the second run ?
regards thomas

Am 28.11.2015 um 18:36 schrieb Gerd Petermann:


Hi Thomas,


I see no way that r3650 produces the string mkgmap-r3336.

So, I guess that you are looking at an old map, which would

also explain that the different options have no effect.


ciao,

Gerd




*Von:* mkgmap-dev-boun...@lists.mkgmap.org.uk 
<mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Thomas 
Morgenstern <webmas...@img2ms.de>

*Gesendet:* Samstag, 28. November 2015 18:08
*An:* Development list for mkgmap
*Betreff:* Re: [mkgmap-dev] question for tdb-file record 0x52; option 
in mkgmap ?
I use mkgmap r-3650 from downloadsite: 
http://www.mkgmap.org.uk/download/mkgmap.html 
-->http://www.mkgmap.org.uk/download/mkgmap-r3650.zip.

<http://www.mkgmap.org.uk/download/mkgmap.html>

mkgmap download page
Branch builds. These jar files are latest builds of recent development 
branches. They are useful if you want to quickly test a branch without 
having obtain and build it.

Weitere Informationen... <http://www.mkgmap.org.uk/download/mkgmap.html>




-family-name=Kanaren also make 'Overview Map'.
My way is:
1. in first run I generate all <123345678>.img from *.osm-pbf . for 
Europa komplett
2. a secand run : /java -Xmx5000m jar mkgmap.jar -family-id=1918 
-product-id=1 -family-name=TopoKanaren -series-name=Topo Kanaren 
-overview-mapname=TopoCeuta -code-page=1252 -mapname=Kanaren -index
.img-file/s. This creates the tdb,preview, mdx and 
_mdr.img. Works perfekt, but the only mistake is : 'Overview Map' .


result is : in mapsource ->Fläche' -->'Overview Map' and not 'Topo 
Kanaren'

Am 28.11.2015 um 17:11 schrieb Gerd Petermann:


Hallo Thomas,


please try --family-name=xyz.


Where did you get the binary that reports mkgmap-r3336 ?

I assume that you build your own binary, in that case please

use these two commands:

svn update

ant clean dist


Gerd


*Von:* mkgmap-dev-boun...@lists.mkgmap.org.uk 
<mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Thomas 
Morgenstern <webmas...@img2ms.de>

*Gesendet:* Samstag, 28. November 2015 15:29
*An:* Development list for mkgmap
*Betreff:* [mkgmap-dev] question for tdb-file record 0x52; option in 
mkgmap ?
Has  mkgmap  a option, which write's the record 0x52 in tdb-file ? My 
maps have in Mapsource all the entry 'Overview map' . But i will for 
example 'Kanaren' or any other countryname. I have testet followings 
option without success: -region-name=anywhat ;-country.name= anywhat; 
-description= anywhat. I use -index to create the tdb-file. I can use 
a hexeditor to change  tdb- file- record 0x52. But this is not a 
preferable way. i must recalculate a CRC 32 checksum for record 0x54.


By the way: i found a error in the tdb-file, created with mkgmap 
r3650 : it prints in the copyright-section :.../.Map created with 
mkgmap -r3336/...; It should bee updated to ./.r3650/



___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev




___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] question for tdb-file record 0x52; option in mkgmap ?

Has  mkgmap  a option, which write's the record 0x52 in tdb-file ? My 
maps have in Mapsource all the entry 'Overview map' . But i will for 
example 'Kanaren' or any other countryname. I have testet followings 
option without success: -region-name=anywhat ;-country.name= anywhat; 
-description= anywhat. I use -index to create the tdb-file. I can use a 
hexeditor to change  tdb- file- record 0x52. But this is not a 
preferable way. i must recalculate a CRC 32 checksum for record 0x54.


By the way: i found a error in the tdb-file, created with mkgmap r3650 : 
it prints in the copyright-section :.../.Map created with mkgmap 
-r3336/...; It should bee updated to ./.r3650/


Regards thomas

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] question for tdb-file record 0x52; option in mkgmap ?

I use mkgmap r-3650 from downloadsite: 
http://www.mkgmap.org.uk/download/mkgmap.html 
-->http://www.mkgmap.org.uk/download/mkgmap-r3650.zip.


-family-name=Kanaren also make 'Overview Map'.
My way is:
1. in first run I generate all <123345678>.img from *.osm-pbf . for 
Europa komplett
2. a secand run : /java -Xmx5000m jar mkgmap.jar -family-id=1918 
-product-id=1 -family-name=TopoKanaren -series-name=Topo Kanaren 
-overview-mapname=TopoCeuta -code-page=1252 -mapname=Kanaren -index
.img-file/s. This creates the tdb,preview, mdx and 
_mdr.img. Works perfekt, but the only mistake is : 'Overview Map' .


result is : in mapsource ->Fläche' -->'Overview Map' and not 'Topo Kanaren'
Am 28.11.2015 um 17:11 schrieb Gerd Petermann:


Hallo Thomas,


please try --family-name=xyz.


Where did you get the binary that reports mkgmap-r3336 ?

I assume that you build your own binary, in that case please

use these two commands:

svn update

ant clean dist


Gerd


*Von:* mkgmap-dev-boun...@lists.mkgmap.org.uk 
<mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Thomas 
Morgenstern <webmas...@img2ms.de>

*Gesendet:* Samstag, 28. November 2015 15:29
*An:* Development list for mkgmap
*Betreff:* [mkgmap-dev] question for tdb-file record 0x52; option in 
mkgmap ?
Has  mkgmap  a option, which write's the record 0x52 in tdb-file ? My 
maps have in Mapsource all the entry 'Overview map' . But i will for 
example 'Kanaren' or any other countryname. I have testet followings 
option without success: -region-name=anywhat ;-country.name= anywhat; 
-description= anywhat. I use -index to create the tdb-file. I can use 
a hexeditor to change  tdb- file- record 0x52. But this is not a 
preferable way. i must recalculate a CRC 32 checksum for record 0x54.


By the way: i found a error in the tdb-file, created with mkgmap r3650 
: it prints in the copyright-section :.../.Map created with mkgmap 
-r3336/...; It should bee updated to ./.r3650/



___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] question for tdb-file record 0x52; option in mkgmap ?

Edit : the string mkgmap -r3336 is in the Copyrightrecord. Maybee the 
copyright is not updated? Creation-time of tbd-file is: 28.11.2015, 
19:17 Uhr GMT+1 hour


thomas
Am 28.11.2015 um 19:30 schrieb Thomas Morgenstern:
So i have newly downloaded mkgmap-r3650 and run it again. The 
resulting tdb-file is available at : 
http://img2ms.de/Downloads/TopoCeuta.tdb. Look  self in it with 
hexeditor. At dezimalposition 950 you will find  'mkgmap-r3336'. 
Hex-position is 0x3ac.

maybee is the problem the second run ?
regards thomas

Am 28.11.2015 um 18:36 schrieb Gerd Petermann:


Hi Thomas,


I see no way that r3650 produces the string mkgmap-r3336.

So, I guess that you are looking at an old map, which would

also explain that the different options have no effect.


ciao,

Gerd




*Von:* mkgmap-dev-boun...@lists.mkgmap.org.uk 
<mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Thomas 
Morgenstern <webmas...@img2ms.de>

*Gesendet:* Samstag, 28. November 2015 18:08
*An:* Development list for mkgmap
*Betreff:* Re: [mkgmap-dev] question for tdb-file record 0x52; option 
in mkgmap ?
I use mkgmap r-3650 from downloadsite: 
http://www.mkgmap.org.uk/download/mkgmap.html 
-->http://www.mkgmap.org.uk/download/mkgmap-r3650.zip.

<http://www.mkgmap.org.uk/download/mkgmap.html>

mkgmap download page
Branch builds. These jar files are latest builds of recent 
development branches. They are useful if you want to quickly test a 
branch without having obtain and build it.

Weitere Informationen... <http://www.mkgmap.org.uk/download/mkgmap.html>




-family-name=Kanaren also make 'Overview Map'.
My way is:
1. in first run I generate all <123345678>.img from *.osm-pbf . for 
Europa komplett
2. a secand run : /java -Xmx5000m jar mkgmap.jar -family-id=1918 
-product-id=1 -family-name=TopoKanaren -series-name=Topo Kanaren 
-overview-mapname=TopoCeuta -code-page=1252 -mapname=Kanaren 
-index.img-file/s. This creates the 
tdb,preview, mdx and _mdr.img. Works perfekt, but the only mistake is 
: 'Overview Map' .


result is : in mapsource ->Fläche' -->'Overview Map' and not 'Topo 
Kanaren'

Am 28.11.2015 um 17:11 schrieb Gerd Petermann:


Hallo Thomas,


please try --family-name=xyz.


Where did you get the binary that reports mkgmap-r3336 ?

I assume that you build your own binary, in that case please

use these two commands:

svn update

ant clean dist


Gerd


*Von:* mkgmap-dev-boun...@lists.mkgmap.org.uk 
<mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Thomas 
Morgenstern <webmas...@img2ms.de>

*Gesendet:* Samstag, 28. November 2015 15:29
*An:* Development list for mkgmap
*Betreff:* [mkgmap-dev] question for tdb-file record 0x52; option in 
mkgmap ?
Has  mkgmap  a option, which write's the record 0x52 in tdb-file ? 
My maps have in Mapsource all the entry 'Overview map' . But i will 
for example 'Kanaren' or any other countryname. I have testet 
followings option without success: -region-name=anywhat 
;-country.name= anywhat; -description= anywhat. I use -index to 
create the tdb-file. I can use a hexeditor to change  tdb- file- 
record 0x52. But this is not a preferable way. i must recalculate a 
CRC 32 checksum for record 0x54.


By the way: i found a error in the tdb-file, created with mkgmap 
r3650 : it prints in the copyright-section :.../.Map created with 
mkgmap -r3336/...; It should bee updated to ./.r3650/



___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev




___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev




___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] question for tdb-file record 0x52; option in mkgmap ?

Edit nr. 2: all sourcefiles i have uploadet to : 
http://img2ms.de/Downloads/Kanaren+Ceuta.rar  Filesize ~ 14 MB. Maybee 
you can reproduce the error in your IDE ?:.


thomas

Am 28.11.2015 um 19:41 schrieb Thomas Morgenstern:
Edit : the string mkgmap -r3336 is in the Copyrightrecord. Maybee the 
copyright is not updated? Creation-time of tbd-file is: 28.11.2015, 
19:17 Uhr GMT+1 hour


thomas
Am 28.11.2015 um 19:30 schrieb Thomas Morgenstern:
So i have newly downloaded mkgmap-r3650 and run it again. The 
resulting tdb-file is available at : 
http://img2ms.de/Downloads/TopoCeuta.tdb. Look  self in it with 
hexeditor. At dezimalposition 950 you will find  'mkgmap-r3336'. 
Hex-position is 0x3ac.

maybee is the problem the second run ?
regards thomas

Am 28.11.2015 um 18:36 schrieb Gerd Petermann:


Hi Thomas,


I see no way that r3650 produces the string mkgmap-r3336.

So, I guess that you are looking at an old map, which would

also explain that the different options have no effect.


ciao,

Gerd




*Von:* mkgmap-dev-boun...@lists.mkgmap.org.uk 
<mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Thomas 
Morgenstern <webmas...@img2ms.de>

*Gesendet:* Samstag, 28. November 2015 18:08
*An:* Development list for mkgmap
*Betreff:* Re: [mkgmap-dev] question for tdb-file record 0x52; 
option in mkgmap ?
I use mkgmap r-3650 from downloadsite: 
http://www.mkgmap.org.uk/download/mkgmap.html 
-->http://www.mkgmap.org.uk/download/mkgmap-r3650.zip.

<http://www.mkgmap.org.uk/download/mkgmap.html>

mkgmap download page
Branch builds. These jar files are latest builds of recent 
development branches. They are useful if you want to quickly test a 
branch without having obtain and build it.

Weitere Informationen... <http://www.mkgmap.org.uk/download/mkgmap.html>




-family-name=Kanaren also make 'Overview Map'.
My way is:
1. in first run I generate all <123345678>.img from *.osm-pbf . for 
Europa komplett
2. a secand run : /java -Xmx5000m jar mkgmap.jar -family-id=1918 
-product-id=1 -family-name=TopoKanaren -series-name=Topo Kanaren 
-overview-mapname=TopoCeuta -code-page=1252 -mapname=Kanaren 
-index.img-file/s. This creates the 
tdb,preview, mdx and _mdr.img. Works perfekt, but the only mistake 
is : 'Overview Map' .


result is : in mapsource ->Fläche' -->'Overview Map' and not 'Topo 
Kanaren'

Am 28.11.2015 um 17:11 schrieb Gerd Petermann:


Hallo Thomas,


please try --family-name=xyz.


Where did you get the binary that reports mkgmap-r3336 ?

I assume that you build your own binary, in that case please

use these two commands:

svn update

ant clean dist


Gerd


*Von:* mkgmap-dev-boun...@lists.mkgmap.org.uk 
<mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Thomas 
Morgenstern <webmas...@img2ms.de>

*Gesendet:* Samstag, 28. November 2015 15:29
*An:* Development list for mkgmap
*Betreff:* [mkgmap-dev] question for tdb-file record 0x52; option 
in mkgmap ?
Has  mkgmap  a option, which write's the record 0x52 in tdb-file ? 
My maps have in Mapsource all the entry 'Overview map' . But i will 
for example 'Kanaren' or any other countryname. I have testet 
followings option without success: -region-name=anywhat 
;-country.name= anywhat; -description= anywhat. I use -index to 
create the tdb-file. I can use a hexeditor to change  tdb- file- 
record 0x52. But this is not a preferable way. i must recalculate a 
CRC 32 checksum for record 0x54.


By the way: i found a error in the tdb-file, created with mkgmap 
r3650 : it prints in the copyright-section :.../.Map created with 
mkgmap -r3336/...; It should bee updated to ./.r3650/



___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev




___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev






___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] question for tdb-file record 0x52; option in mkgmap ?