- mkgmap-dev - The mkgmap lists

suppress street labels / set name=nil
by Ben 03 Dec '09

03 Dec '09

Hi all, Is there a smart way to have mkgmap explicitly setting an empty name for lines? - when I use [default_name ''] the name is filled with some odd content, in my case "Castle Hill Police"... - when I use [default_name ' '] the name is filled with the expected space, but this causes a black rectangle to appear instead of a label background: the setting on Garmin devices (I am testing on a 60CSx) "Max Zoom: Street Label" doesnt seem to work properly fro some ways: even if set to "off", some street labels are still shown, e.g. steps and cycleways. This clutters up the map, so I want to suppress names for those types of ways. Thanks, Ben

5 6

Commit: r1414: Fix turn restriction breakage introduced by r1412.
by svn commit 02 Dec '09

02 Dec '09

Version 1414 was commited by markb on 2009-12-02 21:30:19 +0000 (Wed, 02 Dec 2009) Fix turn restriction breakage introduced by r1412. Duplicating the way meant that it would no longer be matched as a turn restriction 'from' or 'to' way. Associating the duplicate to the original way with an entry in originalWay fixes the bug.

1 0

Suggestion: set mkgmap:dead-end-check=no when endpoints have FIXME=*
by Marko Mäkelä 02 Dec '09

02 Dec '09

I came across an incompletely mapped area that has some dead-end oneways, and mkgmap duly complained. Initially, I "fixed" this with a bogus road that had a FIXME tag, but the original mapper reverted that change. Now I have added fixme=continue to each bogus oneway. I wanted to suppress the dead-end check if the endpoints of the oneway have FIXME or fixme set, but neither Coord nor CoordNode carry any OSM attributes. Where could this be achieved? I would rather not add any mkgmap:dead-end-check=no to the OpenStreetMap repository? The FIXME would be more universal and also show up in validators. Marko

2 3

Possibility to not put certain lines into resolution=24, but e.g. only 18 and 20?
by Felix Hartmann 02 Dec '09

02 Dec '09

I think that neither Garmin nor cgpsmapper compiler do this, but would there be a possibility to start some lines only in resolution 20, while the rest of the map is starting at 24? Reason being is that I would like to change layout (TYP) at level 19 and below for some objects. (namely I display cycleroutes out of center in all resolutions, and would like to have them centered in resolution 20,19 and 18). (sorry Mark, after the last round of patches you asked if I am ever satisfied......) (Furthermore if this is possible, I would probably need an extension to the "continue" system, as two identical key combinations don't both work with "continue"; or even better a change in code like [0x01 resolution 24,22; 0x10a10 resolution 20,19,18]. This would also allow people to have nicer maps that behave like "google maps/mapnik", where when you zoom in roads get wider.

3 6

Re: [mkgmap-dev] Possibility to not put certain lines into resolution=24, but e.g. only 18 and 20?
by Felix Hartmann 02 Dec '09

02 Dec '09

On 02.12.2009 21:09, Johann Gail wrote: > >>>> I think that neither Garmin nor cgpsmapper compiler do this, but >>>> would there be a possibility to start some lines only in resolution >>>> 20, while the rest of the map is starting at 24? >>>> >>> I have just looked at the source. Guess what, it is already in there! >>> >>> The syntax should be >>> >>> [0x01 resolution Max-Min] >>> e.g. >>> [0x01 resolution 24-21] >>> [0x01 resolution 20-16] >>> >>> >>> I have not tested this, just read this from the source. >>> >>> Regards, >>> Johann >> Okay, so however this would mean on can only use one type per "line" >> - or can I put >> highway=* [0x01 resolution 24-21] [0x02 resolution 20-16] >> ??? >> > Nice idea, but will not work. > At the moment you will have to use two lines and hope someone will > correct the continue patch :-) -- Can't use it for the lines I need to duplicate, because I am already using the continue patch for them (with continue patch it is not possible to continue twice for the same tag, which is of course the right decision - because otherwise it would not be able to use it for complex rules) I think it is not the continue patch that should be adapted for this function, but the" [] " code on reading out the style-file. changing it to [0x01 road_class=4 road_speed=7 resolution 24-21; 0x02 resolution 20-18; 0x03 resolution 17-14] would be perfect. The code is still usable (meaning working) as I just tried out. so it would only need to be extended. If someone wants to use it for lines where no "continue" is already in use, he of course can go ahead. > I have no insight into this continue story and can't help here. > >

1 0

Don't let action rule execute its actions if its type isn't going to be used
by Mark Burton 02 Dec '09

02 Dec '09

Felix, As you know, action rules execute their actions (like add tags, etc.) whenever their expression is true. But is that the right behaviour if the type associated with the rule isn't going to be used because of the continue action? I'm not sure that it is so I have made a little patch that stops action rules from executing their actions if the type to be returned isn't going to be used. I don't know if it helps with your current issue or not but perhaps you can try it out. The patch also adds back all the resolveType() methods without the pre argument so that Steve's test suite isn't borked. Mark

4 12

Patch for better Autorouting
by Felix Hartmann 02 Dec '09

02 Dec '09

As announced yesterday - here is a patch against the default-style-file to heavily improve Autorouting for cars/motorcycles. Attached is a patch that should increase Autorouting distance without errors in Mapsource by 30-100% (distance as in number of turns). I am not sure how the maxspeed is currently handled in mkgmap code. In case that maxspeed can actually increase the road_speed, then it has to be used with --ignore maxspeed - Best would be if maxspeed (in case it is tagged) can only decrease road_speed, but not increase it - I am not sure whether this is current behaviour. This patch does blows up mapsize by up to 10% - depending how well mapped a country is (the better it is mapped, the smaller the increase). For Germany it is around 4% size increase. (only 3% if zipped by 7-zip). Using it I had no problems routing from South Spain to Northern Poland in Mapsource and several other as long distances, Map rendering time does not significantly increase. I additionally put add bicycle=no; add foot=no for trunk roads, as in 99% of cases you are not allowed to use them as a cyclist/foot (nor would you like to) - at least in Europe.

2 5

Commit: r1410: Add --merge-lines option to combine lines at lower zoom levels.
by svn commit 01 Dec '09

01 Dec '09

Version 1410 was commited by markb on 2009-11-29 19:18:02 +0000 (Sun, 29 Nov 2009) Add --merge-lines option to combine lines at lower zoom levels. Also adds --reduce-point-density option to set the error distance used by the Douglas Peucker line simplifying filter. Patch by Johann Gail. Trivial mods by me to options text and also to disable the DP filter when --reduce-point-density=0 is specified.

6 11

Turn Restrictions
by Rodrigo Avila 01 Dec '09

01 Dec '09

Hi all, I'm having some problems with turn restrictions in Garmin Mobile XT. Take a look at this roundabout: OSM: http://osm.org/go/M5t4FIy73-- Satellite: https://dl.dropbox.com/u/114881/screenshots/round-1.png In OSM data we have some turn restrictions. But when I convert the osm data to garmin, the mobile XT routing system offers the route in this way, ignoring the turn restriction: https://dl.dropbox.com/u/114881/screenshots/round-3.png How I need to configure the turn restriction to work in Mobile XT? The restrictions are made using the information at http://wiki.openstreetmap.org/wiki/Relation:restriction Thanks. -- Rodrigo de Avila Analista de Desenvolvimento rodrigo(a)avila.net.br • www.avila.net.br

2 2

Mapsource Recalculation Tries
by Felix Hartmann 01 Dec '09

01 Dec '09

Currently with mkgmap created maps (just like most other maps) Mapsource tries 3x to find a route when using the autorouting tool. I have noticed that using Netherlands Onroute Fietskaart Mapsource tries much harder to find a route - sometimes it restarts 15 times until it has found a route. It would be great if we could have the same behaviour. I don't know at all where a parameter for rerouting tries is placed inside the maps, but just if someone finds something, this would be interesting to improve routing (on each successive try, Mapsource lowers a bit its rigorosity of the route quality, but better a route than no route).

1 1