Problem using housenumber option
Hi, I'm trying to generate a map of Italy using house numbers option (--x- housenumbers) with latest mkgmap (r2494). I see this output traces: java.lang.IllegalArgumentException at uk.me.parabola.imgfmt.app.BitWriter.putn(BitWriter.java:89) at uk.me.parabola.imgfmt.app.net.NumberPreparer.writeInitialValue (Number Preparer.java:174) at uk.me.parabola.imgfmt.app.net.NumberPreparer.fetchBitStream (NumberPre parer.java:69) at uk.me.parabola.imgfmt.app.net.RoadDef.writeNet1(RoadDef.java:203) at uk.me.parabola.imgfmt.app.net.NETFile.write(NETFile.java:66) at uk.me.parabola.mkgmap.build.MapBuilder.makeMap(MapBuilder.java:220) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:97) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:61) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:201) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:198) at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source) 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 and the gmapsupp.img is not created at all. Trying to debug a little bit, i found that the problem seems to be related to this OSM element: <relation id="2198742" user="Pab09" uid="178610" visible="true" version="2" changeset="13345939" timestamp="2012-10-03T11:17:51Z"> <member type="way" ref="31563508" role="outer"/> <member type="way" ref="165015469" role="outer"/> <tag k="addr:housename" v="Hidron"/> <tag k="addr:housenumber" v="055892500"/> <tag k="addr:postcode" v="50013"/> <tag k="addr:street" v="Via di Gramignano"/> <tag k="leisure" v="sports_centre"/> <tag k="name" v="Hydron"/> <tag k="sport" v="swimming"/> <tag k="type" v="multipolygon"/> </relation> As you can see, addr:housenumber is not a valid house number (in fact it seems to me a telephon number !). However, there is, possibly, a missing check on what is supposed to be a valid housenumber (probably a sort of sanity check is needed: not all numbers could be used as house numbers, at least in relation to garmin img format limitations). I'm not sure, but I think the same problem is present with other OSM element, at least, in Italy. Thank you to all of you for your attention and for your excellent work ! ggalli
Hi
housenumbers) with latest mkgmap (r2494). I see this output traces:
java.lang.IllegalArgumentException at uk.me.parabola.imgfmt.app.BitWriter.putn(BitWriter.java:89) at uk.me.parabola.imgfmt.app.net.NumberPreparer.writeInitialValue(Number Preparer.java:174) at uk.me.parabola.imgfmt.app.net.NumberPreparer.fetchBitStream
Trying to debug a little bit, i found that the problem seems to be related to this OSM element:
<tag k="addr:housenumber" v="055892500"/>
Thanks, that's in my part of the code. It is as you say probably not a real number and I don't know if numbers that big can be represented in the format or not. If they can't then I will just ignore it. ..Steve
Hi, I've now compiled a Benelux map succesfully with the housenumber search. In the errorlog (mkgmap-r2494) it reported housenumbers with fixme and streetnames (dont know if this is fixed already) but in general it can find most addresses. I even merged the whole database of ALL streets+housenumbers for the Netherlands into the OSM extract (so called BAG data from the Dutch Kadaster) and this went fine :-) One issue is that Mapsource displays street,housenumber,province,country but not street,housenumber,place,country and this is only for some addresses in this street. Other addresses in the same street can find also the placename. This BAG dataset that I merged with OSM contained the nodes with addr:housenumber and addr:street tags, but maybe the search would improve if I added addr:city as well or is it an index problem?
<tag k="addr:housenumber" v="055892500"/>
Thanks, that's in my part of the code. It is as you say probably not a real number and I don't know if numbers that big can be represented in the format or not. If they can't then I will just ignore it.
..Steve
Hi, I maybe have found a cause, it happens often (not always) if the numbers have subletters A B C etc Then the place is not listed, only province and country nr 68 consists of a block of 68 A, B C and D Mapsource or mkgmap leaves the cityname out: Liendertseweg 68, Utrecht, NLD Other addresses along the same street have the cityname 'Amersfoort'. Please note that those addresses are not derived from OSM but from BAG, see http://bagviewer.geodan.nl/index.html You can download the map at http://www.openfietsmap.nl/downloads/bnl_full
One issue is that Mapsource displays street,housenumber,province,country but not street,housenumber,place,country and this is only for some addresses in this street. Other addresses in the same street can find also the placename.
This BAG dataset that I merged with OSM contained the nodes with addr:housenumber and addr:street tags, but maybe the search would improve if I added addr:city as well or is it an index problem?
<tag k="addr:housenumber" v="055892500"/>
Thanks, that's in my part of the code. It is as you say probably not a real number and I don't know if numbers that big can be represented in the format or not. If they can't then I will just ignore it.
..Steve
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
For those who are interested in testing the Dutch address BAG data and merge it with OSM, you can download it here: https://docs.google.com/file/d/0B3EBJnB3prcXczBTNHNVTkRJNlE/edit?pli=1 For combining you need to unzip it and use osmconvert: osmconvert netherlands.osm.pbf adressen.osm -o=nl_address.o5m Some of this data is already imported into OSM, but it seems they don't bite each other so no need to filter it out.
Hi, I've now compiled a Benelux map succesfully with the housenumber search. In the errorlog (mkgmap-r2494) it reported housenumbers with fixme and streetnames (dont know if this is fixed already) but in general it can find most addresses.
I think there is nothing to fix? If the addr:housenumber tag contains the value "fixme" it's a tagging error. Anyhow I will lower the log level of the error message.
I even merged the whole database of ALL streets+housenumbers for the Netherlands into the OSM extract (so called BAG data from the Dutch Kadaster) and this went fine :-)
One issue is that Mapsource displays street,housenumber,province,country but not street,housenumber,place,country and this is only for some addresses in this street. Other addresses in the same street can find also the placename.
Do you use preprocessed bounds? Which mkgmap parameters do you use?
This BAG dataset that I merged with OSM contained the nodes with addr:housenumber and addr:street tags, but maybe the search would improve if I added addr:city as well or is it an index problem?
addr:city is not evaluated for housenumber processing. WanMil
<tag k="addr:housenumber" v="055892500"/>
Thanks, that's in my part of the code. It is as you say probably not a real number and I don't know if numbers that big can be represented in the format or not. If they can't then I will just ignore it.
..Steve
Wanmil wrote:
I think there is nothing to fix? If the addr:housenumber tag contains the value "fixme" it's a tagging error. Anyhow I will lower the log level of the error message.
I agree
I even merged the whole database of ALL streets+housenumbers for the Netherlands into the OSM extract (so called BAG data from the Dutch Kadaster) and this went fine :-)
One issue is that Mapsource displays street,housenumber,province,country but not street,housenumber,place,country and this is only for some addresses in this street. Other addresses in the same street can find also the placename.
Do you use preprocessed bounds? Which mkgmap parameters do you use?
Yes, I use bounds: bounds_20130201.zip location-autofill: is-in,nearest x-housenumbers
This BAG dataset that I merged with OSM contained the nodes with addr:housenumber and addr:street tags, but maybe the search would improve if I added addr:city as well or is it an index problem?
addr:city is not evaluated for housenumber processing.
Ok, so adding those fields won't improve the housenumber search yet. I have now filtered all subnumbers and letters out but it didnt make any difference. Some housenumbers are still found without a city (in the same street other housenumbers were found with city, so it is not caused by a missing or broken boundary) and I couldnt find any logical pattern (I thought it had to do with the subletters but that wasnt the case). Anyway, apart from those small issues I'm very happy with the housenumber search.
Hi, I tested the new housenumber option and found following issues: - Some Housenumbers are shown as tooltip on the map, but are not findable via search-address. - Route Calculation (even to short distance destinations) often stops at 68% or 81% with error message "not enough memory". Release : 2494 Device: Nuvi 250 Greetings Chris
I've had the same problem with a Nüvi 1490T when compiling a map with the default style and mkgmap r2494. I had turned on housenumbers but didn't test if the problem doesn't exist without housenumbers. WanMil
I wrote:
- Route Calculation (even to short distance destinations) often stops at 68% or 81% with error message "not enough memory".
This is not related to the --x-housenumbers option (also occurs without using this option). Maybe some glitch in my style....
Chris
The problem still exist with r2501. I will try now with the default style and without housenumbers. WanMil
I've had the same problem with a Nüvi 1490T when compiling a map with the default style and mkgmap r2494. I had turned on housenumbers but didn't test if the problem doesn't exist without housenumbers.
WanMil
I wrote:
- Route Calculation (even to short distance destinations) often stops at 68% or 81% with error message "not enough memory".
This is not related to the --x-housenumbers option (also occurs without using this option). Maybe some glitch in my style....
Chris
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Am 24.02.2013 20:18, schrieb WanMil:
I've had the same problem with a Nüvi 1490T when compiling a map with the default style and mkgmap r2494. I had turned on housenumbers but didn't test if the problem doesn't exist without housenumbers.
Hi, my problem was caused by using routable lines without road_class (see thread "bollard cause routing breakage"). Sometimes a hard reset can help on the "not enough memory" problem on the Nuvi, especially when the error occurs only for long distance routes. Chris
- Route Calculation (even to short distance destinations) often stops at 68% or 81% with error message "not enough memory".
This is not related to the --x-housenumbers option (also occurs without using this option). Maybe some glitch in my style....
Chris
Chris, are they findable if you ignore the place name? I often see that those addresses contain a letter (for instance 4A). Is it possible to filter non numeric signs out with the style rules by using regular expression?
- Some Housenumbers are shown as tooltip on the map, but are not findable via search-address.
Am 23.02.2013 19:19, schrieb Minko:
- Some Housenumbers are shown as tooltip on the map, but are not findable via search-address.
are they findable if you ignore the place name? I often see that those addresses contain a letter (for instance 4A).
Yes, they are findable if place is ignored. So, numbers "7" and "8" are findable with place and number "2" only w/o place. Funny. Chris
Hi I've now fixed all the known cases where large house numbers cause an exception. For reference the lowest limit is the difference between the start and end number of a stretch of road which must be less that around 100,000. This is the limit of the format (as known) there may well be a lower limit of what can be displayed! ..Steve
participants (5)
-
chris66 -
Jack Ughetta -
Minko -
Steve Ratcliffe -
WanMil