That's the unfortunate result of another pretty annoying iD behavior – instead of suggesting a proper 'railway' tag, it suggests "something" 'public_transport'. I've changed it to railway=service_station. Thanks for pointing out :)

Änderungssatz aufgrund kommentarlos gelöschter POI revertiert. Bitte das wiki konsultieren.

Hi. Zugangsbeschränkungen werden nicht nach Bauchgefühl getaggt, sondern gemäss Signalisation. Dies bedeutet einerseits, dass man _nicht_ sämtliche Optionen, die iD oder JOSM vorhält auf yes/no setzt. Dies bedeutet andererseits, dass man sich an Distanztafeln (ab x Meter) hält, und nicht wie hier "präventiv" Strassenstücke umtaggt, die gar nicht betroffen sind. HTH

And still you're somehow totally missing the point.

Someone took the time to properly set up "public transportation" routes – frankly I don't care if that was a paid job or not. Neither do I care if it's Flix, or TI, or Thello, or a local bus operator or whoever. The point is, that's hours of work were put into those relations, per line and direction. And the nice thing is that PTv2 (being one of the OSM-internally defined things, that don't care about rendering or routing, but just for the scheme of use [of OSM-objects]) has a logical definition, that can be surveyed. Or, I can load any route-relation into JOSM and tell if it's messed up, or not. OSMI or PTNA are just tools addressing those issues, that need attention.

Often it's iD that messes things up, but even JOSM isn't fool proof, and I have to re-check my own changes twice or trice.

And still it's not impossible, there are mappers, that manage to split up a roundabout, and tidy up 30 relations without causing havoc. It's a matter of reading and understanding the manual, and investing the extra time, to do the extra work.

Why exactly are your 5 to 10 minutes of time more valuable, than anyone elses's 15 to 30 minutes, to do the job properly?!

There is virtually no reason to split roundabouts, except for changes in physical properties (two-lane sections and one-lane sections in the same roundabout). It's not recommended, let alone required by the wiki, and it's not even necessary for route-Relations.

Such splitting is cosmetical (aka tagging for the renderer), so please do it either properly, without triggering errors in OSMI and PTNA across half Europe, or leave it.

Also, there weren't turn restrictions on the roundabout, this would have triggered conflict resolution in JOSM (unlike in iD).

Es ist weder erwünscht, noch zielführend irgendwelche temporären Bauzwischenstände zu mappen. Bei langfristigen Baustellen ist das akzeptabel, insbesondere wenn sie grossräumige Umfahrungen nach sich ziehen. Ein fehlendes Gleisstück gehört sicher nicht dazu, das kannst du im März eintragen, wenn die Gleisgeometrie fertiggestellt wird.

Hi, bitte beschreibe im Changeset-Kommentar jeweils die konkrete Änderung, die du vornimmst. Das Datum ist überflüssig, das speichert die Datenbank von sich aus. Happy mapping.

Hi, the change on the ERZ containers acutally was correct. Just the Texaid one (clothes & shoes) changed incorrectly to bottles/cans/scrap_metal.

Kommentarkorrektur: Ersatzneubau Sustenstrasse 11; source Geolion (Geodienst des GIS-ZH): Amtliche Vermessung in Farbe (OGD), note/2412375.

@MFlamm: Thanks for pointing out. Reverted.

Hoi Toni. Danke für den Hinweis.

Ich habe das so gelöst, dass ich im route_master das release_date weglasse (dort soll PTNA meckern, gibt ja dann was zu tun), und bei den Linienvarianten die Feed-Version explizit dokumentiere. Habe schon nicht vor sämtliche Linienvarianten wöchentlich neu zu überprüfen ;)

Teilweise ist es nur ein beauty-pass, da ich die Linien zuvor schon mittels GTFS erstellt bzw. überprüft habe, so dass ich dies jetzt nachdokumentiere. In genau sieben Wochen "droht" schliesslich der Fahrplanwechsel...

Liebe Grüsse

Pardon, aber es existieren keine amtlichen Dokument in der Schweiz, wo 'Sankt' ausgeschrieben wird, das ist reinste Fiktion, die in OSM unter der "keine-Abkürzungen"-Grundregel auf die Spitze getrieben wird. Weder kennt die Bundesverfassung einen Kanton "Sankt Gallen", noch bezeichnen sich der Kanton bzw. die Stadt in der jeweiligen Verfassung, irgendeinem amtlichen Dokument, einem amtlichen (BAV, BFS...) oder halbamtlichen Verzeichnis (Post, Swisscom...) so. Es existiert _nur_ "St. Gallen" (zwingend mit Leerschlag nach dem Punkt) und das trifft für sämtliche analogen Bezeichnungen zu, was sich auch in den Schreibempfehlungen der "Schweizer Orthographische Konferenz" (SOK) niederschlägt.

Das man '*str.', '*pl.', 'Bhf. *' und ähnliches ausschreibt macht Sinn, da es in den meisten professionell geführten Verzeichnissen (z.B. Strassenverzeichnis Zürich) ausgeschrieben und bloss aus Platzgründen (oder reiner Faulheit) abgekürzt wird. 'St.' ist in der Deutschschweiz hingegen die verbindliche, amtlich dominierende Schreibform. Grade bei Ortsbezeichnungen sind das stehende, festgelegte (in der Regel amtliche) Namen und keine 'Abkürzungen' im Sinne von "auf der Tafel hatte es keinen Platz". Entsprechend gibt es hier weder etwas auszuschreiben, noch abzukürzen. Bewusst Falschschreibungen aufgrund ignorant formulierter OSM-Grundsätze durchzusetzen, zeugt war von blinder regeltreue, hat aber herzlich wenig mit der Realität und dem Abbilden selbiger zu tun. Just my two cents.

Wie bereits angemerkt: Segmente existieren in der Regel, weil sie unterschiedliche Eigenschaften und somit unterschiedliche tags besitzen. Eninfach zusammenfügen ist da ein no-go. Dazu auch gleich der Hinweis auf (aktuell) Punkt 18 der [Good-Practice-Regeln](osm.wiki/DE:Good_practice): "lösche keine Attribute, die du nicht verstehst".

Mehrfachmarkierung mittels Shift ist eigentlich üblich, da weder iD noch JOSM Gedanken lesen können, um zu bestimmen welchen Abschnitt du markieren möchtest. Hierzu auch gleich der Hinweis, dass das explizite taggen von Standardvorgaben/defaults völlig unnötig ist, das ist Aufgabe der Datennutzer dies korrekt umzusetzen. Sprich: sind Autobahnen grundsätzlich für 40 t (plus 10% Sicherheitsmarge) zugelassen, dann sind nur die Ausnahmen zu taggen, wo allenfalls nur 32 t, 28 t usw. zugelassen sind. Dies bitte unter Angabe einer lizenzkompatiblen Quelle, sofern es nicht aus der vor-Ort-Beschilderung eruierbar ist. Sonst haben wir auch noch ein Urheberrechtsproblem an der Hand. HTH :)

Do not add undocumented tags. This belongs under 'network'. Thank you.

Hi. geodienste.ch mag zwar "frei verfügbar" sein, die Nutzung unterliegt hingegen den einzelnen kantonalen Nutzungsbedingungen. Für den Kanton Aargau (AGIS) gilt: Finger weg, da die kantonalen Nutzungsbedingungen zur Zeit keine lizenzkonforme Nutzung in OSM zulassen. Die AGIS-Luftbilder darfst du hingegen zum abzeichnen nutzen. Viel Spass beim weiteren Mappen.

I don't understand what exactly the purpose of (mass-)editing an object is, whose function one don't seem to fully understand, but anyway...

First point: you're mass-adding with iD a JOSM-specific tag (public_transport:version=2), which in this case isn't useful, nor required by JOSM. It's pure spam. I didn't notice it was mentioned on the en-wiki, so I rectified this now.

Second point: the stop_area-relation holds the PTv2-stop_position and PTv2-platform elements together. This is however more of a gimmick for software that isn't able to piece the elements together by uic_ref – or in the absence of such data. By original design stop_area should only hold those two element types with appropriate roles (which JOSM assigns automatically).

Third point: someone, at some point felt obviously the need to add the old PTv1-station/halt nodes, to stop_area-relations. While there is absolutely no need, nor function to it, at least it serves as "label node", because it is rendered by most general purpose renderer, while PTv2 elements aren't.

Fourth point: no, it isn't necessary to put 'railway=station/halt' onto a stop_area-relation, but it helps identifying the stop_area as belonging to a railway station or halt. To be more precise: railway=station on a node being a PTv1 abstration, the same tagging on a relation equals a PTv2 abstraction.

Personally I don't see any benefit in removing the station type (railway=station/halt) from the stop_area-relation. It makes the whole concept less useless. The wikidata object or wikipedia article of a railway station logically also applies to the stop_area elements. And technically it isn't correct at all to include the PTv1-node in a stop_area-relation – it's the abstraction of the whole station and by logic the "parent element" of the stop_area elements, and not the other way around.

@datendelphin: any additional thoughts on the topic?

Danke dir, sieht vollständig aus.

This change isn't discussed with the local mapping community, nor is it sanctioned or approved in the wiki. "railway=site" is used for undefined objects on a _node_ (Betriebsstelle, Dienststation), not in a relation. So please stop semi-automatically changing the specific use (railway=station, railway=halt) to 'railway=site' and restore the stop_area-Relations. Thank you.

revertiert mit changeset/91947539, Datenschrott aufgrund eines hirnlos zusammengeklickten Hinweises von Osmose und/oder iD

revertiert mit changeset/91947539, Datenschrott aufgrund eines hirnlos zusammengeklickten Hinweises von Osmose und/oder iD