Hallo Zusammen,
wir werden die Tags wieder entfernen.
Viele Grüße
Tracy
Am 24. April 2015 um 12:00 schrieb <
openrailwaymap-request(a)openrailwaymap.org>:
> Send Openrailwaymap mailing list submissions to
> openrailwaymap(a)openrailwaymap.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.openrailwaymap.org/lists/listinfo/openrailwaymap
> or, via email, send a message with subject or body 'help' to
> openrailwaymap-request(a)openrailwaymap.org
>
> You can reach the person managing the list at
> openrailwaymap-owner(a)openrailwaymap.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Openrailwaymap digest..."
>
>
> Today's Topics:
>
> 1. Re: priority-Tag (danmey(a)web.de)
> 2. Re: priority-Tag (Rolf Eike Beer)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 23 Apr 2015 23:17:17 +0200
> From: danmey(a)web.de
> To: openrailwaymap(a)openrailwaymap.org
> Subject: Re: [openrailwaymap] priority-Tag
> Message-ID: <5539615D.5040500(a)web.de>
> Content-Type: text/plain; charset="windows-1252"; Format="flowed"
>
> Hallo!
> Ein altes Thema ein bisschen anders: In Ostwestfalen-Lippe gibt es
> reihenweise *nodes* mit priority=primary: http://overpass-turbo.eu/s/82J
> Fl?chendeckend an alle nodes von railway=rail.
> Kann das weg? Oder steckt Sinn dahinter?
> VG, Daniel
>
>
>
>
> Am 06.11.2014 um 10:00 schrieb Merle Ro?ner:
> >
> > Hallo,
> >
> > inzwischen ist wieder einiges bei uns passiert:
> >
> > Wir werden jetzt die Relationen an den Schienen auswerten und
> > dementsprechend nicht mehr den Tag priority setzen.
> >
> > Viele Gr??e
> >
> > Merle von MentzDV
> >
> >
> >
> > _______________________________________________
> > Openrailwaymap mailing list
> > Openrailwaymap(a)openrailwaymap.org
> > http://lists.openrailwaymap.org/lists/listinfo/openrailwaymap
>
>
Hello everybody,
for rendering, it would be nice to have any information about the
importance of a station/halt. With this information, the renderer could
render captions in different zoom levels or font sizes or decide which
label is rendered in cases of collision.
Currently we have the tag railway:station_category=1-7 for mapping the
German railway station category [1]. But this is very german-specific,
so we should think about a way to tag the importance of a station using
generic rules that are independent from any country-specific categories.
Should we use the existing tag railway:station_category=* and translate
the German definitions, so that they can be applied internationally?
This would have the advantage that German stations, that are already
tagged with the existing tag, do not require any retagging. But using
just numeric values is not so
Or should we create a new tag a tag like railway:station_importance=*
with some category values such as local/regional/international/... and
leave the existing railway:station_category=* tag for mapping
country-specific categories?
Any ideas?
Regards
Alex
[1] http://en.wikipedia.org/wiki/German_railway_station_categories
Hallo,
beim Erstellen des Schweizer Taggingschemas habe ich ein paar Signale
ausgelassen, an deren Existenz ich Zweifel hatte oder bei denen ich mir
mit dem Verständnis schwer tat. Ein solcher Fall war das
Telefonrufsignal. Die Fahrdienstvorschrift beschreibt es so:
> Obligatorische Verbindungsaufnahme vom Lokführer zum Fahrdienstleiter
> bei haltenden Zugfahrten und Rangierbewegungen
Auf Drehscheibe-Online habe ich dann nachgefragt und mir wurde mit einem
tagesaktuellen Bild bestätigt, dass es dieses Signal noch in Basel
Rangierbahnhof gibt. Verwendet wird es aber nicht mehr (zumindest bei
der SBB in Basel Rangierbahnhof).
http://www.drehscheibe-online.de/foren/read.php?106,7364538
Ich schlage folgendes Tagging vor:
railway:signal:phone=CH-FdV:277
railway:signal:phone:form=light
railway:signal:phone:states=CH-FdV:277;off
Es würde daher also der neue Signaltype "phone" für Signale im
Zusammenhang mit der kabelgebundenen Kommunikation geben. Bisher gibt es
schon "radio" für Signale des Zugfunks (z.B. Zugfunk-Kanaltafel).
Viele Grüße
Michael
--------------------------------
Hi,
at the moment I am finishing a railway signal tagging scheme for
Switzerland. [1] There is one signal there which I cannot assign to a
existing signal type (e.g. main, distant, speed_limit, radio, …) – the
phone call signal (German "Telefonrufsignal"). It flashes if the staff
at the signal box wants to call a train driver. He has to leave his
locomotive and talk to the signal box staff using the next phone.
Although Switzerland has GSM-R (or analogue radio at some lines) and
public cell phone networks as an alternative, this signal still exists
(e.g. at Basel Yard Station). A Swiss train driver told me that he has
not seen it flashing for a long time.
http://www.drehscheibe-online.de/foren/read.php?106,7364538,7365464#msg-7...
I suggest following tagging:
railway:signal:phone=CH-FdV:277
railway:signal:phone:form=light
railway:signal:phone:states=CH-FdV:277;off
This would introduce the signal type "phone" parallel to the existing
"radio". phone should be used for cable-bound communication, radio for
GMS-R etc.
Best regards
Michael
[1] English translation will follow soon. It should be an example
tagging scheme documented both in German and English.
https://wiki.openstreetmap.org/wiki/DE:OpenRailwayMap/Tagging_in_Switzerland
--
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)
Dear OpenRailwayMappers,
recently I had a look at the marvellous openrailwaymap. I am astonished by the
many different classes for railway lines. Although commuting everyday by train,
I never imagined so many different track types.
One thing confused me, maybe you can enlighten me. Why is the 9701
"Brockenbahn" running to the top of the highest peak in the Harz mountains
neither "Schmalspur" nor "Museumsbahn" but a "Überleitgleis". Even more
confusing, at some stations the parallel tracks are tagged as
"Schmalspurbahn" (e.g. Schierke).
According to the website of the "Harzer Schmalspur Bahnen"
http://www.hsb-wr.de/mehr-erfahren/streckennetz/interaktives-streckennetz/
the "Brockenbahn" and the "Harzquerbahn" are claimed to be "Schmalspurbahnen".
thanks
robert
Dear ORM community,
the Dutch rail infrastructure provider ProRail has a lot of data available in the public domain, which makes the Dutch situation quite different than the German one (I heard DB-netz is not very willing to share data). To make use of the data I'm working on quite a large import proposal: named the ProRail import. As described at the wiki-link, it will be done in several slices: one per object category (e.g. platforms, signals, turnouts). I will inform this mailing list about each slice, before proposing it to the imports mailing list.
The first slice is on milestones. The milestone import already has it's own wiki section within the ProRail import wiki. You can read all import details there. The tagging, however, is very important to ORM. This because the milestone placement in the ProRail database is quite in another way than is described in the ORM tagging scheme. Quote: ''They should be entered as nodes on the tracks themselves. If the railway line has more than one track, it should be entered on each track.'' I personally object to such an approach, because it neither encompasses the theoretical nor practical situation. The theoretical situation is placement of milestones directly on the reference ribbon, along the centre of a railway line. The practical situation, however, is placement of signs perpendicular from the reference ribbon (note that this can create other signs intervals than described on the signs).
Railway companies mostly use the reference ribbons in their maps and systems, because those values are more precise. I would propose to make mapping of the theoretical and practical locations of milestones possible, by allowing these systems on the wiki. Importing the Dutch milestones automatically would be impossible without such permission.
Your thoughts on the milestone import and milestone locations are highly appreciated. Thank you in advance.
Best regards,
Jeroen
(English version below)
Hallo,
auch wenn es in den letzten Monaten keine neuen Blogartikel zu lesen
gab, ist die Entwicklung nicht stehen geblieben. Wir freuen uns, mit
Eike (Dakon) einen weiteren Entwickler im Team begrüßen zu können.
Seit dem FOSSGIS-Hackweekend im Linuxhotel im Januar wurde der
Signallayer um weitere deutsche und österreichische Signale ergänzt. Es
werden jetzt Kreuztafeln (So 106), Rangierhalttafeln (Ra 10) bzw.
Verschubhalttafeln und Wartezeichen (DB Ra 11/11a/11b) bzw. Wartesignale
gerendert. Diese drei Signale haben den Vorteil, dass sie in Deutschland
und Österreich ähnlich (oder gar gleich aussehen), sodass man dieselben
Icons verwenden kann. Bei den deutschen Signalen gab es Zuwachs in Form
von Blockkennzeichen (mit Anzeige der Blocknummer), Ks-Signalen mit
Zusatzlicht (bei verkürztem Bremswegabstand oder Wiederholern) und
Sv-Signalen. In der Ansicht der Höchstgeschwindigkeiten werden
stillgelegte und im Bau befindliche Strecken nun ebenfalls angezeigt,
zur Unterscheidung von den übrigen Strecken allerdings etwas heller. An
Brücken und Tunneln werden statt des mit name=* erfassten Streckennamens
bevorzugt die mit bridge:name oder tunnel:name angegebenen Tunnel- oder
Brückennamen dargestellt. Bei spurgeführten Verkehrsmitteln wie etwa
Schwebebahnen, bei denen es sich nicht um Eisenbahnen handelt, werden
Brücken und Tunnel nun nicht mehr dargestellt. Dies hatte in der
Vergangenheit zu unerwarteten Kartendarstellungen geführt.
Eike hat zwischenzeitlich das Rendering von Stellwerken verbessert und
sie in den thematisch passenderen Layer der Signale und
Sicherungssysteme verschoben. Stellwerke werden jetzt mit Namen in grün
gerendert. Damit auch als Gebäude erfasste Stellwerke angezeigt werden,
waren Korrekturen am verwendeten Renderer node-tileserver notwendig. Im
Infrastrukturlayer werden nun Drehscheiben und Schiebebühnen angezeigt.
Der beste Datensatz nützt aber nichts, wenn die Datenqualität niedrig
ist. Um die Qualität zu steigern, haben wir weitere Abfragen in den
Validations-Regeln für JOSM ergänzt. Unter anderem wird jetzt geprüft,
ob Gleisnummern als solche getaggt sind (und nicht als Namen) und ob das
Tagging eines Signals logische Fehler enthält. Ebenfalls werden die
Objekte auf diverse veraltete und nicht unterstützte Tags geprüft.
Auch in der JOSM-Vorlage gab es einige Änderungen: So wurden Einträge
für Zugdeckungssignale und ETCS-Haltetafeln (Ne 14) hinzugefügt und
einige neue Icons ergänzt. Die Signale wurden mit dem neuen
Länder-Betreiber-Präfix versehen. Außerdem wurden einige Einträge auf
neues Tagging umgestellt, das im Rahmen der Treffen in Köln und Bad
Nauheim vereinbart wurde. Ebenfalls wurden kleinere Syntaxfehler behoben
und die Einträge ins Englische übersetzt.
Auf der Webseite selbst gab es ebenfalls kleine Neuerungen: Es ist nun
möglich, die Karte auch ohne Hintergrundkarte zu betrachten. Außerdem
findet die Suche nun auch (Ausweich-)Anschlussstellen, die mit
railway=spur_junction getaggt sind. Daneben ist die Webseite nun auch in
Türkisch verfügbar, vielen Dank dafür an Kudret Emre.
Noch nicht ganz fertig implementiert sind Icons für Bahnübergänge im
Infrastruktur-Stil, die Darstellung von Gleisnummern, Vorsignaltafeln in
verkürztem Bremswegabstand, deutschen Zs 3(v)-Lichtsignalen und
Fahrleitungssignalen (in Deutschland und Österreich, da die Signale
identisch sind).
Wir bedanken uns bei der Geofabrik aus Karlsruhe, auf deren
OSM-Hackweekend im Februar Alex und Michael einen Teil der oben
genannten Funktionen implementiert haben.
Neben dem Fertigstellen der noch offenen Änderungen stehen für die
nächste Zeit eine Überarbeitung der Legende, Aktualisierungen und
Ergänzungen bei den Übersetzungen und eine Neugestaltung der Webseite
an. Daneben wird der Signallayer schrittweise um österreichische und
niederländische Signale erweitert. Die Suchfunktion soll künftig auch
stillgelegte, abgebaute, im Bau befindliche und geplante Betriebsstellen
zurückliefern. Touristisch und militärisch genutzte Strecken, die
momentan nicht auf der Karte angezeigt werden, sollen in der
Kartenansicht berücksichtigt werden.
Gruß
Alex
***
Hi everybody,
even if there was no new blog article in the last few months, the
development has not stopped. We are happy to welcome Eike (Dakon) as a
new developer in our team.
Since the FOSSGIS Hack Weekend in January, the signalling layer was
extended by several German and Austrian signals. Now it shows distant
sign("Kreuztafel"), shunting stop signs ("Rangierhalttafel" /
"Verschubhalttafel") and shunting signs ("Wartezeichen" /
"Wartesignale"). The advantage of these three signals is that they are
almost equal in Germany and Austria, so that we can use the same icons.
The German signals were extended by block marker signs
("Blockkennzeichen"), repeated or shortened light signals type Ks and
combined signals type Sv. The maxspeed layer now also shows disused and
construction tracks, which are rendered in lighter colours to make them
distinguishable from active railroads. In infrastructure layer, bridge
and tunnel names tagged with bridge:name and tunnel:name are favoured
over track names. Bridges and tunnels at tracks such as monorails, which
are not traditional railroads, are not rendered any more. In the past
this caused unexpected results on the map.
In the meantime, Eike improved the rendering of signal boxes and moved
them to the more appropriate signalling layer. Signal boxes are now
rendered in green with names. Some bugfixes at node-tileserver were
necessary to render signal boxes tagged as buildings. The infrastructure
layer now also visualizes turntables and traversers.
To improve the data quality, more validation rules for JOSM were added.
These new rules check e.g. whether track numbers are tagged correctly
and not as names or if signals have logical tagging issues. Features are
also checked for various deprecated and not supported tags.
There were some changes of the JOSM presets, too: Items for platform
section signals ("Zugdeckungssignal"), ETCS stop signs (Ne 14) and some
new icons were added to the German preset. The signals were retagged
with the new country-operator-prefixes. Tagging changes, that were
decided at the meetings in Cologne and Bad Nauheim, were applied to some
items. There were also some bugfixes of syntax errors and translations
to English.
There are also some new features on the website: Users can view the
railway overlay without any basemap. The search now also finds spur
junctions tagged as railway=spur_junction. Kudret Emre added a Turkish
translation of the website, thanks a lot!
Some new features such as icons for crossings in infrastructure layer,
rendering of track numbers, German distant signs with shortened braking
distance, German light speed limit signals and catenary signals (in
Germany and Austria) are still under construction.
We thank Geofabrik from Karlsruhe for hosting the OSM Hack Weekend in
February, where Alex and Michael implemented a part of the new features
mentioned above.
Beside finishing the pending changes, improvements of the legend,
updates and additions of the translations and a redesign of the website
stand on our todo list. The signalling layer will be continously
extended by Austrian and Dutch signals. The search will be improved, so
that it returns also disused, abandoned, constructed and proposed
stations. Tracks used for tourism or military purposes, which are
currently not rendered on the map, will be visualized, too.
Regards
Alex
Hallo,
inzwischen ist wieder einiges bei uns passiert:
Wir werden jetzt die Relationen an den Schienen auswerten und
dementsprechend nicht mehr den Tag priority setzen.
Viele Grüße
Merle von MentzDV
Good evening Michael,
The advantage is that we have data available for the entire Netherlands until the milestones are mapped at their final location.
That looks like an advantage but it is a big disadvantage. It is never a good idea to import data into OSM and let the community fix it.
personally, I regard this differently; why would we only accept a final form of data, while we are currently not having any Dutch milestone data at all? To illustrate this: OSM is actually based on importing data which was afterwards improved. As an example: in the Netherlands all meadows and residential areas for example have been imported by AND. These were welcomed as a country-wide basis because there wasn't any data on this subject at all by then. Nowadays, we are still improving and detailling that data through Bing and other sources.
Imagine the other method: not accepting any meadow imports for example and ask all mappers to map meadows according to Bing. That would take years, while still having blank spots. A nice example of such a contradiction can be found at the border of the Netherlands with Nordrhein-Westfalen: http://www.openstreetmap.org/#map=11/52.2635/7.1727.
Just have a look at all these TIGER data garbage (stevea as railway mapper could teach you a lesson – he is fixing all these data in California). The TIGER import imported road data of a low quality over the whole US. Up to now about 95 % (rough estimation) has not been fixed. The import took place about 6 to 8 years ago! There are several other imports which did the same – their data has not been fixed yet.
A nice example of a big bad import indeed. I think it is not justified to compare such a poor and large import with my current proposal though:
A few weeks ago, I attended a guest lecture on mapping ProRail's infrastructure. Fugro explained how they did it with a standard deviation of 15 mm's. That very data is the source for my import proposal, which makes my import data somewhat 500 times more precise than the TIGER import data. When comparing with the current OSM data, this means a deviation of max. 2 metres with the current OSM data, which I consider as very acceptable. If you wish, please consider the attached lecture nodes at page 21 and the attached JOSM screenshots (blue dots are ProRail data and grey is OSM rail).
TIGER consists of many seperate changesets. When I first attempted the milestone import, it was possible with just one single changeset. This makes it very easy to revert if ever considered necessary.
Another safety measure is the tag combination that I'll add to it, which makes it easy to remove parts of the dataset by using XAPI. This enables mappers that are adding more precise data, to remove old data parallel to theirs with some simple mouseclicks.
TIGER consists of a heterogeneous network of ways with even some weird drawing styles for seperated lanes. My proposal is very simple and contains just nodes with homogeneous properties (all nodes the same tags).
Like described above, the import will not intervene in existing data, because there is literally just two milestones in the entire country (like shown in the attached overpass).
Shortly, if you propose an import at Imports list as you are doing here now, your proposal will definitely fail.
Since I already tried this before, I am well aware of the standards of the Imports mailing list. Thank you for your concerns though; it's members are (with reason) very strict.
2015-04-14 01:47 JJJ Wegdam wrote:
Milestone systems and signal locations are used for many purposes, like defining and finding maintenance or research locations, but also capacity-calculation. Especially the milestones; I simply know that ProRail employees would greatly appreciate a milestone map that works well at their mobile phone. Railmaps does not and ORM does. I promised them to make this work as soon as I could. This is also why I tried the milestone import before.
If people are interested in having milestons in OSM why don't you ask them to help them tracing from an WMS layer.
Because all interested people that I am aware of are working in the rail sector. Because of competition between the companies, they are all interested in either improving their own services or welcoming open source services made by others.
You can set up a WMS service using a database like PostGIS + a server like Mapserver or Geoserver. I will try to set up such a service (it's not much data, i.e. it does not need a powerful server) at my private server but you might have to wait a few days.
I'm unaware of what WMS precisely is and how it works, but it sounds nice. I could provide you with the shapefiles and accompanying QGIS renders?
Kind regards,
Jeroen
Hallo,
da ich bei meinem "mechanischen" (haha [2]) Edit viele Signale sichte,
fallen mir Taggingfehler in nennenswerter Zahl auf. Einen Teil kann ich
korrigieren, weil die Mapper note=* getaggt haben, einen Teil aber auch
nicht. In letzteren Fällen habe ich die Signale oft nicht auf das neue
Präfix umgetaggt (damit sie später noch auffallen) und die schuldigen
Changesets kommentiert.
So wie es unter präfix-losen Signalen Fehler gibt, dürfte es diese
Fehler auch bei präfix-habenden Signalen geben. Wer Zeit und Lust hat,
kann mal mit der Overpass-API auf Fehlerjagd gehen. Die Abfragen geben
XML mit Metadaten aus, d.h. über Export -> JOSM könnt ihr euch die
Abfrageergebnisse direkt in JOSM laden.
(1) Signalnummern, die als railway:ref=* erfasst sind. Beispiel-Abfrage:
http://overpass-turbo.eu/s/8JM
(2) Signale, die sowohl mit railway:signal:main!=DE-ESO:hp als auch
railway:signal:distant=* getaggt sind. Gegebenenfalls andere
Hauptsignal-Vorsignal-Mischungen mit Ks- und Hl-Anteil ausprobieren.
http://overpass-turbo.eu/s/8JN
(3) Ähnlich (2), aber die Kombination railway:signal:main!=DE-ESO:hp und
railway:signal:combined=*.
(4) Ähnlich (2), aber die Kombination railway:signal:distant=* und
railway:signal:combined=*. (Geht in der Realität einfach nicht, da das
Mehrabschnittsignal schon eine Vorsignalfunktion hat)
(5) Signalen mit name=* statt ref=*.
http://overpass-turbo.eu/s/8JO
(6) Weichen mit name=* statt ref=*
http://overpass-turbo.eu/s/8JP
(7) Signale ohne railway:signal:direction=*.
http://overpass-turbo.eu/s/8JR
Ich spreche mich dafür aus, diese nicht mehr zu rendern, denn Renderer
haben Macht. [1]
(8) Signale ohne railway:signal:position=*.
http://overpass-turbo.eu/s/8JS
(9) Sh 1-Licht als eigenständiges Sh-Signal gemappt. In den
Signalschirmen von Hp-, Ks- und Hl-Signalen sind oft Sh 1-Lichter
integriert (sodass dann Hp 0 + Sh 1 gezeigt werden kann). Viele dieser
Signale wurden jedoch so gemappt, als wären es zwei eigenständige
Schirme am gleich Masten (gibt es zwar, aber nur bei Sv-Signalen und
sehr alten Hp-Signalschirmen).
Falsches Tagging (denkt euch das DE-ESO ggf. einfach weg):
railway:signal:main=DE-ESO:hp
railway:signal:main:form=light
railway:signal:minor=DE-ESO:sh
railway:signal:minor:states=DE-ESO:hp0;DE-ESO:sh1 (bis vor Kurzem wurde
statt Hp0 noch Sh0 getaggt, was laut Ril 301 aber bei Lichtsignalen
falsch ist)
railway:signal:minor:form=light
Richtiges Tagging:
railway:signal:main=DE-ESO:hp
railway:signal:main:form=light
railway:signal:minor=DE-ESO:sh1
railway:signal:minor:form=light
Man kann bei Hp-Signalen aus der Ferne eigentlich schlecht diesen Fehler
korrigieren. Es bedarf Ortskenntnis. Beim Rest (Hl, Ks) kann man das
eigentlich aus der Ferne tun, sollte jedoch sehr vorsichtig sein und
ggf. den Mapper kontaktieren.
(10) Ein weiteres Problem, das mir aufgefallen ist, sind Verwechslungen
zwischen Signaltypen. Besonders gerne:
(a) Ks-Haupt- und Ks-Mehrabschnittsignale werden als Hp-Lichtsignale
erfasst. Man erkennt auch ohne Ortskenntnis potentielle Fälle an
Signalnummern, die nach folgenden Schema aufgebaut sind. Sie enthalten
meistens einen Nummer am Anfang, die im gesamten Bahnhof gleich ist.
Einfahrsignale: 53A, 53AA, 53B, 53BB, 53F, 53FF, 53G, 53GG
(Doppelbuchstaben immer im Gegengleis)
Ausfahrsignale: 53N1, 53N2, …, 53P1, 53P2, … (nach N/P steht die
Gleisnummer, gerne auch zwei- oder dreistellig; in einigen Stationen
wird neben N und P auch noch zusätzlich O oder M verwendet, z.B. Krefeld
Hbf)
Zwischensignale: 53ZU1, 53ZU2, … (markant ist das Z, davor die
Bahnhofsnummer, dahinter ein Buchstabe für den Bereich im Bahnhof,
gefolgt von der Gleisnummer)
Regex für Ks-Signalnummern: [0-9]+(([M-Q]{1}|Z[R-V]{1})[0-9]+|[A-K]{1,2})
Diese Regex matcht nicht in Potsdam Hbf!
Wenn also ein Bahnhof vor dem A, B, N, P, Z* usw. eine Nummer hat,
sollte man Googlen, ob dort in den vergangenen Jahren ein ESTW errichtet
wurde. Es gibt auch bei H/V-Signalisierung Bahnhöfe mit Nummern vor den
Buchstaben, diese Bahnhöfe sind dann ferngesteuert, z.B.
Karlsruhe–Graben-Neudorf oder z.B. Mühlhausen (Wern).
(b) Ks-Mehrabschnittsignale werden als Ks-Hauptsignale erfasst. Das
erkennt man nicht aus der Ferne, wenn nur wenige Signale erfasst sind.
Statistisch dürfen Einfahr- und Zwischensignale meist
Mehrabschnittsignale sein, Ausfahrsignale und Blocksignale sind nur
Mehrabschnittsignale, wenn die Blockabstände kurz sind oder der nächste
Abzweig/Bahnhof weniger als Vorsignalabstand + Durchrutschweg + ein
Bisschen entfernt ist.
Viele dieser Fehler (ausgenommen Abfrage 6, 9 und 10) stammen von iD-Usern.
Siehe auch https://github.com/rurseekatze/OpenRailwayMap/issues/192
Viele Grüße
Michael
PS Die OpenRailwayMap-Vorlagen sind mittlerweile in den
Vorlagenverzeichnissen der JOSM-Entwickler gelistet.
[1] Nicht umsonst spricht man von "Mappen für den Renderer".
[2] Da ich sehr viele Signale sichte und viele Fehler finde, fühlt sich
das alles andere als mechanisch an.
-------------------
Hi,
I have found lots of tagging errors during my mechanical edit which adds
the prefix "DE-ESO:*" to a lot of German signals. Following eight
queries might dig out errors in your area:
(1) Signal numbers tagged as railway:ref=* instead of ref=*
http://overpass-turbo.eu/s/8JM
(2) *Germany only* Signals tagged both railway:signal:main!=DE-ESO:hp
and railway:signal:distant=*. You might try other combinations with Hl
and Ks signals.
http://overpass-turbo.eu/s/8JN
(3) *Germany only* SSimilar to (2), but the combination of
railway:signal:main!=DE-ESO:hp und railway:signal:combined=*.
(4) *Germany only* SSimilar to (2), but the combination of
railway:signal:distant=* und railway:signal:combined=*. (It's impossible
in reality that a combined signal shares a its pole with a distant
signal because the combined signal is already a distant signal.)
(5) Signals tagged name=* instead of ref=*.
http://overpass-turbo.eu/s/8JO
(6) Switches tagged name=* instead of ref=*.
http://overpass-turbo.eu/s/8JP
(7) Signals without railway:signal:direction=*.
http://overpass-turbo.eu/s/8JR
I support not to render signals without railway:signal:direction=* (they
are rendered at the moment) because people often only map things which
are rendered.
(8) Signals without railway:signal:position=*.
http://overpass-turbo.eu/s/8JS
(9) *Germany only* If a Hp, Ks or Hl light signal can show Sh 1 the
following is the right tagging:
railway:signal:main=DE-ESO:hp
railway:signal:main:form=light
railway:signal:minor=DE-ESO:sh1
railway:signal:minor:form=light
The wrong tagging:
railway:signal:main=DE-ESO:hp
railway:signal:main:form=light
railway:signal:minor=DE-ESO:sh
railway:signal:minor:states=DE-ESO:hp0;DE-ESO:sh1 (bis vor Kurzem wurde
statt Hp0 noch Sh0 getaggt, was laut Ril 301 aber bei Lichtsignalen
falsch ist)
railway:signal:minor:form=light
The "wrong" tagging should only be used if the minor signal is a
separate signal which is mounted below the main/combined signal at the
same pole.
(10) *Germany only* Some Mappers mix up Hp light signals with Ks light
singals and Hl light signals with Ks light signals. You cannot correct
the tagging without local knowledge but you can create a "review list"
because Ks signals inside stations have different numbering system than
Hp and Hl signals. Inside stations Ks signals have a number which
follows the following regex:
[0-9]+(([M-Q]{1}|Z[R-V]{1})[0-9]+|[A-K]{1,2})
Most of these errors are done by iD users (except no. 6, 9 and 10).
See also https://github.com/rurseekatze/OpenRailwayMap/issues/192
Best regards
Michael
--
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)
Hallo,
ich beabsichtige zur flächendeckenden Einführung des neuen
DE-ESO:*-Präfixes einen mechanischen Edit durchzuführen, der die alten
Signale um das Präfix ergänzt. Weitere Details findet ihr im OSM-Forum.
http://forum.openstreetmap.org/viewtopic.php?id=30676
Wenn ihr in JOSM für die Objektvorlage die URL (also
http://www.openrailwaymap.org/josm-presets/…) eingetragen habt, dann
solltet ihr schon eine Version der Objektvorlagen verwenden, die die
Präfixe nutzt. Andernfalls möchte ich euch bitte, eure Objektvorlage zu
aktualisieren.
Viele Grüße
Michael
Hi,
I am going to run a mechanical edit on railway signals in Germany. I
want to add the DE-ESO:* prefix to all signals which do not have it but
should have it.
More information (in German) can be found at
http://forum.openstreetmap.org/viewtopic.php?id=30676
Best regards
Michael
--
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)
