Hi. Was genau ist jetzt besser daran, dass das zuvor sauber als (Tankstellen-)Dach getaggte Objekt, nicht mehr als solches erkennbar ist? Gruss

Hi, sollten die Greencity-Gebäude nicht als building=construction gemappt werden? Das einzige von dem man etwas sieht, ist glaub Pergamin II, während am Schulhaus IIRC noch nicht mal gebaut wird. Gruss

Hi Bytemark, ich bin zwar auch kein besonders grosser Freund von landuse-Multipolygonen, aber das war jetzt nicht die besonders feine Art. Durch das Zusammenlegen von einigen Linien zu "closed ways", sind jetzt nämlich die verbliebenen multipolygon-Relationen fehlerhaft. Würde daher, falls ich nichts wesentliches übersehen habe, die Änderung begrenzt rückgängig machen.

Falls ich deine Absicht richtig deute, müssen die betroffenen Abschnitte zuerst dupliziert werden, bevor sie zu einem "closed way" zusammengefügt werden können, ohne verbleibende Relationen zu verletzen. Also quasi das Gegenteil von dem, was für den Gebrauch von Multipolygonen spricht. Mir ist grade keine JOSM-Funktion geläufig, die Objekte dupliziert, was auf manuelles Nachzeichnen hinausläuft. Ideen dazu?

Gruss, Sovereign

Hi, das habe ich aufgrund der note (note/1847475) bereits gefragt. ;-)
LG

Hi, in Vespucci ist zur Zeit (seit V13.0 oder V13.1) ein kleiner Bug vorhanden: das Zusammenziehen einer Linie auf einen Punkt löscht die Linie nicht mehr, sondern lädt sie als "one-node-way" (Linie bestehend aus einem einzigen Knoten) wieder hoch.

Sichtbar ist der Fehler im OSMI (Layer Geometry). Falls die betroffene Linie (way/23514167) nicht für einen Bugreport benötigt wird, würde ich sie demnächst gerne löschen. ;-)

Da ich selber Vespucci mangels Endgerät nicht verwende, kann ich den Bug weder bei mir reproduzieren, noch einen allfälligen Bugfix überprüfen; dies müsste jemand übernehmen, der mit der Software arbeitet.

HTH und Gruss

Bitte einen forced refresh (CTRL+F5) durchführen (nötigenfalls mehrfach), bis dein Browser ein Neurendern erzwingt. Oder lade es doch einfach mit iD?!

Die "Wurstknoten" habe ich mit changeset/72406766 beseitigt, bevor ich geantwortet habe, dass es erledigt sei. changeset/72406766

Und was falsch war: für die richtungsabhänigen Routen-Relationen müssen die highway-Elemente korrekt aufgetrennt werden und die Relationen danach auf die Änderung angepasst werden. Hier: zehn öV-Relationen und drei Hauptstrassen-Relationen. OP am offenen Herzen...

Das ist mir durchaus bewusst. Aber: dafür gäbe es den postal_code-tag. Über den bin ich eine handvoll Mal gestolpert (v.a. Birmenstorf AG), und ich habe ihn (noch) nicht entfernt, da ich das übrige Tagging noch nicht analysiert habe.

Die tags vom Typ "addr:*" sind hingegen gemäss Definition im wiki für definierte Adressen (Gebäude, POI, oder Adressnode) gedacht. Hättest du die Gebäude entlang der Strasse angeschaut, hättest du festgestellt, dass diese vollständige, einzeldefinierte addr:*-tags (Hausnummer, Strasse, PLZ, Ort, Land[!]) besitzen. Und dass die einzeldefinierten Adressen, teilweise nicht dem "globaltagging" auf der Strasse entsprechen, da die Strasse am Wechsel des PLZ-Gebiets gar nicht aufgetrennt ist.

Das hier ist ein Musterbeispiel, wie OSMI zur vernachlässigten Qualitätskontrolle beiträgt.

Ich führe keinen Editwar, sondern gewichte Funktionalität und Nutzbarkeit (grade auch im Bezug auf Relationen) massiv relevanter als Optik. Und ich erwarte bei Fortgeschrittenen schon, dass man auch mal um Hilfe fragt, oder mit den Werkzeugen auf einem dev-Server umzugehen lernt, bevor man seine Vorstellungen und Gehversuche einfach auf den live-Server loslässt, und Stunden von Arbeit anderer Leute (nett gesagt) einfach ignoriert.

Mit changeset/72406766 ist das Thema für mich erledigt. Funktionalität stimmt, Optik auch, vermutlich so wie es ursprünglich gedacht war. Wäre schön gewesen, wäre es sofort so herausgekommen, ohne zwei Stunden lang Changesets mit achavi und JOSM zu parsen – hätte nämlich nur knapp 5 Minuten gekostet.

Das war eine Schnellkorrektur um die Relationen wiederherzustellen.

Hätte ich aufgetrennt? Nein.

Sieht das hübsch aus? Nein – die Verkehrsinseln an sich tun es allerdings auch nicht wirklich ;-P

Ist es funktional? Ja, die Fahrbahnflächen laufen in einem (virtuellen) Knotenpunkt zusammen – es ist nur die Signalisation (Ampel, Fahrspurmarkierung), die definiert ob Abbiegen/Wenden erlaubt ist, oder nicht.

Auch hier: es wäre nicht verboten gewesen, um Hilfe zu bitten. Aber auf gut Glück auf dem live-Server draufloszubasteln, anstatt zumindest auf dem dev-Server den Umgang mit Relationen zu lernen ist im Grunde ein absolutes no-go. Dafür gibt jetzt halt eine Ladung Wienerli... *scnr*

Pardon, aber das ist reine Theoriefindung, die vom Vermessungsamt der Stadt Winterthur wiederlegt wird. Der gesamte _Strassenzug_ zwischen Merkurstrasse und Technikumstrasse trägt die Bezeichnung Bahnhofplatz. Mit einem (Stadt-)Platz (korrekter tag wäre übrigens: place=square) hat dies schon mal gar nichts zu tun. Zudem wäre plötzlich fast jede Kreuzung ein Platz – wofür bei uns wiederum in 80% der Fälle ein "named junction"-tag reichen würde (nein, zwei Blumenbeete und acht Bäume am "überbreiten" Trottoir sind nicht wirklich ein Platz).

OSM basiert stark auf Abstraktion, und anstatt Mapnik et al die Fahrbahnbreiten per interner Vordefinition "raten" zu lassen, könnte man sich in JOSM einarbeiten und aus den freigegebenen OGD-Layern des Kantons die Fahrbahnbreiten ausmessen und angeben. Dann verbinden sich die (zu) dürren Strichlein an Kreuzungen plötzlich zu Flächen.

Wenn man hingegen flächenverliebtem "Malen nach Zahlen" frönen möchte: bitte sehr, aber dann strikt um die vorhandenen Strassenmodelle (way/wire/Vektor) herum, ohne eine Bretzel aus vorhandenen highway-Stückchen zu bauen, die locker zwei Dutzend Relationen zerschiesst, und keine funktionierende Logik mehr besitzt.

Knapp zwei Stunden habe ich gebraucht, um etwas zurückzukorrigieren, was davor nicht im geringsten "kaputt" war. Unter anderem, damit die Stunden die zuvor in die Relationen gesteckt wurden, nicht völlig für die Katz waren. Auch wenn dies höchstwahrscheinlich nicht böswillig war, ist es gedankenlos und despektierlich, wegen "nicht erfüllter optischer Kriterien" die Live-Karte kaputtzubasteln. Dafür gibt es nämlich dev-Server, wo in der Sandbox nach Lust und Laune gebastelt werden kann: osm.wiki/DE:Sandbox_for_editing

HTH

Sofern es tatsächlich einen Imbiss hat, selbstverständlich. Einfach nicht auf die gesamte Fläche (one feature, one element), sondern bevorzugt als einzelner Knoten, dort wo sich der Imbissstand physisch befindet. HTH

theme_park ist für Freizeitparks (Connyland, Europapark, Disneyland...) gedacht, auf welche man in der Schweiz nur selten treffen wird. Tiergehege können passender mit "tourism=zoo" und "zoo=enclosure" getaggt werden.

Für Öffnungszeiten müssen die englischsprachigen Kürzel verwendet werden, keine Anwendung wird etwas mit deutschsprachigen Kürzeln anzufangen wissen. Eine Übersicht der gängigsten Werte findet sich im wiki: osm.wiki/DE:Key:opening_hours

Dito hier, die Strasse ist mit SSV 2.13 (und Zusatz "Zubringerdienst gestattet") signalisiert, die korrekten tags hierfür sind "motorcar=destination" und "motorcycle=destination". Gruss

Hi. Bitte keine iD-Vorschläge unüberprüft übernehmen. Es gibt keinen gültigen access-Wert "*=permit", siehe dazu osm.wiki/DE:Key:access

Auch ist zwingend zu unterscheiden welche Signaltafeln vor Ort aufgestellt sind. SSV 2.14 ist motor_vehicle=no (einschliesslich Motorfahrräder/"Mofa"), aufgrund des taggings (motorcar=* und motorcycle=*) muss ich davon ausgehen, dass es hingegen SSV 2.13 ist (mit Zusatz "Zubringerdienst gestattet" oder ähnlich).

Ich erlaube mir dies wieder zu entfernen, und möchte dir zwar nicht den Spass verderben, Bitte dich aber um etwas mehr Sorgfalt, und die vorhandenen tags genau durchzulesen. HTH und Grüsse

PAZ ist (war?) seit 1990 (Geschäftsaufnahme des ZVV) das gängige Kürzel für Postauto Zürich. Ab "Ausgliederung" aus der Post (2006), bis vor einigen Tagen lautete die volle Bezeichnung "PostAuto Schweiz AG, Region Zürich", seit 5. Juni offenbar "PostAuto AG, Region Zürich". Die Postauto-Konzessionen sind beim BAV ebenfalls nach Regionen gruppiert.

Persönlich bin ich mit dem tagging-Schema recht zufrieden, es eignet sich einfach nicht, um schnell irgendwas hinzuklatschen. ;-) Platform ist im Grunde optional – da Mapnik PTv2 nicht rendert ziehe ich bei guten Luftbildern Linien mit PTv1-tag vor, das gibt dann auch einen besseren Eindruck von der Strassenbreite. Im ländlichen Raum wo nur eine regionaltypische Stele steht, natürlich ein ziemlicher Overkill. In Zürich, wo die Kantenhöhen rund 35 cm (Tram) bzw. 25 cm (Züri-Board für Bus) betragen, hat man gleich potentielle Stolperfallen markiert, wo man Fahrbahn/Haltestelle besser nicht überqueren sollte... oder die Türe vom tiefliegenden Liebkind eine neue Form erhält, wenn man sie dort zu öffnen versucht.

Nur weil _dein_ Renderer die Fahrspuren nicht auswerten kann, ist noch lange nichts falsch, wir betreiben hier weiterhin kein Einzelfahrspurtagging, sondern arbeiten mit abstrahiertem Strassenplanung – weder WYSIWYG, noch "malen nach Zahlen". Die PTv1/v2-Haltekante bezeichnet explizit die Haltekante (aka den Randstein zur Fahrbahnfläche).

Daher (und wegen Fehlern im OSMI) revertiert.

Danke, dir. Nach einigen hundert Elementen nur noch zitterige Finger und Tomaten auf den Augen... :-/

Auch als Baumfreund hat man SI-Einheiten korrekt zu beherrschen. Ob das jetzt bloss ein schlechter Scherz war, oder das Nichtbeherrschen von Kommastellen lasse ich mal offen. Fakt ist, die Einheiten sind vorgegeben, und die korrekte Anzahl Kommastellen einzugeben ist eigentlich elementare Primarschul-Algebra. Mit 700+ CS ist man kein blutiger Anfänger mehr. Bitte in Zukunft etwas mehr bei der Sache sein. Danke schön.

Hi. Gibt es einen bestimmten Grund, dass du Gebäudetags von building=* auf ein nichtssagendes building=yes änderst?

Ach so... ouu, aber dann hast du allen Brunnen auch denselben wikidata-Wert zugewiesen? Dann muss ich das dennoch korrigierten. :-/