OpenRailwayMap/Aktiventreffen 2014 2

From OpenStreetMap Wiki
Jump to: navigation, search
Available languages — OpenRailwayMap/Aktiventreffen 2014 2
Afrikaans Alemannisch aragonés asturianu azərbaycanca Bahasa Indonesia Bahasa Melayu Bân-lâm-gú Basa Jawa Baso Minangkabau bosanski brezhoneg català čeština dansk Deutsch eesti English español Esperanto estremeñu euskara français Frysk Gaeilge Gàidhlig galego Hausa hrvatski Igbo interlingua Interlingue isiXhosa isiZulu íslenska italiano Kiswahili Kreyòl ayisyen kréyòl gwadloupéyen Kurdî latviešu Lëtzebuergesch lietuvių magyar Malagasy Malti Nederlands Nedersaksies norsk bokmål norsk nynorsk occitan Oromoo oʻzbekcha/ўзбекча Plattdüütsch polski português português do Brasil română shqip slovenčina slovenščina Soomaaliga suomi svenska Tiếng Việt Türkçe Vahcuengh vèneto Wolof Yorùbá Zazaki српски / srpski беларуская български қазақша македонски монгол русский тоҷикӣ українська Ελληνικά Հայերեն ქართული नेपाली मराठी हिन्दी অসমীয়া বাংলা ਪੰਜਾਬੀ ગુજરાતી ଓଡ଼ିଆ தமிழ் తెలుగు ಕನ್ನಡ മലയാളം සිංහල ไทย မြန်မာဘာသာ ລາວ ភាសាខ្មែរ ⵜⴰⵎⴰⵣⵉⵖⵜ አማርኛ 한국어 日本語 中文(简体)‎ 吴语 粵語 中文(繁體)‎ ייִדיש עברית اردو العربية پښتو سنڌي فارسی ދިވެހިބަސް

This page contains the summarized and translated protocol of the second OpenRailwayMap Meeting in Bad Nauheim near Frankfurt (Main) from 24 to 26 October 2014.



There original protocol was written in an Etherpad document.

Friday, 24. October 2014


  • ballastless track, tagging of track bed structure
    • There seems to be no need at the moment. If you don't think so, invent a tag and discus it at OpenRailwayMap mailing list.
    • There are still hundreds of kilometers without maxspeed tag. Go outside and map.
  • tunnel relations, tunnels with two tubes
    • Tunnels should be mapped as it happens with roads, i.e. use tunnel relations.
    • Tunnel relations are still mentioned in tagging scheme.
  • light rail
    • Light rails are rails which are neither a "heavy" rail nor a tram.
    • only passenger trains, no freight trains
    • connects cities and towns in their agglomeration
    • simpler construction methods (curves, isolation from cars and waiting passengers) than railways but more complex construction methods than trams
    • largely separated from car traffic, level crossings are better secured than those of trams
    • Trains are high-floor while trams are usually low-floor. This should not be a criteria because this would made RNV train near Mannheim/Heidelberg/Weinheim to trams although they are trains by law and their workrules.
    • light rails run from city to towns in agglomeration, subway/tram runs inside the city
    • There cannot be sharp criterias.
    • tram stops look like bus stops, light rails have real halts/stations
    • The network of one operator should be tagged homogenous. -> Don't switch from railway=tram to light_rail every kilometer. :-)
    • List of Criteria:
      • Light rails do not usually share their tracks with car lanes.
      • Trams (old vehicles excepted) are usually low-floor, light rails are usually high-floor.
      • Trams do not have underground tracks.
      • Overhead railways are no trams.
      • If the workrules are the (almost) same as for heavy railways, it is a light rail and no tram.
      • Trams do not have elctric rails beside the track.
      • It does not matter if the network has connecting tracks to a heavy rail network (e.g. national railway company)
      • Light rails usually have train protecting systems of a lower level than heavy rails.
      • Trams run on-sight, light rails usually have signals. That's why driverless operating does only happen on light rails and not on trams or heavy rails.
      • light rails are faster than trams (because of separation from car traffic, level crossings, signals etc.)
      • Subways usually run underground and are totally separated from car traffic and pedestrians on overground sections. They are almost free of level crossings.
  • Heritage railways
    • Alex proposes to deprecate railway=preserved because it is in conflict with railway=narrow_gauge and there is no difference to railway lines where default trains are historic vehicles. He suggest to replace it by railway:preserved=yes + historic=railway (from DE:Historical_Objects/Karteneigenschaften)
    • We agree Alex's proposal.
  • railway=narrow_gauge
    • This tag is used very often. Its sole use is a rough differentiation between railways with the default gauge of a country and all railway lines whose gauge is narrower.
    • After a discussion, we think that "narrow_gauge" is an outdated synonym for rail. We think that changing tagging of this OSM ways is not useful. Data users should handle railway=narrow_gauge like railway=rail and should use gauge=* as basis of decisionmaking if necessary.
  • Interlaced tracks/gauntlet track
    • We waive to use relations for mapping and suggest to tag all involved tracks with railway:interlaced=yes.
    • We have to wait for the first routing application to evaluate the usability of this information.
  • Passing not allowed due to too small track space
    • railway:passing_prohibited=left/right/yes/both if passing is not allow with the track on the left/right/any/both neighbouring tracks
  • facilities to derail
    • Derailers should be tagged railway=derail.
    • We should define (railway:derail=typ of derailer?) which describes what type of derailer it is, e.g. wedges (used in Germany), derailers which look like switches and can be found in UK or …
    • This tag can easily added by additional values. That's why we do not have to invent tags for other types of derailing facilities now.

Saturday, 25. October 2014


  • industrial tracks
    • We allow the combination of service=* and usage=industrial to allow a differentiation of siding tracks of industrial railways from siding tracks of normal railways.
  • working_rules
    • The tag is called workrules=*
    • Usage should be like this: workrules=<country_abbrevation>:<abbrevation or full name of working rules law>
    • country shorting should be the one from ISO 3166-1. If working rules are different depending on county/state, we suggest to use abbrevations of ISO 3166-2.
      • Example: AT: (Austria) or DE-BY (Bavaria, a German state)
    • We use abbrevations for working rules acts in Germany. Following abbrevations are used: EBO (Eisenbahn-Bau- und Betriebsordnung/Working Rules Act for Railways), BOStrab (Working Rules Act for Trams), ESBO (Working Rules Act for Narrow Gauge Railways), …
  • Track class
    • Meter load (maximum weight per metre). You can use meter_load=<allowed metre load in tons/metre>
      • weight_per_metre could describe the weight of rail profile per metre.
    • Axle load: axle_load=<maximum allowed axle load in tons>
    • You can still use railway:track_class=*.
  • Different speed limits for different vehicles
    • Solution 1: The highest speed limit is mapped as maxspeed=* and every other speed limit is mapped as maxspeed:<variant>=*
    • Solution 2: We map the default speed limit for "default traction vehicles" as maxspeed=* and every exception as maxspeed:<special_type>=*
      • If a railway line is mapped as default railway, I expect that maxspeed=* is speed limit for default vehicles; all other vehicles with special equipment (eddy current break, low weight, strong breaks) are exceptions and should be mapped as maxspeed:<special_equipment>=*.
      • wenn eine Strecke als Vollbahn eingetragen ist, dann erwarte ich, dass maxspeed=* die Geschwindigkeit für die Vollbahnfahrzeuge angibt;
      • Problem: What's "default"? Linienzugbeeinflussung (aka LZB, Continous Train Control, a German train protection system allowing speed over 160 km/h)? Ability to tilt? Eddy current break?

Electric Power Supply

  • Catenary masts
    • There is a need to map them if you map a power line (electricity for trains) which is mounted ontop of catenary masts. power=pole and power=tower are not suitable. Without any tag, KeepRight users might tag them with wrong tags (tower or pole) soon.
    • Not railway=* because electric ships and trolleybuses also have catenary masts.
    • tag for catenary masts:power=catenary_mast.
  • Feeding of contact line
  • types of mounting power lines on catenary masts: adjourned
  • Jump separators of catenary lines using switches
  • Tagging of protective sections
  • ground level power supply

Operating Sites

  • manned blockposts and crossing boxes
    • manual operated blockposts are mapped as signal boxes. Because blockposts and signal boxes have a different numbering scheme, they can be differed.
    • Crossing boxes for crossing attendants: railway=crossing_box
  • Blockposts (manned and unmanned)
  • Sidings (Anschlussstellen and Ausweichanschlussstellen)
    • We doubt if there is a difference between sidings, where trains can be "locked in" and allow other trains to pass the siding, and sidings where trains cannot be locked in outside Germany.
    • railway=spur_junction
  • operating times of signal boxes, crossing boxes etc.
  • Differentiation between subway stations, light rail stations and real railway stations
    • Using relations makes no sense.
    • station nodes do not have to be member of an railway OSM way. That's why these stations cannot be differed by the way the node belongs to.
    • We will ask in forum or a mailing list to use a new tag for subway stations – railway=subway_station like railway=tram_halt for tram stops.
    • We need a different tagging to allow renderers to draw different icons.
  • Stations which are two or three stations in reality
    • Mapping this stations by two or three station nodes works in Berlin. stop_area relations show where users can change from/to.
    • subsidary stations ("Bahnhofsteile") are mapped as independent stations and connected to there mother station using relations.
  • railway=stop and how to make station information available for routing applications
    • If a routing application calculates a route from A to D, it can get the stations B and C the train passes by looking at all nodes, which belong to the ways of the route.
    • railway=stop should be tagged on following nodes:
      • Stations and halts (wether with or without passenger trains stopping there): one node per main track, no nodes of siding tracks. If platforms are next to siding tracks every platform track gets a railway=stop, too.
      • Junctions and sidings: one node shortly before (if driving to the junction) the switch(es)
      • Crossovers: one node per track shortly before the crossover
      • Blockposts: one node per track
    • Node should be tagged with railway=stop even if they are tagged with {{Tag|public_transport|stop_position} because freigt train routers should not have to look on things they do not need.
  • platforms with two different surfaces
    • Example: Trier-Quint, Germany (OSM)
    • If it is mapped as area, it should be mapped as two touching areas sharing nodes.
  • Station abbrevations assigned from foreign railway companies
    • This foreign abbrevations are handled like foreign names. Use railway:ref=abbrevation for the reference abbrevation assigned by the station operator. Use [[Key:railway:ref:<company abbrevation>|railway:ref:<company abbrevation>]]=<abbrevation> for abbrevations assigned by foreign companies.
    • If a station has two equal operators (e.g. commonly operated border stations like Brenner Pass Station) should be tagged railway:ref=<abbr1>/<abbr2>
  • owner changes inside a country and at its border
    • In the last months mappers have used railway=owner_change for a change of operator (e.g. DB/AVG, DB/HGK, …)
    • That's why we introduce railway=border for operator changes near country borders between two national railway comapanies.
  • Platform sections (A, B, C, …)
    • Explanation: This image shows section B on platform 2/3 in Günzburg station
    • If you only know the place of the sign but not the length of the section, you should map the sign as a node of the platform edge. If you know how long the section is, you can split up the platform edge way and tag the information on the platform edge way. You have to use mulitpolygons for platforms in both cases.
    • railway:platform:section=A/B/C or North/South

Level Crossings


Sunday, 26. Oktober 2014


  • Signals which do not exist in whole Germany.
    • Hp 3 of Cologne Transport Authority (Kölner Verkehrsbetriebe/KVB): railway:signal:combined:states=.
    • Please use <country abbrevation>-<company>:<signal name or abbrevation> instead of <country abbrevation>-<signal act>:<signal name or abbrevation>

Other Matters

  • harmonization of operator values
    • We think that legal form (AG, GmbH, Ltd, Inc., …) should not be tagged because it can change quickly and contains no information.
    • A discussion with more participants (forum, mailing lists) should answer the question if we tag operator=DB Netz (Deutsche Bahn Infrastructure part) or operator=Deutsche Bahn.
  • Gaps between milestones (if railway lines have been shifted and are shorter/longer afterwards)
    • as a nod (like milestones) on the main tracks of the line using missing_length=<value in metres>
    • This gaps also exist on rivers and roads. We should look how it his handled there.
  • Sidings (if companies are connected with railway network)
    • Landuse is often not mapped very well and not suitable for is-in queries.
    • Tagging the siding tracks with name=Siding Biscuit Factory Ltd. is no good idea because it is no proper name.
    • We suggest to tag the object, which represents the company, which has an own siding, with railway_link=yes.
    • Wir empfehlen, die Eigenschaft, das ein Unternehmen einen Gleisanschluss hat mit railway_link=yes an das Objekt zu taggen, das die Firma repräsentiert.
  • Interlocking range relations
    • Alex proposes to switch from railway=controlled_area to railway=interlocking.
    • We agree this proposal.
  • Defect detectors
  • stations/halts with infrastructure to be request stops (e.g. a button for waiting passengers) is a property of the lines running there, not of the infrastructure itself.
  • historic=*: Should not only cover station buildings, it should cover whole historic railway-related stuff.


A short summary of the meeting can be found in the OpenRailwayMap blog.