Dear fellow railway mappers,
there is a current Github issue with the OpenRailwayMap that I believe is quite worth to be debated. It is on the question if railway signals should no longer be rendered when there is no direction tag attached to them.
The issue is at https://github.com/rurseekatze/OpenRailwayMap/pull/209
Cheers from a regional train ;) Peter
Am Samstag, 20. Juni 2015, 23:13:04 schrieb Peter Reinhart:
Dear fellow railway mappers,
there is a current Github issue with the OpenRailwayMap that I believe is quite worth to be debated. It is on the question if railway signals should no longer be rendered when there is no direction tag attached to them.
It has been merged yesterday. There is now an additional validator check for this, so look at your signals and it will warn you about that.
Greetings,
Eike
Am Samstag, 20. Juni 2015, 23:13:04 schrieb Peter Reinhart:
Dear fellow railway mappers,
there is a current Github issue with the OpenRailwayMap that I believe is quite worth to be debated. It is on the question if railway signals should no longer be rendered when there is no direction tag attached to them.
It has been merged yesterday. There is now an additional validator check for this, so look at your signals and it will warn you about that.
That is little help to hundreds of perfectly tagged signals that (for whatever reason) do not carry a direction tag (yet). It seems that OpenRailwayMap just became the first OSM map that put up a mapper "education" regime. Should the job of a renderer rather be to make the best out of the data available?
If a mapper likes to, say, just map a signal type, position und reference, that data is alredy useful to the map. In fact, that is pretty much everything the OpenRailwayMap can display. Still, ORM won't display those signals even though they are there. Open Data and Open Source software largely rely on such people with very special interests.
As explained in the Github issue discussion, we have just raised the bar for the railway signal mappers. Instead of being thankful for every single bit of information -- in particular from those newbies who spend hours to upload their first few bits -- we raise the bar for no obvious reason.
We should focus on finding wrongly and incompletely tagged signals and improve them, instead of this "mapper education" approach.
Best wishes from Dresden Peter
Hi Peter,
Am 2015-06-21 um 11:57 schrieb Peter Reinhart:
Am Samstag, 20. Juni 2015, 23:13:04 schrieb Peter Reinhart:
Dear fellow railway mappers,
there is a current Github issue with the OpenRailwayMap that I believe is quite worth to be debated. It is on the question if railway signals should no longer be rendered when there is no direction tag attached to them.
It has been merged yesterday. There is now an additional validator check for this, so look at your signals and it will warn you about that.
That is little help to hundreds of perfectly tagged signals that (for whatever reason) do not carry a direction tag (yet). It seems that OpenRailwayMap just became the first OSM map that put up a mapper "education" regime. Should the job of a renderer rather be to make the best out of the data available?
Yes, that might be the job of a renderer if its purpose is a end-user map. But a renderer can also create a map for mappers. As such, it should not support as much tagging as possible if this makes the renderer to support bad/poor tagging.
There are a few occasions at OSM history when OSM Carto discontinued support of a strange tagging. Sometimes people cried and sometimes not. Exmaples: - rendering of buildings inside non-multipolygon pedestrian areas - rendering name=* on selected items But both decisions helped to improve the data quality.
Unfortunately, there are some mappers who use iD to contribute signals. I have discovered them during my mechanical addition of the DE-ESO:* prefix. Because there is no iD tagging template (and I will not create and maintain one), they have to enter each tag manually – and iD's is optimized to use the presets (in contrast to JOSM). That's why these users only add as much tags as necessary. JOSM users usually add as much as they know because JOSM templates always ask everything (just have a look at the default highway templates).
We as a simple map do not need a information about direction at the moment, but there are/will be services which need this data. - railway capacity calculators (the have to know the positions of the block signals and the signal direction) - simulators (there is already a converter for track geometry from OSM to Zusi) - 3D renderers - detailed track plans of stations (example from 1904 https://upload.wikimedia.org/wikipedia/de/archive/c/c8/20141201124901!Gleisp...)
At the time I invented this rules I decided not make railway:signal:position=* mandatory because I thought it is less important. I do not plan to make this key mandatory, too.
Why not "force" users do add at least a minimum of information. Since the early days ORM forces users to add railway=signal. Nobody has complained about that yet.
Btw, something similar will happen in near future. I have developed rendering rules for German light speed signals (Zs 3 and Zs 3v). These new rules only render signals with railway:signal:direction=*. https://github.com/rurseekatze/OpenRailwayMap/pull/201
I do not understand you complains because the number of disappearing signals is low and people who see the map for the first time will not miss them.
Best regards
Michael
Am Samstag, 20. Juni 2015, 23:13:04 schrieb Peter Reinhart:
Dear fellow railway mappers,
there is a current Github issue with the OpenRailwayMap that I believe is quite worth to be debated. It is on the question if railway signals should no longer be rendered when there is no direction tag attached to them.
I'm now hijacking this discussion, because I think it matches my "issue" pretty close.
I would like to have a better tagging for "2 or more signals at the same pole". Think of the German snowplow signal as a reference: in all cases where I have seen this signal it shows up and down on the same pole, just for opposite directions. There is currently no way to reflect this in the tagging, one needs to use 2 nodes for this (which I dislike for various reasons).
Another example are H/V light signals where a main and distant signal is at the same pole. Those often have signs where the ref is written as "G/pII" [1]. You do not need much guessing to find out that "G" is the ref of the main signal, while "pII" matches the distant one. There is however no way one could reflect this in the tagging, either.
So if anyone comes up with a good idea how to increase the tagging for those without breaking everything we already have: just speak up.
For the "ref" I could imaging adding additional railway:signal:main:ref=G and railway:signal:distant:ref=pII, but this duplicates information we already have in the database. A way out could be to say: if there are multiple signals on one pole that could have refs use the "long" form, otherwise "ref" is sufficient. But that sounds hacky to me.
Greetings,
Eike
1) side note: the II are actually smaller and written in superscript, I have no idea how to properly write that down
openrailwaymap@openrailwaymap.org
-
Michael Reichert -
Peter Reinhart -
Rolf Eike Beer