Talk:Proposed features/key:roller coaster

From OpenStreetMap Wiki
Jump to: navigation, search

attraction tag

The only thing I'm not sure about this proposal is keeping the attraction=* tag on the track way/relation. This is currently renders as an enclosed area and so has odd results when rendered (ex). Maybe this tag should be on the perimeter? --Dee Earley 00:41, 10 December 2012 (UTC)

I would also expect the attraction tag on either a perimeter area or a relation (or a node, but only if the rollercoaster has not been mapped in detail yet). Conceptually the "attraction" consists of the entire structure including e.g. the station, not just the tracks. And, of course, you should be able to split the tracks - which is necessary to assign layer or incline tags, for example - without creating multiple "attractions". --Tordanik 16:20, 10 January 2013 (UTC)
Agreed. It's normally difficult to give an outline though unless we use a strict definition like the ground footprint of fencing, buildings and queue. The track itself can (and often does) extend beyond this. --Dee Earley 18:23, 14 January 2013 (UTC)
I've now split attraction=roller_coaster into another way with its own name=* and definition. --Dee Earley (talk) 02:55, 1 February 2013 (UTC)


I was actually thinking about roller coaster tagging last night. Why not a simple railway=roller_coaster? --NE2 17:39, 10 January 2013 (UTC)

As that only covers the track. It also causes problems with rendering/data users that don't understand it and falling back to treating it as a real railway. This proposal is for roller coaster specific tags to handle the track AND other ancillaries like the station, etc. --Dee Earley 18:23, 14 January 2013 (UTC)
In a way it is a "real railway", just like a train ride in an amusement park. --NE2 21:00, 14 January 2013 (UTC)
+1 --Ceyockey 22:42, 14 January 2013 (UTC)
+1 --DCTrans (talk) 01:52, 1 December 2015 (UTC)

layer instead of level

As two contributors have remarked on the tagging list[1], the key that should be used for specifying relative heights is layer=*, not level. --Tordanik 01:08, 12 January 2013 (UTC)

Sorted, thanks --Dee Earley 16:32, 14 January 2013 (UTC)

Manufacturer and designer

Suggest that tags to include the names of the Manufacturer and the Designer of the attraction be included. --Ceyockey 13:23, 12 January 2013 (UTC)

There is no reason someone can't add manufacturer=* or designer=* tags to an object. personally, I don't really think it's of any use for cartography, routing, or rendering so I don't think it should be part of this proposal. For these, maybe an rcdb_id=* tag or similar to provide an ID in the Roller Coaster database? --Dee Earley 17:10, 14 January 2013 (UTC)
I was looking at the notion of enrichment of PoI's with information which is of particular interest to enthusiasts. Certainly this information is not of interest from a cartographic point of view. --Ceyockey 22:41, 14 January 2013 (UTC)


From where should you measure the height?

  • From the ground where the ride starts
  • From where the track starts
  • From the lowest point of the track
  • From ground at the lowest point of the track

The reason I ask is because my nearest park (Liseberg) has roller coasters on a mountain. One track starting at the foot of the mountain while a (soon to be built) starts at the top of the mountain. --Magol 12:37, 15 January 2013 (UTC)

I've said "normal ground level" so I assume the height from ground at that point. Whatever is the usual usage of height=* :) --Dee Earley (talk) 02:43, 1 February 2013 (UTC)
I agree that we should not redefine the normal meaning of height (which relative to the ground below). However, OSM does not have its own terrain data, so the coaster would be deformed depending on which external terrain data source is being used. With buildings, this problem was circumvented by inventing a new key, building:height, which has a somewhat different definition than height. Perhaps we should at least additionally offer such a tag for coasters?
And while I'm thinking about the topic, wouldn't it be better to add the height information to the nodes? After all, the ways are usually going up or down instead of staying at the same height. --Tordanik 20:40, 30 May 2014 (UTC)