Re: [mkgmap-dev] Address search on device with --x-split-name-index option

[Gerd Petermann]

Hi Steve,
same problem with r3449 and r3472.
I did a clean svn checkout for both and compiled and copied the jar into my

My options:
--max-jobs --route --bounds=bounds.zip --index --housenumbers --gmapsupp  
--x-split-name-index -c template.args
The template.args contains a few tiles in the alps. I've uploaded them to
http://files.mkgmap.org.uk/download/346/split.zip
in case you want to try on your own.

Gerd


Von: mkgmap-dev  im Auftrag von Steve 
Ratcliffe 
Gesendet: Sonntag, 9. April 2017 11:52:09
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] Address search on device with --x-split-name-index 
option

Hi

> When I change the code in mdr20 to ignore the additional entries
> produced with the "--x-split-name-index" option the problem seems to
> be solved, I just don't find "Obere Rheingasse" when I search for
> "Rheingasse".

The on device version of mdr20 certainly supports this, so it should
work even if it is broken now.  We need to find out if this ever
worked properly eg in r3472 or r3449

..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] tag landuse=residential produced false areas

[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  im Auftrag von Thomas 
Morgenstern 
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  im Auftrag von Thomas 
Morgenstern 
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
 . 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 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

[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  im Auftrag von Thomas 
Morgenstern 
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  im Auftrag von 
> Thomas Morgenstern 
> 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
>  . 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 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

[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  im Auftrag von Thomas 
Morgenstern 
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
 . 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 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

[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  im Auftrag von Thomas 
Morgenstern 
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
 . 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] tag landuse=residential produced false areas

[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

Re: [mkgmap-dev] gaps in road and other issues with r3875

[lig fietser]

Thanks Gerd, mkgmap-r3890 solved all issues, gap is gone and the small map with 
the default style is visisble again.




Hi Minko,

I think the problem was introduced with r3857. I've reverted those changes in 
r3889. Please check if it also solves the problem with the gap.

Gerd

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

Re: [mkgmap-dev] Commit r3889: revert most changes from r3857, they seem to cause incorrect maps under certain circumstances

[Gerd Petermann]

Hi Steve,

yes, sorry, I've made this error before. r3890 is okay again.

Gerd

Von: mkgmap-dev  im Auftrag von Steve 
Ratcliffe 
Gesendet: Sonntag, 9. April 2017 12:41:33
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] Commit r3889: revert most changes from r3857, they 
seem to cause incorrect maps under certain circumstances

On 09/04/17 11:17, Gerd Petermann wrote:
> please check, this release is not yet available for download

In particular the following line was removed:

  

The builds are done in a clean environment without downloading any
dependencies for optional stuff.
___
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] Commit r3890: revert unintended change in build.xml

[svn commit]

Version mkgmap-r3890 was committed by gerd on Sun, 09 Apr 2017

revert unintended change in build.xml

http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap=3890
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Commit r3889: revert most changes from r3857, they seem to cause incorrect maps under certain circumstances

[Steve Ratcliffe]

On 09/04/17 11:17, Gerd Petermann wrote:

please check, this release is not yet available for download


In particular the following line was removed:

 

The builds are done in a clean environment without downloading any 
dependencies for optional stuff.

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

Re: [mkgmap-dev] Commit r3889: revert most changes from r3857, they seem to cause incorrect maps under certain circumstances

[Steve Ratcliffe]

On 09/04/17 11:17, Gerd Petermann wrote:

please check, this release is not yet available for download.


That's because it doesn't compile :)
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Commit r3889: revert most changes from r3857, they seem to cause incorrect maps under certain circumstances

[Gerd Petermann]

Hi Steve,

please check, this release is not yet available for download.

Gerd

Von: mkgmap-dev  im Auftrag von svn 
commit 
Gesendet: Sonntag, 9. April 2017 11:49:54
An: mkgmap-...@lists.mkgmap.org.uk; mkgmap-dev@lists.mkgmap.org.uk
Betreff: [mkgmap-dev] Commit r3889: revert most changes from r3857, they seem 
to cause incorrect maps under certain circumstances

Version mkgmap-r3889 was committed by gerd on Sun, 09 Apr 2017

revert most changes from r3857, they seem to cause incorrect maps under certain 
circumstances

http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap=3889
___
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 on device with --x-split-name-index option

[Gerd Petermann]

Hi Steve,

okay, I'll try with the older versions.

Gerd

Von: mkgmap-dev  im Auftrag von Steve 
Ratcliffe 
Gesendet: Sonntag, 9. April 2017 11:52:09
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] Address search on device with --x-split-name-index 
option

Hi

> When I change the code in mdr20 to ignore the additional entries
> produced with the "--x-split-name-index" option the problem seems to
> be solved, I just don't find "Obere Rheingasse" when I search for
> "Rheingasse".

The on device version of mdr20 certainly supports this, so it should
work even if it is broken now.  We need to find out if this ever
worked properly eg in r3472 or r3449

..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] gaps in road and other issues with r3875

[Gerd Petermann]

Hi Minko,

I think the problem was introduced with r3857. I've reverted those changes in 
r3889. Please check if it also solves the problem with the gap.

Gerd

Von: mkgmap-dev  im Auftrag von lig 
fietser 
Gesendet: Sonntag, 9. April 2017 11:21:14
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] gaps in road and other issues with r3875

Thanks, encoded it with UTF8 and it is now working,  r3660 accepted ANSI coding 
but later releases not anymore?



Van: mkgmap-dev  namens Gerd Petermann 

Verzonden: zondag 9 april 2017 02:13:47
Aan: Development list for mkgmap
Onderwerp: Re: [mkgmap-dev] gaps in road and other issues with r3875

Hi Minko,

okay, that is probably a problem of utf8 enocoding. Your file is not utf8.

Gerd

Von: mkgmap-dev  im Auftrag von lig 
fietser 
Gesendet: Sonntag, 9. April 2017 11:08:30
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] gaps in road and other issues with r3875

Hi Gerd,

First a minor problem, license2.txt crashes with 3880 but not with 
mkgmap-r3660, (3847 crashes too)


Error reading license file licentie2.txt

java.nio.charset.MalformedInputException: Input length = 1

In my args file I have license-file: licentie2.txt


It has nothing to do with the gaps.


Van: mkgmap-dev  namens Gerd Petermann 

Verzonden: zondag 9 april 2017 01:36:55
Aan: Development list for mkgmap
Onderwerp: Re: [mkgmap-dev] gaps in road and other issues with r3875

Hi Minko,

most changes since r3487 were for the index, 3877 fixed a routing problem. No 
change regarding RGN or handling of license file, esp. no change that would 
explain
the gap.
Don't know how to reproduce that problem. Is it related to OSM data or only to 
options / contents of other input files ?
Please provide a link to a small set of input files + script and let me know 
what you expect and what you get.

Gerd

Von: mkgmap-dev  im Auftrag von lig 
fietser 
Gesendet: Sonntag, 9. April 2017 10:07:49
An: mkgmap-dev
Betreff: [mkgmap-dev] gaps in road and other issues with r3875

Hi,

Users of my OFM map have reported gaps in the roads (mainly non routable lines 
used for highways that are forbidden for cyclists).

I've found out this is worse in the latest mkgmap releases 3875, 3880. See the 
screenshot, the location is 
https://www.openstreetmap.org/?mlat=51.59253=5.33765#map=19/51.59253/5.33765


I have also compiled it with r3847, no gaps.


There are other issues. With the default style I cannot even get a working map 
from the osm file. Something with the overview map is blocking it all?

Really strange, if I open the img with gpsmapedit I can see it contains all the 
data, so something must be wrong with the index or overview files too.

I have found out it makes sense if I leave the %typfile% option out or not (see 
java command below). With no typefile specified, mkgmap r3875 does not show a 
map.

With some typfile behind %argsfile%, everything works as expected (default 
style does not show a gap). I also noticed this mkgmap version crashed on the 
license file, something has changed there too? It contained a ©mark. Only after 
replacing it with (c) mkgmap could finish the job.


java -Xmx4000m -jar %MKGMAP% --product-version=%version% --output-dir=%date% 
--family-id=%FID% --overview-mapname=OFM_%mapname% --series-name="OFM 
(%mapname%v%date%)" --family-name="OFM (%mapname%)" 
--area-name="OFM_%mapname%(%date%)" -c %argsfile% %typfile%




___
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 on device with --x-split-name-index option

[Steve Ratcliffe]

Hi


When I change the code in mdr20 to ignore the additional entries
produced with the "--x-split-name-index" option the problem seems to
be solved, I just don't find "Obere Rheingasse" when I search for
"Rheingasse".


The on device version of mdr20 certainly supports this, so it should
work even if it is broken now.  We need to find out if this ever
worked properly eg in r3472 or r3449

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

[mkgmap-dev] Commit r3889: revert most changes from r3857, they seem to cause incorrect maps under certain circumstances

[svn commit]

Version mkgmap-r3889 was committed by gerd on Sun, 09 Apr 2017

revert most changes from r3857, they seem to cause incorrect maps under certain 
circumstances

http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap=3889
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Possible problem with global search index since r3875

[Steve Ratcliffe]

Hi


The rule that produces the label "13/14 Hauptstrasse"  (start is highway 
shield code) is this:
highway=primary {name '${ref|highway-symbol:box} ${name}' | 
'${ref|highway-symbol:box}' | '${name}'; addlabel '${name} (${ref})' }


This may be unpopular but we should stop doing this.  This was needed
before we could have multiple labels, but that was a long time ago.

The Garmin way to do this is that the name is the first label, then
any refs or alternate names.

So this case would ideally be represented as:

  Label 1: Hauptstrasse
  Label 2: 13
  Label 3: 14

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

Re: [mkgmap-dev] gaps in road and other issues with r3875

[lig fietser]

Thanks, encoded it with UTF8 and it is now working,  r3660 accepted ANSI coding 
but later releases not anymore?



Van: mkgmap-dev  namens Gerd Petermann 

Verzonden: zondag 9 april 2017 02:13:47
Aan: Development list for mkgmap
Onderwerp: Re: [mkgmap-dev] gaps in road and other issues with r3875

Hi Minko,

okay, that is probably a problem of utf8 enocoding. Your file is not utf8.

Gerd

Von: mkgmap-dev  im Auftrag von lig 
fietser 
Gesendet: Sonntag, 9. April 2017 11:08:30
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] gaps in road and other issues with r3875

Hi Gerd,

First a minor problem, license2.txt crashes with 3880 but not with 
mkgmap-r3660, (3847 crashes too)


Error reading license file licentie2.txt

java.nio.charset.MalformedInputException: Input length = 1

In my args file I have license-file: licentie2.txt


It has nothing to do with the gaps.


Van: mkgmap-dev  namens Gerd Petermann 

Verzonden: zondag 9 april 2017 01:36:55
Aan: Development list for mkgmap
Onderwerp: Re: [mkgmap-dev] gaps in road and other issues with r3875

Hi Minko,

most changes since r3487 were for the index, 3877 fixed a routing problem. No 
change regarding RGN or handling of license file, esp. no change that would 
explain
the gap.
Don't know how to reproduce that problem. Is it related to OSM data or only to 
options / contents of other input files ?
Please provide a link to a small set of input files + script and let me know 
what you expect and what you get.

Gerd

Von: mkgmap-dev  im Auftrag von lig 
fietser 
Gesendet: Sonntag, 9. April 2017 10:07:49
An: mkgmap-dev
Betreff: [mkgmap-dev] gaps in road and other issues with r3875

Hi,

Users of my OFM map have reported gaps in the roads (mainly non routable lines 
used for highways that are forbidden for cyclists).

I've found out this is worse in the latest mkgmap releases 3875, 3880. See the 
screenshot, the location is 
https://www.openstreetmap.org/?mlat=51.59253=5.33765#map=19/51.59253/5.33765


I have also compiled it with r3847, no gaps.


There are other issues. With the default style I cannot even get a working map 
from the osm file. Something with the overview map is blocking it all?

Really strange, if I open the img with gpsmapedit I can see it contains all the 
data, so something must be wrong with the index or overview files too.

I have found out it makes sense if I leave the %typfile% option out or not (see 
java command below). With no typefile specified, mkgmap r3875 does not show a 
map.

With some typfile behind %argsfile%, everything works as expected (default 
style does not show a gap). I also noticed this mkgmap version crashed on the 
license file, something has changed there too? It contained a ©mark. Only after 
replacing it with (c) mkgmap could finish the job.


java -Xmx4000m -jar %MKGMAP% --product-version=%version% --output-dir=%date% 
--family-id=%FID% --overview-mapname=OFM_%mapname% --series-name="OFM 
(%mapname%v%date%)" --family-name="OFM (%mapname%)" 
--area-name="OFM_%mapname%(%date%)" -c %argsfile% %typfile%




___
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] gaps in road and other issues with r3875

[lig fietser]

Next issue is the gap.

The gap is only visisble with my OFM styles. Other map styles are ok.

It appears with r3875 and later. Does not appear with r3847. The hole is 
exactly at the junction from the Schijndelseweg where two lanes merge, I think 
mkgmap throws away a connection node? Nothing severe for routing because I dont 
use those roads for routing (non routable lines).


Test file is here:

https://drive.google.com/open?id=0B2FG7SFUssGqQVFJUEV4a3NsZ1k





Van: mkgmap-dev  namens lig fietser 

Verzonden: zondag 9 april 2017 02:08:30
Aan: Development list for mkgmap
Onderwerp: Re: [mkgmap-dev] gaps in road and other issues with r3875


Hi Gerd,

First a minor problem, license2.txt crashes with 3880 but not with 
mkgmap-r3660, (3847 crashes too)


Error reading license file licentie2.txt

java.nio.charset.MalformedInputException: Input length = 1

In my args file I have license-file: licentie2.txt


It has nothing to do with the gaps.


Van: mkgmap-dev  namens Gerd Petermann 

Verzonden: zondag 9 april 2017 01:36:55
Aan: Development list for mkgmap
Onderwerp: Re: [mkgmap-dev] gaps in road and other issues with r3875

Hi Minko,

most changes since r3487 were for the index, 3877 fixed a routing problem. No 
change regarding RGN or handling of license file, esp. no change that would 
explain
the gap.
Don't know how to reproduce that problem. Is it related to OSM data or only to 
options / contents of other input files ?
Please provide a link to a small set of input files + script and let me know 
what you expect and what you get.

Gerd

Von: mkgmap-dev  im Auftrag von lig 
fietser 
Gesendet: Sonntag, 9. April 2017 10:07:49
An: mkgmap-dev
Betreff: [mkgmap-dev] gaps in road and other issues with r3875

Hi,

Users of my OFM map have reported gaps in the roads (mainly non routable lines 
used for highways that are forbidden for cyclists).

I've found out this is worse in the latest mkgmap releases 3875, 3880. See the 
screenshot, the location is 
https://www.openstreetmap.org/?mlat=51.59253=5.33765#map=19/51.59253/5.33765


I have also compiled it with r3847, no gaps.


There are other issues. With the default style I cannot even get a working map 
from the osm file. Something with the overview map is blocking it all?

Really strange, if I open the img with gpsmapedit I can see it contains all the 
data, so something must be wrong with the index or overview files too.

I have found out it makes sense if I leave the %typfile% option out or not (see 
java command below). With no typefile specified, mkgmap r3875 does not show a 
map.

With some typfile behind %argsfile%, everything works as expected (default 
style does not show a gap). I also noticed this mkgmap version crashed on the 
license file, something has changed there too? It contained a ©mark. Only after 
replacing it with (c) mkgmap could finish the job.


java -Xmx4000m -jar %MKGMAP% --product-version=%version% --output-dir=%date% 
--family-id=%FID% --overview-mapname=OFM_%mapname% --series-name="OFM 
(%mapname%v%date%)" --family-name="OFM (%mapname%)" 
--area-name="OFM_%mapname%(%date%)" -c %argsfile% %typfile%




___
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] gaps in road and other issues with r3875

[Gerd Petermann]

Hi Minko,

okay, that is probably a problem of utf8 enocoding. Your file is not utf8.

Gerd

Von: mkgmap-dev  im Auftrag von lig 
fietser 
Gesendet: Sonntag, 9. April 2017 11:08:30
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] gaps in road and other issues with r3875

Hi Gerd,

First a minor problem, license2.txt crashes with 3880 but not with 
mkgmap-r3660, (3847 crashes too)


Error reading license file licentie2.txt

java.nio.charset.MalformedInputException: Input length = 1

In my args file I have license-file: licentie2.txt


It has nothing to do with the gaps.


Van: mkgmap-dev  namens Gerd Petermann 

Verzonden: zondag 9 april 2017 01:36:55
Aan: Development list for mkgmap
Onderwerp: Re: [mkgmap-dev] gaps in road and other issues with r3875

Hi Minko,

most changes since r3487 were for the index, 3877 fixed a routing problem. No 
change regarding RGN or handling of license file, esp. no change that would 
explain
the gap.
Don't know how to reproduce that problem. Is it related to OSM data or only to 
options / contents of other input files ?
Please provide a link to a small set of input files + script and let me know 
what you expect and what you get.

Gerd

Von: mkgmap-dev  im Auftrag von lig 
fietser 
Gesendet: Sonntag, 9. April 2017 10:07:49
An: mkgmap-dev
Betreff: [mkgmap-dev] gaps in road and other issues with r3875

Hi,

Users of my OFM map have reported gaps in the roads (mainly non routable lines 
used for highways that are forbidden for cyclists).

I've found out this is worse in the latest mkgmap releases 3875, 3880. See the 
screenshot, the location is 
https://www.openstreetmap.org/?mlat=51.59253=5.33765#map=19/51.59253/5.33765


I have also compiled it with r3847, no gaps.


There are other issues. With the default style I cannot even get a working map 
from the osm file. Something with the overview map is blocking it all?

Really strange, if I open the img with gpsmapedit I can see it contains all the 
data, so something must be wrong with the index or overview files too.

I have found out it makes sense if I leave the %typfile% option out or not (see 
java command below). With no typefile specified, mkgmap r3875 does not show a 
map.

With some typfile behind %argsfile%, everything works as expected (default 
style does not show a gap). I also noticed this mkgmap version crashed on the 
license file, something has changed there too? It contained a ©mark. Only after 
replacing it with (c) mkgmap could finish the job.


java -Xmx4000m -jar %MKGMAP% --product-version=%version% --output-dir=%date% 
--family-id=%FID% --overview-mapname=OFM_%mapname% --series-name="OFM 
(%mapname%v%date%)" --family-name="OFM (%mapname%)" 
--area-name="OFM_%mapname%(%date%)" -c %argsfile% %typfile%




___
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] gaps in road and other issues with r3875

[lig fietser]

Hi Gerd,

First a minor problem, license2.txt crashes with 3880 but not with 
mkgmap-r3660, (3847 crashes too)


Error reading license file licentie2.txt

java.nio.charset.MalformedInputException: Input length = 1

In my args file I have license-file: licentie2.txt


It has nothing to do with the gaps.


Van: mkgmap-dev  namens Gerd Petermann 

Verzonden: zondag 9 april 2017 01:36:55
Aan: Development list for mkgmap
Onderwerp: Re: [mkgmap-dev] gaps in road and other issues with r3875

Hi Minko,

most changes since r3487 were for the index, 3877 fixed a routing problem. No 
change regarding RGN or handling of license file, esp. no change that would 
explain
the gap.
Don't know how to reproduce that problem. Is it related to OSM data or only to 
options / contents of other input files ?
Please provide a link to a small set of input files + script and let me know 
what you expect and what you get.

Gerd

Von: mkgmap-dev  im Auftrag von lig 
fietser 
Gesendet: Sonntag, 9. April 2017 10:07:49
An: mkgmap-dev
Betreff: [mkgmap-dev] gaps in road and other issues with r3875

Hi,

Users of my OFM map have reported gaps in the roads (mainly non routable lines 
used for highways that are forbidden for cyclists).

I've found out this is worse in the latest mkgmap releases 3875, 3880. See the 
screenshot, the location is 
https://www.openstreetmap.org/?mlat=51.59253=5.33765#map=19/51.59253/5.33765


I have also compiled it with r3847, no gaps.


There are other issues. With the default style I cannot even get a working map 
from the osm file. Something with the overview map is blocking it all?

Really strange, if I open the img with gpsmapedit I can see it contains all the 
data, so something must be wrong with the index or overview files too.

I have found out it makes sense if I leave the %typfile% option out or not (see 
java command below). With no typefile specified, mkgmap r3875 does not show a 
map.

With some typfile behind %argsfile%, everything works as expected (default 
style does not show a gap). I also noticed this mkgmap version crashed on the 
license file, something has changed there too? It contained a ©mark. Only after 
replacing it with (c) mkgmap could finish the job.


java -Xmx4000m -jar %MKGMAP% --product-version=%version% --output-dir=%date% 
--family-id=%FID% --overview-mapname=OFM_%mapname% --series-name="OFM 
(%mapname%v%date%)" --family-name="OFM (%mapname%)" 
--area-name="OFM_%mapname%(%date%)" -c %argsfile% %typfile%




___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Contourlines © SRTM-Data / NASA
and Jonathan de Ferranti (viewfinderpanoramas.org)
Disclaimer:
Please note that the software is experimental and
provided "as is," and you use the software at your own risk.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] gaps in road and other issues with r3875

[Gerd Petermann]

Hi Minko,

okay, tried with that small area and no options beside --nsis
and yes, MapSource doesn't show a map. With older version it works. No idea 
why, I have to compare the img  files.

Gerd



Von: mkgmap-dev  im Auftrag von Gerd 
Petermann 
Gesendet: Sonntag, 9. April 2017 10:36:55
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] gaps in road and other issues with r3875

Hi Minko,

most changes since r3487 were for the index, 3877 fixed a routing problem. No 
change regarding RGN or handling of license file, esp. no change that would 
explain
the gap.
Don't know how to reproduce that problem. Is it related to OSM data or only to 
options / contents of other input files ?
Please provide a link to a small set of input files + script and let me know 
what you expect and what you get.

Gerd

Von: mkgmap-dev  im Auftrag von lig 
fietser 
Gesendet: Sonntag, 9. April 2017 10:07:49
An: mkgmap-dev
Betreff: [mkgmap-dev] gaps in road and other issues with r3875

Hi,

Users of my OFM map have reported gaps in the roads (mainly non routable lines 
used for highways that are forbidden for cyclists).

I've found out this is worse in the latest mkgmap releases 3875, 3880. See the 
screenshot, the location is 
https://www.openstreetmap.org/?mlat=51.59253=5.33765#map=19/51.59253/5.33765


I have also compiled it with r3847, no gaps.


There are other issues. With the default style I cannot even get a working map 
from the osm file. Something with the overview map is blocking it all?

Really strange, if I open the img with gpsmapedit I can see it contains all the 
data, so something must be wrong with the index or overview files too.

I have found out it makes sense if I leave the %typfile% option out or not (see 
java command below). With no typefile specified, mkgmap r3875 does not show a 
map.

With some typfile behind %argsfile%, everything works as expected (default 
style does not show a gap). I also noticed this mkgmap version crashed on the 
license file, something has changed there too? It contained a ©mark. Only after 
replacing it with (c) mkgmap could finish the job.


java -Xmx4000m -jar %MKGMAP% --product-version=%version% --output-dir=%date% 
--family-id=%FID% --overview-mapname=OFM_%mapname% --series-name="OFM 
(%mapname%v%date%)" --family-name="OFM (%mapname%)" 
--area-name="OFM_%mapname%(%date%)" -c %argsfile% %typfile%




___
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] gaps in road and other issues with r3875

[Gerd Petermann]

Hi Minko,

most changes since r3487 were for the index, 3877 fixed a routing problem. No 
change regarding RGN or handling of license file, esp. no change that would 
explain
the gap.
Don't know how to reproduce that problem. Is it related to OSM data or only to 
options / contents of other input files ?
Please provide a link to a small set of input files + script and let me know 
what you expect and what you get.

Gerd

Von: mkgmap-dev  im Auftrag von lig 
fietser 
Gesendet: Sonntag, 9. April 2017 10:07:49
An: mkgmap-dev
Betreff: [mkgmap-dev] gaps in road and other issues with r3875

Hi,

Users of my OFM map have reported gaps in the roads (mainly non routable lines 
used for highways that are forbidden for cyclists).

I've found out this is worse in the latest mkgmap releases 3875, 3880. See the 
screenshot, the location is 
https://www.openstreetmap.org/?mlat=51.59253=5.33765#map=19/51.59253/5.33765


I have also compiled it with r3847, no gaps.


There are other issues. With the default style I cannot even get a working map 
from the osm file. Something with the overview map is blocking it all?

Really strange, if I open the img with gpsmapedit I can see it contains all the 
data, so something must be wrong with the index or overview files too.

I have found out it makes sense if I leave the %typfile% option out or not (see 
java command below). With no typefile specified, mkgmap r3875 does not show a 
map.

With some typfile behind %argsfile%, everything works as expected (default 
style does not show a gap). I also noticed this mkgmap version crashed on the 
license file, something has changed there too? It contained a ©mark. Only after 
replacing it with (c) mkgmap could finish the job.


java -Xmx4000m -jar %MKGMAP% --product-version=%version% --output-dir=%date% 
--family-id=%FID% --overview-mapname=OFM_%mapname% --series-name="OFM 
(%mapname%v%date%)" --family-name="OFM (%mapname%)" 
--area-name="OFM_%mapname%(%date%)" -c %argsfile% %typfile%




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

Re: [mkgmap-dev] Address search on device with --x-split-name-index option

[lig fietser]

I think I got the same results on my Oregon 600, so thats why I dont use 
--x-split-name-index



Van: mkgmap-dev  namens Gerd Petermann 

Verzonden: zondag 9 april 2017 01:15:02
Aan: mkgmap-dev@lists.mkgmap.org.uk
Onderwerp: [mkgmap-dev] Address search on device with --x-split-name-index 
option

Hi all,

not sure how this works on other devices. I have a map containing a part of the 
alps with parts of Germany, Switzerland and France.
On my Oregon 600 when I search for an address I have some dialogs
1) select a country (I select Switzerland)
2) select city or select "search all"
3) Enter Street name. I can type a few characters and press enter. The device 
presents a list of road names matching the selected characters.
4) Last is to enter the house number.  I can leave it empty to search for 
streets.

If I select a city (Feuerthalen)in step 2) everything seems to work fine. It 
lists "Obere Rheingasse" as well as "Rheingasse" when I enter "Rheinga".
If I select "search all" the results are weird. Sometimes I get "no result, 
change search parameters", sometimes results look ok.

When I change the code in mdr20 to ignore the additional entries produced with 
the "--x-split-name-index" option the problem seems to be solved,
I just don't find "Obere Rheingasse" when I search for "Rheingasse".

Does anybody see better results in this case with a map produced  with trunk?

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] Address search on device with --x-split-name-index option

[Gerd Petermann]

Hi all,

not sure how this works on other devices. I have a map containing a part of the 
alps with parts of Germany, Switzerland and France.
On my Oregon 600 when I search for an address I have some dialogs
1) select a country (I select Switzerland)
2) select city or select "search all"
3) Enter Street name. I can type a few characters and press enter. The device 
presents a list of road names matching the selected characters.
4) Last is to enter the house number.  I can leave it empty to search for 
streets.

If I select a city (Feuerthalen)in step 2) everything seems to work fine. It 
lists "Obere Rheingasse" as well as "Rheingasse" when I enter "Rheinga".
If I select "search all" the results are weird. Sometimes I get "no result, 
change search parameters", sometimes results look ok.

When I change the code in mdr20 to ignore the additional entries produced with 
the "--x-split-name-index" option the problem seems to be solved,
I just don't find "Obere Rheingasse" when I search for "Rheingasse".

Does anybody see better results in this case with a map produced  with trunk?

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

[mkgmap-dev] gaps in road and other issues with r3875

[lig fietser]

Hi,

Users of my OFM map have reported gaps in the roads (mainly non routable lines 
used for highways that are forbidden for cyclists).

I've found out this is worse in the latest mkgmap releases 3875, 3880. See the 
screenshot, the location is 
https://www.openstreetmap.org/?mlat=51.59253=5.33765#map=19/51.59253/5.33765


I have also compiled it with r3847, no gaps.


There are other issues. With the default style I cannot even get a working map 
from the osm file. Something with the overview map is blocking it all?

Really strange, if I open the img with gpsmapedit I can see it contains all the 
data, so something must be wrong with the index or overview files too.

I have found out it makes sense if I leave the %typfile% option out or not (see 
java command below). With no typefile specified, mkgmap r3875 does not show a 
map.

With some typfile behind %argsfile%, everything works as expected (default 
style does not show a gap). I also noticed this mkgmap version crashed on the 
license file, something has changed there too? It contained a ©mark. Only after 
replacing it with (c) mkgmap could finish the job.


java -Xmx4000m -jar %MKGMAP% --product-version=%version% --output-dir=%date% 
--family-id=%FID% --overview-mapname=OFM_%mapname% --series-name="OFM 
(%mapname%v%date%)" --family-name="OFM (%mapname%)" 
--area-name="OFM_%mapname%(%date%)" -c %argsfile% %typfile%



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