Nein, wenn neben der Strasse highway=platform verwendet wird, dann gehört highway=bus_stop auf die stop_position.

Hi PT-53,
das war mal als "Quickfix" gedacht, da der Bahnsteig zwar physisch vorhanden, mangels Zugang aber seit Jahren nicht benutzbar ist. Da sich der geplante Um-/Neubau scheinbar endlos verzögert, habe ich dies mit changeset/101505766 in einen lifecycle-prefix geändert.
Danke & Gruss zurück

Hi. You do realize, that your attempt to mass-edit a wikidata-ID onto already properly tagged objects, seems not only redundant, but caused all 114 way & 1546 nodes you mistakenly selected in this changeset[1] to be incorrectly tagged with network and network:wikidata?

Please review your other contributions, if there are more such accidents. I'll try to find time to revert this CS, currently triggering 157 conflicts...

[1] https://overpass-api.de/achavi/?changeset=96828577

Schaust du dir bitte das CS nochmals in achavi[1] an? Anhand der Notiz war es doch bereits korrekt? 2.13 ist motorcar + motorcycle, 2.14 wäre motor_vehicle. Und die neu abgetrennten Stummel mit dem Original-Tagging braucht es dann vermutlich auch nicht? Gruss

[1] https://overpass-api.de/achavi/?changeset=101000969

Weil sämtliche Prüftools davon ausgehen, dass ein Trolleybus Fahrleitungen benötigt. Gäbe es diese Eigenheit nicht, könnte man auf die Unterscheidung komplett verzichten, wie auch Antriebe mit Diesel, Wasserstoff, Plug-In-Hybrid, Depotlader oder Gelegenheitslader für die Routenerfassung in OSM völlig unerheblich sind.

Zudem werden nur maximal 48% (7.08 km) unter Fahrleitung zurückgelegt, und 52% (7.61 km) fahrleitungslos mit Batterie – das schafft ein konventioneller Trolleybus nicht sondern nur die 10 IMC-fähigen. Die VBZ dürfen dies gerne als Trolleybuslinie bezeichnen, für das OSM-Tagging ist dies schlicht eine (Batterie-)Buslinie.

Erstens: dies hier ist OSM und was irgendwo in Wikipedia 'über' OSM steht ist nicht relevant. Zweitens: wie die Zürcher Feuerwehr arbeitet, darüber kann man sich bei der in OSM vertretenen Dienstabteilung SRZ erkundigen. Drittens: der Weg ist in der amtlichen Vermessung (die uns unter OGD zur freien Verfügung steht) erfasst, auf welcher auch sämtliche offiziellen Kartenwerke basieren – diese weisen dann definitiv keine Zugangbeschränkungen mehr aus. Darauf aufbauend, Viertens: Fusswege und Treppen sind physisch vorhanden, das untere Tor eingezeichnet und als versperrt markiert – da technisch alles korrekt erfasst ist, gibt es absolut keinen Grund dies zu löschen. Fünftens: alleine für die Gebühren, die ein audienzrichterliches Betretensverbot kostet (Danke, im Namen der Gemeindekasse) hätte man den oberen Durchgang längst mit einem schönen, schmiedeeisernen Tor ausstatten können, der die Horden von Zürichbergbewohnern von der ersehnten "gated community" fernhält.

Deswegen nochmals in Deutsch: die Eintragung ist technisch korrekt und sie bleibt grundsätzlich; einzig die Zugangsbeschränkung werde ich auf die Wege ausweiten.

Ist korrigiert, da es in OSMI geflaggt war. Schönes Anschauungsbeispiel, wieso dies nicht mit highway-Elementen "gebastelt" werden sollte. Schöns Wuchenänd :-)

Layer verwechselt, Hangsicherung Sulzbach separat korrigiert und dokumentiert in changeset/100438685.

Wenn sich der Grund für "Strassen-Spaghetti" nicht aus den gängigen Quellen (hier ganze 6 verfügbare Luftbilder), dem Changeset-Kommentar, oder der 'note' (richtet sich explizit an andere Mapper) ergibt, dann gehe ich von einem Versehen aus.

Der Nachweis der nicht-Existenz eines Objektes ist weniger trivial, als ein aktuelles Photo zu schiessen und ins Netz zu stellen. Hier wäre es auch mit einem Zeitungsartikel gegangen. Entsprechend habe ich den alten Strassenverlauf mit changeset/100438685 (changeset/100438685) zu track runtergestuft – construction wäre auch gegangen, müsste dann einfach bei Abschluss nochmals angepasst werden. Den alten Verlauf unverändert drin zu lassen ist hingegen technisch falsch, damit können weder Mensch, noch Software etwas anfangen, entsprechend war Notiz 2545603 durchaus berechtigt. Gute Dokumentation ist keine Strafaufgabe, sondern hilft allen.

Rückbau zu Waldbewirtschaftungsweg gemäss: https://www.tagblatt.ch/ostschweiz/rheintal/die-funf-millionen-franken-kurve-ld.1109477

Aktualisiert mit changeset/100436611 (Hallenbad) und changeset/100436674 (Schulhaus).

Gratuliere, dürfte geklappt haben – abhängig von der Zoom-Stufe werden die ersten Tiles wieder als Wald gerendert und die QA-Tools haben auch nichts zu bemängeln. Good job :)

Hi. Man erzeugt keinen gültigen route_master indem man die Attribute der Relation ändert. Bitte nochmals im JOSM-Handbuch nachschlagen, was der Unterschied zwischen 'Apply Preset' und 'New Relation' ist (wie auch immer die deutsche Übersetzung lautet). Danke.

Gordischer Knoten: müsste vermutlich die Rolle 'outer' haben um gerendert zu werden, darf aber nicht 'outer' sein, da innerhalb der 'outer'-Begrenzung der Relation. Die Rolle 'inner' ist auf jeden Fall falsch.

Was passiert, wenn man way/895819739 aus der Relation nimmt? Ausser die Fehlermeldung "untagged way" natürlich. Denke ausprobieren, warten und hoffen, dass niemand auf die OSMI-Fehlermeldung anspricht.

Danke, hab's mit changeset/99846332 angepasst.

Definitly.

Salü

Deine GTFS-Einträge dürften korrekt sein. Für die Schweiz gibt es erfreulicherweise nur einen (aggregierten) GTFS-Datensatz. Habe mangels Alternativen bei grenzüberschreitenden Linien mit nenneswertem Binnenverkehr (Ramsen–Stein [SBG 7349], Rheinfelden [SBG 7312]) auf den CH-Datensatz zurückgegriffen, der in zweiterem Fall leider unvollständig ist. Die werde ich demnächst auf die DE-Versionen umstellen.

Bezüglich iD bin ich unschlüssig, ob es die üblichen Teilungsfehler sind, oder ob es mehr als auch schon sind. Aber eigentlich sollte ohne spezielle Logik jeweils nur eine Richtung betroffen sein, und nicht beide – spricht dafür, dass iD zwar etwas analysiert, es aber dann genau falsch herum "löst". In den letzten Wochen musste ich mindestens zwei Mal die Teilung einer Richtungsfahrbahn(!) reparieren, was meiner Meinung nach nicht vorkommen dürfte...

LG

Hi skyper

Hat sich durch Zufall ergeben, da ich zur Zeit die Grenzregionen (und Lizenzbedingungen) etwas anschaue. Bei einigen Linien konnte ich auf den CH-Datensatz zurückgreifen (teilweise kryptisch hinterlegt), nun bin ich positiv überrascht, dass die Geheimniskrämerei von SBG und SWEG offenbar ein Ende nimmt. :)

Die Strassenrelation (bzw. Ctrl+Alt+D) habe ich tatsächlich vergessen, da mir der Fehler unverdächtig erschien – jetzt sehe ich, da war wieder iD am Werk. *seufz*

Aber danke für den Hinweis, dass auch die anderen Relationen im Norden grundsätzlich gepflegt werden, im Süden habe ich diesbezüglich kapituliert. :/

Grüsse zurück,
sovereign_ch

Reverted with changeset/98962634.

Never use inferior Maxar imagery, when superior orhophotos (in this case Vorarlberg VoGIS) are available.

Wäre in OSM als URL (way/465262378) gewesen. Wie man sieht hat sich auch Map47 des Problems angenommen und das Objekt gelöscht bzw. auf way/904705013 übertragen.

Objektreferenzen können wie oben immer in eine URL "umgewandelt" werden (n = node, w = way, r = relation). JOSM kann das direkt via: File → Download Object (Ctrl+Shift+O). Bei gelöschten Objekten hilft das Plugin 'undelete' weiter (File → Undelete Object (Alt+Shift+U).

Den Gipfel hast du als node/8402126593 erfasst, was korrekt sein dürfte. Die Bezeichnung die Map47 auf way/904705013 (way/904705013) übertragen hat, kann man glaub löschen oder auf 'Rochers des Miroirs' angleichen. LG