From OpenStreetMap Wiki
Jump to: navigation, search

Discuss OpenPisteMap here

Server OpenPisteMap inaccessible

Dear OpenPisteMap developers,

the Server seems not to answer at this time. What's up? Maintenance, or lack of funds?

Gpermant 09:52, 14 December 2011 (UTC)

The openpistemap server is currently up, but is giving 404 errors for the background images. On the sidebar it says "OpenPisteMap is currently experiencing some problems after migration to a new server. Please be patient while we resolve these issues. ... Please see the Wiki for project status information."
So it would be useful to have some "project status information" on this page to give people an idea if/when it's going to get back up to full working order. Does anyone know? Eric2 09:23, 19 January 2012 (UTC)
The status is exactly as given on the side of the main OPM page - OpenPisteMap is currently experiencing some problems after migration to a new server. The I/O demands on the old server were causing problems for my paying customers, as well as an excessive bandwidth bill (largely due to a few abusive pieces of software that pull down huge swathes of the map at a time - sorry, but there is just no excuse for trying to pull all tiles for an entire country at all zoom levels for hours on end!) so the site had to be taken offline until a better solution could be found. OPM has now been moved to a newer, more powerful server, but not all the functionality has been restored yet. Steve Hill 14:41, 7 February 2012 (UTC)

Google Maps Showing Pistes and Lifts for South Lake Tahoe

If you look at South Lake Tahoe, CA on Google Maps you will see a large number of pistes and ski lifts rendered. As far as I know this is the only area where pistes and lifts are rendered on Google Maps so it must be a special project by a Google employee or something. Anyhow, it looks pretty nice so I thought I'd post it here to generate ideas for future Open Piste Map Rendering styles. --Ezekielf 20:16, 21 April 2009 (UTC)

transparent layer

Wouldn't be a lighter job only to render piste features, and view them as a transparent layer over the existing OSM tiles  ???? Pistes feature could then be un rendered on OSM and make it lighter on it's side also... --PhilippeP 13:03, 10 March 2008 (UTC)

Possibly, but that doesn't allow the existing features to be customised to make them more appropriate for a piste map. Also, contour lines probably won't work well as a transparent layer since they would obscure other features. Steve Hill 21:34, 10 March 2008 (UTC)
What existing features ?? As a layer could be switched on/off, nothing would be obscured ... And it wouldn't be necessary to render osmarender and mapnik versions also ... --PhilippeP 08:29, 11 March 2008 (UTC)
Certain features will probably want to be modified - for example, minor tracks probably want to be rendered in a lighter colour since they will often be obscured by a piste during the winter. Steve Hill 12:56, 11 March 2008 (UTC)

Contours tip

Contours duplicate text - you don't need to worry about that, if you're following my guide for the cycle map. If you want to render the contour names for the 10m and 100m shapefiles, just don't render it for the 100m shapefiles at all! All the heights are in the most detailed shapefile. Gravitystorm 13:36, 11 March 2008 (UTC)

Thanks for the tip. I've actually solved it in a different way, which I hope will work out neater once I start importing lots of contour data - instead of generating lots of shapefiles (and 3 layers for each), I am loading the whole 10m dataset into PostGIS. I then define 3 layers (10m, 50m, and 100m) and select the appropriate contour intervals out of the database, excluding the overlapping contours from the higher frequency sets. This means that for n shapefiles I only need 3 layers rather than 3n layers, and don't need to adjust the XML whenever I add contours for more areas. I'll add information about this approach to your contours wiki page once I've got it all working. :) - IE6 browser troubles

Oh. I just realised that you have actually made some good progress with setting something up at I was suggesting you needed some kind of holding page, because I thought there was nothing there, but using firefox, I see a piste map!

It must be serving a wrong mimetype or something because I.E.6 comes up with a download prompt, and then doesn't know what to open the file with

...and before you say it. I'm forced to use IE6 at work. I don't do it voluntarily (but over 50% of web-surfers are still on it) Dunno if IE7 copes better.

-- Harry Wood 18:47, 12 March 2008 (UTC)

The page is served with the correct mime type (but IE, of course, doesn't support the standard mime type). I will be switching to a text/html mime type at some point anyway because OpenLayers actually uses some functionality that is disallowed in XHTML, but that will require some adjustments to the XHTML itself and I haven't had chance to do it yet. - Steve Hill 21:42, 12 March 2008 (UTC)
I've now tweaked the page and it is being served as text/html. I have no way to test it in IE though as I have no access to any Windows machines. - Steve Hill
Yep. that's fixed that problem. Still don't see the slippy map in IE6 though. It looks like the map div is rendering with zero height (I'm seeing a 2px black line along the top of the page) Is it javascript which is supposed to be setting the div's height? Not seeing any javascript error though. -- Harry Wood 09:58, 13 March 2008 (UTC)
The div is positioned and sized by CSS (it is positioned absolutely with the top, bottom, left and right properties set appropriately). I don't have access to any Windows machines, so I can't test it in IE to see why it breaks - if someone else can submit a patch then I'll apply it though. (It's a really simple page... I'm not sure how IE can manage to get it so wrong). Steve Hill 10:29, 13 March 2008 (UTC)
I took a look in a bit more detail. On OpenStreetMap we have
window.onload = handleResize;
window.onresize = handleResize;
...kicking off a resizing function. Openpistemap does not have this. Maybe IE6 depends upon this, while other browsers manage purely with CSS (although I think all browsers use that function when expanding out the search sidebar?) That's my guess. I'll look into it some more some time. I know it's not going to be easy for you to fix it without access to this shabby old browser :-)
-- Harry Wood 11:03, 13 March 2008 (UTC)
Looks possible, although I'd prefer to fix this with (possibly IE-specific) CSS if at all possible. Steve Hill 11:40, 13 March 2008 (UTC)
IE6 should be spelled IESux ... I also have IE @work but I use FF anyway , and I can confirm the IEFix (A hair on my tongue) bug... In the meantime, maybe adding a message promoting another browser in the left pane ? --PhilippeP 12:22, 13 March 2008 (UTC)
I've added an [if IE] section to the sidebar that explains the situation and points at this talk page.Steve Hill 13:09, 13 March 2008 (UTC)
IE8 apparently works ok, so I have changed the conditional comment to only display a warning to people using earlier IE versions. Steve Hill 09:09, 17 February 2009 (UTC)
So for us stuck with old versions of IE through applications servers, a burochrautic IT department, and nazi firewalled access to internet, just have to accept that we cannot see these maps, or wait until IE12 is lounched so they maybe upgrade to IE8.....? --Skippern 01:42, 18 August 2009 (UTC)

Adding piste:type

What about adding type snowshoe and winter-walks. I thank that snowshoe is an activity available in many station, and for winter-walks it is available in "Les Diablerets" ( and it's use ful to know witch ways are available in winter.

CU and thanks in advance Sarge 13:21, 27 December 2008 (UTC)

I've moved this discussion to Talk:Proposed_features/Piste_Maps. - Steve Hill 09:58, 30 December 2008 (UTC)

Add cross country skiing

Please also add cross-country ski runs as they are quiet common here...

I didn't know of your project before... Would you suggest a different Tagging? How about relations as most ski runs use at least some part of a track

Currently rendered Map

What part do you currently render? In which zoomlevel? I sadly see that Austria is (mostly) not included. Could that be changed?

The whole planet is rendered on-demand down to zoom level 17. If you look at a region of the map that hasn't been viewed before and the server is under heavy load it may not render quickly enough to display immediately - try looking again a few minutes later. Contours are only imported for selected regions due to the amount of disk space they would require for the whole planet - if you want contours to be added for a region then email me ( Steve Hill 08:57, 17 February 2009 (UTC)


Hi, I'd like to suggest a tag like piste:name which is the name of the piste only. The problem is, that standard Mapnik does not render pistes, but renders every name of a road, regardless of the other tags. This would help too, when the piste leads over tracks or roads, so that the piste does not need to get it's own way. In general I'd suggest, that OPM removes all piste: prefixes from tags it doesn't know, and tries to render them, as they were just the tag without the prefix. Doing this would make it clear to everyone who uses the data, that the name or ref or whatever applies to the piste, which in most cases is only valid from December to March. --BearT 07:02, 10 February 2009 (UTC)
PS: Would it be possible to render some snow on forrests? Skiing through green forrests (even on the map) is not that nice. ;-)

I dislike fixing a Mapnik rendering problem with creating a new tag (i'd also dislike fixing osmarenderer problems with a new tag ;). The other problem with having two different names for a road and a piste still exists. -- studerap, 16. February 2009
I understand your concerns about fixing rendering bugs in the data, but still the name tag on a highway=track is neither clearly part of the track road nor of the piste on the same location. And most often the piste has another name as the track, if the track has any. So it's not a rendering bug, it's simply impossible to know if the name-tag applies to the track, to the piste or to both unless all piste features are prefixed accordingly. --BearT 22:12, 16 February 2009 (UTC)
I'd support the idea of allowing namespacing in names for situations where the 2 names are in conflict (e.g. a piste and road that follow the same way but have different names could have both "piste:name" and "highway:name" tags). However, I know that some people are almost violently opposed to namespacing, so I'm sure it would create a lot of arguments.
The other option is to use relations - i.e. a way could have both a "highway" relation and a "piste" relation at the same time - this seems like a neater solution, although more complex. In the long run I imagine that most tags will end up migrating into relations, leaving the ways themselves untagged; but I'm not sure the editors are there yet.
I do dislike the way that the OSM Mapnik styles have a habit of rendering the name text for features that it doesn't know how to render, but that is a Mapnik style sheet bug and shouldn't be worked around by changing the tags. Steve Hill 09:06, 17 February 2009 (UTC)
What I'm talking about is, in my case, no bug, since it's a highway=track and a name=*, which is perfectly valid and rendered as such. It's just that the name and the highway are on the same way, but apply to different usages of the way. But of course this bug exists in other places and is very annoying, but that's no topic here.
I really do like the idea of relations for every data attached to a way, but as you said it is complex and hard to do (currently) in the editors. So I'd think of namespacing as a valid and easy solution at the moment. I'd also expect the namespaced tags to be relatively easy (automatically) transformable into relations. But I'd be glad to hear the arguments against namespacing, since I do not really see any at the moment. --BearT 23:13, 17 February 2009 (UTC)
You can read one of the many arguments here: although I'm fast coming to the conclusion that namespaces on attributes are the wrong direction to go in - I'd prefer to switch to a tagging scheme that provides a properly identifiable context and use relations - see (I do still think that the tagging scheme we use on OSM is an almighty mess and needs to be overhauled) Steve Hill 21:24, 19 February 2009 (UTC)

Nordic pistes


I've a question: I've problems to find nordic pists in the OPM. I can see downhill, but not nordic. Is that a problem on my side or are there no nordic pistes on OPM rendered at the moment. Maybe somebody can reference an example? Thanks! -- Mathias71 15:49, 24 March 2009

  • I think I can answer that question by myself: I just realized, that nordic pistes are listet under ToDo. So my next question is: Are there any time plans when they will be included? -- Mathias71 14:00, 25 March 2009

Direction rendering

Hi, have you thought about rendering using arrows (like oneway street rendering in osm)? Most pistes are one-way (by the law of gravity, not accounting for the crazy people that climb up the hill), and some of the lifts are too. Norpan 09:51, 13 October 2009 (UTC)

Rendering separately the basemap and the pistes


Lonvia [1] render only an overlay for hiking path and use other people maps as base maps (base of OSM, shading of H&B). Is it possible to separate the rendering to reuse them on remote sites ? You already edit two maps with/without countours. You could use the osm mapnik as base, you contour rendering as overlay and the pistes as overlay.


--FrViPofm 15:36, 31 August 2010 (BST)

Update Interval

Hello, how often do you update the map? There are some pistes missing, which are mapped in OSM. --Efred 07:39, 13 April 2012 (BST)


I am thinking about creating a dedicated winter map on with routes for skitours. When I start contributing skitour routes, how should I tag them in order to not interfere with the rendering of pists on openpistemap? I guess the most appropriate way at the moment is to use this tagging:


Yes, that would be for a relation. I would prefer route=piste as this scheme takes into account snoshoeing routes.--Yvecai 22:15, 10 October 2012 (BST)