This mailing list has been migrated to Mailman 3. This archive will no longer be updated. Messages after 1 February 2020 are missing. Please use the new archive instead.
Diese Mailingliste wurde auf Mailman 3 umgestellt. Dieses Archiv wird nicht mehr länger aktualisiert. Nachrichten nach dem 1. Februar 2020 fehlen. Bitte benutze das neue Archiv.

[openrailwaymap] Incompletely tagged signals about to disappear

Michael Reichert nakaner at gmx.net
Tue Jun 23 10:34:55 MEST 2015


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!Gleisplan_BadM%C3%BCnster_1904.jpg)

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


-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openrailwaymap.org/archives/openrailwaymap/attachments/20150623/2cec5aaa/attachment.sig>


More information about the Openrailwaymap mailing list