April 2010 - mkgmap-dev - The mkgmap lists

Re: [mkgmap-dev] Change mkgmap default options to make mkgmap more userfriendly
by Greg Troxel 30 Apr '10

30 Apr '10

so we really need a tag for typical_speed, because you're saying that speed limits and typical speeds are not all that well correlated. This is not really about mkgmap.

2 2

Incorrect capitalisation of first letters of every word during mkgmap style processing
by Charlie Ferrero 29 Apr '10

29 Apr '10

Hi list, I use the following style rules to add more information to the names of mountain peaks: natural=peak & ele ~'[\d\s]*m' {name '${name} (${ele})' | 'Peak (${ele})'} [0x6616 resolution 20] natural=peak & ele ~'[\d\s]*ft' {name '${name} (${ele})'| 'Peak (${ele})'} [0x6616 resolution 20] natural=peak {name '${name} (${ele}m)' | 'Peak (${ele}m)' | '${name}' } [0x6616 resolution 20] This works as I would expect, except where the original tags include a space between the elevation and the "ft" or "m" suffix, eg: natural=peak name=Mount Gizmo ele=1200 m This gets processed by mkgmap into a POI with the name "Mount Gizmo (1200 M)" Similarly, natural=peak name=Mount Gizmo ele=1200 ft Gets turned into "Mount Gizmo (1200 Ft)" The same problem crops up when mkgmap converts a postcode from the addr:postcode tab. You end up with addresses like: Place, Some Street, Some Town, UK Sw4 0jg when it should read Place, Some Street, Some Town, UK SW4 0JG Thus mkgmap is capitalising the first letter of all words in names and addresses and lower-casing the rest, even if they were upper-case to start with. Is there any way of stopping mkgmap from doing this? Indeed, is there a reason for it to do this in the first place. -- Charlie

2 2

reduce-point-density vs. remove-short-arcs
by Valentijn Sessink 29 Apr '10

29 Apr '10

Hi, I was wondering what is the difference between --remove-short-arcs and --reduce-point-density. Their description differs (short-arcs says it removes things that cause "routing problems", while point-density seems some sort of general simplification), but I'd think that using --reduce-point-density would mean that there's no short-arcs left afterwards, or are there? I.e. is there any cross effect between the two? (I now have -remove-short-arcs=5.5, but that's probably purely for historical reasons). Best regards, Valentijn

2 1

Delete-Tags-File Option broken with the style-speed merge as of rev 1627
by Felix Hartmann 27 Apr '10

27 Apr '10

Hi, after I got some complaints about wrong routing, I checked it up in gpsmapedit, and noticed that mkgmap is not reading the deletetags file anymore. I think the problem appeared rather recently (maybe the style-speed branch merge??). Can someone find the bug?? Or should it be considered obsoleted by now - as one can do the same with action rules - though I don't know if there is a speed penalty for this? It still worked using rev 1626. It is broken as of 1627

1 0

[PATCH v1] - Do not write unnecessary POI information
by Thilo Hannemann 26 Apr '10

26 Apr '10

The attached patch will prevent writing the additional POI information (address, phone number) if - it won't be shown (POIs with IDs 0x64xx to 0x66xx won't have their information shown) - there is no street given for that POI This reduces the size of the map by about 5% for my map (with a lot of POIs actually generated in the range 0x64xx to 0x66xx). It may be questionable to write no address information if there is no street given. IMHO though, what I want to have from that additional information is the street address. I can see on the map in which city and region the POI is in and in most cases I can also see the distance to my current location. So if I don't have at least a street name the information about the city and region alone (which is most likely autogenerated and therefore error-prone anyway) doesn't help. For my maps the additional size reduction of this is less than 1 % (which I don't understand BTW, should be more). I'm not sure about the ID range 0x64xx to 0x66xx - has anybody tested this and knows whether there are additional IDs that won't have their information shown? Regards Thilo

5 10

Re: [mkgmap-dev] avg speed on roads
by Carlos Dávila 24 Apr '10

24 Apr '10

Florian Lohoff escribió: > On Fri, Apr 23, 2010 at 06:31:42PM +0200, Carlos Dávila wrote: > >> I think there are currently some tools in mkgmap to get a better time >> estimation. I have the lines below in my points style file, which >> certainly improve the arrival time estimation: >> highway=traffic_signals { add mkgmap:road-speed = '-2'; add >> mkgmap:road-speed-min = '1' } >> > > I found the road speed stuff in the source already. It seems it is in the default > style hardcoded by street type/classification which should be possible > to override with some tag i think. > It can be overridden with --ignore-maxspeeds, but you'll need to change lines style with something like this (for each type of road): (highway=secondary | highway=secondary_link) & maxspeed>80 [0x04 road_class=3 road_speed=5 resolution 20] (highway=secondary | highway=secondary_link) & maxspeed>60 [0x04 road_class=3 road_speed=4 resolution 20] (highway=secondary | highway=secondary_link) & maxspeed>50 [0x04 road_class=2 road_speed=3 resolution 20] (highway=secondary | highway=secondary_link) & maxspeed<51 [0x04 road_class=2 road_speed=2 resolution 20] (highway=secondary | highway=secondary_link) [0x04 road_class=2 road_speed=4 resolution 20] The kind of road you describe in La Palma usually have some curvy or urban sections with actual maxspeed lower than the generic one for the road. If you tag them you'll get better time estimation. As an example of what I mean, you can have a look at [1] where I get quite accurate estimation on my nuvi. [1] http://www.openstreetmap.org/browse/relation/12953 > And a maxspeed has nothing to do with what i hav a problem with. All the > roads i travel dont have a maxspeed set, are primary and thus for the > time calculation my GPSMap 60 takes something like 80 km/h - which on > la palma is on some parts more than twice the actual speed one can > travel ... An its nothing time dependent - its something which depends > on the physics of the street - tight corners reduce the speed beeing > traveled ... > > Typical speed/ average speed would be more accurate ... >

1 0

Display problem on nüvi 200
by Carlos Dávila 23 Apr '10

23 Apr '10

An user of my maps reports that he can't see part of the maps on a nüvi 200. He has tried with two maps [1] [2] and in both cases first tile (63240001.img) is not displayed. Nobody else have reported such problem, so I think it can be a device issue. Does anybody know what may be happening? [1] http://mapas.alternativaslibres.es/gmapsupp_spain.zip [2] http://mapas.alternativaslibres.es/gmapsupp_amp.zip

1 0

Different length of name dependent on zoom level
by Felix Hartmann 23 Apr '10

23 Apr '10

There are some special codes that one can use to have zoom dependent length of labels in maps: "{2" - Non-spacing prefix indicator. "{3" - Prefix indicator. "{4" - Non-spacing suffix indicator. "{5" - Suffix indicator. So for example we have a road called B51 (from the ref field) and Streetname (from the name field). Ideally we could now write in the style-file: { set name='{3{$ref}{$name}' } however mkgmap does not correctly enact this and removes the leading"{" so instead of shortening the name, I end up with useless "2", "3", "4" and "5" inside the names. name: Brucker Ersatzstrasse ref: 335 rule: {name '{3${ref|highway-symbol:oval:6:4}{5${name}' | '${ref|highway-symbol:oval:6:4}' | '${name}'} i.e. instead of the following label being encoded like this: {3B335 {5BRUCKER ERSATZSTRASSE it ends up like this: 3~[0x2f]B335 5BRUCKER ERSATZSTRASSE

1 0

Commit: r1637: Unify polygons and points in the default style.
by svn commit 22 Apr '10

22 Apr '10

Version 1637 was commited by marko on 2010-04-22 20:24:50 +0100 (Thu, 22 Apr 2010) Unify polygons and points in the default style. Polygons: Translate amenity=prison, leisure=ice_rink. Points: Translate amenity=prison, various landuse. Do not generate points for unnamed natural features (water, wood).

1 0

Commit: r1636: Distinguish multi-storey parking in the polygons.
by svn commit 22 Apr '10

22 Apr '10

Version 1636 was commited by marko on 2010-04-22 08:54:47 +0100 (Thu, 22 Apr 2010) Distinguish multi-storey parking in the polygons.

1 0