Hi Minko, I am sorry for this awfully late reply. On Tue, Nov 16, 2010 at 11:55:54AM +0100, Minko wrote:

I have also some suggestions/comments to the default style:

Lines:

highway=pedestrian (roadtype 0x06) has the same line type as unclassified roads, why? Garmin has also a line type 0x0d [Pedestrian area] which is routable as well.

Your suggestion of replacing the 0x06 with 0x0d makes sense, provided that it is routeable and does not imply bicycle=no. (In Finland, bicycling up to 20 km/h is allowed on pedestrian areas.)

a suggestion could be to change this into 0x0d or the same as footway, 0x16

How would you identify a footway? There is some path/cycleway/footway controversy and ambiguity going on. Something like this? highway=footway & bicycle=(yes|designated|permissive|official) [ 0x16 ] highway=footway [ 0x0d ] # other cases than the above highway=path & bicycle=no [ 0x0d ] highway=path & bicycle!=no [ 0x16 ] highway=cycleway [ 0x16 ]

In my custom styles I use type 0x0d for footways, paths, pedestrian ways and they route fine Line Type 0x16 can then be used for cycleways, which are now rendered the same as footways in the default style.

Right, it could be useful to distinguish cycleways (or foot-and-cycleways) from foot-only ways.

Other line types that are routable can be used as well to distinguish more type of highways that are rendered the same in the default map: 0x0e 0x0f 0x10 0x11 0x12 0x13

Think about bridges, tunnels, steps etc

I am a little reserved about this, but I agree that this could be useful with a TYP file.

Polygons:

add landuse=grass to landuse=meadow add natural=heath [0x20 resolution 20]? add natural=sand | surface=sand to natural=beach

According to http://wiki.openstreetmap.org/wiki/Editing_OSM_Map_On_Garmin/Area_Types the 0x20 could work, but I would have to test it. There is no natural=beach in the default style. What did you have in mind?

I wrote earlier about a proposal to put some kind of standard TYP file to the default styles. The Mapnik ones from Lionel aka Petrovsk are suitable for this and he already give his permission to enhance it. Maybe this can be worked out and translated it into German, English etc

I can help with a Finnish translation. How would this TYP file be maintained? Is there some editable (text) format and an editor that is free software? Quite a while back, I was toying with the idea of composing a TYP file from an assembler source file, but I never got around to completing it. Best regards, Marko

On Mon, Jan 31, 2011 at 11:43:24PM +0100, Minko wrote:

...

How would you identify a footway? There is some path/cycleway/footway controversy and ambiguity going on. Something like this?

...

highway=footway & bicycle=(yes|designated|permissive|official) [ 0x16 ] highway=footway [ 0x0d ] # other cases than the above highway=path & bicycle=no [ 0x0d ] highway=path & bicycle!=no [ 0x16 ] highway=cycleway [ 0x16 ]

I would suggest highway=path & bicycle=(yes|designated|permissive|official) [ 0x16 ] highway=path [ 0x0d ] so the same as footways

As far as I know on the Dutch map highway=path is a narrow trail in forests or on fields that are not suitable for cycling unless otherwise stated (with bicycle=yes, for mtb trails etc).

In JOSM presets, there is a combined foot and cycleway: highway=path, segregated=no, bicycle=designated, foot=designated, ... This should be mapped as a cycleway 0x16. But what I suggested above obviously won't work; it turn forest paths into cycleways. This idea should work: highway=footway & bicycle=(yes|designated|permissive|official) & snowplowing!=no [ 0x16 ] highway=path & bicycle=(designated|permissive|official) & snowplowing!=no [ 0x16 ] highway=footway | highway=path [ 0x0d ] # other cases than the above highway=cycleway [ 0x16 ] The highway=path & bicycle=yes would be mapped to 0x0d, because there are narrow forest paths that are somewhat suitable for bicycle use (skilled rider, no trailer, not too much cargo). The distinction of snowplowing=no could be useful for winter time. Unplowed roads are often walkable but not that much rideable, except with a mountain bike.

...

...

Other line types that are routable can be used as well to distinguish more type of highways that are rendered the same in the default map: 0x0e 0x0f 0x10 0x11 0x12 0x13

Think about bridges, tunnels, steps etc

...

I am a little reserved about this, but I agree that this could be useful with a TYP file.

I agree, someone has to maintain a default style file first otherwise it wouldnt make much sense.

Right, we would need a default TYP file maintainer and an open source tool for generating binary TYP files. We would distribute a TYP file that matches the default style, both in binary form and some textual form.

...

...

Polygons:

...

add landuse=grass to landuse=meadow add natural=heath [0x20 resolution 20]? add natural=sand | surface=sand to natural=beach

...

According to http://wiki.openstreetmap.org/wiki/Editing_OSM_Map_On_Garmin/Area_Types the 0x20 could work, but I would have to test it.

...

There is no natural=beach in the default style. What did you have in mind?

0x53? sand/tidal/mud flat - although it looks like water in gpsmapedit :(

I will check the highway=path changes first.

I use typviewer from http://opheliat.free.fr/michel40/ to convert a typ file into txt format and back to typ which is also compatible with the online typ file editor from ati.land.cz Drawback is that it's only available in French.

Is there any source code available for that tool? I only saw Windows executables. Best regards, Marko

On Wed, Feb 02, 2011 at 11:00:15AM +0100, Minko wrote:

You could also think of displaying paved footways/path with bicycle=yes as cycleway. This makes it distinguish from a forest mtb trail.

That could do a disservice to on-road and city bicyclists. It is forbidden to ride on footways (except for short distances, in crossings, accessing properties and the like) and usually compulsory to ride on a cycleway. It can be safer and more convenient to ride on a highway=tertiary or highway=residential than on a poor cycleway. The bicycle=designated or bicycle=official suggests compulsory usage. I would like to distinguish the compulsory cycleways from optional ones. I tested the 0x0d and have somewhat mixed results. It does not show up at all in QLandkarteGT. If it really works on all devices and in MapSource and RoadTrip, I guess that we can dismiss that as a QLandkarteGT bug. The Edge 705 draws the 0x0d as a black thin line, with the default label of 'Line' (translated from Finnish). Bicycle and foot routing are OK, and car routing looks like access=destination when I tested routing to a point on such a line. The black thin line would be a better rendering for cycleways than the brown dashed line (0x16, default label 'trail'). If the 0x0d works everywhere, then I would rather use the solid black thin line 0x0d for cycleways and the brown dashed line 0x16 for footways and paths.

And how about highway=track & bicycle=designated [0x16] ?

Do you have a photo of a traffic sign that specifically allows bicycles on a highway=track? I would not expect any traffic signs along a highway=track, and I would expect tracks to be smoothness=bad unless tagged otherwise. Marko

On Wed, Feb 02, 2011 at 02:12:23PM +0100, Minko wrote:

I think we also need to look what kind of definitions Mapnik is using.

Would you propose using the Mapnik.TYP file? I share Charlie Ferrero's concerns about the spaghetti appearance. Being an owner of an 'old' unit (Edge 705) I would prefer a plain drawing style that omits any borders around ways.

The default mkgmap Garmin map should look the same, in order to prevent that some cycleways on the Garmin are footways on mapnik.

Where can I access the Mapnik drawing rules? I tested the line types 0xe..0x13, and all seem indeed routable in the Edge 705. Just like the 0xd, all display as a thin black line and carry the default label 'Line'. If the 0xd works like this on all units, I would translate cycleways to it in the default style. The current 0x16 (brown dashed line) would be for footways and paths that are not (primarily or at all) for bicycling. Best regards, Marko

On Thu, Feb 03, 2011 at 09:59:14AM +0100, Minko wrote:

Advantage of the mapnik.typ is that it looks like the 'default' osm map.

I think that I would find Mapnik too low contrast on the small screen. The paleness is useful for overlays, such as www.latukartta.fi (Nordic skiing tracks overlayed on SlippyMap tiles).

Have you got an example of another Typ file that looks good on the older units?

No. Until there are open source tools for creating TYP files, I try to avoid depending on them.

0x0d on a nuvi and a Dakota: without a typ file they are thin white lines with "line" as label. On a white/grey background almost invisible. :-( On a nuvi 0x16 are thin grey lines. On a Dakota it's a thicker, grey dashed line, same as unpaved roads.

On QLandkarteGT, 0xd..0x14 are totally invisible. This confirms that it would not be wise to use them without a TYP file. I think that the default style must be useable without a TYP file. A TYP file can of course enhance the experience, so to say. :-) I got another idea: promote cycleways to 0x07 (alley), currently used by highway=service. On the Edge 705 it looks identical (brown dashed line) to 0x16, but the default label (shown in navigation instructions and when hovering the cursor over a way) would distinguish cycleways from footways and paths. QLandkarteGT distinguishes these by colour: 0x07 is a brown solid line and 0x16 is gray. Other devices than the Edge 705 might distinguish these too. What do you think about the attached patch that moves highway=pedestrian from 0x06 to 0x16 and highway=cycleway and some bicycle=designated ways from 0x16 to 0x07? 0x07 was previously only used by highway=service and similar. If I get no objections in a few days, I will commit this. Marko

Minko, On Thu, Feb 03, 2011 at 01:08:45PM +0100, Minko wrote:

Marko, I think it's a good idea to display cycleways as 0x07 (alleys according to garmin). I treat pedestrian the same as footway too, because many mappers use one of these for exactly the same roads.

Good that we are on the same page.

How about highway=service? I suggest to display them as type 0x06. Maybe with a default_name=service?

I would keep highway=service as they are (0x07), because they are usually driveways, parking aisles or alleys where the practical maxspeed is lower than on residential streets (which are 0x06). Also, some highway=service are private driveways to properties. I think that anything on 0x06 or 'bigger' road types should generally be public roads. Marko

On Fri, Feb 04, 2011 at 10:05:25AM +0100, Minko wrote:

Maybe if you put a default_name on them (default_name=service) you can read from the label what kind of road it is.

Adding the default_name bloats my gmapsupp.img of Finland by about 70k and the zip compressed gmapsupp.img by about 80k. I would use default_name sparingly in the default style, because it is not a localized string. A better alternative to default_name would be to omit the default_name and define the default name for the line type in the TYP file, for every language supported by Garmin. I think that it should suffice that the access flags prevent motor vehicles from those 0x07 that are cycleways. Usually highway=service are short, and only used as the very first or last leg of the route.

Type 0x07 is actually a pretty good one because it's a thinner solid line than the residential streets but it is not dashed like paths and footways.

On the Edge 705, 0x07 and 0x16 look identical, but they are distinguished in the navigation instructions: alley vs. trail. Best regards, Marko

On Fri, Feb 04, 2011 at 03:38:56PM +0100, Minko wrote:

In the typ file you can't define what kind of road it is in the TYP file, if both roads are set to the same 0x07 type. So there you can only set the label to cycleway/service road and see what the navigation does.

It's sad that the newer Garmin's only can display a very limited number of line types without a typ file, but there is another alternative: How about working with overlays?

line style file:

highway=cycleway [0x070d] highway=service [0x070e]

overlay style file:

0x070d: 0x07, 0x0d 0x070e: 0x07, 0x0e

Routing will be fine, because Garmin only uses 0x07 Without a typ file, GPS unit and Mapsource show only 0x07 because 0x0d / 0x0e are invisible

Without a typ file, the Edge 705 ought to show a black line (0x0d or 0x0e) overlaid with the dashed brown line (0x07).

If you are working WITH a typ file and the default style, this option does offer the possibility to set a label or colour to 0x0d and 0x0e

Yes, that would make sense when using a TYP file.

Speaking of invisble lines, this is also working for bridges:

(bridge=yes | bridge=true | bridge=viaduct) [0x2b resolution 23 continue with_actions]

Without a typ file, bridges are not visible, just the highway. With a typ file, type 0x2b can be made visible with the highway.

I got another idea: What if we create a default-typ style based on the default style, similar to the marine style? It would define overlays for bridges, tunnels, oneways and such. The prerequisite for this would be a TYP file that can be distributed with mkgmap (with an appropriate license and some maintainer). The default-typ style would only contain the tweaks; most definitions would still be in the default style. Best regards, Marko

On Fri, Feb 04, 2011 at 10:44:20PM +0100, Felix Hartmann wrote:

Without typfile lines are not automatically and in all Mapsource / GPS versions invisible or not to distinguish. I would not include invisible (without assigning them invisible by using a typfile) roads into the default style.

This seems to be another vote for my current changes. I committed them in revision 1827.

BTW: the points file resolutions should be drastically reduced. I would basically reduce all but cities to 24. Then maybe put some into 23 and look if there is a need for any (and that they are shown as well, else it is just wasted space) POI except cities in 22 from a general usepoint.

This sounds like a good idea. POIs just clutter the map display, and they should still be found via indexes. I will investigate this. Marko