OpenRailwayMap/Mappingwochenende 2014 1

From OpenStreetMap Wiki
Jump to navigation Jump to search

This page contains the summarized and translated protocol of the first OpenRailwayMap Mapping Party in Cologne from 11 to 13 July 2014. It took place at Lokal K in Hackländerstraße 2, 50825 Köln-Ehrenfeld.

Attendees

Protocol

The protocol has been written in an Etherpad, whose chat history might be interesting in future.

Friday, 11 Juli 2014, begin at about 19:15

Introducing eachother

  • ubahnverleih (Consti) from Dresden (Saxony), newbie in railway mapping, drew icons for ORM
  • rurseekatze (Alex): project founder, main developer, railway fan (at Eisenbahnfreunde Niederrhein/Grenzland)
  • rotkelch (Emrah): works for Mentz DV, lives in Berlin, studies Geoinformation there and writes his master thesis about mapping and visualization of complex train stations
    • presents MENTZ GmbH (ex Mentz DV) . They develop software for public transport networks. They try usage of OSM data and have mapped train stations, too.
  • Nakaner (Michael): mapper since 2011 and mainly railways in last months. Uses videos for railway mapping and started icon collection railway-signals. Dual university student (i.e. study + practice at a company) at a surveying office.
  • bigbug21 (Peter): Studies/Studied at traffic faculty of TU Dresden, maps at train rides (using OsmAnd), writes/wrote tutorial for railway mapping and other ORM wiki pages (http://wiki.openrailwaymap.org).

Public Relations Work

see German protocol

Tagging

  • How to make sure that changes at the wiki article of one language may be transferred to the other languages?
    • define a master version (e.g. English)?
    • There is a lack of possibilities to announce translations of a version.

Mapping Techniques

  • Video mapping (Michael): uses car mount for his smartphone and films into back direction (left side of train)
  • Video mapping (Alex): films without any mount using his smartphone. You could film through the back door of a train (if the train has no control car)
  • Video mapping is very time consuming at home but you get a almost everything. It is very suitable if you travel a railway line only once or twice.
  • Mapping using paper (Michael): If a railway line is almost mapped very well, you can take nots of missing details (e.g. exact position of signals or signal numbers)
  • Mapping using numerated GPX waypoints and additional notes on a sheet of paper (Michael) for not-electrified lines.
  • Extra tours of historic trains are very suitable because of low speed and the possibility to lean out of the train through the window. This trains often use railway lines without passenger trains traffic.
  • Photo mapping at train stations to map the single tracks and signals

Everything else

  • Alex has a look which provider the visitors of ORM use. The provider "Deutsche Bahn" (German federal rail company) is at position 7 in ranking. There are also a lot of views from agencies and companies with relation to railway topics.
  • OpenRailwayMap has been mentioned a Hungarian blog.

Samstag, 12. Juli

  • We talked before noon and mapped in the afternoon.
  • Starting about 9:30 a.m: breakfast at Lokal K
  • joining today: Margin-auto (Chris) from Mainz

Everything else

  • We need a better background map. It might be the best solution to develop a new map style together with other projects in light colors.

Mentz DV

  • After breakfast Emrah presents Mentz Datenverarbeitung.
  • founded 1972 in Munich, today offices in Berlin, Stuttgart, Münster
  • develops software, especially for public transport
  • They use usually Navtec data until now. Mentz tries to import OSM data and convert it into their own data format. Completeness is very important for them, but maintaining, too.
  • There have been a couple of discussions with OSM community about how to map something, e.g. if a platform with two tracks might be split (one are per track) or not.
  • OSM data are usually more detailed. A lot of details are interesting to them, e.g. wheelchair usage possibilities, but lit=* tag, too.
  • During modelling some large train stations they developed tagging scheme. Lifts are a complex example. In history, a layer=* tag was used, today they are mapped as areas at different levels which are connected with all floors they serve.
  • Train station Munich East (München Ost) has been mapped by Mentz DV.
  • Mentz DV themself does not want to map, but they themself map for some special projects (usually armchair-mapping).
  • discussion about mapping of platforms
  • discussion about mapping of platform sections (A, B, …). We suggest to map this sections as nodes on the platform edge. Because such sectioning does not only exists inside railway stations, we suggest an addition of public_transport schema. We wonder if this sectioning system also exists in foreign countries (we only know Germany, Switzerland, Austria and France to do so).
  • discussion about modelling route relations if trains of a route stop at various platforms at one station
  • Footway ramps are interesting/important for routing, too. The operators usually do not provide useful information about incline. This is followed by a discussion how to measure and/or estimate incline in-field.
  • How large should be the distance between steps and escalators?
  • Mentz tags the level information at the end nodes of a step. It is not clear if the way itself should get level information, too.
  • Mentz is also interested in escelators, footway connections between car and bicycle parking, ticket vending machines and emergency phones (at stations).
  • Wiki page how Mentz tags/maps. There is also a list of stations they mapped.
  • During discussion we decide that it is useful to have a special tag for railway stations without ticket vending (machines).
  • Presentation of the modelling scheme which was derived from the wiki. We think that it would be useful to have a "How to map Railway" for public transport.
  • Should a couple of vending machines at one place be mapped as one single node or as a couple of nodes? => One node per machine!
  • OSM data will be used in 'DIVA'.
  • Emrah shows an example routing from Vaterstetten to Munich and onwards to Stuttgart (routing in EFA (Elektronische Fahrplan-Auskunft/electronic journey planner) which does use a track through the depot instead of the main tracks west of Munich Central Station). Explanation of the different types of tracks (e.g. usage=main for main lines vs. service=yard for side tracks) => Mentz is interested in tagging the differences between the tracks.
  • A train from Munich to Ulm is another example for wrong routing. It uses from Augsburg-Oberhausen to Westheim (Schwab) a industrial rail instead of the faster main line via Neusäß. We give the advice to use maxspeed information and existing public_transport route relations, too.
  • Everyone wonders why the routing deviates in Esslingen and crosses several tracks their.
  • Outlook: Mentz will offer OSM data its customers in several German states (amongst others Bayern and Baden-Württemberg). Mentz now thinks that OSM should be run by community and not by companies.

Mapping

We went outdoor to map on afternoon. Peter went to "Südbrücke" bridge in Cologne, everyone else travelled the lines Cologne–Euskirchen and Euskirchen–Bad Münstereifel. At about 7:30 p.m. jotpe joined.

Tagging Discussions

  • When should we tag highspeed=yes?
    • discussed criterias: at least 200 km/h (250 km/h), ballastless tracks, train protecting system via cab signalling, mainly used by long distant and high speed trains
    • What about railway line segments which do not comply with this rules, e.g. the last kilometres until a railway hub?
      • The tag should only be used for the railway line segments which can be used with high speed, not the whole railway line which might be longer.
  • platforms as multipolygons
    • tag platform edges on track side with ref=<track_number>. Advantage: You can model serveral stop positions (if a track is used by two or three trains at the same time). Disadvantage: multipolygon relations are complex
  • Does maxspeed=signals make sense on railway tracks?
  • We decide to antiquate it.
  • Normal direction of traffic of a track
    • very useful for routing on tracks
    • We suggest to draw OSM ways in the direction of traffic to make tagging of signals easier for mappers (right-left-problem). But a simple turning of ways is not enough, we need a special tag.
    • JOSM supports automatic turning of tags of ways which have "forward" or "backward" in any key or value.
    • Suggestion for JOSM developers: Warning if turning a way which has railway signals.
    • Tag: railway:preferred_direction=forward/backward/both, both for single-tracked lines ("both" sounds better than "none").
    • Only for main tracks (i.e. all tracks without service=*, no siding or yard tracks)
  • tunnel:name, bridge:name, name
    • According to Key:tunnel, the usage of tunnel:name is being discussed but disputed; the tag is being used about 1,600 times. The wiki suggest the usage of bridge:name for bridges and using name for the name of the road. bridge:name is used about 11,000 times.
    • tunnel:name and bridge:name should be preferred to make street name evaluations easier.
    • Nominatim and common renderers do not regard tunnel:name and bridge:name. We should inform Sarah Hoffmann that she can use tunnel:name and bridge:name, too.
    • Issue ticket about this topic
    • We should do it for wikipedia links the same way. wikipedia:de=<railway_line_article> and bridge:wikipedia:de=<bridge_article>.
    • Remember that there is the possibility to create line and bridge relations.
  • detail improvements signal tagging
    • German "Haltvorscheibe" has been called "Wärtervorscheibe" since 2006
    • Sh 0 -> Hp 0
    • description of "Schutzhaltsignal" in tagging scheme for signal:minor is not true
  • differentiation of (not ending) main and siding tracks etc.
    • Wohl vor allem ein Thema für die Gestaltung der Vorlagen und Dokumentation
    • policy: Trains stop at siding and are parked at yard tracks.
    • We need a schematic track plan for explanation. -> We can draw it on our own.
    • Tagging of safety siding switches
    • Can you see a difference between safety siding switches and switches which connect dead-ending yard tracks? micha_k via phone: No.
    • Can safety siding tracks be differentiated by the use of derailers? => Not at all because trains may use this tracks for shunting (in Germany).
    • We do not know if there is a formal differentiation at all.
    • Deutsche Bahn differentiates between tracks with and without parking interdiction.
    • We decide to tag it as a yard track. This could be applied international easier.
    • We do not create a new tag for safety siding tracks.
  • Darkening of signals
    • This happens in Germany if a cab signalled train which is allowed to drive passes a classic light signal which would show a red halt signal. Showing a red signal would disturb the train driver.
    • We want to create a new tag. Peter will have a look for the right word in his railway dictionary.
    • What about disablement=dark, disablement=Kennlicht, disablement=yes? (Kennlicht is a German word for showing a simple small white light) If we would use this tag, we would not limit ourselfs to the German variation of disabling signals.
  • catch points/trap points => We adjourn this topic indefinitely because we do not need it in Germany. People from other countries who need such a tag should propose a tag at the mailing list.
  • default direction ("Grundstellung) of switches
    • Could be useful for spring switches. The default direction of switches is hard to determine and can mostly only be estimated.
    • We will have a look into the railway dictionary and propose a tag.
  • switch heating
    • could be a great mapping task in winter. ;) Could be interesting for newspapers. Can only be mapped if there is snow.
    • approved tag proposal: railway:switch:heated=yes/no
  • track ballast
    • We should have a better tagging scheme instead of a simple differentiation between ballastless tracks and not-ballastless tracks.
    • We wonder how to handle trams.
    • At the moment there is no interest in trams by the active mappers. We need people how are interested in trams.
  • Third rails below asphalt (another tram topic)
    • Yes, we will care. We have to choose a good value for "electrified", e.g. electrified=ground-level_power_supply, electrifiec=ground_rail oder electrified=middle_rail.
  • tagging of "strange" milestones (e.g. if some milestones are missing or extra because the railway line has been relocated.
    • adjourn because there are a couple of different solutions in different countries for this problem
  • Gauntlet track
    • should be mapped as two separate tracks
    • We should have a tag for the affected tracks.
  • tagging of track segments on which a train has to enable jumpering of emergency break (new and/or long tunnels in Germany)
    • We should not tag this on the way in Germany because we have a tag for the milestone nodes. (The signal for emergency break jumpering is mounted on the last three or four milestones before a tunnel)
  • tagging of track segments with earthed contact line/third rail
    • We have to have a look into the railway dictionary.
    • prior suggestions: railway:lower_pantograph_section=yes/no and/or railway:main_switch_off=yes/no
  • working rules with country prefix
    • We will have a look how they are used at the moment.
  • railway turntables
    • should be mapped as areas
    • different types are not interesting at the moment
  • spring switches
    • There is a tag conflict if you want to map a wye spring switch
    • We agree that spring switches should be tagged with a new tag (railway:switch:resetting=yes) instead of railway:switch=resetting.

Sunday, July 13

We meet at Lokal K at 9:30 a.m. for breakfast and continue tagging discussion. Departures will happen during the day.

Tagging discussion

  • mapping railway stations as node or as area
    • We think that mapping a area from passenger point of view is not necessary. There are stop_area relations. If you calculate a convex hull around all members of this relation, you will get a similar result. That's why stations should be mapped as a single node and with stop_area relations. There is also the railway facility relation whose members the landuse=railway area and the station node are.
  • disused trams and narrow gauge railways
    • key=status, status=value is bad because there are problems with trams and narrow gauge railways.
    • key=value, status=yes is also bad due to incompatability.
    • We do not make railway=disused a abandoned tag.
    • We define disused:railway=rail/tramway/…
    • Comparison_of_life_cycle_concepts#.3Cstatus.3E:.3Ckey.3E_.3D_.3Cvalue.3E
    • Railway#Tag_life-cycle
    • This tagging scheme is compatible to existing tagging.
    • ORM will render ways tagged in this scheme in future. This will make mappers to use it.
  • preserved railways and railways with historic trains
    • How to tag railway lines with historic passenger trains and regularly local freight trains with historic vehicles?
    • How to tag railway lines with heritage status?
    • We would like to abolish railway=preserved because there is no difference to common railway lines.
    • additional tag railway:preserved=yes for railway lines with historic look and which are operated to perserve an old status. These lines are usually used by historic trains.
    • This avoids conflicts between railway=preserved and railway=narrow_gauge
    • Examples:
      • railway line owned by a rail museum which runs historic railbuses on weekend: railway=rail, usage=tourism, railway:preserved=yes
      • Harz Narrow Gauge Railways (historic trains, but regular traffic with freight trains): railway=narrow_gauge, usage=branch, railway:preserved=yes
      • narrow gauge railway line ("Kleinbahn") owned by a museum and only used for tourism: railway=narrow_gauge, usage=tourism, railway:preserved=yes
      • preserved railway line with not-scheduled extra tours and occasional freight trains transporting wood, both using historic vehicles:

railway=rail, usage=branch, railway:preserved=yes

  • speed limits for trams if cars and trams use the same OSM way
    • trams and streets should be mapped as two ways to avoid conflicts of other tags (e.g. ref=*, name=*, operator=*, …)
    • cleans split-up between cars and trams
    • If you map the two-tracked tram line as two tracks, you have to use at least three ways (tram, street, tram)
    • If the tram line is single-tracked, you should either draw two parallel OSM ways or two OSM ways using the same nodes.
    • In Germany tram speed limit and car speed limit should be the same as ruled by §50 (3) BOStrab (Tram Operation Act). There is maxspeed:tram=*, too.
  • How do we tag two signals sharing one pole (e.g. speed limit signs)?
    • We map them as two neighbouring nodes (distant 1–2 m). That's ok because the pole is also a few centimetres thick.
    • We want to keep signal tagging scheme simple.
    • What to do if two different speed limit signals sharing the same pole (e.g. German Zs3 and Lf7 at the same pole for the same direction)?
    • two nodes with a few centimetres between
      • Other mapping approaches would be too complex with the current OSM data model/API v0.6
  • How to tag light signals which show characters (for direction) or digits (for speed limit), e.g. German Zs2/Zs3, if you do not know what they can show?
    • If Zs2v, Zs2, Zs3v or Zs3 signals are mounted at Ks signals, you can see each LED inside and derive the possible characters/digits they can show. You have to look at them from lower right or left (by going by train on a parallel track or as pedestrian)
  • Wie noch nicht bekannte Geschwindigkeits-/Richtungsangaben bei Geschwindigkeits-/Richtungsanzeigern (Zs3/Zs2)?
    • Tip: overexpose your photos
    • does not always work
    • Whe tag a question mark because this can be queried using Overpass API. Fixme tags are not machine-readable.
  • Other ETCS Features
    • adjourned
  • German Checker boards ("Schachbretttafel")
    • English: checkerboard, see Wikipedia
    • We do not translate it verbatimly and use a word with the same meaning. Suggestions:
    • railway:signal:different_position
    • railway:signal:altered_position
    • railway:signal:elsewhere
    • railway:signal:expected_position=left/right says the expected location of signals (i.e. the location of the checkerboard), the real location is tagged at the signal itself.
  • Trapezoir board (Ne1) with exact location
    • Someone has to add a field to the JOSM preset.
  • Special signals used by some branch line companies in Germany in addition to DB signals
    • special signals of Albtal-Verkehrsgesellschaft (light rail company of Karlsruhe)
    • discussion if we tag DB signals railway:signal:main=DE:EBO:abbrevation or DB:abbrevation or DE:DB:abbrevation (DB = German Rail Company, EBO = German Rail Law)
    • Does this discriminate the branch companies against DB?
    • Can signalling system be derived by the operator tag of the track?
    • There are foreign signals mixed with German ones near the border to other countries
    • We tag railway:signal:main=DE-EBO:hp for Hp signal of Deutsche Bahn and railway:signal:main=DE-AVG:hp for a Hp signal of Albtal-Verkehrsgesellschaft whose Hp2 has a little bit different meaning.
      • Attention: This difference only exists on some AVG lines!
    • We disagree to country shortings because there are standardised Hl signals in whole East Europe. That's why they could be tagged as railway:signal:main=OSSD:hl (OSSD was the East Europe railway association)
    • We declare values without prefix as deprecated.
  • Tagging of German tram signals
    • adjourned due to lack of experts
  • arrows at electricity and speed signals
    • adjourned
  • Stop signs for different train lengths
    • We continue using the description=* because there is an uncountable amount of different captions (200 m, Vollzug, VT 642, …).
    • If it is being entered into OSM as it is written on the sign (number with 'm'), it can be parsed, too.
  • name=* for railway line course
    • name only if it is a real name
    • railway line courses like "Köln–Aachen" only as description=*
  • stations which are two or three stations in reality (e.g. Berlin Eastern Station)
    • no problem if the passenger experiences two stations, too. (e.g. Brig SBB and Brig MGB in front of the station)
    • a problem if there is one station from passenger point of view (Köln Messe/Deutz (2 stations + 1 halt) or Berlin Eastern Station (2 stations)
    • We adjourne this topic and will have a look how airport mappers have handled this at Basel-Mulhouse Airport which has a Swiss and a French part.
  • What does belon to landuse=railway?
    • from railway company view: everything including the embakement/cutting
    • It would be nice (in Germany) to know which areas are reserved for railway use.
    • landuse is the use of land and the embakement is not used
    • Mappers who are no railway expert should be able to map this landuse areas. -> catenary masts as outer border
    • at stations: including stations and other operational buildings
  • Should platforms still be tagged with railway=platform?
    • Problem: osmfilter does not support tag combinations (public_transport=platform + train=yes). If we would also import all public_transport=* objects into the database at the ORM server, the database would become too large.
    • We differ between infrastructure (railway*=*) and usage (public_transport)
  • railway=stop
    • as above: We differ between infrastructure (railway*=*) and usage (public_transport)
    • need for freight stations
    • not every track of a station has a public_transport relation
    • needed for routing
  • We need railway line relations too connect railway=station nodes, railway=junction nodes etc. in one relation. This makes it possible to create Wikipedia-like line tables.
  • Types of platforms
    • Who needs this information?
    • maybe in future, but nood need at the moment
  • remove on_demand at stop_positions, stations and halts?
    • on_demand yes/no is an attribute of the traffic, not of the infrastructure
    • on demand stops should get a special role in route relations: stop_on_demand as stop_entry_only and stop_exit_only
    • We agreee mapper999.
  • A bot unifying decimal separators
    • We agree a bot usage and will ask Oli-Wan if his bot can do this.
    • a future QA tool?
  • Find equivalences to Mirko Küster's railway tagging scheme
    • will be done via mailing list
  • migration of all Mirko Küster tags to ORM scheme
    • should be done manually using Overpass API
  • changing tag of railway:signal:main:function=between -> intermediate
    • We will change JOSM preset and will do an Overpass-based mass edit.
  • railway:signal:electricity -> railway:signal:catenary
    • electricity refers to all types of electricity, catenary only to contact lines -> We do not migrate.
  • structure_gauge vs. loading_gauge
  • signal box relations: railway=interlocking instead of railway=controlled_area?
    • adjourned due to missing language knowledge
  • signal orders (type vs. order)
    • exmaples:
      • electricity signals: railway:signal:electricity=el7, railway:signal:electricity:type=power_off
      • snowplow signals: railway:signal:snowplow=ne7, railway:signal:snowplow:order=up/down
    • We migrate to type to remove the difference.
  • captions on signal signs
    • railway:signal:*:description=* is being used at stop signs and railway:signal:*:caption=* at level crossing signs
    • We migrate to caption because the description of stop signs is as important as the caption of level crossing signs.

Next Meeting

  • should be located more centrically in Germany or in Eastern Germany (Eisenach/Erfurt?)
  • should use a large holiday flat to reduce distances ("living and working consolidated")
  • short distance to Frankfurt would be nice to be able to invite a employee of DB Netze (railway infrastructure company of Deutsche Bahn which is locate in Frankfurt)

Adjourned to Next Meeting

  • everything which is marked as adjourned
  • railway crossings and crossings for passengers inside stations
  • Section "Other Tagging" of agenda
  • signs at signal mast (red-white-red etc. in Germany)
  • signal Hp 3 of KVB (tram and light rail company of Cologne)
  • different maxspeeds for different types of vehicles: DE_talk:OpenRailwayMap/Tagging#Geschwindigkeit_f.C3.BCr_bestimmte_Fahrzeugtypen
  • other German tagging topics

Rückblick

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