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.
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 ]
Thanks for such as quick response.
This apears to be working for me.
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.
Is this coming any time soon?
Hello Beddhist.
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.
Hmm I think I have to update those styles a bit because they have been edited some time ago and mkgmap has been improved.
Yes, I expect some problems due to that among other things with the current test, but that’s why it’s a test 
I would like to report the following river boundary issues (All Photos are Screenshots from Garmin Base Camp):
First, for garmin.streetmap.nl:
The Missouri River is outside of its boundaries.
–
Second, for garmin.streetmap.nl/index_new.php:
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
Mauritius
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.
Openstreetmap displays the maps correctly.
Can anyone help?
Thanks
very much
John
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)?
I’ve just tried the Roadtrip download and it indeed has the mauritius maps.
The download I am referring to is the osm_routable_gmapsupp.zip for my Oregon 450. This doesn’t seem to have the map … even though it’s a 10Meg download.
The map doesn’t seem to load. I have other OSM downloads and they’re fine.
Have you tried sending the RoadTrip download to your OR using MapInstall?
Judging by this topic: news://news.gmane.org:119/20120705194522.GE3389@x220 our work here on the style and typ files is still required. Lambertus, I know you are very busy with your site upgrades, but the months go by and we still have maps that are odd, to say the least. Just as one example: the world is littered with camp grounds that in reality are shelters by the road side.
I have to confess that I haven’t done any work on this little project of ours for months, so I don’t even know whether the style sheets and typ file are in a usable state now. I’m still keen to see this implemented, because if we wait for the mkgmap developers then I don’t think it will ever happen.
A bigger problem than those odd campgrounds is the routing that has been changed in Basecamp and more GPS units with updated firmwares. In this routing most osm access tags are ignored by Garmin. I think the only solution would be to adapt the generic styles only for car routing (since there is a bicycle map now) but this would take more time.
That’s bad news. But, since non-NT maps already can’t distinguish between cars and motorbikes we already need a separate motorbike map. We could add a truck map to the collection. I don’t think creating these sub-maps would be too difficult.
Can you please point me to more info on the routing problem? I’m involved in the NZOpenGPS project and this may impact us. Unless it’s an mkgmap-only problem. We use cgpsmapper.
Thanks.
It has to do with the introduction of the new activity routing profiles. Basecamp 3.3 has that (you can try it yourself)
and more and more units are updated with this feature (Oregon, Montana, GPSmap 62)
http://www.mail-archive.com/mkgmap-dev@lists.mkgmap.org.uk/msg11688.html
http://www.mail-archive.com/mkgmap-dev@lists.mkgmap.org.uk/msg12401.html
There are a lot more vehicle types introduced but I’m still figuring out what the difference is between them (if there is any) in respect to routing.
I think they now only differ in what kind of avoidance and road preference options are preselected or greyed out.
For instance, in the bicycle activity, avoidance of carpool lanes are preselected and greyed out and this has a major impact on routing.
Major highways avoidance are selected by default which sucks because in my bike map the cycle paths are the “highways”.
Toll roads avoidance can’t be chosen (is greyed out) which is a bad because I use this option in my bike map to select cycle routes etc.
I dont think it’s a mkgmap problem only, also cgpsmapper will be affected.
It seems to me that this happens because map makers are using road types for purposes which they were not intended for. I don’t think there is a concept of carpool lanes in non-NT maps. (On top of that, I just checked our road code and (motor)cycles can use transit lanes, so this pre-selection is wrong for NZ.) I don’t understand how you use carpool lanes. These are all NT features, aren’t they? I can’t see how this impacts the non-NT maps we can make.
Can you give me the coordinates for such a lane, so I can download the tile from Lambertus’ server to see what it looks like in GPSMapEdit, please?
I think I’m getting confused…
Peter, I dont use carpool lanes. Garmin selected carpool lanes avoidance by default on the bicycle activity profile.
The nasty thing is that this has an impact on osm routing.
If you select carpool lane avoidance, all roads with access=no are blocked. Even if they have bicycle=yes (Basecamp is ignoring this tag). So Im not happy with this routing and I have to tell my users to use the activity for cars instead.
Roads tagged with motorcar=no are blocked too in this mode. So this means all bike paths in the default mkgmap settings which has motorcar=no by default (or access=no, bicycle=yes) are unaccessible in the Basecamp bike activity settings.
If you make a map for car users, you can benefit from these settings. Selecting carpool avoidance on can block all roads that are not intended for car driving (bikepaths, footways etc). However, selecting of carpool avoidance seems to mess up the routing in Mapsource, so you have to make several maps, one for Basecamp and the newer firmwares, one for Mapsource and the older firmwares. 
Thanks for that explanation, I’m starting to understand now. You have obviously done your homework. I haven’t worked much with BC, it’s too cumbersome for me to use with track editing and gobbles memory like crazy.
Using a motorbike ferry in Thailand I have verified what you wrote. Indeed, routing now only works with a custom profile and carpool lanes deselected. Of course, there is no Garmin tag access=no. There is “no cars/motorbikes” instead. This shouldn’t have any effect on bike routing and would be a bug - if we were talking about a map produced by Garmin. However, I have seen them respond to such bug reports for third-party maps and they may fix it. Have you reported it in the Basecamp forum?
Getting back to the original topic: none of this should stop us from proceeding with an improved style sheet and typ file. Perhaps we could create a style sheet that could easily be adopted for various vehicle types by changing a variable?
I would dearly love to compile my own map of Thailand with it, but I can’t see any way of getting at the OSM data. The existing extracts are either too big, faulty and / or too old.
It seems like it’s easy to put data into OSM, but it’s almost impossible to get something useful out of it at this point in time. I haven’t even been able to find an easy way to print a scale map of a province.
Regards,
Peter.
I have reported it but of course they ignored it because it doesnt affect their own maps.
I guess we have to deal with it and adapt the default mkgmap styles. I already did that for my Openfietsmap but it gets very complicated to explain the users how the set the routing properly given the differences in routing between Mapsource/older firmware vs Basecamp/newer firmware.
Regarding to your Thailand map, can’t you just grab an asia.osm.pbf from the geofabrik site, and extract a rectangle around Thailand from it with osmconvert?
This works for me very well with the benelux: osmconvert europe.osm.pbf -b=2.35,49.35,7.5,54 -o=benelux.osm.pbf