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.

Second, traffic_signals are mapped like documented in the wiki[1], in Zürich the last two schemes are in use. Mostly the one with the traffic_signal and the crossing on the same node. There aren't additional traffic signals on the footways, and we don't map physical locations of the traffic_signals.

[1] highway=traffic_signals

First some common sense: we map tracks (railway, tram) separate from the highway elements even if in the real world they actually share the same space. The highway element in itself is an abstraction (a line representing an area). So just because those lines are crossing in OSM, they don't constitute a crossing – again they share the same space.

But it's editors like iD, that can't make sense of it, and expect something that doesn't exist in the real world. In the shared space, where tram tracks occupy the same space, there is simply no such thing as a "tram_level_crossing", that's a spam tag to make iD shut up. It doesn't improve mapping a bit.

Hi, die Syntax der Öffnungszeiten wird hier in einigen Fällen nicht funktionieren. Ein Semikolon überschreibt alle vorherigen Zeitspannen, wenn sie Tage überschreiten. Wenn auf Sa 10:00-02:00 nach Semikolon ein Su folgt, wird die Zeitspanne nach Mitternacht einfach überschrieben – es gilt nur das was unter Su eingetragen wurde. Im Zweifel einfach Komma anstatt Semikolon setzen hilft. Sonst einfach durch das OH-Tool jagen:

https://openingh.openstreetmap.de/evaluation_tool/?lng=de

HTH

Review: stop clicking 'yes' on each and every SUGGESTION(!) that iD makes. "Suggestion" means: get your ass on the ground and confirm locally(!!!1). And if you don't know what the suggestion means, or aren't able to map the change manually (without help) by yourself, you shouldn't change it.

This is a changeset that a bot could have made. I'll wait for other comments, but this is far from acceptable. Learn the ropes, read the wiki, interact with the community. It's not the first time you get feedback for not getting acquainted with local rules, but just doing what iD suggests. You may waste your time if you feel like it, but please don't waste my time or the time of other mappers. TY

Hi. Ich weiss nicht was du mit diesem Änderungssatz bezwecken wolltest, da dein CS-Kommentar nur den Ort, aber nicht den Inhalt beschreibt. Die Unsitte alle möglichen und unmöglichen Objekte miteinander zu verkleben, hat jetzt dazu geführt, dass du unter anderem mit dem Ziehen am landuse (way/123143250)[1] _sämtliche_ damit vernknüpften Objekte verschoben/verzogen hast,[2] sei es der Schwamendiger Friedhof, die SAW-Siedlung, das GZ Hirzenbach, oder verknüfte Wege. Bist du in der Lage das selber zu revertieren? Map47 hat die OSMI-Fehler nämlich bereits gefixt, aber den eigentlichen Schaden nicht erkannt.

[1] way/123143250
[2] https://overpass-api.de/achavi/?changeset=135098281

Again, incorrect sofamapping. It is intentional (by design), that the pedestrian island, narrows the road to one lane in forward direction.

Don't sofamap with outdated imagery. Baslerstrasse is oneway now, and I just fixed it one month ago.

The markers themselves were "disused" – visible in the Orthophoto 2014/15, but removed on the ground. While I couldn't find any confirmation, I suspect the pipeline between Rehalp and Moos had also to be disused at this point. However, the Swissgas map[1] still claims, the pipeline is present. Also the latest revision (march 2023) of 'Richtplan'[2] lists the pipeline as 'bestehend' (existing).

[1] https://www.swissgas.ch/netzkarte/
[2] https://maps.zh.ch/system/docs/are_rp/RegRicht/rsztext.pdf

This changeset doesn't have a valid source. Valid sources for names in Switzerland are BfS Gemeindeverzeichnis, Ortsverzeichnis or GWR. Please provide a source, instead of reverting this incorrect change for the third time (after two accounts were already deleted).

Stop removing bilingual names. Also stop making (mechanical) edits without valid documentation and without proper source.

Quick heads up, as the user has a new account:

* @yannis323/history

* https://community.openstreetmap.org/t/neuer-osm-mitstreiter-mit-diskussionswurdigen-anderungen/97489

* https://community.openstreetmap.org/t/odd-edits-in-italy/97706

On related note: I just reverted three changesets of user "leonardashley87330" (UID18841250), also removing bilingual names in Fribourg. Obviously the user also does not state valid sources for settlement recategorization (either illegal source or mechanical edit). Seems like a pattern stemming from our southern neighbors...

Cheers