Korrekt gemappte Gebäude (in diesem Fall Garagen) ohne hinreichende Begründung zu löschen gehört sich nicht. Wenn sie aktuell abgebrochen werden, schreibt man dies bitte so in den CS-Kommentar und setzt den lifecycle-Prefix 'demolished:*', da sie im Luftbild und in der amtlichen Vermessung nach wie vor vorhanden sind.

Hi, bei way/952386872[1] hast du die Zugangsbeschränkung von 'no' auf 'designated' geändert. Bist du dir bewusst, dass dies das Gegenteil von 'no' ist und eine verpflichtende Benutzung[2] impliziert? Das sind bei uns insbesondere die blauen Signalisationen 2.60 (Radweg), 2.61 (Fussweg), 2.62 (Reitweg), 2.64 (Busfahrbahn), sowie Kombinationen davon.

Die häufigste Lockerung von 'no' ist in bewohntem Gebiet 'destination' (Zubringerdienst, Anwohner, Besucher), in unbewohntem Gebiet 'agricultural' und/oder 'forestry'.

Kannst du dies bei Gelegenheit überprüfen?

HTH

[1] way/952386872
[2] osm.wiki/DE:Key:access

Hi mdk, beim Bearbeiten dürfte way/21399780[1] ungewollt verrutscht sein.[2] Ich habe mir daher erlaubt das Objekt mit changeset/135762000[3] zurückzuschieben. HTH

[1] way/21399780
[2] https://overpass-api.de/achavi/?changeset=135755775
[3] https://overpass-api.de/achavi/?changeset=135762000

There's neither SSV 2.46 (Wenden verboten), nor SSV 6.01 (Sicherheitslinie) signed on ground. So while it may not be feasable, and doesn't really make much sense, it's not illegal.

While turn restriction 15797752 might be debatable, turn restriction 15797753 is perfectly legal, and therefore wrong.

Please elaborate.

Neither of those turn restrictions exist on the ground. While turn 15797910, might not be very clever, because of the green pedestrian traffic signal during the same phase, turn 15797911 is perfectly legal.

What's the source for your change?

At least that's specific. However, I *do* count two lanes: one for the bus (and bicycles), one for the other traffic. Otherwise there probably should be three loops?

Also, you should specify your data sources, so it can be verified.

Passt doch bitte eueren Auswerter an, wenn irgendwo 'bus=*' mit irgendeiner Freigabe steht [yes|designated|offical] (oder besser: alles ausser NO), dann wird das logisch auch für Notfallfahrzeuge gelten. Auch irgendetwas mit '*=destination'.

Beziehungsweise es ist noch viel einfacher: das einzige das explizit getaggt werden muss, sind die Objekttypen 'footway', 'cycleway' und 'path', da einzig diese gemäss Definition _nicht_ für zweispurige Fahrzeuge geeignet sind. An der Seepromenade macht es dann beispielsweise Sinn, wenn diese angeblichen "Pfade" mit emergency=yes getaggt werden (sofern Breite von 2,55 m gegeben ist). An regulären Strassentypen macht das keinen Sinn, dann sind schlussendlich nur barrier-Objekte ausschlaggebend und nicht die rechtliche Signalisation nach SSV. Niemand fährt Intervention gemäss SSV, sondern im Zielgebiet nach Fahrbahnbreite. Logisch?

No such restriction exists. Talk to your routing engine dev about angles over 120°, but that's not a map data problem.

The aerial imagery is pretty clear, don't map for mediocre routing engines. Thank you.

Now I'm really getting aggravated. Seven years ago I started an intense on-the-ground(sic!) spree, that took me 18 months, just to prove Osmose wrong with it's idiotic "99,9% of navigation data implies, that...". No it doesn't! There's signage. Yes, only the 6 tenants of the building with their motorcar elevator will benefit. Still, it's indended signage, so stop "implying" things that don't exist OTG. There's signage – don't invent it.

And stop mapping for *idiotic routing engines*. Force their developers to implement barriers like a bollard properly.

I will not accept such junk data implementations, just because some devs (or their userbase) are idiots.

Thank you.

Sorry, but this change isn't correct, there's SSV 5.01 (Distanztafel) below SSV 2.02 (Einfahrt verboten), so the oneway starts at Beustweg. Second, the bollard has an implicit default, so the highway doesn't need splitting for (incorrect) restrictions. In fact the only missing tag is a mofa=yes (SSV 4.09: Sackgasse, ausser Velo/Mofa).

Fixed with changeset/135617177.

Please don't add temporary restrictions due to construction works. Also, it's not oneway for public transport.

Sorry, I forgot I switched to manual closing yesterday; reverted while still open, resulting in this zero diff changeset with large bbox. :-/

I'm sorry, I didn't mean to offend – I'm rather tone-deaf, especially in foreign languages.

The problem with iD is, that it's the only editor that adapted the *unapproved* (and inactive) proposal to use 'crossing=marked'. So what those developers do is basically fueling an edit war, by calling the approved tagging outdated and enabling iD users to act out the opinion of the iD devs through what would be considered an automated edit, in any other case.

This is not OK, and neither JOSM, nor Vespucci suggest such semi-automated edits by themselves. They stick to the approved tagging scheme from the wiki. The french language version of the wiki[1] doesn't even recognize the 'marked' variant. And whatever reason for introduction, it has become obsolete with the approval of the 'crossing:markings' key.

Changing the approved tag 'uncontrolled' to the unapproved 'marked' just because iD lies about the status, is quite offensive to all the users that stick to the wiki. In any other case this would be considered trolling, however in this case the trolls are the iD devs. Please, don't play their game. That doesn't improve the map data.

Just because iD "warns" about something frantically it doesn't mean that something is actually wrong. And sometimes the suggested fixes don't improve anything; in worse cases they just mask errors, which makes it near to impossible to identify them.

So map with purpose and don't get distracted. iD is just a tool, and not a reference for good mapping practices. ;-)

[1] osm.wiki/FR:Key:crossing

Ich bin nicht sicher, ob eine Abfrage in dieser Art möglich ist; die Unterscheidung zwischen fehlerhafter Syntax und gezielter Nutzung der Syntax ist nicht ganz trivial.

Man müsste bei xx:aa-yy:bb auf yy<xx OR yy>23 prüfen und if true ein nachfolgendes Semikolon suchen. Wo dies zutrifft wäre dann manuell zu überprüfen, ob die Syntax falsch ist. Könnte man sicher als Tool oder Prüfroutine basteln, mir ist allerdings keines von beiden geläufig.

Oder man bastelt sich etwas ganz simples wie die Suche nach einem Semikolon im OH-String:

nwr["opening_hours"~";"];

Das wird natürlich (fast) alles zurückliefern, insbesondere wo ein "PH off" enthalten ist. ;-)

A propos 'off': mit dem Aufzählen von regelmässigen Ruhetagen hat sich schon mancher Mapper völlig unnötig selber ins Bein geschossen.

Tut mir leid, aber in diesem Änderungssatz war keine einzige Änderung korrekt. Die Signalisation an der Brücke ist SSV 2.14 (motor_vehicle) und weder SSV 2.13 (motorcar+motorcycle), noch SSV 2.01 (vehicle). Und die Brücke ist garantiert keine Hauszufahrt (driveway). 'access=yes' ist auf Strassen der default-Wert, den setzt man nie.

Wieso liest du dich nicht ins OSM-Wiki ein? Einfach beliebige Änderung vorzunehmen und zu hoffen, dass irgendwas davon stimmt ist der denkbar schlechteste Ansatz um Kartendaten zu verbessern.

Das hat geklappt. Hab es im changeset/135219395[3] rückgangig gemacht und gleich einige der 'Schönheitsfehler' behoben, sprich die redundanten Flächen vereint. Die landuse Überlappungen habe ich im changeset/135220440 korrigiert. Im Prinzip macht es nichts aus wenn sich die Flächen überschneiden – nur auf jede Fläche einen (denselben) Namen zu kleben, ist unnötig zumal einige der Flächen noch lange Baustellen bleiben werden. Die können erst neu bebaut werden, wenn das ASTRA die Arbeiten abschliesst und die Grundstücke wieder freigibt, was kaum vor 2025 der Fall sein wird.

[3] changeset/135219395

And also please don't add defaults. On crossing=unmarked the addition of crossing:markings=no is redundant. On 'Trottoirüberfahrt' (not sure how it translates, ask Google for pictures) it's physically impossible to have a crossing:island. The default is always "crossing:island=no", it's just the questmakers that loath the idea of implicit defaults. We generally define objects by what they are (*=yes), and not by what they aren't, because that would be an endless list of useless data. With explicit sidewalk mapping, we have (ten-)thousands of "crossing", that aren't real crossings but just an acknowledgement, that a road passes over a sidewalk (pedestrian priority, and vehicles have to give way). This requires to think about mapping, and not just add tags because iD or StreetComplete suggest them.

Use the tag crossing:island only where crossing islands actually exist – however if the highway element is split around such islands "crossing:island=yes" is incorrect, because the node only represents the segment leading to the crossing island. That's again abstraction: you have an unsplitted way – you have to do an abstraction and get to add island=yes; you have a splitted way – no abstraction anymore and no island tag to add.

Also: a crossing island (or transit stop island) is _not_ a traffic calming element, this one[2] is. And here again: if the highway elements are splitted around, you don't get to tag it, because traffic_calming tags are designed as an abstract (node) in another abstract (way).

[2] https://maps.zh.ch/s/plxyespw

Don't put a layer on a highway, just because iD suggest it. It just conceals errors. There might be a building_passage missing. That's again something to make iD shut up, it doesn't improve anything. Same goes for noexit=yes, that's a tag to suppress warnings, it seldom improves mapping.