I welcome and agree with your comments, skela. We are here doing this because we felt we were not getting adequate responses on the mkgmap mailing list. Feel free to grab whatever suits you. It is all GPL, after all.

When working on the typ files I have had major problems with the text versions, from editors crashing to cgpsmapper not rendering them correctly, so I have come to the conclusion that only the binary version works at this point. I’m sure Minko will prove me wrong now and in fact, I hope he will.

Are any of these style and typ changes in use by Lamertus’s site yet or is site still using the default style?
Is there a plan on when site will start using your mods or are you planning to wait and see if they will be included in upstream mkgmap default style?

It’s working in a test environment using the country server. I still need to prepare the custom map server to use the new stylesheet.

In the UK between the towns of Dorchester and Weymouth there is a new road, the Weymouth Relief Road A354. It seems OK in OSM but having built a custom set for the British Isles there is a section of the road that appears as a thin dotted line which I would associate with a track or footpath when viewed in Mapsource. The section is between Jurassic Roundabout and Veasta Roundabout. Other parts of this new road show correctly. Any ideas?

I have just made a minor edit to this section of road in OSM to remove the Key ‘Construction’ in the advanced menu as other parts of this road do not have this key.

This was originally posted in http://forum.openstreetmap.org/viewtopic.php?id=2625 on page 49 but it may be more appropriate here. Sorry if I have broken cross posting rules - happy for Mod to remove one or other posting if neccessary.

The Construction tag is indeed the cause if you look in the default styles, it says:

Treat ways under construction as highway=path

highway=construction | highway=* & construction=* {add access = no; add bicycle = yes; add foot = yes; add mkgmap:dead-end-check = false } [0x16 road_class=0 road_speed=1 resolution 23]

So in the next update your edits should be visible.

Hi !

Be careful with construction=minor.
http://wiki.openstreetmap.org/wiki/Key:construction
"Additionally construction=minor can be used for existing highways which will be modified or repaired without being closed. In this case we don’t set highway=construction but leave it at its default value. "

So you will brake routing.

I think that

highway=construction | (highway=* & construction=* & construction!=minor & construction!=no) {add access = no; add bicycle = yes; add foot = yes; add mkgmap:dead-end-check = false } [0x16 road_class=0 road_speed=1 resolution 22]

and reduced roadspeed for construction = minor

highway=* & construction=minor [0x16 road_speed=3 resolution 22]

will fix it.

Flacus

Could you please provide a link to default styles such as that refered to above. I have had a look around but can not yet find it.

@32110: http://www.mkgmap.org.uk/svn/wsvn/mkgmap/resources/styles/default/lines
@Flacus: maybe forward this rule to the mkgmap list to add it to the default style?

One thing I really miss in the default mkgmap style as well as “world” style, which I’ve added my own style, is the ability to obey the motor_vehicle and vehicle tags when routing. The two lines below is the one I use, you might certainly have a more effective way to get the work done.

highway=* & (motor_vehicle=no | motor_vehicle=destination | motor_vehicle=agricultural | motor_vehicle=private) { add motorcar=no }
highway=* & (vehicle=no | vehicle=destination | vehicle=agricultural | vehicle=private) { add motorcar=no }

Regards,

jetthe

I hope that the situation is improving now. While you are free to do anything, I think that it would be better to have alternative styles in the mkgmap tree.

I started working on refactoring the mkgmap default style into substyles or ‘include files’, so that you can create derived styles that are largely based on the default style. For example, a sparse style that did not show any other polygons than water should render faster and be quicker to download.

Before completing this task, I will test and implement the routing suggestions that were mentioned later in this thread.

Good news: Steve Ratcliffe (the original author of mkgmap) has now resurrected some code that writes TYP files out of text files. It is no more witchcraft than the reverse engineering of the rest of the Garmin format has been. I am sure that any issues you find with the translator can be addressed quickly.

Good idea. I would suggest the following patch to fix this and the highway=construction routing:

Index: resources/styles/default/lines
===================================================================
--- resources/styles/default/lines    (revision 2091)
+++ resources/styles/default/lines    (working copy)
@@ -98,6 +98,10 @@ contour=elevation | contour_ext=elevatio
 
 # Remove access=yes from highways.
 highway=* & access=yes { delete access }
+# Translate motor_vehicle and vehicle access rules.
+highway=* & motor_vehicle=* { add motorcar='${motor_vehicle}' }
+highway=* & vehicle=* { add motorcar='${vehicle}'; add bicycle='${vehicle}' }
+
 # By default, ways are accessible by the highest allowed mode of
 # transportation, and thus access=yes should be redundant.
 # However, sometimes cycleways may be tagged access=destination or similar,
@@ -164,8 +168,10 @@ junction=roundabout [0x0c road_class=0 r
 
 # Ways that may or may not be useable
 
-# Treat ways under construction as highway=path
-highway=construction | highway=* & construction=* {add access = no; add bicycle = yes; add foot = yes; add mkgmap:dead-end-check = false } [0x16 road_class=0 road_speed=1 resolution 23]
+# Treat ways under construction specially
+highway=construction { add mkgmap:dead-end-check = false } [0x16 road_class=0 road_speed=0 resolution 23]
+highway=* & construction=* [0x16 road_class=1 road_speed=1 resolution 23]
+
 # Treat disused ways as highway=service, but at lower road_speed.
 highway=* & disused=yes [0x07 road_class=0 road_speed=1 resolution 22]
 

I would appreciate feedback on this. I did not test the routing yet. (I would have to download and edit a small map with JOSM, compile with mkgmap, and test the routing on my Garmin unit, because I do not use Garmin software on my computer, and QLandkarteGT does not support routing.)

My reasoning for the highway=construction change is that mkgmap should not make a guess about the access rules. For highway=construction, we lowering the road_speed to minimum, so that the road will be a less likely choice for routing. (One lane can be closed, or the whole road may be closed, at least from time to time.) The construction=* on other than highway=construction could be minor construction, so we only lower road_speed to 1 instead of 0. I could add construction!=no to that rule, even though I think that construction=no is useless, just like oneway=no.

Hi Skela !

http://wiki.openstreetmap.org/wiki/Key:construction

construction=minor means that a road can be driven but at lower speed.
construction=yes mean that a road with the roadtype highway=* will be build, and you cant drive it at the moment with an car.

Thats the way i unterstand the wiki.

Dirk

I thought that highway=proposed and proposed=* would be for future roads. You can argue that there is a bug in the default style, because it does these:

highway=* & motorroad=yes {add bicycle = no; add foot = no}
…
highway=* & motorroad=yes [0x02 road_class=4 road_speed=4 resolution 18]
…
highway=* & area!=yes [0x07 ]

The fix would be to add & highway!=proposed to these.

The changes for motor_vehicle and vehicle are now in r2092. I did not touch the construction=* yet, I will wait for your feedback first.

My current reasoning regarding highway=construction is that the map data should specify the access rules. It is a smaller error to set road_speed or road_class too low than to break routing by guessing that access should be denied. If the highway=construction was spotted by a mapper who does not regularly visit the area, the tag may remain in the database for a long time after the construction was completed.

I think highway=construction is meant for roads that are being built, and so no routing must be possible on these roads, not even for cyclists or pedestrians. Only roads with highway=* & construction=* can be routable. Highway=proposed are ways that only exist on paper, maybe not even build in the near future or maybe never at all. I remove those ways (and including the bridges and tunnels) from my cyclemap.

If routing will break, and the road is finished, it is a fault on OSM and has to be repaired there and not by mkgmap. It is the same as Google Maps already draws completely new districts that only exist on paper.

In my area, ways can be under construction for a long time until they are finally opened for traffic. For example, when a new area is built, the road network will be built for the purpose of constructing the area. It is not open for general traffic, but it is possible (maybe even legal) to use it by pedestrians and bicyclists. It can take months until the actual building construction starts, or there might be no construction activity on evenings and weekends.

But, I guess that the correct solution is to explicitly tag these highway=construction as foot=yes, bicycle=yes in the OSM data when appropriate. Then, if the corrected mkgmap default style rule does {add access=no} or {add bicycle=no;add foot=no}, the existing tags in the OSM data will take precedence. Would anyone oppose that?

I would not hide publicly accessible road tunnels, because that could be confusing when viewing the map. If the tunnels were hidden, I guess that there should be some special tweak to create routing arcs for them in order not to break the routing.

Would it be possible to use the same technique you used for rendering roundabouts the correct color and apply it to highway=*_links

Currently there is only two types used for links - 0x08 and 0x09

I’m using 0x09 for motorways and 0x08 for all the others.

I’d like trunk_link primary_link secondary_link tertiary_link to render in same color as their corresponding trunk primary etc

You can try this
highway=trunk_link [0x02 road_class=3 road_speed=2 resolution 20 ]
highway=trunk [0x02 road_class=4 road_speed=5 resolution 18 ]

I dont know what consequences this has for the navigation directions, do types 0x08 and 0x09 have different navigation directions like the roundabout 0x0c type?

For 0x08/0x09 navigation directions are different. eg says “Exit left onto xxx” rather than “Turn left” and uses a different direction arrow graphic.

Ok, in that case you can try to render the highway link twice with a transparent line on top of a non transparent one with the continue statement:

highway=trunk_link [0x08 road_class=3 road_speed=2 resolution 20 continue]
highway=trunk_link [0x02 road_class=3 road_speed=2 resolution 20 ]
highway=trunk [0x02 road_class=4 road_speed=5 resolution 18 ]

highway=primary_link [0x08 road_class=3 road_speed=1 resolution 21 continue]
highway=primary_link [0x03 road_class=3 road_speed=1 resolution 21]
highway=primary [0x03 road_class=3 road_speed=4 resolution 19]

same with other highway_links

In the typ file make line type 0x08 transparent. Please note that since both lines are routable, don’t omit road_class and road_speed, otherwise routing will break when you search and route to an address.

that is stupid. You could have 0x08/0x09 transparent and routable. Then use a 0x02/0x03 not routable. Everything else seems to be by someone who doesn’t understand how it works. Cause if several lines are routable, you don#t know which one will be used.