Warum gibt es den Spessart doppelt?

Die Wikidata Einträge als auch die Verweise zu Wikipedia sind unterschiedlich.
Einmal ist wohl der Spessart als Mittelgebirge und einmal wohl der Naturpark Spessart gemeint.

1. Dann ist auf jeden Fall das Tagging der Relationen nicht korrekt.
2. Ich kann mir kaum vorstellen, dass die beiden Gebiete fast deckungsgleich sind. Das muss sich jemand mit Ahnung von den Grenzen da anschauen...

Auf jeden Fall spukt das hier gewaltig 😄

EinKonstanzer wrote:

Auf jeden Fall spukt das hier gewaltig 😄

🤣 Bist du alt...

https://www.youtube.com/watch?v=gmCMgQvvH5c

Es gibt noch eine dritte Relation für den Spessart, die da. Und dann gibt es noch diesen Weg ebenfalls für den Spessart.

1 und 2 sind eindeutig redundant, eine von beiden kann weg.

Ja, von den ersten beiden Relationen (5411343) (3894648) kann eine weg, die wohl - da direkt übereinander liegend - die Kopie des bereits vorhandenen Naturparks durch einen Kartler war. Die Grenzen verwenden auch nicht die admin-Grenzen zu Hessen, also sind sie sowieso nicht so akkurat.
Der Naturraum Spessart (Mittelgebirge, place=region) (6308866) schließt noch im Norden den Hessischen Teil des Spessarts mit ein und orientiert sich an den geomorphologischen Grenzen (Main und Kinzig als das Mittelgebirge umfassenden Flüsse).
Den letzten Way (57776149) würde ich löschen, insbesondere wegen des 1x-igen tags type=mountain_range und der groben Ausführung.
Cepesko

Zur Info: Ich habe mal einen CS Kommentar erstellt für die erste Version von 5411343:
https://www.openstreetmap.org/changeset/33091612
Die andere Relation von mir gefundene Rel ist etwas älter.
Ich habe keine Ahnung, wo die Grenzen tatsächlich verlaufen, daher möchte ich hier nicht selbst etwas ändern.

Habe leider keine Reaktion von Kartler175 bekommen, auch nicht auf PM vom 28.9.
Ich lösche also die Relation
https://www.openstreetmap.org/relation/5411343
weil sie später hinzugefügt wurde und auch die Wege, weil sie nur in dieser Relation verwendet werden.
Dazu lade ich in JOSM die Relation, selektiere alle Nodes und verwende dann die Funktion
"Download parent ways and relations", damit ich nichts lösche, was von anderen Objekte referenziert wird.
Das zieht sich ewig weil es 3909 Nodes sind. Gibt es da einen besseren Weg?
Könnte ja auch einfach alles löschen und schauen, ob der CS durchgeht. Ist wahrscheinlich auch für den OSM Server weniger Arbeit?

Gerd

Wenn du Nodes löschst die von anderen Relationen oder Wegen referenziert werden wirft der OSM-Server eine Fehlermeldung aus, das funktioniert also nicht.

Es ging deutlich flotter, mit etwa 40 downloads die Daten entlang der Wege zu laden. Werde mir vielleicht mal anschauen, ob man das in JOSM verbessern kann.

GerdP wrote:

Es ging deutlich flotter, mit etwa 40 downloads die Daten entlang der Wege zu laden. Werde mir vielleicht mal anschauen, ob man das in JOSM verbessern kann.

Daten in der Umgebung einer Relation runterladen geht auch mit Overpass und around...

Interessant. Werde aber leider aus dem Wiki nicht schlau. Hast Du ein Beispiel?

GerdP wrote:

Interessant. Werde aber leider aus dem Wiki nicht schlau. Hast Du ein Beispiel?

Ich hatte das gerade mit der anderen Spessart-Relation probiert, das liefert allerdings unfassbar viele Daten zurück (http://overpass-turbo.eu/s/saR). Muss nochmal genauer drauf schauen, ob man da noch was machen kann.

GerdP wrote:

Es ging deutlich flotter, mit etwa 40 downloads die Daten entlang der Wege zu laden. Werde mir vielleicht mal anschauen, ob man das in JOSM verbessern kann.

Ich mache:
- im Relationen-Editor "Elemente herunterladen"
- im RE "Elemente auswählen"
- Weitere Werkzeuge/Herunterladen entlang

Das reicht mir eigentlich.

Gruss
walter

wambacher wrote:

GerdP wrote:

Es ging deutlich flotter, mit etwa 40 downloads die Daten entlang der Wege zu laden. Werde mir vielleicht mal anschauen, ob man das in JOSM verbessern kann.

Ich mache:
- im Relationen-Editor "Elemente herunterladen"
- im RE "Elemente auswählen"
- Weitere Werkzeuge/Herunterladen entlang

Das reicht mir eigentlich.

Gruss
walter

Das hatte ich auch probiert, aber das download_along plugin scheint damit ein Problem zu haben. Jedenfalls passierte lange Zeit gar nichts.
Mit einem einfachen natural Polygon kam sofort eine Reaktion.

GerdP wrote:

Das hatte ich auch probiert, aber das download_along plugin scheint damit ein Problem zu haben. Jedenfalls passierte lange Zeit gar nichts.

Das war bei mir auch so, im Kommandozeilen-Fenster sieht man jedoch mehrere Minuten lang, wie irgendwelche Bounding Boxes berechnet werden. Danach darf man dann den Download der 66 BBOxes bestätigen. Leider hat der Download dennoch nicht funktioniert, weil irgendeine der 66 BBoxes zu groß für den Server war 🙁

GerdP wrote:

Das hatte ich auch probiert, aber das download_along plugin scheint damit ein Problem zu haben. Jedenfalls passierte lange Zeit gar nichts.
Mit einem einfachen natural Polygon kam sofort eine Reaktion.

Hängt nur von der Komplexität/Größe der Relation ab. Und das kann dauern. Aber im Endeffekt ist es immer noch schneller als alles manuell zu laden.

wambacher wrote:

Hängt nur von der Komplexität/Größe der Relation ab. Und das kann dauern. Aber im Endeffekt ist es immer noch schneller als alles manuell zu laden.

Habe einen Patch der das Berechnen deutlich schneller macht, siehe https://josm.openstreetmap.de/ticket/15408
Der download selbst dauert natürlich trotzdem...

GerdP wrote:

wambacher wrote:

Hängt nur von der Komplexität/Größe der Relation ab. Und das kann dauern. Aber im Endeffekt ist es immer noch schneller als alles manuell zu laden.

Habe einen Patch der das Berechnen deutlich schneller macht, siehe https://josm.openstreetmap.de/ticket/15408
Der download selbst dauert natürlich trotzdem...

Das Beispiel war recht ergiebig, es gibt auch hier einen neuen Patch: https://github.com/drolbr/Overpass-API/issues/440 😎