Hi johsin18,

Zu einem conditional gehört zwingend ein Interval (Anfang-Ende). Wenn das Basler Tiefbauamt erklärt, das Einrichtungsregime bleibt bis Sommer 2026[1], dann werde ich das nicht in Zweifel ziehen. Zweieinhalb Jahre sind mehr als genug Zeit, um den Endtermin gegebenenfalls anzupassen. Und stur auf 'oneway=yes' setzten (und vergessen) ginge natürlich auch – halte ich für eine unsaubere Lösung, da erfahrungsgemäss oft irgendwelche Segmente vergessen gehen.

Das Velorouting habe ich auf den drei Abschnitten beim Zoll tatsächlich vergessen – entweder 'bicycle=yes' auf die 'highway=construction'-Abschnitte oder 'oneway:bicycle=no' auf die drei Abschnitte daneben – oder den Abschnitt einfach krude mit 'highway=cycleway' überbrücken.

Ersteres dürfte am ehesten "man kann sich durchschlängeln" entsprechen, zweiteres ist aufgrund des provisorischen Charakters ebenfalls nicht falsch und für Router wohl eindeutiger. Hab jetzt zweiteres genommen, Ende April 2024 ist ohnehin die nächste Verkehrsphase absehbar, wenn der Verkehr wieder durch (respektive um) den Zoll via Kreisverkehr in die Neuhausstrasse geleitet wird.

Die Anpassungen sind im changeset/146399306[2] enthalten. Kommentar willkommen. ;-)

Grüsse,
d_berger

[1] https://www.tiefbauamt.bs.ch/baustellen-und-projekte/aktuelle-grossprojekte/Freiburgerstrasse.html

[2] changeset/146399306

Würdest du dir freundlicherweise die Zeit nehmen, das wiki zu lesen, bevor du einfach irgendwas zusammenklickst und Fehler am laufenden Band produzierst?

iD ist kein geeignetes Werkzeug um, ÖV-Routen zu warten, das geht nur mit JOSM sauber.

Die Haltstellenelemente werden nicht in einer stop_area_group zusammengefasst, sondern in einer stop_area.

Die korrekte Rolle für eine stop_position lautet 'stop' und nicht 'stop_position'.

Das Auftrennen von Kreisverkehren ist weder produktiv, noch erwünscht, sofern keine zwingenden Gründe vorliegen (z.B. wechselnde Anzahl Spuren im Kreisel).

HTH

Hi. Bitte die Änderungen im CS-Kommentar zusammenfassen.

Und wieso "layer=1"? Strassen auf der Oberfläche sollten _nie_ eine layer-Angabe tragen. Bei iD ist dies meist ein Zeichen, dass ein ahnungsloser Mapper einen (allfälligen) Fehler maskiert. Ich sehe den Grund dafür nicht, und der Validator in JOSM auch nicht...

Jetzt reicht es langsam. Ich habe dich bereits aufgefordert nicht mit veralteten Datensätzen und veralteten Luftbildern zu mappen, sondern deinen Hintern hoch zu kriegen und die Angaben vor Ort zu überprüfen. Jetzt trägst du wiederholt denselben Datenmüll ein, den ich bereits gelöscht habe, da es ihn vor Ort nicht mehr gibt.

Ich werde dies in Zukunft kommentarlos entfernen. Insbesondere auch aus den aktuellen Baustellen im Quartier. Vielleicht hilft es, dann man mal den Kopf einschaltet und etwas mitdenkt, bevor man einfach irgendwelchen Datenmüll "importiert."

Beste Grüsse

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.