OpenStreetMap logo OpenStreetMap

Changeset When Comment
152992845

Hallo, nochmals. Lösche keine tags, die du nicht kennst. Dazu gehören auch korrekt gemappte Gebäudeteile, wo sich jemand die Mühe gemacht hat die einzelnen Dachformen und -farben zu erfassen. Danke.

152993127

Bitte lies die tags richtig, das ist mit 'building=construction' eingetragen und bereits der neue Gebäudegrundriss.

151269581

Hallo Moritz. OSM ist leider gelegentlich eine Sammlung von halbgaren Ideen. ;-)

stop_area war einzig dazu gedacht, PTv2-Elemente (stop_position und platform) zusammenfassen, welche dieselben Referenzwerte (ref, uic_ref, uic_name, name) besitzen. Dies als wundervolles 'high-concept', um Redundanzen zu minimieren. Leider im Alltag unbrauchbar, da ich zumindest beim Editieren auf Klarnamen angewiesen bin und mit der OSM-ID der Objekte selber nichts anfangen kann. Und auch QA-Tools wie PTNA holen sich aus den ÖV-Relationen die Angaben von den Objekten und nicht von allfälligen Elternrelationen.

Inzwischen werden daher (wenig beachtet) auch 'Kraut & Rüben' erfasst, und Relationen wie wikipedia-Kategorien verwendet, obwohl dies dies als 'do-not' [2] deklariert ist.

platform_edge ist ein railway-Element (und als solches nie automatisch ein PT-Element), und erfüllt als eigenständiges Objekt keinen Zweck, sondern dient dazu ein platform-Objekt besser zu beschreiben. Grade im Beispiel hier, wo die platform bereits ein multipolygon ist, hättest du dir etwas Arbeit sparen und den Umriss an den Eckpunkten auftrennen können, dann hättest du automatisch zwei Kanten erhalten. platform_edge ist dann auch logisch korrekt Teil des Perron-Multipolygons, der wiederum Teil der stop_area ist (sofern er im Personenverkehr verwendet wird). Reiner Güterverkehr ist nie public_transport – wenn man dies erfassen möchte, dann müsste man korrekterweise mit einer (railway-)site-Relation arbeiten. Das Problem ist, dass "schlaue" Editoren wie iD, solche Unterscheidungen nicht beherrschen, überall dieselben tag-Vorschläge machen und auf diese Weise fehlerhaftes Tagging salonfähig machen.

Ich hoffe, dass meine Erklärung die Zusammenhänge klarer macht.

Liebe Grüsse, Dani

[2] osm.wiki/DE:Relationen/Relationen_sind_keine_Kategorien

152230310

@Fijord: Das ist im Grunde so, dass wir die "technischen Adressen" mit Dezimalpunkt und ähnlichem in OSM _nicht_ erfassen – zumindest solange es erkennbar technische Adressen sind. Was man in jedem Fall vermeiden sollte, ist dann daraus noch eine "postalische Adresse" mit PLZ und Ort zu basteln, die es schlicht nicht gibt.

152187942

Hallo Mischa, danke für die Quelle. In dieser ist abzulesen, dass Velo und Bus weiterhin in Gegenrichtung fahren dürfen, was ich in changeset/152244334 ergänzt habe.

Ich nehme an die Pestalozzistrasse ist ebenfalls wie abgebildet nur auf dem Abschnitt Schiller–Hadwig 'oneway' und nicht auf voller Länge?

152203253

Ich habe dir bereits erklärt, dass du keine separat gemappten Trottoirs löschen sollst. OSM ist kein Spielplatz und es gibt Grundregeln, die du dir dringend verinnerlichen solltest. Danke.

152184235

Ohje, sorry... unclosed changeset.

152170141

Hallo Swissplay, ich hoffe dein Benutzername hat nichts mit deinem Mappingverhalten zu tun. OSM ist eine produktive Geodatenbank und lebt davon, dass Nutzer Geodaten eintragen und nicht bestehende Geodaten löschen oder ständig neu zeichnen.

Separat gemappte Trottoirs sind in der Schweiz erlaubt und es ist nicht in Ordnung diese einfach zu löschen.

Entsprechend habe ich selbige wiederhergestellt und lege dir nahe, dass du dich mit dem lokal verwendeten Schema (und dem wiki) vertraut machst und bei allfälligen Fragen via Forum oder Mailinglist an die Schweizer Mapper wendest. Links hierzu findest du im Wiki.[1]

HTH

[1] osm.wiki/WikiProject_Switzerland

151722443

Da ihr regelmässig Stockwerkangaben verwendet, bitte beachtet, dass 'level=*' nicht als Freitextfeld konzipiert ist und Angaben in Form einer Ganzzahl/integer erfordert – oder gegebenenfalls als Halbstockwerk (z.B. "2.5"). Auch Angaben wie MVE und ähnliches sind nicht zulässig, können aber zusätzlich als "level:ref=*" erfasst werden.

HTH

151706579

Noch ein Wort zu euerem Sammelaccount und wie ihr diesen nutzt: es ist nicht in Ordnung, wenn einmal Person A und einmal Person B antwortet, und dann auf eine Rückfrage gar nichts mehr kommt.

Was hingegen völlig daneben ist, ist auf einen technischen Einwand, mit einem aus dem Zusammenhang gerissenen Wiki-Zitat zu antworten und eure Taggingfehler auf weitere Objekte auszuweiten.

Ihr befindet euch hier nicht im luftleeren Raum, bei Unklarheiten und Einwänden stehen euch Forum[1] und Mailinglist[2] zur Verfügung. Dort können wir gerne über Fehler in euerem Konzeptpapier diskutieren – dies _bevor_ ihr seit Jahren etablierte Taggingschemata einfach über den Haufen werft.

Und bitte keine PM, damit auch andere Mapper die Diskussion nachvollziehen und ihren Input geben können. Danke schön.

[1] https://community.openstreetmap.org/c/communities/ch/107
[2] https://lists.openstreetmap.ch/mailman3/lists/talk-ch.openstreetmap.ch/

151706666

'highway=*' ist kein indoor-Objekt. 'indoor=*' wäre ein korrektes indoor-Objekt.

151706615

Entfernt keine Layerangaben, wenn ihr keine echten indoor-Objekte verwendet.

151706607

Entfernt keine Layerangaben, wenn ihr keine echten indoor-Objekte verwendet. Die Halle ist nicht auf derselben Ebene wie die Gleise.

151706579

Entfernt keine Layerangaben, wenn ihr keine echten indoor-Objekte verwendet. Die Halle ist nicht auf derselben Ebene wie die Gleise.

151627974

Im wiki steht vieles, das bedeutet nicht, dass alles richtig ist. Denn konsequenterweise wird vorausgesetzt, dass _in_ Gebäuden dann auch ausschliesslich indoor-Elemente[1] verwendet werden. Diese werden von osm-carto nicht gerendert und benötigen die layer-Angabe nicht zwingend.

Solange wir allerdings den organisch gewachsenen Mischmasch aus "outdoor"-Elementen wie 'hw=footway' oder 'hw=pedestrian' statt 'indoor=corridor' verwenden, ist die layer-Angabe weiterhin zwingend.

[1] indoor=*

151660531

Do not mess around with local name conventions, unless you talk to the local mapping community. Thank you.

151659941

Do not delete PTv2-platforms. This is not France.

151659900

Do not mess around with local name conventions, unless you talk to the local mapping community. Thank you.

151659754

Do not mess around with local name conventions, unless you talk to the local mapping community. Thank you.

151659848

Do not mess around with local name conventions, unless you talk to the local mapping community. Thank you.