January 2013 - mkgmap-dev - The mkgmap lists

Commit: r2439: Remove tdb-v3 option and now a tdbfile is always created even when there
by svn commit 06 Jan '13

06 Jan '13

Version 2439 was committed by steve on Sun, 06 Jan 2013 Remove tdb-v3 option and now a tdbfile is always created even when there is only one input file. The interaction between --index and --tdbfile is still as before. In other words --tdbfile is not truly set by default.

1 0

Commit: r2438: In a TYP file the section indexes need to be sorted by type.
by svn commit 06 Jan '13

06 Jan '13

Version 2438 was committed by steve on Sun, 06 Jan 2013 In a TYP file the section indexes need to be sorted by type.

1 0

removeShortArcs_v1.patch
by GerdP 06 Jan '13

06 Jan '13

Hi, I thought again about this patch and I think it is not correct, but I am not able to produce a correct solution. Why is it not correct? The removeShortArcsByMergingNodes() method in ElementSaver iterates multiple times over all ways, a change in the "last" way may trigger a change in ways that come before during the next pass. My patch changes that so that a change in the last way doesn't trigger anything in previously processed ways. I tried to change the patch so that all roads added in StyledConverter.addConvertedWay() are first placed in a HashMap, together with a copy of the corresponding GType object and all these roads are processed later in the end() routine, but I see different results when I do so and don't understand why. Any ideas ? Gerd -- View this message in context: http://gis.19327.n5.nabble.com/removeShortArcs-v1-patch-tp5743043.html Sent from the Mkgmap Development mailing list archive at Nabble.com.

1 0

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