August 2009 - mkgmap-dev - The mkgmap lists

some comments on mkgmap default style
by maning sambale 06 Feb '10

06 Feb '10

Hi, some observation about the default style: 1. Coastlines are shown as thin blue lines, is it possible to render coastline as polygon, where sea areas are shaded as blue. A work around I did before is to manually edit all sea-areas and then add a natural=water tag (bad data edit) . 2. Administrative boundaries clutter the map. They appear like roads and can be confusing while driving. Suggestion is to make the admin boundaries thinner. Hope it helps improving the default stylesheet. -- cheers, maning ------------------------------------------------------ "Freedom is still the most radical idea of all" -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ ------------------------------------------------------

5 8

[PATCH v1] Merge similar lines and ways
by Thilo Hannemann 30 Nov '09

30 Nov '09

The attached will merge lines that are similar* after styling. It is activated by the switch "--merge-lines". As there are less way fragments, the Douglas-Peucker filter will work better and the routing should improve somewhat, because the ways will be longer and the routing algorithm won't give up too soon. The size of the resulting map is reduced a little bit as well. The patch is based on code published by Johann Gail on this mailing list. *) similar means that they have the same attributes: name, ref, access, etc. Regards Thilo

6 15

Can you set background colour in a TYP file?
by Mark Burton 01 Nov '09

01 Nov '09

Hi, Just playing around with TYP files and wondered if it is possible to change the "Garmin yellow" background to anything else using a TYP file? If not, is there any other way of doing that? Cheers, Mark

7 24

address search problem due to required "State" value
by maning sambale 24 Sep '09

24 Sep '09

Several problems with Search by Address in Garmin Mobile XT reported by some of my users. " - unable to search for road names via Address Search option using Where to?" -> "Addresses" -Step 1 0f 5 in Address Search requires entry of "State", no state is listed and no matches found if the "Spell" option is used -unable to proceed with the following Address Search steps because of the said bug" In the Philippines and surely in other countries, we don't have "State". -- cheers, maning ------------------------------------------------------ "Freedom is still the most radical idea of all" -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ ------------------------------------------------------

12 30

POI's don't show in the 3d or routing mode
by maning sambale 07 Sep '09

07 Sep '09

hi, Anyone encountered this issue? Using custom typ file for POIs and roads, POI's don't show in the 3d display or routing mode on nuvi200. -- cheers, maning ------------------------------------------------------ "Freedom is still the most radical idea of all" -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ ------------------------------------------------------

1 1

Re: R: [mkgmap-dev] [PATCH v3] - beware of the bollards!
by Marco Certelli 03 Sep '09

03 Sep '09

--- Mer 8/7/09, Mark Burton <markb(a)ordern.com> ha scritto: > Da: Mark Burton <markb(a)ordern.com> > Oggetto: Re: R: [mkgmap-dev] [PATCH v3] - beware of the bollards! > A: mkgmap-dev(a)lists.mkgmap.org.uk > Data: Mercoledì 8 luglio 2009, 11:15 > > Hi Marco, > > > Why either side? shoudn't be enough one side only for > restrict the access to the whole way? > > Hey, thanks for that question, it reminded me that I needed > to make the > POI a routing node to stop routing across the POI when the > start point > is within the restricted region. > > The only case it doesn't work for now is when both the > start and end > points are within the restricted region (one each side of > the POI). > Mark, this is how I "solved" the issue so far: a short piece (say 10m) of footway on one side of the bollard http://www.openstreetmap.org/?lat=41.895031&lon=12.414956&zoom=18&layers=B0… I still do not see the reason to make 2 unaccessible arcs on both sides instead of one. Ciao.

4 5

"Turn/Exit Left" instruction given too early
by Steve Hosgood 03 Sep '09

03 Sep '09

I'm in the UK, so it's "Left" for me but for many of you the same problem would be with "Turn/Exit Right". Basically, I drive a few roundabouts around here where the "Exit Left" instruction is given so early that I've not actually cleared the previous exit yet! The moving-map shows what was intended, but it would have been confusing to someone relying on the spoken instructions. I was wondering: has anyone noticed if the distance between an "Exit/Turn Left" spoken instruction and the exit/turn that it refers-to is linked to the road class or road speed of the way? If so, maybe we want to examine ways to downgrade the speed that the router assumes you can drive a roundabout. I see quite a few problems around my way, mostly with motorway junction roundabouts. If it isn't the road class or road speed, could it be linked to the curvature of the road (unlikely, surely)? Steve

1 1

Administrative boundaries
by Lambertus 03 Sep '09

03 Sep '09

It appears that very low level administrative boundaries are rendered quite prominently using the default Mkgmap style. An example is shown here: http://forum.openstreetmap.org/viewtopic.php?pid=31404#p31404 What are the options to reduce the visibility of those boundaries?

4 6

[patch] change bus_stop to Transit Service category and add name / operator
by Ben Konrath 02 Sep '09

02 Sep '09

Hi, Here's a patch to change the highway=bus_stop POI to the Transit Service category and add the name and/or operator. As usual, comments are welcome. Cheers, Ben

5 10

[PATCH] stop/continue scheme extended to style-rules without conversion
by Torsten Leistikow 01 Sep '09

01 Sep '09

Moin, I have extended the stop/continue scheme to style-rules without conversions, i.e. a style rule might now look as follows: highway=* & surface=sand {set surface=unpaved} [continue] With this extension the incomplete rules should get an own priority, so that the processing order of such rules should be defined by their order in the style file. A compiled mkgmap based on the multiple_garmin_elements-mb.patch provided by Mark Burton on 20.09.2009 can be downloaded at: http://demuur.gmxhome.de/mkgmap_no_conversion_rules.jar So please try it out, until now I have tested the modification only on a rather simple example. And please let me know, whether the attached patch is usable, since this is my first generated patch. I simply asked svn for the differences between my local copy and the head version. Gruss Torsten

5 9