NumberFormatException when making marine chart
Hi, I am trying to make a marine chart out of the Europe file. When I use the marine style from resources/styles/marine, I get a lot of errors similar to this: SCHWERWIEGEND (ExtTypeAttributes): ..\tiles\63240040.osm.pbf: OSM id 1460137282 (java.lang.NumberFormatException: For input string: "3+") With other styles I do not get this errors. I am running mkgmap under Windows 7 x64 with 4GB memory and -Xmx3000m option. Any suggestions? Regards RheinSkipper
On Wed, Feb 08, 2012 at 06:16:19PM +0100, Jürgen Baumgartl wrote:
When I use the marine style from resources/styles/marine, I get a lot of errors similar to this:
SCHWERWIEGEND (ExtTypeAttributes): ..\tiles\63240040.osm.pbf: OSM id 1460137282
(java.lang.NumberFormatException: For input string: "3+")
Do you see it in http://www.openstreetmap.org/browse/node/1460137282 or does it come from the style? In the source data, there seems to be seamark:light:sequence="3+(1)". Is this causing the error?
Any suggestions?
The marine style was written by Mark Burton, who appears to have disappeared since then. (Does anyone know what happened?) The marine style points file defines this rule: seamark:light:sequence=* { add mkgmap:xt-note='Sequence: ${seamark:light:sequence}'; } I guess that this tag is being processed by the mkgmap core. I think that you should answer the following questions? 1. Is the source data correct? 2. Can this be represented in the Garmin format? How? If the data is incorrect, correct it, either at the source or (not so nice approach) in the style file, for example so that only the part before the + sign is chosen. If the translation can be improved, then we need some fix for the handling of mkgmap:xt-note in the mkgmap core. Marko
On 08/02/12 18:55, Marko Mäkelä wrote:
On Wed, Feb 08, 2012 at 06:16:19PM +0100, Jürgen Baumgartl wrote:
When I use the marine style from resources/styles/marine, I get a lot of errors similar to this:
SCHWERWIEGEND (ExtTypeAttributes): ..\tiles\63240040.osm.pbf: OSM id 1460137282
(java.lang.NumberFormatException: For input string: "3+")
Do you see it in http://www.openstreetmap.org/browse/node/1460137282 or does it come from the style? In the source data, there seems to be seamark:light:sequence="3+(1)". Is this causing the error?
Yes it is. The piece of code that deals with light:sequence's is unfinished and does nothing, so I suggest just commenting it out as in attached patch. Until someone works out how to make them work. ..Steve
Am 08.02.2012 22:54, schrieb Steve Ratcliffe:
On 08/02/12 18:55, Marko Mäkelä wrote:
On Wed, Feb 08, 2012 at 06:16:19PM +0100, Jürgen Baumgartl wrote:
When I use the marine style from resources/styles/marine, I get a lot of errors similar to this:
SCHWERWIEGEND (ExtTypeAttributes): ..\tiles\63240040.osm.pbf: OSM id 1460137282
(java.lang.NumberFormatException: For input string: "3+")
Do you see it in http://www.openstreetmap.org/browse/node/1460137282 or does it come from the style? In the source data, there seems to be seamark:light:sequence="3+(1)". Is this causing the error?
Yes it is. The piece of code that deals with light:sequence's is unfinished and does nothing, so I suggest just commenting it out as in attached patch. Until someone works out how to make them work.
The attached patch enables/fixes the encoding of sequence. A new line appears in the property window ("Blinkfolge" in german MapSource, I suppose this will be sequence in english). While debugging the code I found that many seamark* attributes used in ExtTypeAttributes.java were not contained in attributes map although they are set in OSM data. It seems that there has to be a rule for each attribute in style. Is there a possibility to force mkgmap to keep all seamark attributes? Ronny
Hi
The attached patch enables/fixes the encoding of sequence. A new line appears in the property window ("Blinkfolge" in german MapSource, I suppose this will be sequence in english).
Thanks! that is great. I've tried it out and will commit it.
While debugging the code I found that many seamark* attributes used in ExtTypeAttributes.java were not contained in attributes map although they are set in OSM data. It seems that there has to be a rule for each attribute in style. Is there a possibility to force mkgmap to keep all seamark attributes?
All the tags can be listed under the extra-used-tags option in the options file of the marine style, instead of the do-nothing rules. Which ones are missing? ..Steve
Hi,
While debugging the code I found that many seamark* attributes used in ExtTypeAttributes.java were not contained in attributes map although they are set in OSM data. It seems that there has to be a rule for each attribute in style. Is there a possibility to force mkgmap to keep all seamark attributes?
All the tags can be listed under the extra-used-tags option in the options file of the marine style, instead of the do-nothing rules. Which ones are missing?
Thanks for the hint. The first one I found is seamark:light:character. I think a bit more complicated are sectors of lights since the sector number is part of the tag. They are tagged with seamark:light:# or more detailed with seamark:light:#:<attribute>, where # is the sector number and <attribute> describe the sector. This will result in a large number of extra used tags (I found a light with 9 sectors, each having 4 required tags). So it would be nice if we could use placeholders: extra-used-tags=seamark:light:* Todays implementation handles only the first, compact form with only one tag per sector. I will try to work out a patch to support both. Ronny
-----Ursprüngliche Nachricht----- Von: Ronny Klier [mailto:ronny.klier@s1999.tu-chemnitz.de] Gesendet: Montag, 13. Februar 2012 22:18 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] NumberFormatException when making marine chart
Am 08.02.2012 22:54, schrieb Steve Ratcliffe:
On 08/02/12 18:55, Marko Mäkelä wrote:
On Wed, Feb 08, 2012 at 06:16:19PM +0100, Jürgen Baumgartl wrote:
When I use the marine style from resources/styles/marine, I get a lot of errors similar to this:
SCHWERWIEGEND (ExtTypeAttributes): ..\tiles\63240040.osm.pbf: OSM id 1460137282
(java.lang.NumberFormatException: For input string: "3+")
Do you see it in http://www.openstreetmap.org/browse/node/1460137282 or does it come from the style? In the source data, there seems to be seamark:light:sequence="3+(1)". Is this causing the error?
Yes it is. The piece of code that deals with light:sequence's is unfinished and does nothing, so I suggest just commenting it out as in attached patch. Until someone works out how to make them work.
The attached patch enables/fixes the encoding of sequence. A new line appears in the property window ("Blinkfolge" in german MapSource, I suppose this will be sequence in english).
While debugging the code I found that many seamark* attributes used in ExtTypeAttributes.java were not contained in attributes map although they are set in OSM data. It seems that there has to be a rule for each attribute in style. Is there a possibility to force mkgmap to keep all seamark attributes?
Ronny
Thank you very much for working on this problem. With the new release of mkgmap I do not get these errors anymore when compiling a Germany map. But when compiling Europe, there are still a few hundred similar errors. Here are some of them: SCHWERWIEGEND (ExtTypeAttributes): ..\tiles\63240139.osm.pbf: OSM id 1370799327 (java.lang.NumberFormatException: For input string: ",1") SCHWERWIEGEND (ExtTypeAttributes): ..\tiles\63240139.osm.pbf: OSM id 1370799327 (java.lang.NumberFormatException: For input string: ",1") SCHWERWIEGEND (ExtTypeAttributes): ..\tiles\63240167.osm.pbf: OSM id 1568125071 (java.lang.NumberFormatException: For input string: ",0.5") SCHWERWIEGEND (ExtTypeAttributes): ..\tiles\63240167.osm.pbf: OSM id 1568125071 (java.lang.NumberFormatException: For input string: ",0.5") SCHWERWIEGEND (ExtTypeAttributes): ..\tiles\63240167.osm.pbf: OSM id 1568125071 (java.lang.NumberFormatException: For input string: ",0.5") SCHWERWIEGEND (ExtTypeAttributes): ..\tiles\63240187.osm.pbf: OSM id 1370800943 (java.lang.NumberFormatException: For input string: ",1") SCHWERWIEGEND (ExtTypeAttributes): ..\tiles\63240187.osm.pbf: OSM id 1370800943 (java.lang.NumberFormatException: For input string: ",1") SCHWERWIEGEND (ExtTypeAttributes): ..\tiles\63240187.osm.pbf: OSM id 1370800943 (java.lang.NumberFormatException: For input string: ",1") SCHWERWIEGEND (ExtTypeAttributes): ..\tiles\63240191.osm.pbf: OSM id 1572635927 (java.lang.NumberFormatException: For input string: ",0.5") SCHWERWIEGEND (ExtTypeAttributes): ..\tiles\63240191.osm.pbf: OSM id 1572635927 (java.lang.NumberFormatException: For input string: ",0.5") SCHWERWIEGEND (ExtTypeAttributes): ..\tiles\63240191.osm.pbf: OSM id 1572635927 (java.lang.NumberFormatException: For input string: ",0.5") SCHWERWIEGEND (ExtTypeAttributes): ..\tiles\63240235.osm.pbf: OSM id 1370799398 (java.lang.NumberFormatException: For input string: ",1") SCHWERWIEGEND (ExtTypeAttributes): ..\tiles\63240235.osm.pbf: OSM id 1370799398 (java.lang.NumberFormatException: For input string: ",1") SCHWERWIEGEND (ExtTypeAttributes): ..\tiles\63240235.osm.pbf: OSM id 1370799398 (java.lang.NumberFormatException: For input string: ",1") SCHWERWIEGEND (ExtTypeAttributes): ..\tiles\63240251.osm.pbf: OSM id 1370799843 (java.lang.NumberFormatException: For input string: ",1") SCHWERWIEGEND (ExtTypeAttributes): ..\tiles\63240251.osm.pbf: OSM id 1370799843 (java.lang.NumberFormatException: For input string: ",1") SCHWERWIEGEND (ExtTypeAttributes): ..\tiles\63240251.osm.pbf: OSM id 1370799843 (java.lang.NumberFormatException: For input string: ",1") SCHWERWIEGEND (ExtTypeAttributes): ..\tiles\63240261.osm.pbf: OSM id 1420666124 (java.lang.NumberFormatException: For input string: ",1") SCHWERWIEGEND (ExtTypeAttributes): ..\tiles\63240261.osm.pbf: OSM id 1420666124 (java.lang.NumberFormatException: For input string: ",1") SCHWERWIEGEND (ExtTypeAttributes): ..\tiles\63240261.osm.pbf: OSM id 130475520 (java.lang.NumberFormatException: For input string: ",1") SCHWERWIEGEND (ExtTypeAttributes): ..\tiles\63240261.osm.pbf: OSM id 1420666124 (java.lang.NumberFormatException: For input string: ",1") SCHWERWIEGEND (ExtTypeAttributes): ..\tiles\63240296.osm.pbf: OSM id 1370799405 (java.lang.NumberFormatException: For input string: ",1") SCHWERWIEGEND (ExtTypeAttributes): ..\tiles\63240296.osm.pbf: OSM id 1370799406 (java.lang.NumberFormatException: For input string: ",0.2") SCHWERWIEGEND (ExtTypeAttributes): ..\tiles\63240296.osm.pbf: OSM id 1370799408 (java.lang.NumberFormatException: For input string: ",0.2") SCHWERWIEGEND (ExtTypeAttributes): ..\tiles\63240296.osm.pbf: OSM id 1370799405 (java.lang.NumberFormatException: For input string: ",1")
Hi,
But when compiling Europe, there are still a few hundred similar errors.
Here are some of them:
SCHWERWIEGEND (ExtTypeAttributes): ..\tiles\63240139.osm.pbf: OSM id 1370799327 (java.lang.NumberFormatException: For input string: ",1")
The sequence is given as 1+(1),1+(3). I'm no expert on marine charts but according to the informations I found this seems to be an error (or uncommon way) to describe the sequence. The comma should be a + too. Ronny
Hi, I had a look for the occurences of sequence format like 1+(1),1+(3) in OSM and found it used at least in GB, france and spain. Given this wide usage, this patch allows "," as seperator. Additional (), which mark phases of eclipse, are handled explicit and not as seperator. Ronny
Hi, On Tue, Feb 21, Ronny Klier wrote:
I had a look for the occurences of sequence format like 1+(1),1+(3) in OSM and found it used at least in GB, france and spain. Given this wide usage, this patch allows "," as seperator. Additional (), which mark phases of eclipse, are handled explicit and not as seperator.
Looks like the patch itself is missing. Thorsten -- Thorsten Kukuk, Project Manager/Release Manager SLES SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
Am 22.02.2012 05:10, schrieb Thorsten Kukuk:
Hi,
On Tue, Feb 21, Ronny Klier wrote:
I had a look for the occurences of sequence format like 1+(1),1+(3) in OSM and found it used at least in GB, france and spain. Given this wide usage, this patch allows "," as seperator. Additional (), which mark phases of eclipse, are handled explicit and not as seperator.
Looks like the patch itself is missing.
Thorsten
Sorry, here it is.
Thank you for working out this patch. Most of those errors are away now. But there are still a few left: SCHWERWIEGEND (ExtTypeAttributes): ..\tiles\63240171.osm.pbf: OSM id 858908267 (java.lang.NumberFormatException: For input string: "0.7(1.3)0.7(2.8)") SCHWERWIEGEND (ExtTypeAttributes): ..\tiles\63240171.osm.pbf: OSM id 858908267 (java.lang.NumberFormatException: For input string: "0.7(1.3)0.7(2.8)") SCHWERWIEGEND (ExtTypeAttributes): ..\tiles\63240171.osm.pbf: OSM id 858908267 (java.lang.NumberFormatException: For input string: "0.7(1.3)0.7(2.8)") SCHWERWIEGEND (ExtTypeAttributes): ..\tiles\63240171.osm.pbf: OSM id 858908267 (java.lang.NumberFormatException: For input string: "0.7(1.3)0.7(2.8)") SCHWERWIEGEND (ExtTypeAttributes): ..\tiles\63240171.osm.pbf: OSM id 858908267 (java.lang.NumberFormatException: For input string: "0.7(1.3)0.7(2.8)") SCHWERWIEGEND (ExtTypeAttributes): ..\tiles\63240226.osm.pbf: number of light and eclipse phases has to be equal SCHWERWIEGEND (ExtTypeAttributes): ..\tiles\63240226.osm.pbf: number of light and eclipse phases has to be equal SCHWERWIEGEND (ExtTypeAttributes): ..\tiles\63240347.osm.pbf: OSM id 34329207 (java.lang.NumberFormatException: For input string: "0.3(2.7)0.3(2.7)0.3(8.7)0.3(8.7)") SCHWERWIEGEND (ExtTypeAttributes): ..\tiles\63240411.osm.pbf: OSM id 1329409893 (java.lang.NumberFormatException: For input string: "5n") SCHWERWIEGEND (ExtTypeAttributes): ..\tiles\63240411.osm.pbf: OSM id 1329409893 (java.lang.NumberFormatException: For input string: "5n") SCHWERWIEGEND (ExtTypeAttributes): ..\tiles\63240411.osm.pbf: OSM id 1329409893 (java.lang.NumberFormatException: For input string: "5n") SCHWERWIEGEND (ExtTypeAttributes): ..\tiles\63240577.osm.pbf: OSM id 1579301572 (java.lang.NumberFormatException: For input string: "unknown") SCHWERWIEGEND (ExtTypeAttributes): ..\tiles\63240577.osm.pbf: OSM id 1579301572 (java.lang.NumberFormatException: For input string: "unknown") SCHWERWIEGEND (ExtTypeAttributes): ..\tiles\63240577.osm.pbf: OSM id 1579301572 (java.lang.NumberFormatException: For input string: "unknown") http://wiki.openstreetmap.org/wiki/User:RheinSkipper
-----Ursprüngliche Nachricht----- Von: mkgmap-dev-bounces@lists.mkgmap.org.uk [mailto:mkgmap-dev- bounces@lists.mkgmap.org.uk] Im Auftrag von Ronny Klier Gesendet: Mittwoch, 22. Februar 2012 22:05 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] [Patch] sequence in marine charts
Am 22.02.2012 05:10, schrieb Thorsten Kukuk:
Hi,
On Tue, Feb 21, Ronny Klier wrote:
I had a look for the occurences of sequence format like 1+(1),1+(3) in OSM and found it used at least in GB, france and spain. Given this wide usage, this patch allows "," as seperator. Additional (), which mark phases of eclipse, are handled explicit and not as seperator.
Looks like the patch itself is missing.
Thorsten
Sorry, here it is.
Hi,
SCHWERWIEGEND (ExtTypeAttributes): ..\tiles\63240171.osm.pbf: OSM id 858908267 (java.lang.NumberFormatException: For input string: "0.7(1.3)0.7(2.8)")
If there are only a small number of lights with sequence given in this format I would propose to insert the + signs. This format is defined by the norm IHO-S-57 (see http://www.caris.com/S-57/frames/S57catalog.htm, Object:Lights, Attribute:SIGSEQ) which is referred by OpenSeaMap/Lights Data Model.
SCHWERWIEGEND (ExtTypeAttributes): ..\tiles\63240226.osm.pbf: number of light and eclipse phases has to be equal
This seems to be an error in OSM data. It would mean that two phases of light or eclipse follow each other but this isn't possible. The attached patch includes the OSM id in the message, so it should be easy to fix the error. The patch also fixes a problem introduced with my last patch: single light phases (e.g. 1+(2)) were ignored.
SCHWERWIEGEND (ExtTypeAttributes): ..\tiles\63240347.osm.pbf: OSM id 34329207 (java.lang.NumberFormatException: For input string: "0.3(2.7)0.3(2.7)0.3(8.7)0.3(8.7)") SCHWERWIEGEND (ExtTypeAttributes): ..\tiles\63240411.osm.pbf: OSM id 1329409893 (java.lang.NumberFormatException: For input string: "5n")
I don't know what this should mean. Does anybody else?
SCHWERWIEGEND (ExtTypeAttributes): ..\tiles\63240577.osm.pbf: OSM id 1579301572 (java.lang.NumberFormatException: For input string: "unknown")
We could not invent missing information ;-) Ronny
Thank you very much for patching again. Here is the output of the new r2235: SCHWERWIEGEND (ExtTypeAttributes): ..\tiles\63240169.osm.pbf: Type=66057, l=[4344]nullnumber of light and eclipse phases has to be equal SCHWERWIEGEND (ExtTypeAttributes): ..\tiles\63240256.osm.pbf: OSM id 858908267 (java.lang.NumberFormatException: For input string: "0.7(1.3)0.7(2.8)") SCHWERWIEGEND (ExtTypeAttributes): ..\tiles\63240256.osm.pbf: OSM id 858908267 (java.lang.NumberFormatException: For input string: "0.7(1.3)0.7(2.8)") SCHWERWIEGEND (ExtTypeAttributes): ..\tiles\63240256.osm.pbf: OSM id 858908267 (java.lang.NumberFormatException: For input string: "0.7(1.3)0.7(2.8)") SCHWERWIEGEND (ExtTypeAttributes): ..\tiles\63240256.osm.pbf: OSM id 858908267 (java.lang.NumberFormatException: For input string: "0.7(1.3)0.7(2.8)") SCHWERWIEGEND (ExtTypeAttributes): ..\tiles\63240256.osm.pbf: OSM id 858908267 (java.lang.NumberFormatException: For input string: "0.7(1.3)0.7(2.8)") SCHWERWIEGEND (ExtTypeAttributes): ..\tiles\63240273.osm.pbf: Type=66058, l=[1675]nullnumber of light and eclipse phases has to be equal SCHWERWIEGEND (ExtTypeAttributes): ..\tiles\63240320.osm.pbf: OSM id 1329409893 (java.lang.NumberFormatException: For input string: "5n") SCHWERWIEGEND (ExtTypeAttributes): ..\tiles\63240320.osm.pbf: OSM id 1329409893 (java.lang.NumberFormatException: For input string: "5n") SCHWERWIEGEND (ExtTypeAttributes): ..\tiles\63240320.osm.pbf: OSM id 1329409893 (java.lang.NumberFormatException: For input string: "5n") SCHWERWIEGEND (ExtTypeAttributes): ..\tiles\63240384.osm.pbf: OSM id 34329207 (java.lang.NumberFormatException: For input string: "0.3(2.7)0.3(2.7)0.3(8.7)0.3(8.7)") SCHWERWIEGEND (ExtTypeAttributes): ..\tiles\63240496.osm.pbf: OSM id 1653367564 (java.lang.NumberFormatException: empty String) SCHWERWIEGEND (ExtTypeAttributes): ..\tiles\63240496.osm.pbf: OSM id 1653367564 (java.lang.NumberFormatException: empty String) SCHWERWIEGEND (ExtTypeAttributes): ..\tiles\63240496.osm.pbf: OSM id 1653367564 (java.lang.NumberFormatException: empty String)
-----Ursprüngliche Nachricht----- Von: mkgmap-dev-bounces@lists.mkgmap.org.uk [mailto:mkgmap-dev- bounces@lists.mkgmap.org.uk] Im Auftrag von Ronny Klier Gesendet: Dienstag, 28. Februar 2012 22:54 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] [Patch] sequence in marine charts
Hi,
SCHWERWIEGEND (ExtTypeAttributes): ..\tiles\63240171.osm.pbf: OSM id 858908267 (java.lang.NumberFormatException: For input string: "0.7(1.3)0.7(2.8)")
If there are only a small number of lights with sequence given in this format I would propose to insert the + signs. This format is defined by the norm IHO-S-57 (see http://www.caris.com/S- 57/frames/S57catalog.htm, Object:Lights, Attribute:SIGSEQ) which is referred by OpenSeaMap/Lights Data Model.
SCHWERWIEGEND (ExtTypeAttributes): ..\tiles\63240226.osm.pbf: number of light and eclipse phases has to be equal
This seems to be an error in OSM data. It would mean that two phases of light or eclipse follow each other but this isn't possible. The attached patch includes the OSM id in the message, so it should be easy to fix the error. The patch also fixes a problem introduced with my last patch: single light phases (e.g. 1+(2)) were ignored.
SCHWERWIEGEND (ExtTypeAttributes): ..\tiles\63240347.osm.pbf: OSM id 34329207 (java.lang.NumberFormatException: For input string: "0.3(2.7)0.3(2.7)0.3(8.7)0.3(8.7)") SCHWERWIEGEND (ExtTypeAttributes): ..\tiles\63240411.osm.pbf: OSM id 1329409893 (java.lang.NumberFormatException: For input string: "5n")
I don't know what this should mean. Does anybody else?
SCHWERWIEGEND (ExtTypeAttributes): ..\tiles\63240577.osm.pbf: OSM id 1579301572 (java.lang.NumberFormatException: For input string: "unknown")
We could not invent missing information ;-)
Ronny
participants (6)
-
Jürgen Baumgartl -
Marko Mäkelä -
RheinSkipper -
Ronny Klier -
Steve Ratcliffe -
Thorsten Kukuk