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.
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?
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.
Of course you understand this all better and I know Im just stupid but it works for me.
I have tested your suggestion before and this will break the routing when searching for addresses.
then you did something wrong. Address search works on all routable lines. You could also use another type for the non routable lines - which would indeed make more sense if you use a .typ-file anyhow. So use 0x08 0x09 invisible for routing, and for example 0x10e?? or 0x10f?? for display.
Cause with your example very often also 0x02 would be used for routing, and hence you get the wrong description on the device. If unroutbable 0x02 produces problems with address search - there is an mkgmap bug so you should report it.
It’s a bug, either from Garmin or Mkgmap. Address search works, but if I search for the ramp and I route to it, routing breaks. It routes first to the tile border and then a straight line to the ramp, if I use your suggestion: 0x08/0x09 transparent and routable. Then use a 0x02/0x03 not routable.
Better suggestion is using my example with two routable lines, or maybe the second display line a non routable type instead of 0x02, 0x03 etc.
Why would you want to put two routable lines on top of each other? Why not
highway=trunk_link [0x08 road_class=3 road_speed=2 resolution 20 continue]
highway=trunk_link [0xsomeNonRoutableCode resolution 20 ]
Not saying it’s wrong, I just don’t understand why you’d do it.
Because you dont have to make separate lines for trunk_link primary_link secondary_link and teritairy_link. This works for me, try it out yourself, if it doesnt suit you make other lines with non routable lines in your typ file.
I understand that another approach is to use a non-routable code for the non-transparent entry. If I discover any issues I’ll switch to using that method - it’ll just mean I’ll also have to update my typ file so the new non-routables codes also render the same as the appropiate routable codes.
The lead I had for another server did not work out but fortunately the new custom server should be able to host a generic routing and cycle map at the same time. So I have been working on this again since the new custom server is working normally.
The basic scripts for generating the precompiled tiles are nearly complete. The generic routable tiles that this stylefile are already generated and openfietsmap lite tiles using the style from Ligfietser are being generated now.
This has yet to be done:
Configure the map combining scripts to cope with the two tilesets.
Update the new website to use this server.
I will be busy the coming days with real life so expect access to a test website somewhere next week.
I hope I can provide a link to the new webpage that contains these two maps for testing this evening. I’m sure the website needs more work, but at least the Garmin map generation functionality can be tested.
Here, not only is the Missouri River outside of it’s boundaries, but part of the Mississippi River and the Meramec River are outside of their boundaries.
This is the end of my report.
–Stephen Brown/Firefishe
–firefishe AT gmail DOT com
hi, I’ve tried generating the preset maps for Mauritius and they seem to blank for the whole of mauritius.
then I tried generating a custom map and only 1/3 of mauritius is displayed.
I downloaded the MapSource installer for Mauritius which has been created on the 20th. MapSource shows the top 3/4 and lower 1/4 without problems here. Have you tried clearing the tile cache in MapSource (start MapSource and press ctrl-G twice)?
