Hallo HappySquid,

Statt access=no wäre highway=construction besser, poppt dann in Editor-Apps auch entsprechend auf zum neu anschauen: osm.wiki/Tag:highway=construction

LG Lezurex

access=visitors ist kein gültiger Wert. Für Besucherparkplätze (nicht im Sinne von Kundenparkplätzen) habe ich bisher immer access=destination genutzt. Da hier eine Besucherkarte nötig ist, hätte ich gesagt access=permit passt am besten, die Besucherkarte ist ja die Berechtigung.

note würde ich noch zu description ändern, da note für andere Mapper gedacht ist, nicht für die Datenkonsumenten. Ist sicherlich eine nützliche Info.

Überall sonst auf dem Stadtgebiet wird operator=VBZ genutzt, drum denke ich, sollte das auch hier so bleiben.

Überall sonst auf dem Stadtgebiet wird operator=VBZ genutzt, drum denke ich, sollte das auch hier so bleiben.

Welchen Sinn hat alt_name=Dietikon überhaupt noch? Ich glaube kaum, dass da jemand direkt an den Skilift denkt.

Hallo Teddych,

Da du grad vor Ort warst: Sind die Gebäude 5, 3, 12, 14 und 27a/b schon fertig? Die sind noch als Baustelle eingetragen.

LG Lezurex

Hallo stillhart,

Bitte schau dir nochmals genau an, wie area:highway genutzt wird: osm.wiki/Proposal:Street_area

Konkret sollte es hier also area:highway=track sein. Ausserdem sollten Kreuzungen separat sein und mit junction=yes getaggt werden, bspw. bei Breitloo-/Hohenstein-/Panoramaweg. Wo der highway=* in die area:highway=* eintritt sollte dann auch ein geteilter Node platziert werden. So ist dann mehr oder weniger klar zu welchem highway die area:highway gehört.

Aber ja, das ganze Tagging-Schema ist noch etwas experimentell.

Übrigens: Mit JOSM und dem "Highway areas" style geht das auch viel einfacher :D

LG Lezurex

Data consumers can and should be able to expect such values to be plain text. Requiring them to filter anything out that might get in the way is making the whole process unnecessarily complex, rendering the **structured** data of OSM useless.

I don't care what's e.g. in a description value, it's a freetext field, use emojis there as you want. But almost anything else is structured data which consumers have to be able to rely on. Never ever before have I seen Emojis anywhere in OSM. Furthermore, not every device/font displaying that data actually supports emojis. Yes, it's Unicode, but that doesn't mean every device and font can actually display it.

So, please: Don't use emojis where they don't belong.

Hallo Fabian,

Bis nach Kloten ist dies tatsächlich die A11, ab Kloten wird sie zur A51 als kantonale Autobahn. Auch wenn die Richtungsschilder in Zürich-Nord bereits die A51 kennzeichnen, die Kilometerschilder entlang der Autobahn kennzeichnen die A11.

https://map.geo.admin.ch/#/map?lang=de&center=2685449.67,1256401.5&z=9.349&topic=ech&layers=ch.astra.nationalstrassenachsen&bgLayer=ch.swisstopo.pixelkarte-farbe&featureInfo=default

Kann ich das rückgängig machen?

LG Lezurex

But here it's a guidepost solely for bicycles. I know the problem you describe, but that's not a solution. Data consumers can't do anything with it, and it's unsuitable e.g. for screenreaders.

Seems like it should be something like direction_northeast:bicylcle (but only if it's ambiguous). But I don't know if that combination is actually commonly used/supported yet. Found one similar thing for mtb: https://taginfo.openstreetmap.org/keys/direction_east%253Amtb

I think that way of :lanes mapping is rather confusing, and it adds a lot of tags. But it's in the wiki, so what can I say? That mapping schema probably needs some refining haha. But it's probably the only way to add detailed cycle lane mapping, which I, as a cyclist myself, support, of course. Anyways...

Then I'll just change the slight_left back to through.

Thanks!

What are the emojis for? I think they could be more distracting than useful for data consumers. It's already clear that it's for bicycles with bicycle=yes.

Hi vmicho

osm.org/way/737655605/history/7 I disagree: Turn should reflect what is marked on the ground (which in that case is straight). As the value is mainly used by navigation software, it should match what's marked on the ground and signs. Also, the way you did it is highly subjective, e.g. I'd interpret that as straight on, as we have streets to the left and right. The marking is objective and verifiable.

road_marking should only be used on nodes, see wiki.

The :lanes values do not match the number specified in lanes. But that was already a problem before. Bicycle lanes should not be counted as lanes, unless they're e.g. combined with a bus lane or physically separate. E.g. turn for bicycles can be mapped like this: osm.wiki/Key:turn#Special_turn_indications_for_specific_vehicle_types

Please take another look at this.

Happy Mapping
Lezurex

Hallo Jannis,

Für nächstes Mal: Gebäude bitte nicht einfach löschen sondern, als abgerissen markieren, sprich mit building=apartmens => demolished:building=apartments. Damit wird verhindert, dass sie versehentlich nochmals gemappt werden (bspw. von einem alten Luftbild) und man kann die ganze History behalten, indem man die Linien und Nodes für die neuen Gebäude wiederverwendet.

Ich bin jetzt gerade dran, die projektierten Gebäudeumrisse einzuzeichnen. Eine Frage noch: Die Altwiesenstrasse 136 ist noch nicht abgerissen? Warum nicht? Bisschen komisch, so von einer Baustelle umzingelt zu sein, haha.

LG Lezurex

Wo genau ist hier das Abbiegen markiert? Scheint auf einer Quartierstrasse eher fehl am Platz. Auch sollte das nicht auf der ganzen Länge getaggt werden, gibt ja noch andere Kreuzungen dazwischen.

57.2 ist keine "echte" Hausnummer. Die Nachkommastelle wird genutzt, um einzelne (Neben)Gebäude zu nummerieren, die zu einer Hausnummer gehören. 1a und 1b wären unterschiedliche Hausnummern, 1.1 und 1.2 aber nicht. Diese sind nämlich auch nicht ausgeschildert und damit nicht on-the-ground verifizierbar. Bei der Briefanschrift gibts die ja auch nicht. Deshalb mappen wir die auch nicht in OSM.

Daher ist das schon richtig so, der k Kiosk war mit der entsprechenden Adresse gemappt, die in der Suche auftaucht.

Die Wohnungen sind aber auch noch nicht fertiggestellt. Die sind voraussichtlich erst 2026 fertig und daher natürlich auch noch nicht suchbar. Ich habe die im Bau befindlichen Gebäude in osm.org/changeset/163158207 aus der Amtlichen Vermessung hinzugefügt.

Was den k Kiosk angeht, weiss ich es tatsächlich nicht. Die Migros allerdings ist auf der Visualisierung auf der Projektseite zusammen mit einem Denner zu sehen: https://www.jaco.ch/projekte/areal-kesslerplatz-schlieren Der k Kiosk Node könnte dann einfach zum Denner geändert werden.

Etwas, das in construction ist, ist im Bau und daher nicht für seinen vorgesehenen Zweck nutzbar, also auch nicht zum Einkaufen. Da die Nodes nun mit construction:shop und nicht mit shop gettagt sind, tauchen sie auf Karten auch nicht als solche auf.

Je nachdem welche Suche du nutzt kann es natürlich sein, dass der Index etwas ältere Daten hat. Kannst du mir sagen mit was und nach was du genau gesucht hast?

LG Lezurex

osm.org/changeset/163158207

Hallo Nicolas,

Ich habe dein Changeset rückgängig gemacht, weil wir solche Dinge in OSM nicht einfach löschen, sondern entsprechend markieren. Soweit ich weiss, ist hier ja nach dem Umbau immer noch eine Migros. Daher wäre hier der Prefix construction gut gewesen: osm.wiki/Lifecycle_prefix Damit bleibt der Node samt seiner History nämlich bestehen und kann so immer noch rückverfolgt werden. Das hat dann auch den Vorteil, dass bspw. in StreetComplete eine Quest auftaucht mit der Frage, ob der Umbau schon fertig ist.

LG Lezurex

osm.org/changeset/163157420

Whoops da hab ich beim Reverten wohl noch vergessen den Node vom Way zu entfernen. Danke fürs fixen.