Hallo Mumaker,

vielen Dank für Deine Antwort, es ist wirklich einfacher das mal am Stück durchzulesen. Wenn ich das jetzt richtig verstanden habe war mein Fehler, stop_position sowohl an den Halteplatz-Punkt als Objekt als auch an die Relation der Linen zu taggen, oder?

Dann bin ich da tatsächlich auf iD reingefallen und hab für die Relation den Vorschlag übernommen, weil ich die Anpassung auf stop_position da versehntlich auch eingetragen habe.

Passe ich an wo ich es sehe, danke für Deinen Hinweis!

Viele Grüße
bene

My edit was not focused on the potions nor relation of speed and red light enforcement, the "detached" state exist since v1 (see osm.org/node/9811915647/history/1)

As I don't know which directions are monitored, I cannot attach the camera to the road or create a relation.

Hallo Muhmaker,

vielen Dank für Deinen Hinweis.

Ich bin bin mir gerade nicht mehr sicher, in welchen Dokumentationen ich das gelesen hatte, aber wenn ich es richtig im Kopf habe soll die stop_position den eigentlichen "Ort des Anhaltens" im Gegensatz zur Haltestelle definieren. So auch hier erläutert: osm.wiki/Tag:public_transport%3Dstop_position

Das ist so in Teilen auch in der englischen Variante des von Dir verlinkten Wikiartikels unter stop, siehe osm.wiki/Tag:route%3Dbus#Members

Wenn das nicht richtig ist und/oder im ÖPNV-Mapping und/oder in Düsseldorf eine andere Konvention angewendet wird, dann kann ich das sehr gerne berücksichtigen und sowohl Fehler korrigieren als auch in Zukunft beim Mappen beachten.

Ich bin mir gerade nur nicht sicher, welche Dokumentation hier anzuwenden ist. Sollte eine Haltestelle im abstrakten Sinne nicht aus (mindestens) zwei Elementen bestehen? Dem Punkt/Linie/Fläche für die Haltestelle selbst, also wo Fahrgäste warten und ein-/aussteigen und der stop_position auf der Linie/Route?

Viele Grüße
bene

Ja, wirklich besser so, bin zum entfernen irgendwie nicht mehr gekommen. Danke dir

Gab es hier ein Problem? :)

Top! :D Ich war gestern gucken und Du warst schon da. Vielleicht noch eine Frage, weil wir offenbar gleiches verfolgen: Hat das einen Grund, dass Du keine Straßennamen angibst?

Beste Grüße

Machen wir so (y)

Oder an Kreuzungen sind die Übergänge erfasst, passen dann aber nicht mehr zu den Bus- und Straßenbahnhaltestellen oder zur nächsten Kreuzung. Eigentlich ist dadurch regelmäßig das Nahmobilitäts-Routing für den Arsch.

Ich arbeite überwiegend mit dem Luftbild, teilweise in Rückschau mit dem der vorherigen Jahre oder dem für NRW.
Ich schaue mir viele Wege vorher an, meistens lieber Fotos als Notizen. Das Verkehrskataster der Stadt ist aber auch frei verfügbar (so wie alle WMS-Server), wobei das Tagging der Beschilderung wirklich arg ins Detail geht. Manchmal gibt es Straßenaufnahmen bei Mapillary.

Ich fand bisher die Installation und Anwendung von JOSM zu mühsam, aber vielleicht tu ich dem Programm auch unrecht. Ich wollte tatsächlich erst den Seitenraum erfassen und dann durchgängig die Routenrelation verschieben, bin da aber auch um jede Unterstützung dankbar :)

Ja das mit der Zeit ist so eine Sache, der Seitenraum an den großen Straßen ist zum Teil wirklich mau. Mir geht es nicht mal direkt um das Rendering oder die Routenanalyse, sonder um das zum Teil eklatant abweichende Routing für den nicht-Kfz Verkehr. Das fängt bei Pollern an, geht über andere Ampelanlagen weiter und mündet in einer zum Teil völlig abweichend Verkehrsführung. Gerade an stark belastenden Straßen versuche ich das zunächst zu verbessern, die Menge ist aber einfach groß. Dazu kommen noch Details, die zumindest mir in der Regel die Orientierung deutlich vereinfacht. Die Routen-Relationen wollte ich später™ in einem Rutsch anpacken, die Kreuzungen Hennekamp/Mecum und Hennekamp/Witzel haben mir da aber einen Strich durch die Rechnung gemacht. Muss da nochmal hin und mir das angucken, solange keine neues Luftbild da ist.

Ich hab da ehrlich keinen Vertrag mit, dachte irgendwie das oneway:bicycle weniger "invasiv" ist sprich nur die tatsächlich betroffene Verkehrsart ausgewiesen wird. Ich würde mich aber anders jetzt an dem Standard orientieren und auf oneway "umsteigen".

Danke für dein Feedback.

Hi Hendrik,

macht oneway=yes hier und andere Wege einen Unterschied zu oneway:bicycle=yes? Der Weg an sich hat ja keine Richtungsvorgabe, nur die Fahrtrichtung für den Radverkehr ist vorgegeben?

Soweit ich das erkenne, kann das im Routing vom Fußverkehr zu Fehlern führen.

Viele Grüße
Bene

Hi Hendrik,

Danke für Deinen Hinweis :) War mir leider durchgegangen, ich bin auch noch nicht ganz fertig hier, bin dazu aber nicht nochmal gekommen.

Viele Grüße
Bene

Thanks mate :)

Any good reason you reopened a closed road?

Hallo redrace,

dopellt sich die Änderung mit meiner vielleicht?
Ich schlage vor den Weg in der Eigenchaft unverändert, aber als zerstört zu taggen, also "destroyed:highway=track".

Viele Grüße
enemenebene

In der Intzestraße sind keine Parkplätze im Sinne des wikis und als Beschreibung einer größeren Fläche zum Parken, wie z.B. nebenan in der Claßenstraße zwischen Nobis und CARL, osm.wiki/DE:Tag:amenity=parking.

Die vorhandenen Stellplätze sind als "parking:lane:both=perpendicular" an der Linie und mit dieser Änderung nun doppelt erfasst. Ich schlage daher vor, die Flächen weiterhin nicht als Parkplatz zu erfassen, weil das etwas andere beschreibt als Stellplätze am Fahrbahnrand.

Danke, ich schaue mir das im Detail an um das Problem zu verstehen und den Fehler nicht nochmal zu machen. Bin gestern leider nicht mehr dazu gekommen.

Hallo aixbrick,

vielen Dank für deinen Hinweis, ich hab es angepasst.
osm.org/changeset/115049647#map=19/50.76990/6.06103

Viele Grüße
enemenebene

Andersherum wird das Recht abbiegen für Radfahrende und zufußgehende zu spät, nämlich für den Straßenmittelpunkt im Routing angekündigt.

Die Verkehrsinsel ist eine physische Barriere, die anderes Fahren erzwingt, warum also nicht als solche auch aufnehmen?

Hallo aixbrick,

ich bin länger nicht zum Antworten gekommen. Ist jetzt alles an meinernFehlern korrigiert oder muss ich noch etwas verbessern?

Grüße