Any chance that ski lifts be included in the maps?
Good question, on the Openfietsmap a few are already rendered, so yes that wouldnt be too difficult:
aerialway=cable_car
aerialway=gondola
http://wiki.openstreetmap.org/wiki/Ski_Lift
Let me know which other types are important too?
Thanks. I think the consideration here is for Garmin equipped recreational skiers and that all ski lifts should be included ie. From magic carpet to gondola. As a minimum, maybe not magic carpets but T-bar and above. This would make unfamiliar ski resorts that much easier to navigate. 
I think it make sense to render aerialway = cable_car, gondola, chair_lift, mixed_lift, but I doubt if we should render T-bars and drag lifts etc, for this you better use a specific osm ski map?
Ski lifts usually are placed in an area, that doesn’t contain many map objects. You don’t risk to make map overloaded even including all of them.
Hi,
I am using your maps (tdb version) with TTQV4 Software. With the new style there is an ugly brown diagonal hatch in the background all over the map. With the old style the background is white (as it should be) and only urban areas are shown as brown hatch. I tested this with Denmark and a while ago with Romania. Unfortunately TTQV4 cannot use TYP files. Do you see any chance to remove the brown hatch and getting a white backgrund with the new style?
thanks
Wolfgang
Thanks Wolfgang, I’ll see what I can do. The reason for choosing a different background was that the default background showed “ghost shading” when zooming in/out, but I think this issue has been solved already.
We have a routing problem. A couple of days ago my GPS tried to send me through a bike track.
The original is a highway=footway, with bicycle and m/c=yes. In the Garmin map that becomes “Unknown type” 0x10 with routing restrictions for everything but peds, bikes and CARS.
If this map was compiled for motorcycles then that would be correct, but for a car map it is not. Having said that, as far as I know the car restriction doesn’t work anyway. This will probably have to be compiled into a walkway (0x16).
Why is this tagged as footway? Imho the tagging as footway is wrong since cylists and even motorbikes are allowed so better use another highway type with motorcar =no. I dont think garmin types have anything to do with routing, its the road attributes and access tags that impact the routing.
It’s a rough dirt track that connects the two lanes of a dual carriageway. You find them everywhere in Thailand. Anything that fits through will use it. I didn’t really know how to tag it, being such an “ad-hoc” feature. I guess cycleway would be better. On a bike it saves you from riding several km up the road to do a U-turn. (The locals will also quite happily ride/drive down the wrong side. Seen a big concrete truck doing it today.)
You can see it nicely on Google Streetview. It’s at 14.874111, 100.086608.
The routing restriction for cars in Garmin maps doesn’t work, so everything tagged with motorcar=no needs to be rendered in the Garmin map as footpath.
Kind regards,
Peter.
Would be easier if you gave me the exact street view link instead of coordinates…
I think highway=track would be the best solution, you mention it as dirt track so why making it a footway?
I still don’t understand your problem that in your Garmin routing for cars doesnt work. What device do you have and is it the new activity routing that is bothering you?
Sorry, I tried, but Google have made changes to GM and the only way to share a map view seems to be via Google+. You can paste the coords into GM and it will take you to the spot, then use the slider to zoom in all the way. It’s visible in the aerial map already, so you can drop the orange man into the location.
I have done some testing with the routing restriction for cars. It doesn’t work on anything that is not a footpath. (Even in the new NT maps Garmin have mapped a pedestrian street in our town as footpath.) Tested with MS, BC and several devices. I have a Zumo 660.
In our NZOpenGPS maps if we want to prevent routing through a street we must use a footpath, or cars will be sent through, routing restriction or not.
Sorry, I don’t know what activity routing is. All I know is Garmin’s software and my Zumo behave the same.
Regards,
Peter.
I"m sorry Peter but I have no idea what you are talking about. If I use car routing it respects the osm tags whatever garmin line I use in Mapsource.
Only in Basecamp and all the latest units which have the new activity routing, you need some workarounds as carpool avoidance,.
Can you post here an example, with screenshots, map you are using and links to osm please to show what you mean?
Suggestion: Could the maps include name label for lakes? I just noticed that lake names aren’t showing on these maps, both in BaseCamp and on a Garmin unit. Examples being Lake St Clair and Lake Judd in Tasmania, Australia. Thanks for considering.
Fault report: Blue colour missing for harbour water
Just downloaded a copy of generic routable new style of Sydney Australia region. On my Garmin Oregon 650 with the latest firmware, I note that the blue colour that denotes Sydney Harbour is missing to the East of Cockatoo Island. To the West, it correctly shows the blue colour all the way out to the very end of Sydney Harbour/Parramatta River. Not have had this problem in the recent past but quite a while back (a few months ago), the section to the West of the harbour was not properly coloured. This was fixed and all areas were correctly coloured for a good while until this download. Odd. Not sure if it’s something on the server or people have changed something on OSM. Although there’s no error in the display in Garmin’s BaseCamp.
This is very odd since you mention the rendering in Basecamp is ok.
Are you sure you have no other maps activated on your Oregon?
On my Oregon 600 the harbour looks ok.
No I don’t have other maps activated on my Oregon 650.
I did a bit more look around and in the OSM source data editor, I note that the waterway to the west of Cockatoo Island is separately marked as a waterway (river) while to the east, there’s no similar notation for the harbour waterway. The boundary were all land boundaries, not water. I trust my interpretation of the map entries is correct. Would be good if some more experienced user can confirm.
Waterway=river is for line elements and is not intended for rendering water polygons.
Is this part ‘dry’: http://www.openstreetmap.org/browse/relation/1252425 ?
Can you make a screenshot and post it online and please describe all the map settings as possible that you use in your oregon.
Thanks Ligfietser. I have just got back on a bushwalk yesterday and found out there’s more waterway that didn’t display to the north of the city. So it would appear it’s something more than just Sydney Harbour. I am going to re-d/l the map and try to load the latest version, just in case there’s a build or installation problem. If the problem persists, then I’ll get back to you on those questions.
Update: I have found the problem, one that lies in the ‘Land Cover’ setting (Map Setup → Advanced Setup → Zoom Level → Land Cover). I did re-download the OSM map and place a new install prior to this discovery.
If I use Auto, then a significant part of the Sydney Harbour waterway and major waterways up north of the city would not get displayed. If I switch the setting to Off or any other fixed options, then the expenses of water will be displayed properly.
Thinking back in terms of the sequence of events, I now suspect it might have something to do with firmware 3.50 in my Oregon 650. The issue was noted after this firmware upgrade. I’ll report it to Garmin unless there are other thoughts on why this is happening.