- mkgmap-dev - The mkgmap lists

Adaptions in style (needed to make good use of) for overview2 branch
by Felix Hartmann 20 May '13

20 May '13

So - I've played around a bit - just rendering Europe for right now - actually I would suggest the following (needs some adaptations in the lines/poi file though): levels = 0:24, 1:22, 2:20, 3:18 overview-levels = 4:17, 5:16, 6:15, 7:14, 8:12.... This should give quite sensible map detail for European countries, or Europe as a continent - without getting near to crash the overview map, because it 's getting too big. I'm unsure whether we should add a completly empty 9:11 or 9:10 so that when zooming out superfar, the map get's blank instead of a pixel mashup... We definitely do need resolutions 14 and 12 in the overview map. They help tremendously when opening big maps in orientation - without the dreaded setting of details to max setting. As the speed of drawing is now very fast compared to before, resolution 14 and 12 with data do make lot of sense! Level 8 should only contain capitals and country borders. Here are some adpation proposals for *points file* - add this before any other POI - due to continue other pois will still be included: (place=capitol | place=capital) & population > 999999 & name=* {set cityxx=yes} [0x0100 resolution 12 continue with_actions ] place=city & population > 799999 & cityxx!=yes & name=* {set cityxx=yes} [0x0200 resolution 14 continue with_actions ] place=city & population > 399999 & cityxx!=yes & name=* {set cityxx=yes} [0x0300 resolution 15 continue with_actions ] place=city & population > 299999 & cityxx!=yes & name=* {set cityxx=yes} [0x0400 resolution 16 continue with_actions ] place=city & population > 199999 & cityxx!=yes & name=* {set cityxx=yes} [0x0500 resolution 16 continue with_actions ] place=city & population > 99999 & cityxx!=yes & name=* {set cityxx=yes} [0x0600 resolution 17 continue with_actions ] place=city & population > 49999 & cityxx!=yes & name=* {set cityxx=yes} [0x0700 resolution 17 continue with_actions ] place=city & population > 9999 & cityxx!=yes & name=* {set cityxx=yes} [0x0800 resolution 18 continue with_actions ] place=city & population > 0 & cityxx!=yes & name=* {set cityxx=yes} [0x0800 resolution 18 continue with_actions ] place=city & cityxx!=yes & name=* {set cityxx=yes} [0x0700 resolution 18 continue with_actions ] place=town & population > 69999 & cityxx!=yes & name=* {set cityxx=yes} [0x0600 resolution 17 continue with_actions ] place=town & population > 19999 & cityxx!=yes & name=* {set cityxx=yes} [0x0700 resolution 18 continue with_actions ] place=town & population > 9999 & cityxx!=yes & name=* {set cityxx=yes} [0x0800 resolution 19 continue with_actions ] place=town & population > 4999 & cityxx!=yes & name=* {set cityxx=yes} [0x0900 resolution 19 continue with_actions ] place=town & population > 999 & cityxx!=yes & name=* {set cityxx=yes} [0x0a00 resolution 19 continue with_actions ] place=town & population > 0 & cityxx!=yes & name=* {set cityxx=yes} [0x0b00 resolution 20 continue with_actions ] place=town & cityxx!=yes & name=* {set cityxx=yes} [0x0800 resolution 19 continue with_actions ] *Relations file:* route=road & network=e-road { apply { add ref='${ref'; add int_ref='${int_ref'}; set network=e-road } *Lines file* # (the main routing part needs to be adapted to only start with level 21) - this here can then start the lines file: highway=motorway & network=e-road [0x01 resolution 14-14 continue] highway=motorway [0x01 resolution 15-20 continue] highway=trunk & network=e-road [0x02 resolution 15-17 continue] highway=trunk [0x02 resolution 18-20 continue] highway=primary & network=e-road [0x03 resolution 16-18 continue] highway=primary [0x03 resolution 19-20 continue] highway=secondary & network=e-road [0x04 resolution 17-18 continue] highway=secondary [0x04 resolution 19-20 continue] # Maybe add main rivers - but how to know what are the biggest rivers worldwide? There doesn't exist a relation/network thingy so far AFAIK. # country borders are already at 12. Dunno if they maybe should stop at 14 already. *Polygons file:* # I would propose to only show sea/land up to resolution 17 by default. Maybe forest/wood and other very important big objects also in 17?

7 36

Compare Two Tags (name and name:de)
by tduenne＠freenet.de 18 May '13

18 May '13

Hi, how can I compare two tags, for example name and name:de. If the tags are not identical, I want to build a new name-Tag "[name] ([name:de])" name != '${name:de}' { set name='${name} (${name:de})' } does not work. Regards, Thomas --- Alle Postfächer an einem Ort. Jetzt wechseln und E-Mail-Adresse mitnehmen! Rundum glücklich mit freenetMail

1 0

Warning about flare road in multi-lane roundabout
by Marko Mäkelä 18 May '13

18 May '13

Hi all, mkgmap is complaining about this roundabout entry/exit lane (way id 221616945): 2013/05/18 08:39:30 WARNING (RouteNode): 63240005.osm.pbf: Incoming roundabout flare road (4;9;13;23 Vaajakoskentie, http://www.openstreetmap.org/browse/way/221616945) points in wrong direction? http://www.openstreetmap.org/?mlat=62.24637&mlon=25.87235&zoom=17 2013/05/18 08:39:30 WARNING (RouteNode): 63240005.osm.pbf: Outgoing roundabout flare road (4;9;13;23 Vaajakoskentie, http://www.openstreetmap.org/browse/way/221616945) points in wrong direction? http://www.openstreetmap.org/?mlat=62.24639&mlon=25.87304&zoom=17 Can someone check if it results in a sane routing graph? Is there anything that could be done in the source data to make the warning go away? (I can of course filter out this particular warning message, but I am looking for a more general solution.) I would guess that we will start to see similar error messages when the mapping detail increases, for multi-lane roundabouts connected to highway=primary, trunk, or motorway_link, when there are lanes specific to certain roundabout exits. BTW, in Finland, some mappers have already started to map traffic signs, and mapping individual trees and lamp posts is already the norm in some cities. Best regards, Marko

1 0

Optimization in overviev2 branch
by Gerd Petermann 15 May '13

15 May '13

Hi all, I've committed r2612. This creates much fewer polygons, esp. in combination with the SeaGenerator and large sea areas. For a map of South America, the gmapsupp size is decreased by 20MB, the overview map size went down from 12 Mb to 3.9 Mb. It also seems that this fixes an issue with MapSource / Basecamp: If you max zoom out of the map created with r2610, the programs show many white rectangles for the sea areas, with r2612 this is no longer the case. Gerd

3 2

[Patch v1] Oneway handling
by Gerd Petermann 15 May '13

15 May '13

Hi, attached is a patch that should fix cosmetic issues with merge-lines and oneways. The idea: 1) merge-lines should not merge two lines if one is a oneway and one is not 2) merge-lines should not merge two oneway lines if the angle between the two ways is too small (< 30°). Not sure what it does with roundabouts. Please try this if your style creates overlays for oneways. I don't expect any changes in routing. Compiled version is here: http://files.mkgmap.org.uk/download/123/mkgmap.jar @Steve: Please can you check if the implemented test reg. bearings makes sense? Gerd

4 3

more refined mkgmap:skipSizeFilter=true handling
by Felix Hartmann 15 May '13

15 May '13

Well, the skip filter function works well, but there are problems with it - especially on South America. For South America geofabrik extract - the overview map gets rather large. Using higher polygon size on filter - would be the essential tool in order too keep the overview .img file to be getting too large, without nearly any visual deterioration. a) A quick (or I hope that would be quick) adaption could be to have instead: mkgmap:changeSizeFilter=? with ? being the number for the filter to be used. Even a value of 2, would have quite good effect in case of South America. (about 15% saving on the overview.img size with default style). b) A more optimal solution would be the following: mkgmap:changeSizeFilter="level:filter_strenght" so e.g. "0:12, 1:12, 3:12, 4:12, 5:10, 6:8, 7:8, 8:4, 9:2, 10:1" A filter working this way, would have great impact on the overview.img size, as well as normal map.img size - without leading to strong visual impact. (up to 50% saving on the overview.img size) The effect of the polygon size filter on South America is especially strong, as there is a huge sea area included in the extract... (also I still don't understand, why mkgmap makes so small squares for the sea, instead of larger squares - which should also save on .img size).

3 6

Need help with docu for overview map
by Gerd Petermann 14 May '13

14 May '13

Hi all, I am sorry, I did not make much progress on documenting the changes in the overview2 branch. I planned to add a chapter about the meaning of the overview-levels parm, but it seems that we need much more. I only found a stub in mkgmap/doc/styles/design.txt which seems to be the right place: = Designing the map TBW == Levels TBW I don't know what to wrtite in the main chapter, but I assume it should be an updated version of this wiki page? http://wiki.openstreetmap.org/wiki/Mkgmap/help/custom Questions: 1) I think the support for the "map feature file" is really obsolete now. Would it be ok to remove the corresponding program code? 2) Is the part "Watch out with levels when building topographical maps " still correct? I think most users are merging the SRTM data with the OSM data first. Gerd

5 4

[PATCH v1] Remove one direction of motorways in overview
by WanMil 14 May '13

14 May '13

Attached patch gives a little try how we could remove the duplicate motorways in the overview map. Usually both directions of a motorway are painted on each other. The patch removes all motorway segments from the overview map that span an angle 0° to 180° between first and last point of a segment. It should not be commited because I think we could do better with a specialized filter (?) but it's an easy prototype to check if it's worthy to start such an implementation. WanMil

3 6

ways are deleted when not routable
by Minko 14 May '13

14 May '13

I have found another issue. Mkgmap (latest versions) is deleting parts of roads that are not routable at zoomlevels below 24. See screenshot at http://mijndev.openstreetmap.nl/~ligfietser/test/N301.jpg This is one of the parts that are removed at resolution 22 and below: http://www.openstreetmap.org/browse/way/6971876 I have tested it with two line types: highway=trunk [0x02 resolution 18] road is removed highway=trunk [0x02 road_class=4 road_speed=5 resolution 18] road is rendered It doesn't matter if I use a non routable line type for 0x02, or convert it into motorway. Any ideas what makes this road disappear? BTW I need to make motorways, trunk roads and all other non cyclable roads not routable, because access=no / bicycle=no is not working anymore in the latest devices and Basecamp. But I do want to see them rendered at the map and sometimes I see those holes. I have uploaded the map tile here: http://mijndev.openstreetmap.nl/~ligfietser/test/10010069.o5m

6 25

overlaid lines and reversed oneways
by Gerd Petermann 14 May '13

14 May '13

Hi, see also http://gis.19327.n5.nabble.com/merge-lines-and-routing-tp5758913p5759595.ht… I wonder how this feature (overlaid line shows oneway direction) works with ways that are tagged oneway=-1 or oneway=reverse like this? http://www.openstreetmap.org/browse/way/6971216 or with the recent example from Minko http://www.openstreetmap.org/browse/way/6971876 The current implementation in r2606 works like this: 1) If the tag is found after style evaluation, the points of a road are reversed, but the points of the overlaying line(s) are not. 2) The merge-lines function connects lines without checking the direction. I want to correct the merge-lines method so that it doesn't connect oneway lines with opposite directions, so I have to make sure that all copies of a way have the same order of points. Will this change cause arrows showing into the wrong directions in existing styles? Gerd

1 0