- mkgmap-dev - The mkgmap lists

Commit: r2437: All java files are in utf-8, so explicity state this on the javac
by svn commit 06 Jan '13

06 Jan '13

Version 2437 was committed by steve on Sun, 06 Jan 2013 All java files are in utf-8, so explicity state this on the javac tasks, so that compilation will work if the default encoding is not utf-8.

1 0

mkgmap unit tests fail
by GerdP 06 Jan '13

06 Jan '13

Hi Steve, please check: I used ant obtain-test-input-files ant test on r2436 and I see errors in package uk.me.parabola.imgfmt.app.srt Gerd -- View this message in context: http://gis.19327.n5.nabble.com/mkgmap-unit-tests-fail-tp5742996.html Sent from the Mkgmap Development mailing list archive at Nabble.com.

2 5

Short Arc Problem? Error 3 Mapsource, Problem on Calculating this route Basecamp.
by Felix Hartmann 06 Jan '13

06 Jan '13

I have found (or better someone told me about a problem) a road that crahes Mapsource. Go to "Tossa del Mar" in Spain, and on the GI-681 - just outside the residential area of Tossa del Mar - close to the Campo del Futbol / below the transversing electricity line, you cannot route over the GI-681 if you don't set a routepoint into the short road piece that is joined by a pedestrian area. It's not really related to the style I would say, it's broken in my maps, as well on Lambertus maps. See screenshot here: http://img515.imageshack.us/img515/2748/brokentossadelmar.png I use the default remove-short-arcs (meaning I removed the option). Maps broken (Lambertus default style) - online for the next 40 hours only: http://osm2.pleiades.uni-wuppertal.de/garmin/generic/29-12-2012/07f785dfaff… my own broken: ftp://ftp5.gwdg.de/pub/misc/openstreetmap/openmtbmap/odbl/mtbspain.exe However routing not broken in this map from mapas.alternativaslibres: http://mapas.alternativaslibres.es/descargar.php?file=OpenStreetMap_Spain.e… -- keep on biking and discovering new trails Felix openmtbmap.org & www.velomap.org

9 43

Commit: r2436: change way.clockwise() to a static method
by svn commit 06 Jan '13

06 Jan '13

Version 2436 was committed by gerd on Sun, 06 Jan 2013 change way.clockwise() to a static method

1 0

Option review
by Steve Ratcliffe 05 Jan '13

05 Jan '13

Hi Thanks to everyone who commented on the options issue. I also went back and read the thread started by Felix in 2010. Yes 2010, so it is time to do something. I am giving Greg's statement that currently "ignoring options does not lead to success" a lot of weight in deciding what to do. Many of our options are really input data that have to be options because the input file does not contain them. Compare with the Polish format which does in fact include several of our options (FID, CountryName etc) in its data. These options generally don't cause confusion or bugs and so are mostly harmless even if there are quite a few of them. So I will concentrate on "true" options that cause mkgmap to operate in different ways or produce different outputs. In the next days or weeks I am going to do the following. 1. Create a way of setting the default value of an option in the options help file. The help will then always be up to date with the actual default value. 2. Move options that already have a default value (eg description is "OSM street map") from code to the help file. 3. Create a way to mark an option as obsolete with a reason. So a warning can be printed for options that are being removed or having their names changed and what you can do instead. 4. Implement a --warnings option, so that the warning-type options can be migrated there. 5. Expand the list of options that can be given in the "options" file of a style to include all data input options. This is the preliminary list of changes to be made, last chance for comments! Options to be defaulted ----------------------- add-pois-to-areas code-page=1252 generate-sea=sectors,close-gaps=6000 ignore-maxspeeds index location-autofill=is_in min-size-polygon nsis preserve-element-order process-destination reduce-point-density=5 route tdbfile Options to be removed --------------------- Some of these involve a good amount of code removal too. block-size charset ignore-builtin-relations ignore-osm-bounds lower-case make-all-cycleways make-cycleways make-poi-index map-features max-flare-length-ratio net no-poi-address road-name-pois tdb-v3 latin1 Options to change name ---------------------- gmapsupp --> gps keep-going --> ignore-errors Options to become --warnings sub-options ------------------------------------- check-roundabout-flares check-roundabouts report-dead-ends report-similar-arcs Options allowed in style 'options' file --------------------------------------- Start off with the list from Geoff, excluding ones that are already allowed and removing ones that will be removed anyway. Probably more to add. mapname=name description=text country-name=name country-abbr=abbreviation region-name=name region-abbr=abbreviation code-page=number family-id family-name product-id product-version series-name area-name overview-mapname=name overview-mapnumber=8 digit number drive-on-left drive-on-right ..Steve

2 3

Commit: r2435: Always copy the point list when creating a new Way object
by svn commit 05 Jan '13

05 Jan '13

Version 2435 was committed by wanmil on Sat, 05 Jan 2013 Always copy the point list when creating a new Way object This prevents unintended use of the Way constructor which didn't copy the points list. If the points of a way was changed afterwards it happened that the points list of a copy was changed also. This caused routing errors in special situations (e.g. a road was also a member of a multipolygon that has a highway tag too).

1 0

Detecting, reporting and highlighting dead-ends
by Marko Mäkelä 05 Jan '13

05 Jan '13

Recently, a fellow mapper (FinWonder) came up with the idea of highlighting dead ends: http://forum.openstreetmap.org/viewtopic.php?pid=299968 He posted some Python code here: https://github.com/KonstantinShemyak/no-dead-ends-OSM python markOSMBridges.py example.osm > marked-example.osm Unfortunately, the code is a bit memory-hungry; it failed to process the entire finland.osm (about 3 gigabytes, uncompressed from finland.osm.pbf) within 8 gigabytes of RAM. I think that this is a very interesting idea. I would even refine it further and split the 'dead-end graphs' for each mode of transportation: car, bicycle, foot, etc. For example, a way that ends in highway=steps is not a dead-end for pedestrians, but it is for everyone else. A highway=service leading to a fuel station along a highway=motorway is not a dead-end for cars, but is for everyone else. A way that ends in highway=path,access=no,bicycle=yes is dead-end for everyone except bicyclists. Short dead-ends (say, 10-meter or shorter driveways) should probably be ignored. While computing the dead-ends, the code could warn about 'major' highways that are dead-end, possibly because a T crossing with another way is incorrectly tagged (the junction node is not linked to both ways). Currently, mkgmap only complains about dead-end oneways, because that is much easier. Would this be feasible to implement in mkgmap? Or maybe better in a separate tool? I would guess that the dead-end way sections would be useful to be in separate layers that can be enabled or disabled on demand. Marko

1 0

Some point icons from TYP file don't display
by Carlos Dávila 05 Jan '13

05 Jan '13

Hello all The txt file I use as base for my TYP files contains some 60 points defined. Most of them are correctly displayed when compiled with mkgmap, but a few of them are not (see them below). If I compile the same txt wiz TYPWiz they work fine, and also if I load the mkgmap generated TYP into the web compiler and recompile it. Any idea why they fail when compiled with mkgmap? Carlos [_point] Type=0x02000 ;size: 144 String1=0x8,Salida de autopista String2=0x4,Motorway exit String3=0x2,Anschlussstelle String4=0x1,Échangeur ExtendedLabels=N DayXpm="12 12 41 2" Colormode=32 "$$ c #003399" canalalpha=0 "$% c #02349A" canalalpha=0 "$& c #A9BADC" canalalpha=0 "$' c #728EC7" canalalpha=0 "$( c #8BA3D1" canalalpha=0 "$) c #1C49A4" canalalpha=0 "$* c #AFBFDF" canalalpha=0 "$+ c #B6C4E2" canalalpha=0 "$, c #B5C4E1" canalalpha=0 "$- c #1544A1" canalalpha=0 "$. c #365EAF" canalalpha=0 "$/ c #FFFFFF" canalalpha=0 "$0 c #90A6D3" canalalpha=0 "$1 c #F9FBFD" canalalpha=0 "$2 c #10409F" canalalpha=0 "$3 c #1D4AA5" canalalpha=0 "%$ c #BBC8E4" canalalpha=0 "%% c #C5D1E8" canalalpha=0 "%& c #889FCF" canalalpha=0 "%' c #7D97CB" canalalpha=0 "%( c #9DB1D8" canalalpha=0 "%) c #EAEEF7" canalalpha=0 "%* c #6180C0" canalalpha=0 "%+ c #ADBEDE" canalalpha=0 "%, c #5A7BBD" canalalpha=0 "%- c #D9E1F0" canalalpha=0 "%. c #6B88C4" canalalpha=0 "%/ c #839CCD" canalalpha=0 "%0 c #365EAE" canalalpha=0 "%1 c #06389C" canalalpha=0 "%2 c #2C56AB" canalalpha=0 "%3 c #5879BC" canalalpha=0 "&$ c #5577BB" canalalpha=0 "&% c #456AB5" canalalpha=0 "&& c #6A88C3" canalalpha=0 "&' c #CFD9EC" canalalpha=0 "&( c #325BAD" canalalpha=0 "&) c #A5B7DB" canalalpha=0 "&* c #1040A0" canalalpha=0 "&+ c #B2C2E0" canalalpha=0 "&, c #A6B8DB" canalalpha=0 "$$$$$$$$$$$$$$$$$$$$$$$$" "$$$$$$$$$$$$$$$$$$$$$$$$" "$$$$$%$&$'$($$$)$*$+$,$-" "$$$$$.$/$0$1$2$3%$$/%%$$" "$$$$%&$/%'$/%(%)%*%+%,$$" "$$$$%-$/%.$/$/%/$$%0%1$$" "$$%2$/$/%3$/$/&$$$$$$$$$" "$$%'$/$/&%$/$/&&$$$$$$$$" "$$&'$/$/&($/$/&)$$$$$$$$" "&*$,$+&+$)$+$+&,$$$$$$$$" "$$$$$$$$$$$$$$$$$$$$$$$$" "$$$$$$$$$$$$$$$$$$$$$$$$" [end] [_point] Type=0x06409 ;&16C5 pointers:&17FA ;size: 32 ;bmp:&16CD ;night_bmp:&16F5 String1=0x4,Power tower String2=0x8,Torreta String1=0x2,Strommast String2=0x1,Pylône ExtendedLabels=N DayXpm="7 16 2 1" Colormode=16 "$ c #000000" "% c none" "%%%$%%%" "%%$%$%%" "$$$$$$$" "%$%$%$%" "%%%$%%%" "%%%$%%%" "%%$%$%%" "%%$%$%%" "%%$%$%%" "%$%$%$%" "%$%%%$%" "%$$%$$%" "%$%$%$%" "$%$%$%$" "$$%%%$$" "$%%%%%$" NightXpm="7 16 2 1" "% c #424242" "$ c none" "$$$%$$$" "$$%$%$$" "%%%%%%%" "$%$%$%$" "$$$%$$$" "$$$%$$$" "$$%$%$$" "$$%$%$$" "$$%$%$$" "$%$%$%$" "$%$$$%$" "$%%$%%$" "$%$%$%$" "%$%$%$%" "%%$$$%%" "%$$$$$%" [end] [_point] Type=0x06411 ;&172E pointers:&17FF ;size: 45 ;bmp:&173C String1=0x8,Repetidor String2=0x4,Antenna String1=0x2,Turm String2=0x1,Répétiteur ExtendedLabels=N DayXpm="5 15 4 1" Colormode=16 "$ c #4B4B4B" "% c #C0C0C0" "& c #FF0000" "' c none" "$'&'$" "'$$$'" "$'&'$" "''$''" "''&''" "'&'&'" "'$'$'" "'&'&'" "'$'$'" "'&'&'" "&'''&" "$'''$" "&'''&" "$'''$" "&'''&" [end]

3 5

There is not enough room in a single garmin map for all the input data
by GerdP 05 Jan '13

05 Jan '13

I still get this message in mkgmap when processing data that was created with splitter r275 and --precomp-sea option. It seems that it is not sufficient to count the nodes in the precompiled sea data, which leads me to the assumption that this is a general problem with polygons. I don't know what else we could do to handle this problem :-) I've added a few lines of code to get a stacktrace (see attached patch): uk.me.parabola.imgfmt.app.BufferedImgFileWriter.ensureSize(BufferedImgFileWriter.java:197) uk.me.parabola.imgfmt.app.BufferedImgFileWriter.put(BufferedImgFileWriter.java:160) uk.me.parabola.imgfmt.app.trergn.Polyline.write(Polyline.java:145) uk.me.parabola.imgfmt.app.trergn.RGNFile.addMapObject(RGNFile.java:140) uk.me.parabola.imgfmt.app.map.Map.addMapObject(Map.java:242) uk.me.parabola.mkgmap.build.MapBuilder$ShapeAddFilter.doFilter(MapBuilder.java:1156) uk.me.parabola.mkgmap.build.LayerFilterChain.doFilter(LayerFilterChain.java:57) uk.me.parabola.mkgmap.build.LayerFilterChain.addElement(LayerFilterChain.java:66) uk.me.parabola.mkgmap.filters.PolygonSplitterFilter.doFilter(PolygonSplitterFilter.java:88) uk.me.parabola.mkgmap.build.LayerFilterChain.doFilter(LayerFilterChain.java:57) uk.me.parabola.mkgmap.build.LayerFilterChain.startFilter(LayerFilterChain.java:75) uk.me.parabola.mkgmap.build.MapBuilder.processShapes(MapBuilder.java:1027) uk.me.parabola.mkgmap.build.MapBuilder.makeSubdivision(MapBuilder.java:712) uk.me.parabola.mkgmap.build.MapBuilder.makeMapAreas(MapBuilder.java:646) uk.me.parabola.mkgmap.build.MapBuilder.makeMap(MapBuilder.java:200) uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:97) uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:61) uk.me.parabola.mkgmap.main.Main$1.call(Main.java:208) uk.me.parabola.mkgmap.main.Main$1.call(Main.java:1) java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) java.util.concurrent.FutureTask.run(FutureTask.java:138) java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) java.lang.Thread.run(Thread.java:662) stacktrace.patch <http://gis.19327.n5.nabble.com/file/n5741801/stacktrace.patch> Gerd -- View this message in context: http://gis.19327.n5.nabble.com/There-is-not-enough-room-in-a-single-garmin-… Sent from the Mkgmap Development mailing list archive at Nabble.com.

7 17

alternate maps on a new Nuvi 50LM?
by Richard Welty 05 Jan '13

05 Jan '13

another OSMer here in the Capital District of NY is having a difficult time getting a an alternate map from mkgmap working in a new Nuvi 50LM (he had no troubles with a Nuvi 265.) has anyone tried this device with an mkgmap sourced map and had any issues (or not had any issues)? thanks, richard

1 1