- mkgmap-dev - The mkgmap lists

branch expr
by Gerd Petermann 18 Sep '17

18 Sep '17

Hi all, I think we should merge the expr branch into trunk. @Steve: Any reason why you didn't do it already? Gerd

1 0

Recent Garmin Firmware "cannot authenticate maps" when they are unicode
by franco_bez 17 Sep '17

17 Sep '17

Hi all, maybe it's already a know bug. I just stumbled over this one: On a new Oregon750 I got the Error "cannot authenticate maps", while on the old Oregon550 the maps worked like always. I found out that changing the option "unicode" to "latin1" in my style did the trick, the resulting maps work on both devices. Over here in Germany I have no problem with latin1, but I suspect that in Russia or in the middle east or far east countries this will be a real problem. I attached the Error Screenshots. Ciao, Franco <http://gis.19327.n8.nabble.com/file/n5901399/IMG_20170818_063414%7E01.jpg> <http://gis.19327.n8.nabble.com/file/n5901399/IMG_20170818_063911%7E01.jpg> -- View this message in context: http://gis.19327.n8.nabble.com/Recent-Garmin-Firmware-cannot-authenticate-m… Sent from the Mkgmap Development mailing list archive at Nabble.com.

6 13

Rule not working consistently
by Felix Hartmann 14 Sep '17

14 Sep '17

Anyone got any idea why the following rule is not working as expected? name:int!=* & ( name:en=* | int_name=* | name:fr=* | name_en=* | name_int=* | name:es=* | name:pt=* | name:de=* | name:it=* | name:nl=* | name:dk=* ) {set name:int='${name:en}' | name:int='${int_name}' | name:int='${name_int}' | name:int='${name_en}' | name:int='${name:de}' | name:int='${name:fr}' | name:int='${name:es}' | name:int='${name:pt}' | name:int='${name:it}' | name:int='${name:nl}' | name:int='${name:dk}' } If I use it - and then later set name:int=* {set name='${name:int}'} I end up having many places in my map where instead of using the actual name:int value I get "name:int" instead. Sometimes it does work however - so I'm at a loss why. If I instead write out the rules one after another it does work well - is the rule to long? is there some bug in mkgmap? Do I have some super strange spelling mistake in it? (so if I write name:int!=* & name:en=* { set name:int='${name:en}' } name:int!=* & int_name=* { set name:int='${int_name}' } ...... it works correctly (but I think this will be slow to process and is simply many more lines to write.) Is the rule too long? Is there some bug in mkmgap? do I have a typo even though I checked it for ages? It really just works for some objects and for some it will instead put name:int into the label instead even though all name tags are identical. -- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich

2 4

mkgmap NPE
by Carlos Dávila 13 Sep '17

13 Sep '17

Hello I'm getting a NPE building a map of Asia: java.lang.NullPointerException at uk.me.parabola.mkgmap.osmstyle.housenumber.HousenumberGenerator.useAddrPlaceTag(HousenumberGenerator.java:873) at uk.me.parabola.mkgmap.osmstyle.housenumber.HousenumberGenerator.generate(HousenumberGenerator.java:626) at uk.me.parabola.mkgmap.osmstyle.StyledConverter.end(StyledConverter.java:658) at uk.me.parabola.mkgmap.reader.osm.ElementSaver.convert(ElementSaver.java:243) at uk.me.parabola.mkgmap.reader.osm.OsmMapDataSource.load(OsmMapDataSource.java:157) 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:263) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:259) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) Tile causing the error can be downloaded from: http://alternativaslibres.org/51700527.o5m mkgmap command: export MAPA=Asia FID=70 ABR=ASI NAMETAG=name LANGUAGE=non_latin; java -Xmx7G -ea -Dlog.config=logging.properties -jar mkgmap-r3995/mkgmap.jar --output-dir=./tmp --bounds=bounds.zip --precomp-sea=sea.zip --max-jobs --route --latin1 --code-page=1252 --area-name=$MAPA --family-name="OpenStreetMap $MAPA" --family-id=1${FID} --product-id=1 --series-name="OSM-$MAPA" --overview-mapname=$ABR-1${FID} --overview-mapnumber=51${FID}0000 --name-tag-list=$NAMETAG --process-destination --process-exits --housenumbers --reduce-point-density=4 --polygon-size-limits="24:12, 18:10, 16:0" --add-pois-to-areas --report-similar-arcs --report-dead-ends=2 --link-pois-to-ways --location-autofill=is_in,nearest --drive-on=detect --check-roundabouts --check-roundabout-flares --license-file=license_ODbL.txt --copyright-message="OpenStreetMap contributors, ODbL. See: http://www.openstreetmap.org/copyright" 51700527.o5m

2 3

default style and highway=services
by Gerd Petermann 13 Sep '17

13 Sep '17

Hi all, I've just noticed that there is no special rule for this tag https://wiki.openstreetmap.org/wiki/Tag:highway=services in the default style. In fact, it is often handled by the "mop up" rule highway=* & area!=yes [0x07 road_class=0 road_speed=0 resolution 23] because many mappers forget to add area=yes as suggested in the wiki. I think we should add a rule like highway=services & area!=* & is_closed() = true {add area=yes} somewhere before the mop up rule. Comments? Gerd -- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html

2 1

Commit r3996: add test to avoid rare NPE in HousenumberGenerator.useAddrPlaceTag()
by svn commit 11 Sep '17

11 Sep '17

Version mkgmap-r3996 was committed by gerd on Mon, 11 Sep 2017 add test to avoid rare NPE in HousenumberGenerator.useAddrPlaceTag() A rare combination of addr:place, addr:street and a way with addr:interpolation in combination with missing road name seems to cause this. Did not find the right place to fix it, so the data is now simply ignored. http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3996

1 0

default style:pier
by nwillink 08 Sep '17

08 Sep '17

Hi Just an observation : The default style adds a footway to all piers. (man_made=pier | man_made=piste:halfpipe) & area!=yes {add highway=footway; name '${ref} ${name}' | '${ref}' | '${name}' } I can see why ,particularly with large wide piers like Brighton Pier. Such piers are relatively rare. Unfortunately , the pier tag is too general and can also include a place for mooring (mooring=yes). These 'mooring piers' are most commonly not open to the general public , their entrance being barred by a gate. In an ideal world such piers should have an access restriction. When I visited Falmouth this summer I thought I was able to walk along all the piers mapped ; unfortunately, I couldn't. When I create my 'walking maps' I only add a footway when area=yes or the pier includes route=hiking etc relation. Take Torquay harbour : it looks as if you can do a nice stroll along all these 'piers'; in reality access is private. I'm not sure what to do about this other than adding access tags to each pier. -- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html

1 0

License issue in mkgmap & splitter source: GPL-2 (v2 only) incompatible with GPL-3 (v3 only)
by Sebastiaan Couwenberg 02 Sep '17

02 Sep '17

Several source files are licensed under the GPL-2 which is incompatible with GPL-3 source in splitter. To combine GPL-2 code with GPL-3 code, the GPL-2 code needs to be license under the GPL-2+ (v2 or later), or dual-licensed under the GPL-2 (v2 only) or GPL-3 (v3 only).[0] The mkgmap source files in question: src/uk/me/parabola/mkgmap/filters/MustSplitException.java src/uk/me/parabola/mkgmap/reader/MapReader.java The splitter source files in question: src/uk/me/parabola/splitter/tools/BitReader.java src/uk/me/parabola/splitter/tools/BitWriter.java test/func/ArgsTest.java test/func/Base.java test/func/SolverAndProblemGeneratorTest.java test/func/lib/Args.java test/func/lib/Outputs.java test/func/lib/TestUtils.java test/uk/me/parabola/splitter/tools/TestBitReader.java Steve & Gerd, can you relicense the code to GPL-2+ (v2 or later) or dual license those files as GPL-2 (v2 only) or GPL-3 (v3 only)? This issue prevents the update of the mkgmap packages in Debian. Kind Regards, Bas [0] https://www.gnu.org/licenses/gpl-faq.html#AllCompatibility -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1

3 8

splitter crash
by Mike Baggaley 25 Aug '17

25 Aug '17

I had an osm file that had an empty value for lat and long at one node and it crashed splitter as below: Exception in thread "producer for DensityMapCollector" java.lang.AssertionError at uk.me.parabola.splitter.parser.O5mMapParser.readNode(O5mMapParser.java:248) at uk.me.parabola.splitter.parser.O5mMapParser.readFile(O5mMapParser.java:183) at uk.me.parabola.splitter.parser.O5mMapParser.parse(O5mMapParser.java:141) at uk.me.parabola.splitter.OSMFileHandler.process(OSMFileHandler.java:85) at uk.me.parabola.splitter.OSMFileHandler$1.run(OSMFileHandler.java:148) I think the attached patch should fix the problem (I can't test it because I haven't got a full development environment of splitter, but it just replaces the asserts with throws). Can you please test and commit if you are happy with it? Thanks, Mike

2 1

Re: [mkgmap-dev] Buildings with wrong corners.
by d.kwapisz 24 Aug '17

24 Aug '17

Thank You Gerd Darek W dniu 2017-08-24 19:46:39 użytkownik Gerd Petermann <GPetermann_muenchen(a)hotmail.com> napisał: > Hi Dariusz, > > this is caused by the rather low resolution used in the img format (~ 2.3m) while OSM is somewhere near 1 cm. > You did nothing wong and mkgmap already contains code to reduce the errors. > Imagine you have to draw a picture using lines on a bed of nails. Each real OSM node is rounded so that it > falls exactly on a nail. > > Gerd > > ________________________________________ > Von: mkgmap-dev <mkgmap-dev-bounces(a)lists.mkgmap.org.uk> im Auftrag von d.kwapisz <d.kwapisz(a)onet.eu> > Gesendet: Mittwoch, 23. August 2017 16:11:15 > An: mkgmap-dev(a)lists.mkgmap.org.uk > Betreff: [mkgmap-dev] Buildings with wrong corners. > > Hi, > The buildings which are correct in OSM, after using 'mkgmap', they haven't right angles (the edges are not perpendicular). > > There are any 'mkgmap' options responsible for this? Or maybe I'm doing something wrong? > > I attached file with two screens (from OSM and BaseCamp). > > Best regards > Dariusz Kwapisz > > _______________________________________________ > mkgmap-dev mailing list > mkgmap-dev(a)lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >

1 0