- mkgmap-dev - The mkgmap lists

Commit: r1315: Now warns when it finds roundabouts that fork.
by svn commit 26 Oct '09

26 Oct '09

Version 1315 was commited by markb on 2009-10-26 09:36:22 +0000 (Mon, 26 Oct 2009) Now warns when it finds roundabouts that fork. This detects roundabouts that have multiple segments that lie on top of each other. Also, no longer erroneously warns about flare roads being the wrong way around when a roundabout has a single flare and no other connections.

1 0

U-turn restriction via way instead of node
by Marko Mäkelä 25 Oct '09

25 Oct '09

I remember that this was discussed some weeks ago, but I cannot remember if a final conclusion was reached. Certain types of these U-turn restrictions can be rewritten as only_straight_through. For instance, the only_straight_through relation on Itäkatu (southbound) also prevents a U-turn from Itäkatu (southbound) via Kehä I (east) to Itäkatu (northbound): at http://www.openstreetmap.org/browse/relation/32875 When ways have been split to opposing oneway lanes, a via node must be replaced with a via way, like this: http://www.openstreetmap.org/browse/relation/59928 However, mkgmap will not like it: 2009/10/25 21:53:00 WARNING (RestrictionRelation): Turn restriction 59928 (http://www.openstreetmap.org/?lat=60.21242&lon=25.08756&zoom=17) 'via' member 4775828 is not a node Can this kind of turn restrictions be represented in the Garmin format? Best regards, Marko

2 1

Different representations according to resolution
by Toby Speight 25 Oct '09

25 Oct '09

Is it possible to use different types at different resolutions? Example - I'd like a motorway to be a thin line when I'm zoomed out to 50km scale, but quite a thick line at the 120m scale. Also, it would be nice to have roundabouts rendered in the correct colour (motorway, trunk, primary, ...) but still appear as 0xc in the routing layer.

3 4

Merging few .img to gmapsupp.img - typ error.
by honny 25 Oct '09

25 Oct '09

Hi. I'm trying to merge few .img files (generated with mkgmap from osm data) into one gmapsupp.img file. Also, every .img file was created with own customization, own TYP file, ...). But, when i use java -jar mkgmap.jar --gmapsupp a.img b.img, it overwrite their TYP setting. :( Is there any way to merge .img files, but keep their TYP file settings? :/ Thanks, ~ honny

3 4

-add-pois-to-area does not use "level"/"resolution"?
by Ben 25 Oct '09

25 Oct '09

Hi, Im facing a problem with -add-pois-to-area: The level of the derived POI defaults to 0! Example: amenity=parking exists in "points" and "polygons" in the style-directory: points: amenity=parking [0x3f0b level 2] polygons: amenity=parking [0x05 level 2] ("level 2" is defined as "resolution 22" in "options", in case that makes any difference) 0x3f0b is defined in the TYP-file as 10x10 pixel icon (because I found other resolution/level issues when using Garmin builtin icons) What happens: - A POI with amenity=parking produces a point on the map, using 0x3f0b visible at level 2 and below, as expected - An area with amenity=parking produces a POI with 0x3f0b in the center of that polygon, only visible at level 0! (btw: when setting a specific name for the POI, it is picked up by the "real" POI, but not from the POI generated from the area) When changing the zoom level in "points", the "real" POIs behave properly, the area-POIs stick to level 0. When using "resolution" instead of "level": same result. Why are the area-POIs not shown on higher zoom levels? Can anyone reproduce this problem? Or better: Give me a hint what Im missing here? Thanks, Ben

1 0

Commit: r1314: Add latin1 varient of the transliterations.
by svn commit 24 Oct '09

24 Oct '09

Version 1314 was commited by steve on 2009-10-24 15:19:44 +0100 (Sat, 24 Oct 2009) BRANCH: translit Add latin1 varient of the transliterations. They were created with icu4j. However the romanisations provided by this library use characters outside the target character set, so all those are commented out and will therefore fall back to the ascii version. This mixture may or may not make any sense.

1 0

Transliteration
by Lambertus 24 Oct '09

24 Oct '09

A question popped up on the OSM forum about the many ??? in my maps. They are a result of the single code page which is used for the whole world and missing automatic transliteration. I'm starting to understand what's needed for automatic transliteration: detection of source language and various methods for transliteration to another language (some languages suffice with 1-on-1 character replacement, others need lookup tables etc). The subject has been mentioned on this mailinglist before but doesn't seem like it's very active, so: is anyone working on this? The discussion on the OSM forum starts here (and further down): http://forum.openstreetmap.org/viewtopic.php?pid=42175#p42175

5 7

Commit: r1313: Complete transliteration tables based on perl's Text::Unidecode and the
by svn commit 24 Oct '09

24 Oct '09

Version 1313 was commited by steve on 2009-10-24 14:05:13 +0100 (Sat, 24 Oct 2009) BRANCH: translit Complete transliteration tables based on perl's Text::Unidecode and the script used to create them.

1 0

Commit: r1312: Add in transliteration when --latin1 is given.
by svn commit 24 Oct '09

24 Oct '09

Version 1312 was commited by steve on 2009-10-24 11:45:04 +0100 (Sat, 24 Oct 2009) BRANCH: translit Add in transliteration when --latin1 is given.

1 0

Commit: r1311: When checking for dead end roads, also warn about non-contiguous roundabouts.
by svn commit 23 Oct '09

23 Oct '09

Version 1311 was commited by markb on 2009-10-23 23:10:05 +0100 (Fri, 23 Oct 2009) When checking for dead end roads, also warn about non-contiguous roundabouts. This will find (non-looped) ways that have been tagged as roundabouts by mistake and also where a way that is part of a segmented roundabout is missing its roundabout tag. Also, made existing warning messages more consistent (shame about losing "confluence" but you can't stand in the way of progress).

1 0