Danke, aber: nicht die Relation rausnehmen, sondern nur das Extra-Gleis, die Extra-Stop-Position und die Extra-Platform aus den Relationen entfernen.

Gruß,
Toni

Der Browser-Editor iD ist für Relationen mittelmäßig bis schlecht geeignet. Hierfür lohnt sich mittel- und längerfristig der Einstieg, die Installation von JOSM (josm.openstreetmap.de)

Servus,

die Zug-Relationen sind nach public_transport:version=2 (PTv2) gemapped und hier wird für jede Variante einen eigene Relation angelegt.
Für Züge ist das in der Regel nicht sinnvoll, wie hier. Bei (Regional-)Bussen macht es dagegen Sinn, wenn diese mal Dorf A, ein andermal Dorf B anfahren.

Ich denke, hier könnte man die beiden Ausnahmen ausklammern. Der Aufwand hierfür eigenen Raltionen anzulegen lohnt nicht, es se dann man nimmt die Abfahrzeiten noch mit in die Relation rein (opening_hours).

Was die Karten und Programme angeht:

- OSMAND macht schon ÖPNV-Routing

- changeset/95000863#map=13/50.7737/12.1195&layers=T

- changeset/95000863#map=13/50.7737/12.1195&layers=O

ist identisch zu

- http://öpnvkarte.de

- http://openptmap.org/?zoom=15&lat=50.77937&lon=12.0813&layers=B0000TFT hier poppt sogar die DB-Fahrplanauskunft auf, wenn man auf eine Haltestelle klickt.

Und dann noch ein genereller Überblick auch unter "Public Transport"

- https://geohack.toolforge.org/geohack.php?project=osm&pagename=M%C3%BCnchen&language=en&params=48.139_N_11.566_E_type:city

Viele Grüße,
Toni

Hi Wolfgang,

wir hatten noch kurz per PM Kontakt, diesen Aspekt allerdings nicht angeschnitten.

Danke, und viel Grüße
Toni

Hallo InnBiker,

der Bayernatlas ist keine geignete, keine erlaubte Quelle. Wir hatten schon eine Abmahnung.

Ich werde die Änderung umgehend rückgängig machen.

Viele Grüße,
Toni

Hallo soilinvestigator83,

bei den Zug-Relation von RE 3 stimmt nun was nicht.

In beiden Relationen sind nun jeweils beide Gleise und Bahnsteige von Berga (Elster) drin. Das ist in der Regel noch der Fall. Die beiden Relationen beinhalten jeweils nur eine Fahrtrichtung und somit in der Regel auch nur jeweils ein Gleis/einen Bahnsteig pro Bahnhof.

https://ptna.openstreetmap.de/results/DE/SN/DE-SN-MDV-Analysis.html#train_RE_3

Viele Grüße
Toni

Hab's schon geändert ... und viele - ganz alte - Unstimmigkeiten

Servus,

stimmt das, dass man hier überhaupt nicht zufuß lang kann?

- foot=no

- sidewalk=none (von mir vor kurzem eingetragen?)

- Ein Weitwanderweg führt hier entlang.

Gibt es hier evtl. doch einen Sidewalk?

Gruß,
Toni

Hi srikmar,

I don't think this is correct.

As this is a residential area and not farmland, farmyard or forest even the Bachstraße is wrongly tagged as "track" - IMO.

Best regards
Toni

Servus wies1,

eventuell schon bekannt? Wir haben da zwei Tools zur Unterstützung der Qualitätssicherung bei ÖPNV-Linien.
Die helfen ungemein, die Relationen fehlerfrei zu mappen.

1.) OSM-Inspector mit Analyse von Stops und Routes: http://tools.geofabrik.de/osmi/?view=pubtrans_routes&lon=8.57602&lat=48.56407&zoom=10&overlays=ptv2_routes_,ptv2_routes_valid,ptv2_routes_invalid,ptv2_error_,ptv2_error_ways,ptv2_error_nodes

2.) PTNA https://ptna.openstreetmap.de

Viele Grüße,
Toni

Servus Busbahnhof,

bitte die zugehörigen route_master ebenfalls berücksichtigen.

Gilt "landesweit" (nur) für MV oder "bundesweit"?

https://ptna.openstreetmap.de/results/DE/DE-Bahnverkehr-Analysis.html

Viele Grüße,
Toni

Hi Andreas, danke für das überzeugende Beispiel. Ich sehe, dass Nominatim hier für die Suche mal wieder den nächstgelegenen Place-Node heranzieht - bekanntes "Problem" oder eher Verfahren.

Die place-Polygone alleine habe einen Nachteil: sie erzeugen keinen Namen des place auf der Karte, das scheint in Mapnik und anderen Renderern ohne weitere Attribute ("landuse", aber das passt von der tatsächlichen Nutzung her nicht) nicht zu gehen. Dann muss wohl auch der plave-Node stehen bleiben, auch wenn das dopplete name= bedeutet.
Ich revertiere meine Änderungen.

Viele Grüße,
Toni

You're welcome!

Br
Toni

... and the imagery is as of Oct 12, 2019, so the temporary signs should have been removed in the meantime.

BR
Toni

Hi asnghpi,

thanks for the feedback.

There are two indications that this is a temporary restriction:

1) see the yellow sign at the right "Umleitung" which means "Detour"/"Redirection" and this is usually set when there are temporary constructions which limit the access

2.) the sign "straight on" (not: "oneway") is not fixed/anchored into the ground but rather mounted into a socket so that the sign can easily be (re)moved - same for the "Umleitung" sign though

Best regards
Toni

solved with

access:conditional = no @ (2020 Oct 19-2020 Nov 27)

it is temporary and finished at 2020-11-27:

https://stadt.weimar.de/aktuell/presse/mitteilung/bushaltestellen-im-bereich-der-marcel-paul-strasse-allstedter-strasse-werden-barrierefrei/

And they say there: road is completely blocked not just a oneway

But why does Amazon-Logistics map so weird? Not the first time though!

Hi asnghpi,

according to MKnight, this could be a temporary deviation. Do you have any information, imagery which shows why such a road is suddenly turned into a oneway and for how long?

BR
Toni

Hi Andreas,

> "... und ein *zusätzliches* place-Polygon ist nicht korrekt ..." Würde ich so nicht unterschreiben :-)

bezog sich vornehmlich auf das "zusätzlich" ... doppelt gemappte Information, ansonsten spricht nichts gegen "Fläche", wie es ja im Wiki steht.

Ich hatte das ungenaue place-Polygon zugunsten des bei uns üblichen place-Nodes gelöscht.

Ein "einfacher" Revert würde die doppelt gemappte Information fälschlicherweise wieder herstellen. Da wäre dann mehr zu tun.

Viel Grüße,
Toni

Servus Andreas,

nicht alle waren so "willkürlich" wie ich das behaupte, dennoch sind die Flächen in der Regel durch keine Bebauung, Grenzen, ... verifizierbar.
Straßenschilder als solche kann man auf dem Way/der Straße mappen, das ist dann für Navis sogar besser auswertbar ...

Klar, der place-Node sagt nichts über die Ausdehnung aus, diese Vorgehensweise ist jedoch die allgemein übliche und ein *zusätzliches* place-Polygon ist nicht korrekt.

Die allgemeine Vorgehensweise scheint sogar place-Nodes mit Name zu bevorzugen, vor landuse=residential mit place=* und name=*, welches ja nur die bebaute Fläche umfasst und auch keine Grenzziehung darstellt (Verwaltungs-technisch gesehen).

Ich hatte im größeren Umfeld von Rosenheim/München/...zur Verifikation meines Vorgehens auch eine Overpass-Turbo Abfrage mit 'place'~'.' auf nwr gemacht: diese place-Polygone gab es (fast) nur in in dem Bereich, wo ich gelöscht habe.

landuse=residential mit place=* und name=* halte auch ich nicht für OK.
place-Polygone, nur mit place=* und name=* sind mMn sogar "schlimmer" als die landuse=* ...

Soweit meine Argumente und "Einschätzungen" ...
Wenn du anderer Meinung bist und den alten Zustand wieder herstellen möchtest:
Ich haben in diesem CS nur diese Änderungen gemacht, plus die selbe Änderung kurz vorher für "Lack" im Norden von Stephanskirchen.
Ein Revert ist somit problemlos.

Viele Grüße,
Toni

Sorry, aber ich glaube nicht, dass der Kunstturm das gesamte Gelände umfassen wird mit seinen 16 Stockwerken.
Wenn ich mir den nördlichen Teil des Geländes anschaue, wird dort wohl der Turm entstehen, oder?

Und: wir mappen nur real existierende Dinge. Verschattung von zukünftigen Gebäuden bitte anders simulieren, nicht bei OSM.

Ich werde den Kunstturm wieder löschen.

Gruß
Toni