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.
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>