- mkgmap-dev - The mkgmap lists

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

Commit: r1635: Add restaurant polygons, for add-pois-to-areas.
by svn commit 22 Apr '10

22 Apr '10

Version 1635 was commited by marko on 2010-04-22 08:45:25 +0100 (Thu, 22 Apr 2010) Add restaurant polygons, for add-pois-to-areas.

1 0

Recycling menu items in the Oregon
by Daniela Duerbeck 21 Apr '10

21 Apr '10

Hi! In the Oregon text strings can be easily changed since they are defined in xml-files in a directory inside the flash file system. I recycled now e.g. truckstop (0x2f16) to amenity=taxi. #amenity=fuel & fuel:HGV_diesel=yes [ 0x2f16 resolution 19 ] must be commented out in the point file, amenity=taxi [0x2f16 resolution 20] added. In the german.gtt file in Garmin/text, I changed <str> <tag>TXT_Truck_Stop_STR</tag> <txt>Truckstop</txt> </str> to <str> <tag>TXT_Truck_Stop_STR</tag> <txt>Taxistand</txt> </str> And I added an icon in my typfile and now I can search for the next taxi point. :-) Dani

5 15