Re: [mkgmap-dev] osm combiner error

[paco . tyson]

Hi all,

By the way, are splitter/mkgmap compatible with java8 now ?

Thanks,
Paco

- Mail original -
De: "Steve Ratcliffe" 
À: "Development list for mkgmap" 
Envoyé: Mardi 22 Mars 2016 17:14:45
Objet: Re: [mkgmap-dev] osm combiner error


> What does Unsupported major.minor version 51.0 mean?

This happens when you try to run with Java 6 or lower. I realise that he says 
he on the latest version of Java and the previous version of osm combiner was 
running OK, so there may be more to it. The last version of mkgmap that worked 
with Java 6 was a long time ago.

.. Steve

On 22 March 2016 15:37:28 GMT+00:00, Minko  wrote:
>Hi,
>On the osm forum someone reported this error with OSM combiner
>(http://www.openfietsmap.nl/news/osmcombiner) (mkgmap r.3654)
>http://forum.openstreetmap.org/viewtopic.php?id=30632
>
>What does Unsupported major.minor version 51.0 mean?
>
>--
>
>Unfortunately the new OSM Combiner 1.8 did not solve the problem for
>me.
>I dowloaded a fresh set of osm_generic_tiles.zip files for the
>Netherlands, Belgium and France and tried to combine them with OSM
>combiner 1.8 but consistently get an error message (see below). All
>steps up to "Start" work, the final step fails and gives the error
>message.
>I use MacOS 10.11.3 with the latest Java installed and allocated 5gb of
>memory to Java, disk space is plenty.
>
>What am I doing wrong?
>
>Thank you!
>
>--- Error message:
>
>Exception in thread "main" java.lang.UnsupportedClassVersionError:
>uk/me/parabola/mkgmap/main/Main : Unsupported major.minor version 51.0
>at java.lang.ClassLoader.defineClass1(Native Method)
>at java.lang.ClassLoader.defineClassCond(ClassLoader.java:637)
>at java.lang.ClassLoader.defineClass(ClassLoader.java:621)
>at
>java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
>at java.net.URLClassLoader.defineClass(URLClassLoader.java:283)
>at java.net.URLClassLoader.access$000(URLClassLoader.java:58)
>at java.net.URLClassLoader$1.run(URLClassLoader.java:197)
>at java.security.AccessController.doPrivileged(Native Method)
>at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
>at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
>at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
>at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
>___
>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] Improve error reporting for a corrupted sea.zip file

[paco . tyson]

Hi all,

I found that mkgmap can display an exception with a confusing description :

Time started: Wed Feb 10 14:27:05 CET 2016
GRAVE (SeaGenerator): D:\tmp\idf-generic\14070303.osm.pbf: Cannot read index 
file index.txt.gz
java.util.zip.ZipException: error in opening zip file
at java.util.zip.ZipFile.open(Native Method)
at java.util.zip.ZipFile.(ZipFile.java:215)
at java.util.zip.ZipFile.(ZipFile.java:145)
at java.util.zip.ZipFile.(ZipFile.java:159)
at 
uk.me.parabola.mkgmap.reader.osm.SeaGenerator.init(SeaGenerator.java:161)
at 
uk.me.parabola.mkgmap.reader.osm.OsmMapDataSource.pluginChain(OsmMapDataSource.java:209)
at 
uk.me.parabola.mkgmap.reader.osm.OsmMapDataSource.setupHandler(OsmMapDataSource.java:180)
at 
uk.me.parabola.mkgmap.reader.osm.bin.OsmBinMapDataSource.load(OsmBinMapDataSource.java:49)
at 
uk.me.parabola.mkgmap.reader.osm.OsmMapDataSource.load(OsmMapDataSource.java:130)
at uk.me.parabola.mkgmap.main.MapMaker.loadFromFile(MapMaker.java:154)
at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:52)
at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:255)
at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:251)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)

At first, I understood that the pbf file is corrupted (this exception is thrown 
for each .pbf file). Actually, the pbf files are OK : the error is the sea.zip 
file that is corrupted. I improved the error reporting in the attached patch.
I'd like to have mkgmap fail when this happens but I don't know how to do that.


Lambertus, I think you're the person providing the sea and bounds files at 
http://osm2.pleiades.uni-wuppertal.de/ , can you provide a checksum file for 
these files in order to detect bad downloads ?


Thanks,
Paco
Index: mkgmap/reader/osm/SeaGenerator.java
===
--- mkgmap/reader/osm/SeaGenerator.java	(revision 3665)
+++ mkgmap/reader/osm/SeaGenerator.java	(working copy)
@@ -184,7 +184,7 @@
 			try{
 precompData = loadIndex(indexStream);
 			} catch (IOException exp) {
-log.error("Cannot read index file " + indexFileName,
+log.error("Cannot read index file " + indexFileName + " in " + precompSeaDir,
 		exp);
 			}
 			
@@ -198,7 +198,7 @@
 			indexStream.close();
 		}
 	} catch (IOException exp) {
-		log.error("Cannot read index file " + indexFileName,
+		log.error("Cannot read index file " + indexFileName + " in " + precompSeaDir,
 exp);
 
 	}
___
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.

[Paco Tyson]

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

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

[Paco Tyson]

The option is indeed returned by "java -jar mkgmap.jar --help=options"

I use mkgmap inside an Ant wrapper script : args are passed inside a file. If I 
add —x-split-name-index inside in this args file, mkgmap crashes with an 
exception. If I add the option as a command line arg (hardcoded in the Ant 
script), then mkgmap runs OK. Is this intended ?

Cheers,
Paco

> Le 31 déc. 2015 à 14:57, Gerd Petermann <gpetermann_muenc...@hotmail.com> a 
> écrit :
> 
> 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] Address search index questions.

[Paco Tyson]

Hhm, Gerd, please discard what I wrote below, I forgot to remove the 2 dashes 
in the option name when I added it to the option file. It is accepted in the 
option file.

Sorry for the noise.

Paco.

> Le 31 déc. 2015 à 15:19, Paco Tyson <paco.ty...@free.fr> a écrit :
> 
> The option is indeed returned by "java -jar mkgmap.jar --help=options"
> 
> I use mkgmap inside an Ant wrapper script : args are passed inside a file. If 
> I add —x-split-name-index inside in this args file, mkgmap crashes with an 
> exception. If I add the option as a command line arg (hardcoded in the Ant 
> script), then mkgmap runs OK. Is this intended ?
> 
> Cheers,
> Paco
> 
>> Le 31 déc. 2015 à 14:57, Gerd Petermann <gpetermann_muenc...@hotmail.com> a 
>> écrit :
>> 
>> 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

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

Re: [mkgmap-dev] Commit: r3620: improve throughput in HousenumberGenerator

[Paco Tyson]

Hi Gerd,

 Version mkgmap-r3620 was committed by gerd on Wed, 10 Jun 2015
 
 improve throughput in HousenumberGenerator
 
 - shuffle road points before adding to (unbalanced) k-d-tree, this 
 drastically reduces tree depth 
 and thus improves both the creation speed and the search speed

Speed improvement while generating the map or when using it in BC/GPS ?

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

Re: [mkgmap-dev] GUI for POI Search TYPES

[Paco Tyson]

Hi everyone,

I can't run this software and I'm wondering what it does exactly.
I understand that it creates an OSM file of a grid of all POI types in a 
specified range. Then you can run mkgmap to generate a Garmin map from this 
source file.

If that's true,
1) mkgmap.jar produces a map of all POIs in a grid pattern when called without 
any argument. How does POI-tester compares to that ?
2) Why there's a dependency on mkgmap r3612 ?


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

Re: [mkgmap-dev] Wrong adresses for 3 french cities

[Paco Tyson]

Hi Gerd,

What kind of special rule do you think of ?

This is how it should work : in France, we don't use admin_level=9 expect for 3 
cities (Paris, Lyon, Marseille).
For an address in these 3 cities, the city name is still the one from 
admin_level=8 but the post code is from admin_level=9. We don't use 
admin_level=9 boundaries for anything else.

Having said that, the current default style is wrong as it gets the name from 
admin_level=9 instead of 8.

Paco

Le 5 juin 2015 à 11:21, Gerd Petermann gpetermann_muenc...@hotmail.com a 
écrit :

 Hi Paco,
 
 I wonder if we should add a special rule for Paris instead like we do for 
 other large cities.
 
 I'll run a few tests to find out more.
 
 Gerd
 
  From: paco.ty...@free.fr
  Date: Thu, 4 Jun 2015 22:59:15 +0200
  To: mkgmap-dev@lists.mkgmap.org.uk
  Subject: [mkgmap-dev] Wrong adresses for 3 french cities
  
  Hi,
  
  I had a look at the default style for addresses and found out what I think 
  is a bug for 3 French cities.
  We shouldn't have the lines : 
  
  mkgmap:country=FRA  mkgmap:city!=*  mkgmap:admin_level9=* { set 
  mkgmap:city='${mkgmap:admin_level9}' }
  mkgmap:country=FRA  mkgmap:city!=*  mkgmap:admin_level8=* { set 
  mkgmap:city='${mkgmap:admin_level8}' }
  
  As described in this 2 year old thread : 
  http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2013q2/017982.html
  It seems WanMil never deleted those 2 lines.
  
  Can somebody please update the inc/address file ?
  
  Thanks,
  Paco
  ___
  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 adresses for 3 french cities

[Paco Tyson]

Hi,

I had a look at the default style for addresses and found out what I think is a 
bug for 3 French cities.
We shouldn't have the lines : 

mkgmap:country=FRA  mkgmap:city!=*  mkgmap:admin_level9=* { set 
mkgmap:city='${mkgmap:admin_level9}' }
mkgmap:country=FRA  mkgmap:city!=*  mkgmap:admin_level8=* { set 
mkgmap:city='${mkgmap:admin_level8}' }

As described in this 2 year old thread : 
http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2013q2/017982.html
It seems WanMil never deleted those 2 lines.

Can somebody please update the inc/address file ?

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

[mkgmap-dev] Exception with location-autofill option on r3605

[Paco Tyson]

Hi all,

I've updated mkgmap from r3596 to r3605 to try the house number improvements. 
Nothing else in my toolchain changed.

mkgmap returns the following exception 6 times, I can't explain why they appear 
as nothing in the change logs is related to this option (location-autofill: 
is-in,nearest) : 

 [java] java.lang.IllegalArgumentException: is-in is not a known sub option 
for option location-autofill: is-in,nearest
 [java] at 
uk.me.parabola.mkgmap.build.LocatorUtil.parseAutofillOption(LocatorUtil.java:75)
 [java] at uk.me.parabola.mkgmap.build.Locator.init(Locator.java:52)
 [java] at 
uk.me.parabola.mkgmap.reader.osm.boundary.BoundaryLocationPreparer.init(BoundaryLocationPreparer.java:57)
 [java] at 
uk.me.parabola.mkgmap.reader.osm.boundary.BoundaryQuadTree.init(BoundaryQuadTree.java:107)
 [java] at 
uk.me.parabola.mkgmap.reader.osm.boundary.BoundaryUtil.loadQuadTreeFromStream(BoundaryUtil.java:493)
 [java] at 
uk.me.parabola.mkgmap.reader.osm.boundary.BoundaryUtil.loadQuadTrees(BoundaryUtil.java:176)
 [java] at 
uk.me.parabola.mkgmap.reader.osm.boundary.BoundaryGrid.init(BoundaryGrid.java:103)
 [java] at 
uk.me.parabola.mkgmap.reader.osm.boundary.BoundaryGrid.init(BoundaryGrid.java:66)
 [java] at 
uk.me.parabola.mkgmap.reader.osm.LocationHook.end(LocationHook.java:98)
 [java] at 
uk.me.parabola.mkgmap.reader.osm.OsmReadingHooksChain.end(OsmReadingHooksChain.java:79)
 [java] at 
uk.me.parabola.mkgmap.reader.osm.bin.OsmBinMapDataSource.load(OsmBinMapDataSource.java:63)
 [java] at 
uk.me.parabola.mkgmap.reader.osm.OsmMapDataSource.load(OsmMapDataSource.java:130)
 [java] at 
uk.me.parabola.mkgmap.main.MapMaker.loadFromFile(MapMaker.java:154)
 [java] at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:52)
 [java] at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:255)
 [java] at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:251)
 [java] at java.util.concurrent.FutureTask.run(FutureTask.java:262)
 [java] at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
 [java] at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
 [java] at java.lang.Thread.run(Thread.java:744)

The produced files are corrupt.

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

Re: [mkgmap-dev] [Patch v1] use role=label member to place POI

[paco . tyson]

Hi Gerd,

I found the case I was talking about, it's the relation for France ( 
http://www.openstreetmap.org/relation/2202162 )

Paco.

- Mail original -
De: Gerd Petermann gpetermann_muenc...@hotmail.com
À: mkgmap-dev@lists.mkgmap.org.uk
Envoyé: Mercredi 20 Mai 2015 17:07:32
Objet: Re: [mkgmap-dev] [Patch v1] use role=label member to place POI



Hi Paco, 

the first one that matches is used. Do you think that one should be prefered? 
Do you have a case where both nodes have the same name as the relation itself? 

Gerd 



From: paco.ty...@free.fr 
Date: Wed, 20 May 2015 16:58:45 +0200 
To: mkgmap-dev@lists.mkgmap.org.uk 
Subject: Re: [mkgmap-dev] [Patch v1] use role=label member to place POI 

Hi Gerd, 


What happens when the relation has both role=label and role=admin_centre ? 





Le 20 mai 2015 à 16:41, Gerd Petermann  gpetermann_muenc...@hotmail.com  a 
écrit : 




Hi all, 

quite a lot of mp-relations have a node member with role=label. 

The attached patch changes the code for the --add-pois-to-areas option 
so that the location of this node is used for the generated POI 
when the name of the node and the name of the relation are equal 
(like with role=admin_centre) 

A binary is here: 
http://files.mkgmap.org.uk/download/268/mkgmap.jar 

Gerd 


use-label-node-v1.patch ___ 
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] [Patch v1] use role=label member to place POI

[Paco Tyson]

Gerd,

I don't really have an opinion on which one should be preferred, I was just 
asking out of curiosity.
The first matching means the first in the list of objects linked to the 
relation, am I right ?

I have seen label used in the past, I can't guarantee you that both were set 
but as usual with OSM, we can't eliminate this combination.

Paco

Le 20 mai 2015 à 17:07, Gerd Petermann gpetermann_muenc...@hotmail.com a 
écrit :

 Hi Paco,
 
 the first one that matches is used. Do you think that one should be prefered?
 Do you have a case where both nodes have the same name as the relation itself?
 
 Gerd
 
 From: paco.ty...@free.fr
 Date: Wed, 20 May 2015 16:58:45 +0200
 To: mkgmap-dev@lists.mkgmap.org.uk
 Subject: Re: [mkgmap-dev] [Patch v1] use role=label member to place POI
 
 Hi Gerd,
 
 What happens when the relation has both role=label and role=admin_centre ?
 
 
 Le 20 mai 2015 à 16:41, Gerd Petermann gpetermann_muenc...@hotmail.com a 
 écrit :
 
 Hi all,
 
 quite a lot of mp-relations have a node member with role=label.
 
 The attached patch changes the code for the --add-pois-to-areas option
 so that the location of this node is used for the generated POI
 when the name of the node and the name of the relation are equal
 (like with role=admin_centre)
 
 A binary is here:
 http://files.mkgmap.org.uk/download/268/mkgmap.jar
 
 Gerd
 
 
 use-label-node-v1.patch___
 mkgmap-dev mailing list
 mkgmap-dev@lists.mkgmap.org.uk
 http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
 
 
 ___ mkgmap-dev mailing 
 listmkgmap-...@lists.mkgmap.org.ukhttp://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] [Patch v1] use role=label member to place POI

[Paco Tyson]

Hi Gerd,

What happens when the relation has both role=label and role=admin_centre ?


Le 20 mai 2015 à 16:41, Gerd Petermann gpetermann_muenc...@hotmail.com a 
écrit :

 Hi all,
 
 quite a lot of mp-relations have a node member with role=label.
 
 The attached patch changes the code for the --add-pois-to-areas option
 so that the location of this node is used for the generated POI
 when the name of the node and the name of the relation are equal
 (like with role=admin_centre)
 
 A binary is here:
 http://files.mkgmap.org.uk/download/268/mkgmap.jar
 
 Gerd
 
 
 use-label-node-v1.patch___
 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] License and copyright text defects

[Paco Tyson]

Hi Thorsten,

Le 15 mai 2015 à 22:08, Thorsten Kukuk ku...@suse.de a écrit :

 On Fri, May 15, Paco Tyson wrote:
 
 This is the license and copyright text : 
 
 Your format is wrong. A newline defines a new license, not
 a new line. GARMIN Software and devices will sort the different
 licenses and remove duplicates before displaying them.

I understand what you wrote but I doesn't match with the documentation nor the 
default text that mkgmap produces : 
Map data (c) OpenStreetMap and its contributors
http://www.openstreetmap.org/copyright

This map data is made available under the Open Database License:
http://opendatacommons.org/licenses/odbl/1.0/
Any rights in individual contents of the database are licensed under the
Database Contents License: http://opendatacommons.org/licenses/dbcl/1.0/

Each line is not a new license. Or maybe you mean that we should separate 
licenses by an empty line ?

 
 Independently of the exposed results above, I have a few questions and 
 remarks :
 - Despite providing a lower case copyright text, the result text is in upper 
 case. Is it done by mkgmap ? Is it a Garmin format limitation ?
 
 It's done by the Software/Device displaying this.
 
 - In the default license/copyright text, one can read Program released 
 under the GPL and PROGRAM LICENCED UNDER GPL V2. I assume it's the mkgmap 
 license, instead I'd expect here the license of the produced Garmin map.
 
 The default license cannot show the license of your map, the mkgmap
 devlopers don't know them.

Yes, of course but my point is that the default text added by mkgmap should be 
something else than the mkgmap license.

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

[mkgmap-dev] License and copyright text defects

[Paco Tyson]

Hi all,

I started customizing the copyright/license text for my map. I found some 
strange results that I want to share with you.

This is the license and copyright text : 
license.txt : 
My license text
Second line of license
Third and last line, blabla êß

copyright.txt :
Beginning of the copyright text
Second line of the copyright text, including accentuated characters : éàß
Third and last line of the copyright text

For each run, I run mkgmap v3539, create a .gmap map with jmc_cli, install it 
on Basecamp thanks to MapManager. I then install it on my Oregon 600 via 
MapInstall.

First run : --license-file=license.txt and --copyright-file=copyright.txt
JaVaWa GMTK displays :
My license text
Second line of license
Third and last line, blabla êß

BEGINNING OF THE COPYRIGHT TEXT
SECOND LINE OF THE COPYRIGHT TEXT, INCLUDING ACCENTUATED CHARACTERS : ÉÀSS
THIRD AND LAST LINE OF THE COPYRIGHT TEXT

Basecamp displays : 
BEGINNING OF THE COPYRIGHT TEXT
My license text
Second line of license
Third and last line, blabla êß

SECOND LINE OF THE COPYRIGHT TEXT, INCLUDING ACCENTUATED CHARACTERS : ÉÀSS
THIRD AND LAST LINE OF THE COPYRIGHT TEXT

Oregon 600 displays on the Info page of the map :
©SECOND LINE OF THE COPYRIGHT TEXT, INCLUDING ACCENTUATED CHARACTERS : ÉÀSS
©THIRD AND LAST LINE OF THE COPYRIGHT TEXT


The first line of the copyright file is displayed before the license block on 
Basecamp and it is missing on the GPS device.



Second run : --license-file=license.txt and --copyright-file=copyright.txt but 
copyright.txt content is : Only one line
JaVaWa GMTK displays :
My license text
Second line of license
Third and last line, blabla êß

PROGRAM LICENCED UNDER GPL V2
ONLY ONE LINE

Basecamp displays : 
My license text
Second line of license
Third and last line, blabla êß

ONLY ONE LINE
PROGRAM LICENCED UNDER GPL V2

Oregon 600 displays on the Info page of the map :
©ONLY ONE LINE


Note how the lines of the copyright block are switched between GMTK and 
Basecamp.


Independently of the exposed results above, I have a few questions and remarks :
- Despite providing a lower case copyright text, the result text is in upper 
case. Is it done by mkgmap ? Is it a Garmin format limitation ?
- In the default license/copyright text, one can read Program released under 
the GPL and PROGRAM LICENCED UNDER GPL V2. I assume it's the mkgmap license, 
instead I'd expect here the license of the produced Garmin map.

Documentation remarks :
--copyright-message=note
Specify a copyright message for files that do not contain one.
What files are we talking about ? The OSM data files ?
By the way, we could add here that --copyright-message is ignored if 
--copyright-file is also provided.

--copyright-file=file
Specify copyright messages from a file. Note that the first copyright message 
is not displayed on a device, but is shown in BaseCamp. The copyright file must 
include at least two lines.
Based on my tests, one can specify a one-line copyright file, mkgmap adds the 
line PROGRAM LICENCED UNDER GPL V2, the last sentence is not true anymore.

--license-file : I don't understand All entries of all maps will be merged in 
the overview map.. What are all maps ? Is the overview map used to store the 
overview levels or the gmapsupp.img file ?



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

[mkgmap-dev] Documentation defect on add-pois-to-lines

[paco . tyson]

Hi all,

I noticed a documentation defect on the add-poi-to-something options.
style-manual.pdf, page 23 lists these options as add-poi-to-something. But 
mkgmap refuses them, it only accepts add-pois-to-something (note the S in the 
option label).


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

[mkgmap-dev] MapFailedException when parsing a commented line in text TYP file

[Paco Tyson]

Hi all,

I've stumbled upon a MapFailedException when compiling a text TYP file.
I use TYPViewer to create TYP files and I chose to create an empty icon to a 
POI. This leads to the following error :

Severe (MapFailedException): /path/to/typfile.txt: (thrown in 
TypCompiler.makeMap()) Compiling TYP txt file: Error: 
(/path/to/typfile.txt:3454): Expecting , instead saw ;

Typ file extract : 
[_point]
Type=0x00b
SubType=0x00
ExtendedLabels=Y
FontStyle=SmallFont
CustomColor=No
DayXpm=1 1 0 1   Colormode=16
;Couleurs 24 bits : pas de palette  - line 3454
#D4D0C8
#D4D0C8
;1
[end]


If I delete the faulty line, mkgmap compiles the TYP file successfully.


In this format, a line starting with ;  is a comment. Shouldn't any comment be 
ignored by the parsing algorithm ?


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

Re: [mkgmap-dev] Why is there a code-page in the .typ-file? And - is there a code-page a gmapsupp.img?

[paco . tyson]

Hi everyone,

 De: Steve Ratcliffe st...@parabola.me.uk
 À: extremecar...@gmail.com, Development list for mkgmap 
 mkgmap-dev@lists.mkgmap.org.uk
 Envoyé: Lundi 30 Juin 2014 23:00:07
 Objet: Re: [mkgmap-dev] Why is there a code-page in the .typ-file? And - is 
 there a code-page a gmapsupp.img?

 Hi Felix

  1. Switching to unicode I ask myself If I should also change the
  typ-file to code-page=65001

 I don't think you need to unless you want you labels to be in
 more than one character set eg Greek and Cyrilic.


I can't compile a text TYP file saved in UTF-8 format. I found no information 
in the mkgmap help regarding the file format. From this message, I understand 
that mkgmap should be able to compile a unicode text TYP file but mkgmap 
crashes. I've been using this file in CP1252 successfully before.

I converted it in a text editor (UTF-8 with BOM), set the code page to 
CodePage=65001.
This is the error I get :
java -Xmx1G -jar ..\bin\mkgmap-r3498\mkgmap.jar typfile.txt
Time started: Fri Mar 20 16:00:59 CET 2015
java.nio.charset.UnsupportedCharsetException: cp65001
at java.nio.charset.Charset.forName(Unknown Source)
at 
uk.me.parabola.mkgmap.main.TypCompiler$CharsetProbe.setCodePage(TypCompiler.java:210)
at 
uk.me.parabola.mkgmap.main.TypCompiler$CharsetProbe.tryCharset(TypCompiler.java:250)
at 
uk.me.parabola.mkgmap.main.TypCompiler$CharsetProbe.probeCharset(TypCompiler.java:217)
at 
uk.me.parabola.mkgmap.main.TypCompiler$CharsetProbe.access$000(TypCompiler.java:200)
at uk.me.parabola.mkgmap.main.TypCompiler.makeMap(TypCompiler.java:67)
at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:253)
at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:249)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Exiting - if you want to carry on regardless, use the --keep-going option
Number of ExitExceptions: 1
Time finished: Fri Mar 20 16:00:59 CET 2015
Total time taken: 203ms


Am I missing something or is this an mkgmap bug ?

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

Re: [mkgmap-dev] mixed index branch merge

[Paco Tyson]

Hi all,

In French, from the top of my head, I can think of : 

Rue, Ruelle, Avenue, Boulevard, Quai, Chaussée, Route, Cour, Cours, Cité, 
Chemin, Place, Esplanade, Passage, Allée, Carrefour, Sentier, Square, Villa.

This list is without a doubt not complete but should cover more than 95% of 
named addresses in France.

They should only be ignored from index if they're in the first place and 
followed by anything else.


Cheers,
Paco

Le 14 févr. 2015 à 08:50, Marko Mäkelä marko.mak...@iki.fi a écrit :

 On Thu, Feb 12, 2015 at 01:24:29PM +, Steve Ratcliffe wrote:
 So finally I will merge the mixed index branch.
 
 I believe that the database terminology for this is 'inverted index' or 
 'fulltext index'.
 
 I think it would be best to selectively enable it per country along with 
 lists of names to avoid. This would be best done by people from or familiar 
 with the countries in question.
 
 In fulltext search, these are called 'stopwords'.
 
 It might not be necessary to do anything to for countries where street names 
 are commonly written as a single word. Example: Main Street would be 
 Hauptstrasse in German, Huvudgatan in Sweden and Päätie in Finnish. 
 Only if the first part of the street name is a proper name such as a person's 
 name, the second part could be written as a separate word, separated by a 
 space or dash.
 
 That said, I guess it would still make sense to introduce some stopwords. 
 Words that I can think of:
 
 Swedish: gata, gatan, gränd, gränden, stig, stigen, (stråk, stråket)
 Finnish: tie, katu, polku, kuja, (raitti, taival)
 German: Straße, Strasse, Weg, Allee, Chaussee
 Estonian: mnt, maantee, tn, tänav, pst, puiestee
 
 In Estonia, it seems to be common to write the tn, mnt or pst as a separate 
 word.
 
 I could be missing some stopwords in Estonian and for German-speaking 
 countries. Also, it could be that the French loan words Allee and Chaussee 
 are sometimes accented.
 
 The Finnish and Swedish words that I have put in parenthesis should be very 
 rare, typically used for ways for non-motorized traffic.  I don't think that 
 including them would pollute the index much. You might in fact want to search 
 for such a name when you are looking for a nice walking or cycling route 
 (i.e., you expect there to exist some random-famous-person-name-stråket, but 
 you do not know the random name).
 
   Marko
 ___
 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 add millions of addresses to your garmin maps of France

[paco . tyson]

Hi Stéphane, Gerd,

I see that you have already discussed this issue.

However, I checked your case and found something:

1) From osm.org, I search 3 Chemin de la Source de Baduel, cayenne, Nominatim 
knows the address and points to this building : 
http://www.openstreetmap.org/way/71465825#map=19/4.92915/-52.30935 . 
2) BANO locates 3 Chemin de la Source de Baduel, cayenne on another building, 
200 m apart : http://www.openstreetmap.org/way/71476554

When you're searching on the garmin map, which building are you looking for ?


You said also that you're finding 2 different points, maybe they're located at 
these two buildings ?
Note that the building returned by Nominatim is probably the wrong one (it's 
missing the addr:street tag), it looks like it should belong to the unnamed 
road.
Gerd, is it possible that mkgmap does the same mistake, hence the 2 different 
points for the same address ?


Paco


- Mail original -
De: Stéphane MARTIN st3ph.mar...@laposte.net
À: Development list for mkgmap mkgmap-dev@lists.mkgmap.org.uk
Envoyé: Mardi 3 Février 2015 21:54:19
Objet: Re: [mkgmap-dev] How to add millions of addresses to your garmin maps of 
France

Hi,

Thank you very much Paco Tyson :-) for your script.

I made a test with French Guiana and it seems working fine…
I obtain a file guyane-latest-with-bano.osm.pbf and mkgmap compiles it
with no error.

However, searching an address in the device (etrex 30) or in BaseCamp is
the same as before.

e.g. I search «3 Chemin de la Source de Baduel» in Cayenne.
The address is located on a building (verified with bano-guyane.osm in
Josm) but on my map the result is pointing approximately to the
beginning of the street!

I use the default style with modifications but not in inc/address.

Options :
--max-jobs --latin1 --area-name=$COUNTRY \
--bounds=../bounds.zip \
--route \
--index --tdbfile --housenumbers \
--location-autofill=is_in,nearest \
--name-tag-list=name:fr,int_name,name \
--adjust-turn-headings \
--process-destination --process-exits \
--x-add-indirect-links \
--verbose \
--style-file=$WORKDIR/styles/$STYLE/ \
--list-styles --check-styles \
--family-name=$COUNTRY OSM $STYLE \
--series-name=$COUNTRY-OSM-$STYLE \
--mapname=$MAPNAME \
--overview-mapnumber=$MAPNAME \
--reduce-point-density=4 --reduce-point-density-polygon=8 \
--polygon-size-limits=24:12, 18:10, 16:8, 14:4, 12:2, 11:0 \
--preserve-element-order \
--add-pois-to-lines \
--add-pois-to-areas \
--report-similar-arcs \
--link-pois-to-ways \
--min-size-polygon \
--drive-on=detect --check-roundabouts --check-roundabout-flares \
--make-opposite-cycleways \
--country-name=$COUNTRY --country-abbr=$ABBR \
--precomp-sea=$WORKDIR/sea.zip --generate-sea=multipolygon \

An idea what I'm doing wrong ?

Steph

Le 02/02/2015 04:06, Paco Tyson a écrit :
 Hi map makers,
 
 The french OSM community has recently created an address database for
 France, under the ODbL licence. By using this database, we can build
 Garmin maps with 6 times more addresses than only OSM data.
…
 I wrote a shell script that does all of the above. It's published on
 https://github.com/PacoTyson/bano2garmin/ and attached as a zip archive.
 
 
 The prerequisites are awk, wget or curl and osmconvert (
 http://wiki.openstreetmap.org/wiki/Osmconvert ). 
  
 You'll have to edit the script to configure it to your installation : 
 
   * BANODIR=directory where the script will download and store the BANO
 files
   * PBFDIR=directory where the .pbf files are read and written
   * BINDIR=directory where osmconvert is stored
 
 Usage : add-bano-addresses.sh /region /
 where /region/ can be /france/ or any of those listed on
 http://download.geofabrik.de/europe/france.html
 
  [1]
 : 
 http://layers.openstreetmap.fr/?zoom=6lat=46.4lon=2.3508layers=BFT
 
 Cheers,
 Paco
___
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] leading and trailing spaces

[Paco Tyson]

Hi Mike,

I agree with you, there's no need for leading and trailing spaces.
An alternative way is to fix the OSM data. FYI, we can use the Osmose QA tool 
that detects those errors : 
http://osmose.openstreetmap.fr/en/errors/?item=5010class=903

I try to periodically tidy the zones I'm mapping with this tool.

Cheers,
Paco

Le 29 janv. 2015 à 01:16, Mike Baggaley m...@tvage.co.uk a écrit :

 Good evening all,
 
 I've noticed that there are a number of unwanted leading and trailing spaces
 in OSM data. You can get a list of the ones on the name field using the
 following:
 
 name~'.* ' {echotags name ends with a space}
 name~' .*' {echotags name starts with a space}
 
 I can't see any facility in mkgmap to remove these, and was wondering
 whether the best way would be simply to code them out by replacing the
 following line in parseDense, parseNodes, ParseWays and parseRelations:
 
 String val = getStringById(...);
 
 With
 
 String val = getStringById(...).trim();
 
 I can't think of any reason why a value would need to start or end with a
 space, so it seems reasonable to just remove them. Are there any other
 suggestions, or reasons why this should not be done?
 
 Regards,
 Mike
 
 ___
 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] Server error when downloading latest version of mkgmap

[Paco Tyson]

Hi everyone,

I'm trying to download the latest version of mkgmap through 
http://www.mkgmap.org.uk/download/mkgmap-latest.zip . It fails with error 
message A server error occurred. We're sorry but there is currently a problem 
with the site. We appologize for any inconvenience, please try again later. 
(NB : Note the spelling error on apologize). This is different from an HTTP 404 
error.

Could somebody check what's happening ? Same issue with splitter-latest.zip. 
Those 2 links worked OK last week IIRC.


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

Re: [mkgmap-dev] Server error when downloading latest version of mkgmap

[Paco Tyson]

Yep, I can download the file, thanks Steve.

Cheers,
Paco

Le 18 déc. 2014 à 22:25, Steve Ratcliffe st...@parabola.me.uk a écrit :

 Hi
 
 I'm trying to download the latest version of mkgmap through 
 http://www.mkgmap.org.uk/download/mkgmap-latest.zip . It fails with error 
 message A server error occurred. We're sorry but there is currently a 
 problem with the site. We appologize for any inconvenience, please try again 
 later. (NB : Note the spelling error on apologize). This is different from 
 an HTTP 404 error.
 
 Could somebody check what's happening ? Same issue with splitter-latest.zip. 
 Those 2 links worked OK last week IIRC.
 Thanks for letting me know, should be fixed now.
 
 Cheers,
 ..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] Merging pbf files before splitter/mkgmap fails

[paco . tyson]

Hello Gerd,

Following your advice, I tried processing my generated .pbf file (I replaced 
the usual geofabrik pbf file with this one) : it doesn't work, I only get a 
white rectangle in Basecamp.


In the splitter log, I can see the map coverage is right.
Splitter produces only one tile : 

 [java] Number of stored ids: 121 580 require ca. 69.15 bytes per pair. 
1899 chunks are used, the avg. number of values in one 64-chunk is 64.
 [java] Map details: bytes/overhead 18 990 / 8 389 034, overhead includes 1 
arrays with 8 MB
 [java] RLE compresion info: compressed / uncompressed size / ratio: 1 899 
/ 121 520 / 99%
 [java] 
 [java] Statistics for ways map:
 [java] Map is empty
 [java]   JVM Memory Info: Current 167MB (119MB used, 48MB free) Max 683MB
 [java] Full Node tests:  0
 [java] Quick Node tests: 121 580
 [java] Thread worker-0 has finished
 [java] Distribution pass(es) took 3467 ms
 [java] Time finished: Sun Aug 03 10:41:08 CEST 2014
 [java] Total time taken: 9s

Using osmconvert to convert to osm format the splitter-produced pbf returns the 
original data. I assume that splitter processing is OK.


Mkgmap runs without errors nor logs. Opening the final map in javawa shows the 
expected map coverage.

I recall that mkgmap produces address data only if it finds a matching highway 
name, would that explain why the map is empty ?

Can you confirm that mkgmap can process negative ids ?

Thanks,
Paco.



- Mail original -
De: Gerd Petermann gpetermann_muenc...@hotmail.com
À: mkgmap-dev@lists.mkgmap.org.uk
Envoyé: Lundi 28 Juillet 2014 06:46:49
Objet: Re: [mkgmap-dev] Merging pbf files before splitter/mkgmap fails



Hi Paco, 

I suggest to try processing addresses.osm on its own first. 
Do you get the expected data in the img file? 
Is this still the case when you convert the file to pbf with osmconvert? 

Gerd 


 Date: Sun, 27 Jul 2014 22:10:49 +0200 
 From: paco.ty...@free.fr 
 To: mkgmap-dev@lists.mkgmap.org.uk 
 Subject: [mkgmap-dev] Merging pbf files before splitter/mkgmap fails 
 
 Hi all, 
 
 I need help for a slightly offtopic problem. 
 
 I've got a (huge) list of addresses in CSV format. I want to add them to the 
 pbf file from geofabrik before running splitter/mkgmap. Those addresses 
 aren't in OSM. 
 I converted the CSV file to an .osm file. The script produces the addresses 
 with a negative osm id. 
 I then use osmconvert : 
 ./osmconvert geofabrik.osm.pbf addresses.osm --out-pbf -o=complete.pbf 
 No error returned. The complete.pbf file is correctly processed by the 
 splitter/mkgmap toolchain. But the map doesn't show the addresses. 
 
 I tried to look for the problem : 
 - The .osm file seems correct, it opens correctly in JOSM. 
 - Converting the .osm file to .pbf format before merging doesn't help 
 - Something funny : after merging, the .pbf file is slightly smaller than the 
 geofabrik one. osmconvert does a more efficient job at creating pbf files ? 
 
 
 I guess that the problem lies in the merging part but I didn't find any 
 inspection tool for the pbf format. 
 
 Can anybody help ? 
 
 Paco. 
 
 ___ 
 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] Merging pbf files before splitter/mkgmap fails

[paco . tyson]

Gerd,

Yes, I want to use these addresses for search/navigation. My idea is to merge 
them with the pbf source file when building a garmin map. My style is OK, 
addresses coming from OSM can be searched/navigated to.
So what could be wrong ? How can I investigate this issue ?

Paco

- Mail original -
De: GerdP gpetermann_muenc...@hotmail.com
À: mkgmap-dev@lists.mkgmap.org.uk
Envoyé: Dimanche 3 Août 2014 12:28:37
Objet: Re: [mkgmap-dev] Merging pbf files before splitter/mkgmap fails

Hi Paco,

yes, mkgmap can process negative ids. 
The question for me is what you expect when you merge the address data.
If you expect an effect on housenumber search/navigation, 
you should make sure that your style sets the tags like mkgmap:street
etc.

Gerd


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

Re: [mkgmap-dev] Basecamp shows series-name as blank on MacOSX 10.9

[paco . tyson]

- Mail original -
De: Andrew Gillespie m...@andrew.nom.za 
À: mkgmap-dev@lists.mkgmap.org.uk 
Envoyé: Dimanche 27 Juillet 2014 14:15:28 
Objet: [mkgmap-dev] Basecamp shows series-name as blank on MacOSX 10.9 



The series name for the map I build shows as blank in Basecamp's map 
selection dropdown on OSX 10.9. When I install the same map on OSX 10. 
Basecamp shows the name as normal. I have tried rebuilding the map with 
various names for --series-name=whatever but it still happens. Has anyone 
solved this problem? 





Hello Andrew, 

I've not witness such a bug. I've just tested, a recent map or a fairly old one 
shows the series name. Map installed with the .gmap format by MapInstall. 
Basecamp 4.2.4 
OS X 10.9.4 
mkgmap r3145 




Maybe a bug coming from a unicode-enabled version of mkgmap ? 
Paco___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] Merging pbf files before splitter/mkgmap fails

[paco . tyson]

Hi all,

I need help for a slightly offtopic problem.

I've got a (huge) list of addresses in CSV format. I want to add them to the 
pbf file from geofabrik before running splitter/mkgmap. Those addresses aren't 
in OSM.
I converted the CSV file to an .osm file. The script produces the addresses 
with a negative osm id.
I then use osmconvert :
./osmconvert geofabrik.osm.pbf addresses.osm --out-pbf -o=complete.pbf
No error returned. The complete.pbf file is correctly processed by the 
splitter/mkgmap toolchain. But the map doesn't show the addresses.

I tried to look for the problem : 
- The .osm file seems correct, it opens correctly in JOSM.
- Converting the .osm file to .pbf format before merging doesn't help
- Something funny : after merging, the .pbf file is slightly smaller than the 
geofabrik one. osmconvert does a more efficient job at creating pbf files ?


I guess that the problem lies in the merging part but I didn't find any 
inspection tool for the pbf format.

Can anybody help ?

Paco.

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

Re: [mkgmap-dev] access_country for default style

[paco . tyson]

Selon Stéphane MARTIN st3ph.mar...@laposte.net:

 Hi,
Hi Stéphane, hi all

I reply to Stéphane but I think everyone should read and may reply as I have
general questions.

 Does this proposal makes sense for France ?
 According to

http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions#France

I don't understand this page as you do. I read this table as : which traffic
mode is allowed *by default* (when the OSM way has no access tag defined, only
the highway tag).


 # France (FRA)

 highway=trunk  mkgmap:country=FRA
   { add bicycle=no; add foot=no }

Correct, we can duplicate this one for motorway also.

 highway=cycleway  bicycle=designated  mkgmap:country=FRA
   { add foot=no }
 highway=cycleway  mkgmap:country=FRA
   { set mkgmap:foot=yes; }

As I explained in the beginning, the rules are :
highway=cycleway  mkgmap:country=FRA
  { set mkgmap:access=no; set mkgmap:bicycle=yes;}
highway=cycleway  foot=yes  mkgmap:country=FRA
   { set mkgmap:access=no; set mkgmap:bicycle=yes; set mkgmap:foot=yes; }

I don't even think the second rule is needed.

 highway=bridleway  horse=designated  mkgmap:country=FRA
   { add bicycle=no; add foot=no }
 highway=bridleway  mkgmap:country=FRA
   { set mkgmap:foot=yes; set mkgmap:bicycle=yes; }

This one is tricky, I'm no horse rider but I think bridleways have no legal
definition in France. I understand there are only paths which may be allowed to
horse riders. I'd consider them as highway=path. But this should be discussed
with the French OSM community, not here. So for now, let's apply the wiki table
:

highway=bridleway  mkgmap:country=FRA
   { set mkgmap:access=no; set mkgmap:horse=yes;}

BTW, I don't remember mkgmap:horse exists, correct ? So what should we do with
them ?

Do we need to define rules for all the other highway tag values (primary,
secondary, tertiary, unclassified, residential, living_street, track, footway
and pedestrian) ? Are they handled by mkgmap by default ?



 Steph

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

Re: [mkgmap-dev] access_country for default style

[paco . tyson]

Selon Stéphane MARTIN st3ph.mar...@laposte.net:

 Hi Paco,

Hi Stéphane,

 It seems that there is no consensus for the French OSM community:

http://gis.19327.n5.nabble.com/Acces-de-certaines-voies-en-France-td5804000.html

I read this thread, I think there's too much misunderstanding and offtopic
issues to get something meaningful out of it.


 Furthermore, I'm realizing that designated can be associated with an
 other designated or with an other tag important for routing.

I think you nailed it, much of the misunderstanding and our disagreement comes
from this tag.
I understand the key designated as : this way has been made specifically for
this vehicle, it should be used in priority before the surrounding ones.
What do you think designated is used for ?

Following this definition, a way tagged with (highway=bridleway 
horse=designated) has redundancy because a bridleway is, by definition, made
specifically for horses.


 Therefore, permissive rules would be better here and some restrictions
 can be added, e.g. in lines, depending the wanted routing.

 # France (FRA)

 highway=trunk  mkgmap:country=FRA { add bicycle=no; add foot=no }
Agree

 highway=cycleway  mkgmap:country=FRA  { add foot=yes }
Disagree. In French law, a cycleway is not allowed to pedestrians unless signed
otherwise.
highway=cycleway  mkgmap:country=FRA  { add foot=no }
(if this rule is not already applied by default in mkgmap, I don't know the
default ones, are they posted somewhere ?)

 highway=bridleway  mkgmap:country=FRA { add bicycle=yes; add foot=yes }
Agree

Of course, these rules are to be applied at the beginning of the mkgmap
processing so a superseding attribute (for example foot=yes for a cycleway) can
be applied correctly.



 Do you agree with that ?

 Steph

 Le 03/05/2014 05:00, paco.ty...@free.fr a écrit :
  Selon Stéphane MARTIN st3ph.mar...@laposte.net:
 
  Hi,
  Hi Stéphane, hi all
 
  I reply to Stéphane but I think everyone should read and may reply as I
 have
  general questions.
 
  Does this proposal makes sense for France ?
  According to
 
 

http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions#France
 
  I don't understand this page as you do. I read this table as : which
 traffic
  mode is allowed *by default* (when the OSM way has no access tag defined,
 only
  the highway tag).
 
 
  # France (FRA)
 
  highway=trunk  mkgmap:country=FRA
{ add bicycle=no; add foot=no }
 
  Correct, we can duplicate this one for motorway also.
 
  highway=cycleway  bicycle=designated  mkgmap:country=FRA
{ add foot=no }
  highway=cycleway  mkgmap:country=FRA
{ set mkgmap:foot=yes; }
 
  As I explained in the beginning, the rules are :
  highway=cycleway  mkgmap:country=FRA
{ set mkgmap:access=no; set mkgmap:bicycle=yes;}
  highway=cycleway  foot=yes  mkgmap:country=FRA
 { set mkgmap:access=no; set mkgmap:bicycle=yes; set mkgmap:foot=yes; }
 
  I don't even think the second rule is needed.
 
  highway=bridleway  horse=designated  mkgmap:country=FRA
{ add bicycle=no; add foot=no }
  highway=bridleway  mkgmap:country=FRA
{ set mkgmap:foot=yes; set mkgmap:bicycle=yes; }
 
  This one is tricky, I'm no horse rider but I think bridleways have no legal
  definition in France. I understand there are only paths which may be
 allowed to
  horse riders. I'd consider them as highway=path. But this should be
 discussed
  with the French OSM community, not here. So for now, let's apply the wiki
 table
  :
 
  highway=bridleway  mkgmap:country=FRA
 { set mkgmap:access=no; set mkgmap:horse=yes;}
 
  BTW, I don't remember mkgmap:horse exists, correct ? So what should we do
 with
  them ?
 
  Do we need to define rules for all the other highway tag values (primary,
  secondary, tertiary, unclassified, residential, living_street, track,
 footway
  and pedestrian) ? Are they handled by mkgmap by default ?

 ___
 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] vehicles in restriction relations

[paco . tyson]

Hi Gerd,

Selon Gerd Petermann gpetermann_muenc...@hotmail.com:

 AFAIK the img format doesn't contain any kind of traffic light.
Too bad.
It's a pity because traffic lights can have a big impact on the total average
speed. When you've got a traffic light every 150 m on average (i.e. inner
Paris), it's worth taking a detour to avoid them. Longer but quicker.


 I think this is not needed, as it only influences the avg. speed.

Well, if it influences the moving speed, it's meaningful when routing with
fastest route setting, isn't it ?
On average, a right turn would take a fraction of time compared to a straight or
left turn.


 BTW: In Germany we have a green arrow which allows right turn after stopping
 and giving way.

Same here.

 It is often misunderstood to be something like a ignore red light sign.

 Gerd



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

Re: [mkgmap-dev] vehicles in restriction relations

[paco . tyson]

Selon GerdP gpetermann_muenc...@hotmail.com:

 Hi Paco,

 I see no problem here.
 It is up to you to set the speed class of a road, or you can use
 the link-pois-to-ways option to lower the speed at every traffic light
 or other traffic signs which have an influence on the avg. speed.

Nice idea, that's seems a good workaround. If I understand correctly, you
suggest lowering the speed on a node only ? Is this possible with mkgmap/garmin
format ? Or should we cut the road right before and after the node so the
smaller speed applies to a way ?

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

Re: [mkgmap-dev] vehicles in restriction relations

[paco . tyson]

Hi Minko, Hi Gerd,

Selon Minko ligfiet...@online.nl:

 Good question Gerd,
 I never realized that actually ;-)
 Route restrictions for cycling are hardly tagged I suppose,
 and if they apply for cars they are on places where you don't cycle anyway.


You're reminding me of a question I've got for mkgmap developers.

I'd like to know if the right turn on red
(https://en.wikipedia.org/wiki/Right_turn_on_red) is taken into account by
Garmin in their map format and routing algorithm. I guess yes because Garmin is
US-based, where this kind of traffic light is widespread and that it allows for
faster right turns.

Has anyone ever succeeded in reverse-engineering it in the map file format ?

It'd be great because we recently got a new sign in France allowing cyclists to
turn right on red after yielding to crossing pedestrians.
(https://en.wikipedia.org/wiki/File:Turn_right_on_red.JPG).
In OSM, it's tagged with :
type=restriction
restriction:bicycle=give_way


Thanks,

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

Re: [mkgmap-dev] Name-tag-list parameter not used in relations processing

[paco . tyson]

Selon Gerd Petermann gpetermann_muenc...@hotmail.com:

 Hi Paco,

 thanks for the details, that helped a lot.

 I found out that I have to patch RelationStyleHook, not StyledConverter.
 patch v1 works, but the apply rules are processed before,
 so it has not much effect ;-)

 Attached is a version 2 of the patch, a compiled binary based on r3138 is
 here:
 http://files.mkgmap.org.uk/download/195/mkgmap.jar

 Gerd

Hi Gerd,

Great, it works as expected! :) Now my map is completely localized.
From my point of view, you can commit the patch.

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

Re: [mkgmap-dev] Name-tag-list parameter not used in relations processing

[paco . tyson]

Selon GerdP gpetermann_muenc...@hotmail.com:

 Hi Paco,

 you can try it, I've uploaded the binary :
 http://files.mkgmap.org.uk/download/192/mkgmap.jar

 Gerd

Hi Gerd,
I'm afraid the patch isn't effective.

For your information, the relations file contains :

network=icn  state!=proposed {
apply {
set icn_from_relation=yes;
set icn_name='${name}';
set icn_ref='${ref}';
};
echotags Relation ICN;
}

and the corresponding lines file :
highway=*  icn_from_relation=yes  {name '${icn_ref}
(${icn_name|not-equal:icn_ref})' | '${icn_ref}'; echotags ICN way; }  [0x00
resolution 15-15 continue]



Mkgmap r3116, without name-tag-list parameter set :
[java] 2345035 - [route=bicycle,type=route,name=EuroVelo 3 - part
France,ref=EV3,network=icn] Relation ICN
[java] 254539829 - [motorcar=yes,mkgmap:label:1=EV3 (EuroVelo 3 - part
France),mkgmap:admin_level2=FRA,mkgmap:admin_level3=France
métropolitaine,mkgmap:admin_level4=Picardie,icn_from_relation=yes,mkgmap:admin_level6=Oise,icn_ref=EV3,mkgmap:admin_level8=Pontpoint,mkgmap:admin_level7=Senlis,name=Trans'Oise,surface=paved,highway=cycleway,foot=designated,mkgmap:street=Trans'Oise,mkgmap:country=FRA,mkgmap:city=Pontpoint,icn_name=EuroVelo
3 - part
France,bicycleroute=yes,source=GPS,mkgmap:region=Picardie,toll=no,tollroad=no,bicycle=yes]
ICN way



Mkgmap r3116, name-tag-list parameter set to name:fr,name,int_name :
[java] 2345035 - [route=bicycle,type=route,name=EuroVelo 3 - part
France,name:fr=La route des pèlerins - portion France,ref=EV3,network=icn]
Relation ICN
[java] 254539829 - [motorcar=yes,mkgmap:label:1=EV3 (EuroVelo 3 - part
France),mkgmap:admin_level2=FRA,mkgmap:admin_level3=France
métropolitaine,mkgmap:admin_level4=Picardie,icn_from_relation=yes,mkgmap:admin_level6=Oise,icn_ref=EV3,mkgmap:admin_level8=Pontpoint,mkgmap:admin_level7=Senlis,name=Trans'Oise,surface=paved,highway=cycleway,foot=designated,mkgmap:street=Trans'Oise,mkgmap:country=FRA,mkgmap:city=Pontpoint,icn_name=EuroVelo
3 - part
France,bicycleroute=yes,source=GPS,mkgmap:region=Picardie,toll=no,tollroad=no,bicycle=yes]
ICN way



Mkgmap r3118, with jar file overwritten with your patched jar, without
name-tag-list-parameter:
[java] 2345035 - [route=bicycle,type=route,name=EuroVelo 3 - part
France,ref=EV3,network=icn] Relation ICN
[java] 254539829 - [motorcar=yes,mkgmap:label:1=EV3 (EuroVelo 3 - part
France),mkgmap:admin_level2=FRA,mkgmap:admin_level3=France
métropolitaine,mkgmap:admin_level4=Picardie,icn_from_relation=yes,mkgmap:admin_level6=Oise,icn_ref=EV3,mkgmap:admin_level8=Pontpoint,mkgmap:admin_level7=Senlis,name=Trans'Oise,surface=paved,highway=cycleway,foot=designated,mkgmap:street=Trans'Oise,mkgmap:country=FRA,mkgmap:city=Pontpoint,icn_name=EuroVelo
3 - part
France,bicycleroute=yes,source=GPS,mkgmap:region=Picardie,toll=no,tollroad=no,bicycle=yes]
ICN way


Mkgmap r3118, with jar file overwritten with your patched jar, name-tag-list
parameter set to name:fr,name,int_name :
[java] 2345035 - [route=bicycle,type=route,name=EuroVelo 3 - part
France,name:fr=La route des pèlerins - portion France,ref=EV3,network=icn]
Relation ICN
[java] 254539829 - [motorcar=yes,mkgmap:label:1=EV3 (EuroVelo 3 - part
France),mkgmap:admin_level2=FRA,mkgmap:admin_level3=France
métropolitaine,mkgmap:admin_level4=Picardie,icn_from_relation=yes,mkgmap:admin_level6=Oise,icn_ref=EV3,mkgmap:admin_level8=Pontpoint,mkgmap:admin_level7=Senlis,name=Trans'Oise,surface=paved,highway=cycleway,foot=designated,mkgmap:street=Trans'Oise,mkgmap:country=FRA,mkgmap:city=Pontpoint,icn_name=EuroVelo
3 - part
France,bicycleroute=yes,source=GPS,mkgmap:region=Picardie,toll=no,tollroad=no,bicycle=yes]
ICN way


What I want is to get for way 254539829 the tag mkgmap:label:1=La route des
pèlerins - portion France. So I expect the relation to automatically get the
tag name=La route des pèlerins - portion France.
Or did I misunderstood the way this parameter works ?
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] mkgmap Unsupported major.minor version 51.0

[paco . tyson]

Selon Nev Wedding nevwedd...@gmail.com:

 That seems plain enough even for me now - I must have a later Java version
 installed and this can't be done on this machine.


 ** Is it likely that the developers of mkgmap will recompile a version of the
 program in the near future so that it runs under java 1.6?

I don't think so. You either have to use an older mkgmap version or upgrade your
OS X installation to Lion or newer. You can check in the commit logs when mkgmap
dropped java1.6 support and use that mkgmap version. I know that r2960 can run
on java1.6

I upgraded from SL to Mavericks recently in order to get java7 and keep up with
mkgmap.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] [Patch v5] correct make-cycleways

[paco . tyson]

Selon Gerd Petermann gpetermann_muenc...@hotmail.com:

 Hi all,

 this is version 5 of the patch for this problem:
 http://gis.19327.n5.nabble.com/link-pois-to-ways-tags-tp5800124p5800575.html

 It creates the cycleway first (with access for bicycles only) and forbids
 bicycle for the normal way.

Why do you forbid routing a bicycle on the normal way although it's allowed ?
Is this done with the default style or is it hardcoded ?

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

Re: [mkgmap-dev] Name-tag-list parameter not used in relations processing

[paco . tyson]

Selon Gerd Petermann gpetermann_muenc...@hotmail.com:

 Hi Paco,

Hi Gerd,

 I think it is a very simple change, see attached patch.
 I don't know why it wasn't always done.
 Does anybody expect a problem if we add/replace the name=* tag of a
 Relation?

I looked at the patch but I can't guess if it's effective.

I can give you an example of what I'd like. When mkgmap analyses a route
relation (e.g. bicycle route), I'd like the mkgmap name variable set to the OSM
name:xx tag as per the name-tag-list parameter instead of the OSM name tag.

If your patch does this, then fine for me :)

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

Re: [mkgmap-dev] Name-tag-list parameter not used in relations processing

[paco . tyson]

Hi Gerd,

The bug still appears with the latest stable, is it still in your todo list ?
Do you need more information from me ?

Regards,
Paco

Selon paco.ty...@free.fr:

 Selon Gerd Petermann gpetermann_muenc...@hotmail.com:

  Hi Paco,

 Hi Gerd,

  do you see this error also with r2960?

 Yes.

 
  Gerd
 
   Date: Fri, 10 Jan 2014 17:01:07 +0100
   From: paco.ty...@free.fr
   To: mkgmap-dev@lists.mkgmap.org.uk
   Subject: [mkgmap-dev] Name-tag-list parameter not used in
  relations   processing
  
   Hi,
  
   I noticed that the name-tag-list parameter is ignored by mkgmap when
  processing
   relations with the apply directive. It works as expected for all the
  other
   types.
  
   If I hard-code the name:xx tag in my relations file, mkgmap uses it and
 the
   right language is displayed.
  
   I tried putting the parameter in the -c config file and on the command
  line,
   same buggy behaviour (tested on r2673 and r2889).
  
   Regards,
   Paco
   ___
   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] Name-tag-list parameter not used in relations processing

[paco . tyson]

Well, I don't know what else to add to my initial email :

I noticed that the name-tag-list parameter is ignored by mkgmap when processing
relations with the apply directive. It works as expected for all the other
types. If I hard-code the name:xx tag in my relations file, mkgmap uses it and
the right language is displayed.
I tried putting the parameter in the -c config file and on the command line.



Selon GerdP gpetermann_muenc...@hotmail.com:

 Hi Pcao,

 I am not familiar with that part of the code,
 so I hoped that someone else takes care.
 No one did, so yes, please post more details.

 Gerd


 paco.tyson wrote
  Hi Gerd,
 
  The bug still appears with the latest stable, is it still in your todo
  list ?
  Do you need more information from me ?
 
  Regards,
  Paco
 
  Selon

  paco.tyson@

  :
 
  Selon Gerd Petermann lt;

  gpetermann_muenchen@

  gt;:
 
   Hi Paco,
 
  Hi Gerd,
 
   do you see this error also with r2960?
 
  Yes.
 
  
   Gerd
  
Date: Fri, 10 Jan 2014 17:01:07 +0100
From:

  paco.tyson@

To:

  mkgmap-dev@.org

Subject: [mkgmap-dev] Name-tag-list parameter not used in
   relationsprocessing
   
Hi,
   
I noticed that the name-tag-list parameter is ignored by mkgmap when
   processing
relations with the apply directive. It works as expected for all
  the
   other
types.
   
If I hard-code the name:xx tag in my relations file, mkgmap uses it
  and
  the
right language is displayed.
   
I tried putting the parameter in the -c config file and on the
  command
   line,
same buggy behaviour (tested on r2673 and r2889).
   
Regards,
Paco
___
mkgmap-dev mailing list
   

  mkgmap-dev@.org

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

  mkgmap-dev@.org

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

  mkgmap-dev@.org

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





 --
 View this message in context:

http://gis.19327.n5.nabble.com/Name-tag-list-parameter-not-used-in-relations-processing-tp5792522p5800773.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] Mkgmap exception while reading options file

[paco . tyson]

Hi Gerd,

Selon Gerd Petermann gpetermann_muenc...@hotmail.com:

 Hi Paco,

 this seems to be a problem with java7.

I'm not in front of my computer but I remember that I downloaded the java7 jdk
from oracle's website. It's the latest version, 64bit.

 The program crashes while complaining about the last
 part of this line :Levels specification not all numbers 
 overview-levels=5:17,6:15,7:14

 I  assume that you have a special character following the 7:14 pair,
 maybe uncommon line ending 0x0d ?

Maybe, I checked the documentation for a requirement on the encoding and line
ending of the style files but found nothing. So I assumed that wasn't an issue.
Which line ending should I use ?
By the way, what encoding should I use ?

 I'll try to find a correction for the crash.

Thanks, right now this bug is a showstopper, I can't compile any map.

 Gerd

  Date: Wed, 26 Feb 2014 23:40:15 +0100
  From: paco.ty...@free.fr
  To: mkgmap-dev@lists.mkgmap.org.uk
  Subject: [mkgmap-dev] Mkgmap exception while reading options file
 
  Hi all,
 
  I'm faced with this error :
 
  java -jar ../../../bin/mkgmap-r3057/mkgmap.jar --style-file=src/
  --style=style-FR --check-styles
  Time started: Wed Feb 26 23:20:35 CET 2014
  checking style: style-FR
  Exception in thread main java.lang.ArrayIndexOutOfBoundsException: 2
  at
 uk.me.parabola.mkgmap.general.LevelInfo.createFromString(LevelInfo.java:74)
  at 
  uk.me.parabola.mkgmap.osmstyle.StyleImpl.readRules(StyleImpl.java:275)
  at uk.me.parabola.mkgmap.osmstyle.StyleImpl.init(StyleImpl.java:160)
  at uk.me.parabola.mkgmap.main.Main.readOneStyle(Main.java:382)
  at uk.me.parabola.mkgmap.main.Main.checkStyles(Main.java:362)
  at uk.me.parabola.mkgmap.main.Main.processOption(Main.java:264)
  at
 

uk.me.parabola.mkgmap.CommandArgsReader$CommandOption.processArg(CommandArgsReader.java:303)
  at
 uk.me.parabola.mkgmap.CommandArgsReader.readArgs(CommandArgsReader.java:125)
  at uk.me.parabola.mkgmap.main.Main.main(Main.java:117)
 
 
  When I invoke mkgmap as usual to compile a map, it fails after outputting
 this
  exact same exception trace 8 times. No map produced.
 
 
  I've narrowed the issue to the options file, pasted here :
  #
  # Style options.
  #
  # The name tag determines what tag is used as the name of a
  # feature.  Usually this is just 'name' but you might want something
  # more specific such as name:en or another language variant.
  # You can specify a list here, the first one that exists will be
  # used
  #
  # Example:
  # name_tag = name:en, int_name, name
 
  # The levels specification for this style
 
  levels=0:24,1:23,2:22,3:20,4:18
  overview-levels=5:17,6:15,7:14
 
 
 
  If I comment out the 2 lines, then mkgmap runs fine (style checking and map
  compiling).
  This file was OK before I migrated from OS X Snow Leopard to Mavericks.
 Before :
  OS X 10.6.8, java6, mkgmap r2685. Now OS X 10.9.2, java7, mkgmap 3057 (same
  exception with r2960)
  ___
  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 exception while reading options file

[paco . tyson]

Selon Gerd Petermann gpetermann_muenc...@hotmail.com:

 Hi Paco,

 I hope r3069 helps you to find out where the problem
 is.

 Gerd


Using r3069, when checking the style, I get :

Error: Levels specification not all numbers: 5:17,6:15,7:14null check 7:14null

I found out with an hex editor that :
- line endings are LF
- encoding doesn't matter : latin1 or utf-8 output the same result

However the file was missing a LF at the end of the last line. Simply adding a
blank line at the end of the file solved the issue.


Out of curiosity, I tried removing the last LF character in the lines file but
it doesn't trigger the issue.


Thanks Gerd and Steve for the help. :)
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] Mkgmap exception while reading options file

[paco . tyson]

Hi all,

I'm faced with this error :

java -jar ../../../bin/mkgmap-r3057/mkgmap.jar --style-file=src/
--style=style-FR --check-styles
Time started: Wed Feb 26 23:20:35 CET 2014
checking style: style-FR
Exception in thread main java.lang.ArrayIndexOutOfBoundsException: 2
at 
uk.me.parabola.mkgmap.general.LevelInfo.createFromString(LevelInfo.java:74)
at 
uk.me.parabola.mkgmap.osmstyle.StyleImpl.readRules(StyleImpl.java:275)
at uk.me.parabola.mkgmap.osmstyle.StyleImpl.init(StyleImpl.java:160)
at uk.me.parabola.mkgmap.main.Main.readOneStyle(Main.java:382)
at uk.me.parabola.mkgmap.main.Main.checkStyles(Main.java:362)
at uk.me.parabola.mkgmap.main.Main.processOption(Main.java:264)
at
uk.me.parabola.mkgmap.CommandArgsReader$CommandOption.processArg(CommandArgsReader.java:303)
at 
uk.me.parabola.mkgmap.CommandArgsReader.readArgs(CommandArgsReader.java:125)
at uk.me.parabola.mkgmap.main.Main.main(Main.java:117)


When I invoke mkgmap as usual to compile a map, it fails after outputting this
exact same exception trace 8 times. No map produced.


I've narrowed the issue to the options file, pasted here :
#
# Style options.
#
# The name tag determines what tag is used as the name of a
# feature.  Usually this is just 'name' but you might want something
# more specific such as name:en or another language variant.
# You can specify a list here, the first one that exists will be
# used
#
# Example:
# name_tag = name:en, int_name, name

# The levels specification for this style

levels=0:24,1:23,2:22,3:20,4:18
overview-levels=5:17,6:15,7:14



If I comment out the 2 lines, then mkgmap runs fine (style checking and map
compiling).
This file was OK before I migrated from OS X Snow Leopard to Mavericks. Before :
OS X 10.6.8, java6, mkgmap r2685. Now OS X 10.9.2, java7, mkgmap 3057 (same
exception with r2960)
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] boundary France broken?

[paco . tyson]

Selon GerdP gpetermann_muenc...@hotmail.com:

 Hi Bernd,

 yes, that's typical. I assume the level 2 relations were broken
 on 2014-01-01. The one for France was okay when I tested it today.

 Gerd

Hi, Frenchman here,

Yes, there was a lot of work going on on the national boundaries around new
year's eve.
If I got it right, the admin_level=2 relation for France is now a group of all
boundaries, metropolitan and overseas. The metropolitan boundary that is missing
in the boundaries file is now an admin_level=3 relation.

More information at
http://wiki.openstreetmap.org/wiki/France_boundary_pyramidal_construction


Hope it helps,
Paco
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Mkgmap always returns exit code 0 even when it fails

[paco . tyson]

Selon Gerd Petermann gpetermann_muenc...@hotmail.com:

 Hi Paco,

 I agree, but I found no simple way to change mkgmap.
 I assume that you consider a non empty stderr file as
 an error,

No, Ant checks for the return code : I invoke the java task with the failonerror
attribute (http://ant.apache.org/manual/Tasks/java.html#failonerror) which
explicitly mentions the result code. The result code is set in the Java code
with the System.exit() method.

 so maybe we can check whether anything was
 written to stderr, but sometimes we use this file also for
 important hints like this:
 WARNING: input files have different code pages

I agree with you, mkgmap outputs lots of warnings, this workaround would be
tricky at best. It would work if we output information and warnings to stdout
and errors and exceptions to stderr but that requires a check on the complete
codebase.

I ran a grep for System.exit on the codebase and found several calls to
System.exit(), adding a few of them in the right places (e.g. at the end of the
options processing, catching any exception mkgmap can't deal with...) should do
the trick.
Forgive me if I'm wrong here, it's been 10 years since I wrote a single line of
java code.



 BTW: Also splitter doesn't make sure that it ends
 with a non-zero return code in case of errors, but
 it tries to do so.

As far as I remember, I've run into incorrect options or missing file errors,
splitter always behaved as expected.


 Gerd

  Date: Sat, 11 Jan 2014 00:22:54 +0100
  From: paco.ty...@free.fr
  To: mkgmap-dev@lists.mkgmap.org.uk
  Subject: [mkgmap-dev] Mkgmap always returns exit code 0 even when it fails
 
  Hi,
 
  I'm building a map generation tool with Ant. Problem is that if mkgmap
  encounters an error, the exit code is 0, no matter what. As this is the
 OK
  exit code, Ant carries on to the rest of the workflow.
  On the contrary, splitter does return a non zero code when it fails.
 
  Please make mkgmap return a non zero exit code for errors.
 
 
  Thanks,
  Paco
  ___
  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] Name-tag-list parameter not used in relations processing

[paco . tyson]

Selon Gerd Petermann gpetermann_muenc...@hotmail.com:

 Hi Paco,

Hi Gerd,

 do you see this error also with r2960?

Yes.


 Gerd

  Date: Fri, 10 Jan 2014 17:01:07 +0100
  From: paco.ty...@free.fr
  To: mkgmap-dev@lists.mkgmap.org.uk
  Subject: [mkgmap-dev] Name-tag-list parameter not used in
 relations processing
 
  Hi,
 
  I noticed that the name-tag-list parameter is ignored by mkgmap when
 processing
  relations with the apply directive. It works as expected for all the
 other
  types.
 
  If I hard-code the name:xx tag in my relations file, mkgmap uses it and the
  right language is displayed.
 
  I tried putting the parameter in the -c config file and on the command
 line,
  same buggy behaviour (tested on r2673 and r2889).
 
  Regards,
  Paco
  ___
  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] Name-tag-list parameter not used in relations processing

[paco . tyson]

Hi,

I noticed that the name-tag-list parameter is ignored by mkgmap when processing
relations with the apply directive. It works as expected for all the other
types.

If I hard-code the name:xx tag in my relations file, mkgmap uses it and the
right language is displayed.

I tried putting the parameter in the -c config file and on the command line,
same buggy behaviour (tested on r2673 and r2889).

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

[mkgmap-dev] Mkgmap always returns exit code 0 even when it fails

[paco . tyson]

Hi,

I'm building a map generation tool with Ant. Problem is that if mkgmap
encounters an error, the exit code is 0, no matter what. As this is the OK
exit code, Ant carries on to the rest of the workflow.
On the contrary, splitter does return a non zero code when it fails.

Please make mkgmap return a non zero exit code for errors.


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

[mkgmap-dev] NullPointerException when compiling a TYP file

[paco . tyson]

Hi all,

I created my TYP file with the latest TYPViewer. I can compile it using this
tool. However, mkgmap fails with a NullPointerException :
java.lang.NullPointerException
at uk.me.parabola.imgfmt.app.typ.Xpm.writeImage(Xpm.java:43)
at 
uk.me.parabola.imgfmt.app.typ.TypElement.writeImage(TypElement.java:206)
at uk.me.parabola.imgfmt.app.typ.TypPoint.write(TypPoint.java:53)
at uk.me.parabola.imgfmt.app.typ.TYPFile.writeSection(TYPFile.java:168)
at uk.me.parabola.imgfmt.app.typ.TYPFile.write(TYPFile.java:70)
at uk.me.parabola.mkgmap.main.TypCompiler.writeTyp(TypCompiler.java:145)
at uk.me.parabola.mkgmap.main.TypCompiler.makeMap(TypCompiler.java:102)
at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:243)
at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:239)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:695)
Exiting - if you want to carry on regardless, use the --keep-going option



I found the culprit to be a blank POI :
[_point]
Type=0x02f03
String1=0x04,X
String2=0x03,
String3=0x02,
String4=0x01,Y
ExtendedLabels=Y
FontStyle=SmallFont
CustomColor=Day
DaycustomColor:#8B
DayXpm=0 0 0 0
[end]

If I select the Bitmap checkbox, TYPViewer generates the POI like this :
[_point]
Type=0x02f03
String1=0x04,X
String2=0x03,
String3=0x02,
String4=0x01,Y
ExtendedLabels=Y
FontStyle=SmallFont
CustomColor=Day
DaycustomColor:#8B
DayXpm=16 16 2 1   Colormode=16
!  c #FF
   c none
















;1234567890123456
[end]

This format compiles just fine.


http://www.mkgmap.org.uk/doc/typ-compiler says :
In particular the files produced by TYPWiz and TYPViewer are supported.


So, is this a bug in mkgmap or TYPviewer ?

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