June 2015 - mkgmap-dev - The mkgmap lists

[Patch v1] simplify address rules
by Gerd Petermann 06 Jun '15

06 Jun '15

Hi all, attached is a patch that removes all rules which I think are superfluous. I've also attached the modified inc/address file. My understanding is that country specific rules should only be used when the general rules don't work. It makes no sense to have a specific rule mkgmap:country=BEL & mkgmap:city!=* & mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8}' } when the next possible match is the general rule mkgmap:city!=* & mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8}' } Or is this meant as some kind of documentation (meaning we have verified these rules for Belgium) ? Gerd

2 5

OT: tool to split gpx file ?
by Gerd Petermann 06 Jun '15

06 Jun '15

Hi all, does anybody know a simple tool to split a gpx track file with e.g. 50.000 points into pieces of 2000 points, giving each one a name like xyz-part-001.gpx, xyz-part-002.gpx etc? Or is there another way to avoid long load times when using such a large gpx track on the Oregon 600 ? Gerd

3 3

Commit: r3611: prevent merging of roads when special tag mkgmap:numbers is different
by svn commit 06 Jun '15

06 Jun '15

Version mkgmap-r3611 was committed by gerd on Sat, 06 Jun 2015 prevent merging of roads when special tag mkgmap:numbers is different

1 0

Commit: r3610: remove wrong rules to set mkgmap:city for France
by svn commit 06 Jun '15

06 Jun '15

Version mkgmap-r3610 was committed by gerd on Sat, 06 Jun 2015 remove wrong rules to set mkgmap:city for France 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. - Paco Tyson

1 0

Wrong adresses for 3 french cities
by Paco Tyson 06 Jun '15

06 Jun '15

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

2 3

Commit: r3609: revert unintended changes in comments
by svn commit 06 Jun '15

06 Jun '15

Version mkgmap-r3609 was committed by gerd on Sat, 06 Jun 2015 revert unintended changes in comments

1 0

Commit: r3608: change type 0x2b03 to 0x2b05 for camping, 0x2b03 is not
by svn commit 05 Jun '15

05 Jun '15

Version mkgmap-r3608 was committed by gerd on Fri, 05 Jun 2015 change type 0x2b03 to 0x2b05 for camping, 0x2b03 is not listed in POI search on modern devices

3 2

index problem camp_site
by Minko 05 Jun '15

05 Jun '15

Hi, On the OSM forum someone found out that on some Garmin devices tourism=camp_site and tourism=caravan_site [0x2b03] cannot be found. See http://forum.openstreetmap.org/viewtopic.php?id=31093 http://forums.gpsreview.net/discussion/29752/campsite-pois-do-not-show-on-g… On the device's map they are rendered ok, in Basecamp and Mapsource as well and can also be found. But on an Oregon, Dakota and GPSmap 64 they are not listed. On my Openfietsmap I use 0x2b05 for camp_site, and this poi has not this issue (appears in the search menu of my Oregon). Is this a Garmin device bug or mkgmap index problem? Should we use 0x2b05 in the default style for camp sites/caravan sites?

3 7

Re: [mkgmap-dev] POIs without POI-search
by arndt 05 Jun '15

05 Jun '15

Thanks, is it possibel too, that the POIs NOT visible in AllPois? Arndt <div>-------- Ursprüngliche Nachricht --------</div><div>Von: Bernd Weigelt <weigelt.bernd(a)web.de> </div><div>Datum:05.06.2015 09:36 (GMT+01:00) </div><div>An: Arndt <arndt(a)speichenkarte.de>, Development list for mkgmap <mkgmap-dev(a)lists.mkgmap.org.uk> </div><div>Betreff: Re: [mkgmap-dev] POIs without POI-search </div><div> </div>Am Freitag, 5. Juni 2015, 08:46:36 schrieb Arndt: Hi Arndt you can use these types 0x2900-?, they are visible in 'all POIs', but not in other categories We, Franco and i, made a lot of tests to make sure how POIs types are sorted by the garmin devices. Bernd > Hello experts, > > there are many POIs like barrier, traffic lights, trees an so on. Is it > possible to show them in the map, but without a hit in the poi-search? > > Best regards > > Arndt -- amarok2 now playing:

4 3

IndexOutOfBoundsException in US map with mkgmap 3605
by Ben Konrath 05 Jun '15

05 Jun '15

Hi, I have a IndexOutOfBoundsException while generating a map of the United States with mkgmap 3605. I think this is related to the recent house number merge because 3598 worked fine and the problem seems to come from house number related code. java.lang.IndexOutOfBoundsException: bitIndex < 0: -1 at java.util.BitSet.get(BitSet.java:615) at uk.me.parabola.mkgmap.osmstyle.housenumber.HousenumberGenerator$RoadSegmentIndex.createHousenumberMatch(HousenumberGenerator.java:2055) at uk.me.parabola.mkgmap.osmstyle.housenumber.HousenumberGenerator.findClosestRoadsToHouse(HousenumberGenerator.java:794) at uk.me.parabola.mkgmap.osmstyle.housenumber.HousenumberGenerator.generate(HousenumberGenerator.java:621) at uk.me.parabola.mkgmap.osmstyle.StyledConverter.end(StyledConverter.java:619) at uk.me.parabola.mkgmap.reader.osm.ElementSaver.convert(ElementSaver.java:250) at uk.me.parabola.mkgmap.reader.osm.o5m.O5mBinMapDataSource.load(O5mBinMapDataSource.java:53) 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) Here's how I'm calling mkgamp: java -Xmx14000M -jar -Dlog.config=/home/ben/osm/confs/logging.properties /home/ben/osm/mkgmap/dist/mkgmap.jar --latin1 --gmapsupp --index --route --min-size-polygon --series-name="United States 2015.06.03" --family-name="United States 2015.06.03" --location-autofill=bounds,is_in,nearest --remove-ovm-work-files --bounds=/home/ben/osm/data/bounds --precomp-sea=/home/ben/osm/data/sea_20150602.zip --generate-sea --add-pois-to-areas --process-destination --process-exits --pois-to-areas-placement="entrance=main;entrance=yes;building=entrance" --check-roundabout-flares --remove-short-arcs --family-id=14244 --product-id=1 --make-opposite-cycleways --drive-on=detect,right --check-roundabouts --housenumbers -c template.args --description="United States 2015.06.03" /home/ben/osm/confs/typ.txt Obviously a full US map is big so I don't know exactly where the problem is. What's the best way to help narrow done the problem? Let me know what I can do. Thanks, Ben

2 2