Hilfe bei Mulipolygonen benötigt / Fehler in JOSM korrigieren

Hallo Tippeltappel,

da ist wohl so einige schiefgelaufen...

tippeltappel wrote:

Was bedeutet die Angabe <different> in dieser relation: http://www.openstreetmap.org/browse/relation/1184895

vergleicht man
http://www.openstreetmap.org/api/0.6/relation/1184895/6
http://www.openstreetmap.org/api/0.6/relation/1184895/7

so erkennt man dass du in dem Changeset die Rolle von inner auf <different> gesetzt hast.
Das kommt wohl, wenn man mehrere Elemente markiert hat. Im deutschen JOSM steht dann <verschieden>, aber normalerweise wird das dann nicht als Wert gespeichert.

Dir bleibt wohl nichts anderes übrig, als die Relation der Version 6 wiederherzustellen nach folgender Anleitung:
http://wiki.openstreetmap.org/wiki/DE:J … herstellen

Und das für jede der Relationen.

Wenn du mit deinen /browse/relation-URLs nicht weiterkommst, sind die /api/0.6/relation-urls meist noch brauchbar. Zur Not die Adressleiste des Browsers abändern.
Mit /versionsnummer dahinter kannst du die einzelnen Versionen vergleichen, ohne die history bemühen zu müssen.

Generell solltest du Multipolygone erst komplett laden, und dann Reparationsversuche starten. Sonst gibts Kleinholz mit Elementen, die du nicht runtergeladen hast.

Gruß,
ajoessen

Danke, ajo

Habe mir die Anleitung genau durchgelesen.
Trau mich im Moment aber nicht so recht an diese hin und her Kopiererei ran.
Die ganzen Änderungen von mir würd ich löschen, bzw. das Multipolygon auf die erste Ursprungsversion zurücksetzen.
Dasselbe gilt auch für andere Multipolygone in diesem Bereich, wenn da was angemeckert wird.

Dann würd ich alle Daten frisch herunterladen (also die bisher auf meinem Rechner upgedatete Datei in Archiv oder besser noch Papierkorb schieben) und mir in der neuen Datei angucken, ob da immer noch was angemeckert wird. Wenn ja, berichte ich. Werde nicht noch einmal an den riesigen Polygonen ohne Rückfrage rumschrauben.

Gruß
tippeltappel

Du kannst ganze changesets einfach Rückgängig machen. (JOSM Plugin)
Wenn Du mit mehreren changesetzs die gleichen Objekte geändert hast, dann musst Du mit dem letzten changeset anfangen mit dem zurücksetzen und dann alle nahc der Reiche durchgehen.

Ich kann Dir anbieten die changesets rückgängig zu machen wenn Du mir sagst welche changesets revidiert werden sollen.
Dabei drängt aber die Zeit denn jede Änderung die jetzt dazukommt macht die Sache schwieriger.

Danke, nightdive.

Die von ajo beschriebene Vorgehensweise finde ich eigentlich am sympatischsten. Nach so etwas hatte ich gesucht. Ist zwar ziemlich umständlich diese Vorgehensweise. Aber sie nimmt nicht auch automatisch andere Dinge mit, die man besser nicht anpacken sollte.

Es geht mir nicht darum, alles in einem Rutsch in den Müll zu schmeißen, sondern gezielt die kaputten Dinge anzupacken.
Da deren Historie noch sehr übersichtlich ist, sollte das gehen.

Meine größte Sorge ist, daß sich bei den großen MPs mein Rechner aufhängt und noch mehr Chaos anrichtet.
Das ist einer der Hauptgründe, warum ich mich da nicht ran trau.

Falls jemand die von ajo verlinkte Vorgehensweise bereits kennt und darin fit ist:
Ich mach mir gern die Arbeit und suche die einzelnen MPs heraus und sehe nach, auf welche Version zurück gesetzt werden muß.

Bei kleinen MPs werde ich das später noch selbst probieren. Nur bei den riesigen Monstern hab ich Zweifel, daß das funktioniert.

Man sagt ja gerne: "Versuch macht klug ... " 😉
Aber wenn meine Stümpereien anderer Mapper Arbeit zerschießen, dann find ich das schon megapeinlich und möcht herausfinden, wie ich das künftig vermeiden kann.

Viele Grüße
tippeltappel

Hi,

hab mir Version 5 von 1184895 angeschaut und das ist bereits fehlerhaft:
Einige (11) kleine Wege sind mit "inner" gekennzeichnet, obwohl es "outer" sein müßten.

Bereits Version 1 ist im jetzigen Zustand mMn auch nicht mehr "sauber", da Du z. B. daraus den Weg 78279059 vorgestern abend gelöscht hast,
der (und andere) müßten wieder hergestellt werden.

Eine Menge Arbeit ...

Ciao,
Frank

wenns keiner macht, würde ich morgen Abend mal die Relation http://www.openstreetmap.org/browse/relation/1185739 neu erfassen. Meiner Meinung nach wurde das Outer Polygon gelöscht. Ich hatte schon das Vergnügen, mit riesigen MPs zu arbeiten.

Vielen Dank für Eure Mithilfe. 🙂

@ kellerma
Wenn die Version 1 von mir erzeugt wurde, kann/muß sie komplett rausgeschmissen werden.
Das ist dann ein versehentlich erzeugtes Duplikat von einer bereits vorhandenen Relation. 😐
Hoffentlich kann man die dann auch noch finden.

Weiter oben hab ich ja bereits Multipolygon-Relationen angegeben, die abgesehen von den Fehlern identisch sind.
Da mein Rechner teilweise beim Öffnen der Chronik hängen blieb, konnte ich nicht bei allen prüfen, welche auf der Originalversion (oftmals von http://www.openstreetmap.org/user/masaminh) basiert.

@ SunCobalt
Wenn Du Duplikate der Wald-Multipolygon-Relationen findest, kannst Du getrost wegschmeißen, was in der 1. Version auf mich verweist.

So wie es aussieht, habe ich diese Duplikate letzte Tage ungewollt und unwissentlich durch einen fehlerhaften Datenabgleich mit JOSM erzeugt.
Als ich das (siehe oben) revidieren wollte, ging das leider auch daneben.

Langer Rede kurzer Sinn:
Wald-Multipolygon-Relationen mit meinem Namen gehören alle in die Tonne. 🤔

Ich gucke mal, welche Chroniken ich jetzt öffnen kann und poste dann meine Erkenntnisse.

Danke, daß Ihr mir unter die Arme greift!!!

Ich hoffe, es tröstet ein wenig, daß ich dafür das Straßennetz von Kushiro bald fertig habe.
Diese Arbeit ist mein Hauptziel. Die Wälder wollte ich gar nicht anpacken.
Als ich das Mappen dieser Stadt am Meer und im Moor begann (laut Wiki die kälteste von Japan), war außer ein paar Hauptstraßen (rot, grün, orange) so gut wie nichts da.
Und jetzt ... 🙂

Und die von JOSM angemeckerten Brückenlayer kommen auch noch nach und nach.
Das sind die Feinarbeiten.
Nur die angemeckerten Tags (road, unclassified road) laß ich erst mal.

Viele Grüße
tippeltappel

Hi,

tippeltappel wrote:

@kellerma
Wenn die Version 1 von mir erzeugt wurde, kann/muß sie komplett rausgeschmissen werden.
Das ist dann ein versehentlich erzeugtes Duplikat von einer bereits vorhandenen Relation. 😐
Hoffentlich kann man die dann auch noch finden.

Weiter oben hab ich ja bereits Multipolygon-Relationen angegeben, die abgesehen von den Fehlern identisch sind.
Da mein Rechner teilweise beim Öffnen der Chronik hängen blieb, konnte ich nicht bei allen prüfen, welche auf der Originalversion (oftmals von http://www.openstreetmap.org/user/masaminh) basiert.

Mmh, hab' mich wohl etwas missverständlich ausgedrückt.

Die Relation 1184895 ist in der Version 1 von masaminh, da aber aber dort der gelöschte Weg 78279059 enthalten, muß
zusätzlich zur auf Version 1 zurückgesetzten Relation 1184895 auch noch der Weg un-deleted werden 😉

Falls die Historie einer sehr langen Relation via
http://www.openstreetmap.org/browse/rel … d>/history
nicht (mehr) klappt, kann man ja die Ur-Version per
http://api.openstreetmap.org/api/0.6/<relation-id>/1
noch anschauen.

Sehe gerade, dass Nightdive fleißig am werkeln ist.

Ciao,
Frank

Ich bekenne mich schuldig die Änderungen reverted zu haben bevor es nicht mehr möglich ist wegen zu vieler nachfolgender Änderungen die es extrem kompliziert bis unmöglich machen.
Es sollte eigentlich alles wieder ok sein

@Nightdive
Rel. 1187042 und 1171308 schauen sehr ähnlich aus?

Ciao,
Frank

Danke Nightdive
Ich denke nicht, daß Du mir irgendwas kaputt gemacht hast, da die Änderungen an den MP-Relationen größtenteils in separaten Changesets steckten. 🙂

Für mich stellt sich nach Durchsicht der Historien der von mir angefaßten MPs die Situation folgendermaßen dar:

http://www.openstreetmap.org/browse/rel … 95/history
erste Version masaminh (Sonntag, 19. September 2010, 23:22 Uhr)
letzte Version nightdive
sehr große MP-Relation
outer ist wieder vervollständigt
scheint in dieser Anzeige ok zu sein

http://www.openstreetmap.org/browse/rel … 39/history
erste Version masaminh (Montag, 20. September 2010, 22:41 Uhr)
letzte Version nightdive
sehr große MP-Relation
scheint zumindest in dieser Anzeige ok zu sein

http://www.openstreetmap.org/browse/rel … 37/history
letzte Version nightdive
sehr große MP-Relation
History kann bei mir nicht angezeigt werden
Karte wird nicht geladen

http://www.openstreetmap.org/browse/rel … 08/history
erste Version masaminh (Freitag, 10. September 2010, 23:30 Uhr)
letzte Version nightdive
kleine MP-Relation
scheint ok

http://www.openstreetmap.org/browse/rel … 42/history
erste Version masaminh (Mittwoch, 22. September 2010, 00:33 Uhr)
letzte Version nightdive
kleine MP-Relation
scheint ok
die Flächen scheinen mit der MP-Relation 1171308 identisch zu sein (hat kellerma gerade auch gepostet)

Bei letzterer MP-Relation scheint es Weg-Duplikate zu geben.
Ob sinnvoll oder nicht, kann ich im Moment nicht nachvollziehen.

Ich besorge mir dann mal einen neuen Datensatz für JOSM und gucke mir an, was das Programm bei der Datenprüfung zu meckern hat.
Wenn ich dann Hinweise auf doppelte Wege finde, melde ich mich.
Für heute reicht's aber erst mal.

Herzlichen Dank an Nightdive, der meinen Mist in einer "Nacht-und-Nebel-Aktion" (Nomen est Omen! 😉 ) aufgeräumt hat.

tippeltappel

kellerma wrote:

@Nightdive
Rel. 1187042 und 1171308 schauen sehr ähnlich aus?

Das muss ein Fehler vom ursprünglichen Import gewesen sein.
Es waren alle outer/inner ways doppelt vorhanden und jeweils Mitglied in eineer Relation.

Ich habe die Relation und die ways gelöscht.

Die Neugier hat gesiegt ....

Die Reparaturen sehen gut aus.
Ein paar meiner Fehlerkorrekturen an Straßen und Wegen wurden wieder zurückgesetzt.
Nicht der Rede wert. Das bring ich beim nächsten Mal wieder in Ordnung.

Komischerweise haben einzelne Wege jetzt "Zacken".
Soll heißen, da tanzen einzelne Punkte aus der Reihe.
Wie das wohl entsteht. Hmmm. *grübel*
Die find ich aber beim Absurfen der Gegend.
Irgendwann bekommt man einen Blick für so was.

Ok

Jetzt aber Schluß. 😉

Gruß
tippeltappel

Nachdem Nightdive die oben aufgeführten MP-Relationen überprüft und instandgesetzt hat, ließ ich heute in dem Bereich eine Prüfung von JOSM durchführen. Ergebnis (ohne Details):
Es werden zahlreiche Dopplungen angemeckert.
Es sieht aus, als seien die Mitglieder verschiedener kleiner MP-Relations-Einheiten dupliziert und dann in die Monster-Relation http://www.openstreetmap.org/browse/relation/1177937 eingebunden worden.
JOSM zeigt dafür über 500 Mitglieder an.

Was macht man jetzt damit?

Da ich keine Lust habe, mir damit noch einmal Stress einzuhandeln, schicke ich angemeckerte Polygone dieser Sorte jetzt in die Ignore-Kiste.

Hier im Forum wurde ja bereits wiederholt darüber diskutiert, wie sinnvoll große Multipolygon-Relationen sind oder nicht sind.
Das aktuelle Beispiel zeigt meines Erachtens, daß man sich mit solchen monströsen Konstruktionen keinen Gefallen tut.

Vielleicht mag einer der Pro-Verfechter das Teil ja mal sichten und mir erklären, wo der Vorteil so einer Relation zu sehen ist.

Gruß tippeltappel

Die ganze Insel ist geprägt von KSJ2-Massenimporten:
http://wiki.openstreetmap.org/wiki/Impo … SJ2_Import

Dabei kamen für natural=wood derartige Monster-MP's heraus. Ich glaube nicht , das diese gordischen Knoten einfach zu lösen sein werden.

Ach sooooooooo ..... Hmmmmm .... Vielen Dank, hgm!

🤔

Das erklärt einiges:
- vereinzelt einsame Straßenzüge und nichts "drumrum" > Hauptverkehrsstraßen, wo definitiv noch Baustelle oder sogar gar nichts ist
- Wälder, wo keine mehr sind
- Waldflächenformen, die nicht dem Satbild entsprechen

und last but not least: gps-tracks?????

Wären jetzt keine super-aktuellen Sat-Bilder zu sehen, hätte ich angenommen, da hätte jemand nach neuestem Wissen gemappt.
Aber es ist genau umgekehrt.

Aus solchen Quellen stammen dann auch wohl die immer zahlreicher werdenden POIs und sind somit auch mit Vorsicht zu genießen ????
Kann man auf Satbildern leider nicht kontrollieren.
Städte, in denen bislang nicht gemappt wird, geben die POIs ein merkwürdiges Bild ab, wenn sie auf der ansonsten leeren Karte auftauchen.

http://www.openstreetmap.org/?lat=42.91 … 5&layers=M
http://www.openstreetmap.org/?lat=42.65 … 5&layers=M
http://www.openstreetmap.org/?lat=42.57 … 5&layers=M
http://www.openstreetmap.org/?lat=42.52 … 5&layers=M
http://www.openstreetmap.org/?lat=42.55 … 5&layers=M

Schaltet man hier
http://www.openstreetmap.org/?lat=42.41 … 4&layers=M
auf die Potlach-Ansicht durch, sieht man zwei übereinander liegende Formen des Sees, doppelte POIs ... und fast keine Straßen

ironie an: So stelle ich mir OSM-Mapping vor 🙄 :ironie aus

Gruß
tippeltappel

Auch nett:
http://www.openstreetmap.org/?lat=43.01 … 4&layers=M

Zwei unterschiedliche übereinander liegende Waldpolygonimporte.
Diese Importe sind Horror.
Sie bringen zwar Farbe in die Karte, taugen aber für die Orientierung nicht das Geringste.
In der Importliste ist nachzulesen, daß die Daten teilweise von 2005 stammen.
Nicht gerade aktuell.
Dazu die Überlagerung von widersprüchlichen Daten.

Das bringt doch nichts.

Oder sehe ich das verkehrt?

Ich kann daraus nur die Konsequenz ziehen, vorhandene Waldpolygone im Zweifel nicht zu ändern, sondern komplett rauszuschmeiden, wenn sie nicht dem Sat-Bild entsprechen.

Oder?

Gruß
tippeltappel

hallo,

ich denke den umgang mit importen in japan,
sollten wir den japanern überlassen....

grüße von lutz

Hi,

bitte nicht einfach - ugesehen - löschen, hat sich ja jemand Mühe gemacht, es zu importieren.

Auf Satellitenbilder kann man sich auch nicht immer verlassen. Ginge es nur nach denen, hätt ich in Portugal/Spanien
jeden 2. Fluss löschen können ....

Interessant finde ich z. B. das hier:
http://www.openstreetmap.org/?lat=43.43 … 31&zoom=11
😉

Ciao,
Frank

Nein, ungesehen wird nichts gelöscht.
Nur wenn ich auf dem Satbild Wohngebiete sehe, die ganz offensichtlich gerade im Bau sind und in diesem Gebiet auf ebenso offensichtlich veraltete Waldpolygone treffe, dann ist meiner Meinung nach nichts gegen eine Löschung einzuwenden.
Und wenn da 2 identische Polygone ohne Bezug zu einer MP-Relation liegen, mein ich, daß man auch eines davon wegnehmen kann, wenn man grad nebendran was anderes mappt und einem das aufgrund der Knotendarstellung auffällt.
Gezielt suchen werde ich danach aber nicht.
Worauf ich aufpassen muß, daß kein neuer Schrott entsteht, weiß ich ja jetzt.

@ kellerma
Die von Dir verlinkte Gegend hab ich auch schon angeguckt. Wirklich sehr interessant.
Ob da ein großes Waldgebiet für die landwirtschaftliche oder sonstige Nutzung zurecht gestutzt wurde?
Sieht fast so aus.
Die Gliederung der im weitesten Sinne bebauten oder bewirtschafteten Landschaft weist dort wie an vielen anderen Orten in Japan sehr spezivische Eigenheiten auf. Solche Beobachtungen machen Mappen nach Satbildern spannend.

Im festgepinnten Thread war zu lesen, daß die Satbilder ganz neu sind.
Mal abgesehen von Verzerrungen müßten die doch die Realität abbilden.
Oder?

Die an der Küste zurückgebliebenen Überschwemmungen bestätigen jedenfalls die Aktualität der Bilder.

Gruß
tippeltappel

Hi,

in der osm-wochennotiz-nr-36 wird auch die multipolygon-Unterstützung des OSM Inspektor vorgestellt.
Sehr nützlich bei solchen MP wie http://www.openstreetmap.org/browse/relation/1177937 bei überschneidenen Knoten,
zumal die Validatormeldungen des JOSM nicht sehr aufschlußreich sind und händisch/visuell 500 Wege mit teils über 1000 Knoten
auch nicht opti ist.

Ciao,
Frank

Vielen Dank für den Hinweis auf die Toolerweiterung, Frank
Hab sie auch gleich mal ausprobiert.
So einige Multipolygon-Relationen wirken da etwas problematisch.

Hmmmm .... das insgesamt aufzuräumen wird nicht leicht sein. ...

Gruß
tippeltappel

Hallo
Ich wollte keinen neuen Thread aufmachen, daher hänge ich mich mal hier dran.

Bei meiner Bitte geht es um Relationen. Ich habe hier: http://www.openstreetmap.org/browse/way/115207555 einen neu erbauten Verteilerkreis getaggt. Die darauf zulaufenden Straßen waren alle mit Relationen versehen. Ich habe versucht diese auf den Verteilerkreis zu übertragen.
Könnte das jemand kontrollieren und ggf. korrigieren, oder mir Hilfestellung beim korrigieren leisten? Ich bin nämlich nicht der König der Relationen.
Schönen Dank und schöne Grüße

Meik

redrace wrote:

Bei meiner Bitte geht es um Relationen. Ich habe hier: http://www.openstreetmap.org/browse/way/115207555 einen neu erbauten Verteilerkreis getaggt. Die darauf zulaufenden Straßen waren alle mit Relationen versehen. Ich habe versucht diese auf den Verteilerkreis zu übertragen.
Könnte das jemand kontrollieren und ggf. korrigieren, oder mir Hilfestellung beim korrigieren leisten? Ich bin nämlich nicht der König der Relationen.

Hallo Meik

Sieht soweit alles gut aus.

Die Buslinie 721 endet am Verteilerkreis. Das sieht etwas seltsam aus. Vermutlich war das aber schon in den Ausgangsdaten so. Das sollte/könnte man daher mal mit den VRS-Unterlagen abgleichen.

Die Radwege um den Kreisverkehr sind in Nord-Süd Richtung im Radwegenetz NRW enthalten. In Ost-West ist jedoch wie bisher bei der Kreuzung die Straße (nun der Kreisverkehr) enthalten. Das könnte/sollte man mal vor Ort prüfen. Für das 1:1 Umsetzen von einer Kreuzung auf einen Kreisverkehr ist das jedoch erst mal richtig.

HTH
Edbert (EvanE)

EvanE wrote:

redrace wrote:

Bei meiner Bitte geht es um Relationen. Ich habe hier: http://www.openstreetmap.org/browse/way/115207555 einen neu erbauten Verteilerkreis getaggt. Die darauf zulaufenden Straßen waren alle mit Relationen versehen. Ich habe versucht diese auf den Verteilerkreis zu übertragen.
Könnte das jemand kontrollieren und ggf. korrigieren, oder mir Hilfestellung beim korrigieren leisten? Ich bin nämlich nicht der König der Relationen.

Hallo Meik

Sieht soweit alles gut aus.

Die Buslinie 721 endet am Verteilerkreis. Das sieht etwas seltsam aus. Vermutlich war das aber schon in den Ausgangsdaten so. Das sollte/könnte man daher mal mit den VRS-Unterlagen abgleichen.

Die Radwege um den Kreisverkehr sind in Nord-Süd Richtung im Radwegenetz NRW enthalten. In Ost-West ist jedoch wie bisher bei der Kreuzung die Straße (nun der Kreisverkehr) enthalten. Das könnte/sollte man mal vor Ort prüfen. Für das 1:1 Umsetzen von einer Kreuzung auf einen Kreisverkehr ist das jedoch erst mal richtig.

HTH
Edbert (EvanE)

Vielen Dank. Da bin ich ja froh das das geklappt hat. Es gibt Radwege in Ost-West Richtung die habe ich bis jetzt nur noch nicht getaggt. Ich gebe mich mal daran!
Schöne Grüße
Meik

redrace wrote:

EvanE wrote:

...
Die Radwege um den Kreisverkehr sind in Nord-Süd Richtung im Radwegenetz NRW enthalten. In Ost-West ist jedoch wie bisher bei der Kreuzung die Straße (nun der Kreisverkehr) enthalten. Das könnte/sollte man mal vor Ort prüfen. Für das 1:1 Umsetzen von einer Kreuzung auf einen Kreisverkehr ist das jedoch erst mal richtig.

Vielen Dank. Da bin ich ja froh das das geklappt hat. Es gibt Radwege in Ost-West Richtung die habe ich bis jetzt nur noch nicht getaggt. Ich gebe mich mal daran!

Hallo Meik

Das hat sicher Zeit bis du oder jemand anders die Radwege ergänzt.

Edbert (EvanE)

HUHU
Ich habe die Radwege mal ergänzt. Macht es Sinn die Radwegenetzrelation auf der Straße http://www.openstreetmap.org/browse/way/40268566

Schöne Grüße
Meik

FIXME=incomplete 😉

redrace wrote:

Ich habe die Radwege mal ergänzt. Macht es Sinn die Radwegenetzrelation auf der Straße http://www.openstreetmap.org/browse/way/40268566

Hallo Meik

Meines Erachtens gehören die Radwege zum Radwegenetz NRW und damit in die Radwegenetzrelation und nicht die Straße.

Du solltest dir aber vorab an anderen Beispielen in deiner Gegend ansehen, wie die Relation Radwegenetz NRW bei beidseitigen Radwegen gehandhabt wird. Wenn du dir das nicht zutraust, lasse es erst mal an der Straße. Das ist besser als es ganz aus der Relation zu werfen.

Edbert (EvanE)

EvanE wrote:

redrace wrote:

Ich habe die Radwege mal ergänzt. Macht es Sinn die Radwegenetzrelation auf der Straße http://www.openstreetmap.org/browse/way/40268566

Hallo Meik

Meines Erachtens gehören die Radwege zum Radwegenetz NRW und damit in die Radwegenetzrelation und nicht die Straße.

Du solltest dir aber vorab an anderen Beispielen in deiner Gegend ansehen, wie die Relation Radwegenetz NRW bei beidseitigen Radwegen gehandhabt wird. Wenn du dir das nicht zutraust, lasse es erst mal an der Straße. Das ist besser als es ganz aus der Relation zu werfen.

Edbert (EvanE)

Hallo Edbert
Ich hätte jetzt die Abschnitte der Radwege in die Relation eingefügt und die Straße aus der Relation gelöscht. Oder ist das der falsche Weg?
Aber die Relation endet sowieso hier: http://www.openstreetmap.org/browse/way/109791456 , da habe ich im Zweifelsfall noch genug arbeit.

Schöne Grüße
Meik

EvanE wrote:

Du solltest dir aber vorab an anderen Beispielen in deiner Gegend ansehen, wie die Relation Radwegenetz NRW bei beidseitigen Radwegen gehandhabt wird.

Ist nur so, dass die Radnetzrelationen angelegt wurden, als es in OSM noch kaum separat gemappte Radwege gab. Wenn jetzt nun jemand aus den Luftbildern die Radwege nachträgt, denkt er in der Regel nicht daran, die Radrelationen von der Straße auf den Radweg zu übertragen. Die meisten Mapper machen ja nen großen Bogen um Relationen.

Gruß,
ajoessen

ajoessen wrote:

EvanE wrote:

Du solltest dir aber vorab an anderen Beispielen in deiner Gegend ansehen, wie die Relation Radwegenetz NRW bei beidseitigen Radwegen gehandhabt wird.

Ist nur so, dass die Radnetzrelationen angelegt wurden, als es in OSM noch kaum separat gemappte Radwege gab. Wenn jetzt nun jemand aus den Luftbildern die Radwege nachträgt, denkt er in der Regel nicht daran, die Radrelationen von der Straße auf den Radweg zu übertragen. Die meisten Mapper machen ja nen großen Bogen um Relationen.

Gruß,
ajoessen

Gibt ja auch genügend negative Beispiele (MP), bei deren Ansehen (zur Information, wie machen es andere) man schon das große Grausen bekommen kann.

Gruß
Josef

ajoessen wrote:

EvanE wrote:

Du solltest dir aber vorab an anderen Beispielen in deiner Gegend ansehen, wie die Relation Radwegenetz NRW bei beidseitigen Radwegen gehandhabt wird.

Ist nur so, dass die Radnetzrelationen angelegt wurden, als es in OSM noch kaum separat gemappte Radwege gab. Wenn jetzt nun jemand aus den Luftbildern die Radwege nachträgt, denkt er in der Regel nicht daran, die Radrelationen von der Straße auf den Radweg zu übertragen. Die meisten Mapper machen ja nen großen Bogen um Relationen.

Gruß,
ajoessen

HUHU
Zu den letzt genannten gehöre ich auch.:-) Aber ich arbeite ja daran mich der Aufgabe zu stellen. Meine Frage ist aber dadurch noch nicht beantwortet.
Wie gesagt ich würde beide Seiten des Radweges in die Relation einfügen (oder reicht eine Seite) und die Straße aus der Relation nehmen und anschließend noch mal die Bitte äußern das dies jemand kontrolliert. Sonst lerne ich es nie! :-)

Schöne Grüße
Meik

redrace wrote:

Wie gesagt ich würde beide Seiten des Radweges in die Relation einfügen (oder reicht eine Seite) und die Straße aus der Relation nehmen und anschließend noch mal die Bitte äußern das dies jemand kontrolliert. Sonst lerne ich es nie! :-)

Schöne Grüße
Meik

Es reicht schon eine. Es bleibt dem Radfahrer überlassen, ob er die nach STVO benutzungspflichtige Straßenseite nimmt oder nicht. Bei "normalen" Radrouten von A nach B macht es auch die Routenwartung einfacher, wenn die Elemente zusammenfügbar bleiben.

Gruß,
ajoessen

Moin,

ajoessen wrote:

redrace wrote:

Wie gesagt ich würde beide Seiten des Radweges in die Relation einfügen (oder reicht eine Seite)

Es reicht schon eine. Es bleibt dem Radfahrer überlassen, ob er die nach STVO benutzungspflichtige Straßenseite nimmt oder nicht. Bei "normalen" Radrouten von A nach B macht es auch die Routenwartung einfacher, wenn die Elemente zusammenfügbar bleiben.

Unbedarfter Einwand:
Das funzt aber nur solange, wie die beidseitigen Radwege nicht als oneway getaggt sind, sonst klappt ja die Routenführung nicht mehr.
Siehe am angrenzenden nordöstlichen Kreisel. (Warum hat der eigentlich name=L 300 NRW?)

Ketzerischer Einwand:
Wenn Du es dem Radfahrer überlassen willst, welchen Weg er wählen soll, kann man eigentlich auch gleich die Straße samt Subtags belassen. <duck-und-wech> 😉

Wer A sagt muss eigentlich auch zu B bereit sein.

Gruß
Georg

NB:
Der angesprochene Kreisel sieht mir bei den begleitenden Fuß-/Radwegen noch stark überarbeitungswürdig aus - zu Fuß ist da plötzlich eine Sackgasse wegen way 115674150.

ajoessen wrote:

redrace wrote:

Wie gesagt ich würde beide Seiten des Radweges in die Relation einfügen (oder reicht eine Seite) und die Straße aus der Relation nehmen und anschließend noch mal die Bitte äußern das dies jemand kontrolliert. Sonst lerne ich es nie! :-)

Es reicht schon eine. Es bleibt dem Radfahrer überlassen, ob er die nach STVO benutzungspflichtige Straßenseite nimmt oder nicht. Bei "normalen" Radrouten von A nach B macht es auch die Routenwartung einfacher, wenn die Elemente zusammenfügbar bleiben.

Wenn man nur eine Seite eintragen will, dann kann man auch gleich bei der Straße bleiben. 🙁

Edbert (EvanE)

GeorgFausB wrote:

Moin,

ajoessen wrote:

redrace wrote:

Wie gesagt ich würde beide Seiten des Radweges in die Relation einfügen (oder reicht eine Seite)

Es reicht schon eine. Es bleibt dem Radfahrer überlassen, ob er die nach STVO benutzungspflichtige Straßenseite nimmt oder nicht. Bei "normalen" Radrouten von A nach B macht es auch die Routenwartung einfacher, wenn die Elemente zusammenfügbar bleiben.

Unbedarfter Einwand:
Das funzt aber nur solange, wie die beidseitigen Radwege nicht als oneway getaggt sind, sonst klappt ja die Routenführung nicht mehr.
Siehe am angrenzenden nordöstlichen Kreisel. (Warum hat der eigentlich name=L 300 NRW?)

Ketzerischer Einwand:
Wenn Du es dem Radfahrer überlassen willst, welchen Weg er wählen soll, kann man eigentlich auch gleich die Straße samt Subtags belassen. <duck-und-wech> 😉

Wer A sagt muss eigentlich auch zu B bereit sein.

Gruß
Georg

NB:
Der angesprochene Kreisel sieht mir bei den begleitenden Fuß-/Radwegen noch stark überarbeitungswürdig aus - zu Fuß ist da plötzlich eine Sackgasse wegen way 115674150.

HUHU

Ich habe jetzt mal die Radwege soweit beidseitig vorhanden auch beidseitig eingetragen. Ich hoffe alles richtig gemacht zu haben.

Schöne Grüße
Meik

EvanE wrote:

Wenn man nur eine Seite eintragen will, dann kann man auch gleich bei der Straße bleiben. 🙁

Sehe ich auch so. Die jeweiligen Radwege einzutragen macht IMHO nur Sinn wenn man pro Richtung eine
Relation erfasst.

GeorgFausB wrote:

... Siehe am angrenzenden nordöstlichen Kreisel. (Warum hat der eigentlich name=L 300 NRW?)
...

Hallo Georg

Bei einem highway=secondary soll ein Name und eine Referenznummer angegeben werden. Das gilt auch für einen Kreisverkehr (junction=roundabout). Das obwohl es sehr oft keinen direkten Namen für einen Kreisverkehr gibt. Oft wird dann willkürlich ein Name aus den abgehenden Straßen gewählt.

Sehr große Kreisverkehre haben sogar gelegentlich einen eigenen Namen. Das Bonner Ende der A 555 zum Beispiel ist ein Kreisverkehr und heißt Potsdamer Platz, lokal auch als Verpoorten Ei (nach der angrenzenden Firma) bekannt.

Edbert (EvanE)

Moin,

EvanE wrote:

GeorgFausB wrote:

... Siehe am angrenzenden nordöstlichen Kreisel. (Warum hat der eigentlich name=L 300 NRW?)
...

Bei einem highway=secondary soll ein Name und eine Referenznummer angegeben werden.

Wieso soll?
So eindeutig und ausschließlich würde ich das nicht sehen:
- Eine Straße muss nicht immer einen Namen haben - viele Straßen haben schlicht keinen Namen.
- Eine secondary muss auch nicht immer eine ref haben - wenn sie nun mal keine hat, aber von der Verkehrsbedeutung her eine ist.
Was nicht ist, kann nunmal nicht angegeben werden.

EvanE wrote:

Das gilt auch für einen Kreisverkehr (junction=roundabout). Das obwohl es sehr oft keinen direkten Namen für einen Kreisverkehr gibt. Oft wird dann willkürlich ein Name aus den abgehenden Straßen gewählt.
Sehr große Kreisverkehre haben sogar gelegentlich einen eigenen Namen. Das Bonner Ende der A 555 zum Beispiel ist ein Kreisverkehr und heißt Potsdamer Platz, lokal auch als Verpoorten Ei (nach der angrenzenden Firma) bekannt.

Soweit ja ok.
- Ein Kreisverkehr kann einen eigenen Namen haben.
- Ein Kreisverkehr kann den Namen einer bzw. in der Regel den der durchgehenden Straße haben.
Z. B. wenn er nachträglich in die Straße eingebaut wurde, gibt es keinen Grund, warum er nicht den Namen der Straße behält (sofern er keinen eigenen Namen bekommen hat).
- Das Straßenstück eines Kreisverkehrs muss aber nicht unbedingt einen Namen haben.

In diesem speziellen Fall bezweifle ich, dass der Name stimmt.
1) L300 ist die ref, NRW ein verdeutlichender Zusatz der Landesbezeichnung, als Name klingt das für mich schlicht unglaubwürdig.
(Es gibt Ausnahmen, wo die Straße wie die ref benannt ist ... falls das hier tatsächlich in dieser Form der Fall ist, ok)
2) L300 NRW ist (soweit ich mich erinnere) der Name der Fahrradroute?

Gruß
Georg

GeorgFausB wrote:

In diesem speziellen Fall bezweifle ich, dass der Name stimmt.
1) L300 ist die ref, NRW ein verdeutlichender Zusatz der Landesbezeichnung, als Name klingt das für mich schlicht unglaubwürdig.
(Es gibt Ausnahmen, wo die Straße wie die ref benannt ist ... falls das hier tatsächlich in dieser Form der Fall ist, ok)
2) L300 NRW ist (soweit ich mich erinnere) der Name der Fahrradroute?

Gruß
Georg

Also das ist so: Die Straße ist eine Landstraße und heisst L 300. Im Stadgebiet Wesseling hat sie noch zusätzliche Namen. Von Bonn kommend erst Willy Brandt Straße dann bis kurz hinter den besagten Verteilerkreis Konrad Adenauer Straße und danach Theodor Heuss Straße.
Außerdem ist der Name doch schon in L300 geändert, aber ich kann den auch in K-A-Straße ändern wenn das richtiger ist.

Schöne Grüße Meik

HUHU
Ich habe da nochmal eine Frage die Radwegerelation betreffend. Hier: http://www.openstreetmap.org/browse/way/28841128
ist eine area=pdestrian in die Relation eingefügt. Ist das in Ordnung oder sollte es ehr so aussehen wie hier: http://www.openstreetmap.org/browse/way/23612207/ , da ist ein highway=pedestrian in eine area eingezeichnt. Wobei beide in der Relation sind, allerdings die Area noch in der falschen(Rhein-Sieg-Kreis)! Oder ist das doppelt gemoppelt.
Funktioniert das Routing eigentlich mit bzw. über Area´s?
Viele Fragen!

Schöne Grüße Meik

redrace wrote:

Funktioniert das Routing eigentlich mit bzw. über Area´s?

Die meisten Router ignorieren das area=yes, routen also entlang des Randes der Area.

Bei der im zweiten Fall gezeigten Variante wird der Router entlang des nicht-Area-Ways
routen, da der Weg ja kürzer ist als der area=yes Weg.

Probleme könnte es geben, wenn der area=yes Bereich nicht mit dem area=no
Way verbunden ist.

Wenn die Routerstart-Position nun zufällig auf dem area=yes Way liegt, kann der Router
keine Route mehr zu einem Ziel berechnen.

Konkret erlebt habe ich das Anfang der Woche in Bern:

http://www.openstreetmap.org/?lat=46.94 … 8&layers=M

Hier ist der Waisenhausplatz nicht mit dem Rest der Welt verbunden.
(Edit: Wurde inzwischen korrigiert)

Hab den Weg zum Hotel dann eben ohne GPS gefunden. 😉

Chris

@Chriss66

Verstanden, Ende! :-)

Schöne Grüße
Meik

Hi,

redrace wrote:

HUHU
Ich habe da nochmal eine Frage die Radwegerelation betreffend. Hier: http://www.openstreetmap.org/browse/way/28841128
ist eine area=pdestrian in die Relation eingefügt. Ist das in Ordnung oder sollte es ehr so aussehen wie hier: http://www.openstreetmap.org/browse/way/23612207/ , da ist ein highway=pedestrian in eine area eingezeichnt. Wobei beide in der Relation sind, allerdings die Area noch in der falschen(Rhein-Sieg-Kreis)! Oder ist das doppelt gemoppelt.
Funktioniert das Routing eigentlich mit bzw. über Area´s?

IMHO eindeutig doppelt gemoppelt.
Eine pedestrian area durch die auch noch ein pedestrian way führt.
Wenn man nicht will, daß da am Rande entlang geroutet wird, könnte man, was ich auch schon gesehen habe, einen virtuellen Weg (ohne Tags) über die area legen, und diesen in die Relation einbinden.

Der nächste legt dann auch andere Wege durch eine Fußgängerzone.

Gruß
Josef

Radeln wrote:

Hi,

einen virtuellen Weg (ohne Tags) über die area legen, und diesen in die Relation einbinden.

Gruß
Josef

HUHU
Wird der dann nicht als "Fehler" in Keepright oder osm-inspektor angezeigt?

Scxhöne Grüße
Meik

Radeln wrote:

redrace wrote:

Ich habe da nochmal eine Frage die Radwegerelation betreffend. Hier: http://www.openstreetmap.org/browse/way/28841128
ist eine area=pedestrian in die Relation eingefügt. Ist das in Ordnung oder sollte es eher so aussehen wie hier: http://www.openstreetmap.org/browse/way/23612207/ , da ist ein highway=pedestrian in eine area eingezeichnet. Wobei beide in der Relation sind, ... Oder ist das doppelt gemoppelt.
Funktioniert das Routing eigentlich mit bzw. über Area´s?

IMHO eindeutig doppelt gemoppelt.
Eine pedestrian area durch die auch noch ein pedestrian way führt.
Wenn man nicht will, daß da am Rande entlang geroutet wird, könnte man, was ich auch schon gesehen habe, einen virtuellen Weg (ohne Tags) über die area legen, und diesen in die Relation einbinden.

Der nächste legt dann auch andere Wege durch eine Fußgängerzone.

Josef das kommt immer auf die Situation an.
Manchmal sind Vorzugswege auf einer Fläche markiert. Dann kann man das durchaus vertreten.
In Dortmund (Campus Nord) lag ein Weg auf einer Fußgänger-Fläche. Das war auch notwendig, da dort die tastbare Markierung (tactile_paving=yes) für Blinde angebracht war.

Ein Weg ohne Taggs für eine Routen-Relation ist im Grunde das gleiche, nur dass man es nicht auf der Karte sieht.

An redrace:
area=yes an einem Weg-Typ funktioniert bei den meisten Routern (mindestens bei OpenRouteService.org). Der Nachteil ist, dass über den Rand der Fläche geroutet wird. Nicht optimal weil es meist einen kürzeren Weg gibt.

Zumindest Mapnik rendert area=yes bei highway=footway, highway=track und highway=service (vermutlich bei allen Wege-Typen). Das ist recht praktisch für Schulhöfe und andere Gehflächen ohne spezifischen Namen sowie für Rangierbereiche auf Firmengeländen.

Edbert (EvanE)

redrace wrote:

Radeln wrote:

Hi,

einen virtuellen Weg (ohne Tags) über die area legen, und diesen in die Relation einbinden.

Gruß
Josef

HUHU
Wird der dann nicht als "Fehler" in Keepright oder osm-inspektor angezeigt?

Scxhöne Grüße
Meik

Weiß ich nicht. Habe dies vor längerer Zeit mal gesehen.
Habe eben die ganze Zeit versucht die Stelle in AFAIK Bonn zu finden. Leider vergeblich.

Gruß
Josef

EvanE wrote:

Radeln wrote:

redrace wrote:

Ich habe da nochmal eine Frage die Radwegerelation betreffend. Hier: http://www.openstreetmap.org/browse/way/28841128
ist eine area=pedestrian in die Relation eingefügt. Ist das in Ordnung oder sollte es eher so aussehen wie hier: http://www.openstreetmap.org/browse/way/23612207/ , da ist ein highway=pedestrian in eine area eingezeichnet. Wobei beide in der Relation sind, ... Oder ist das doppelt gemoppelt.
Funktioniert das Routing eigentlich mit bzw. über Area´s?

IMHO eindeutig doppelt gemoppelt.
Eine pedestrian area durch die auch noch ein pedestrian way führt.
Wenn man nicht will, daß da am Rande entlang geroutet wird, könnte man, was ich auch schon gesehen habe, einen virtuellen Weg (ohne Tags) über die area legen, und diesen in die Relation einbinden.

Der nächste legt dann auch andere Wege durch eine Fußgängerzone.

Josef das kommt immer auf die Situation an.
Manchmal sind Vorzugswege auf einer Fläche markiert. Dann kann man das durchaus vertreten.
In Dortmund (Campus Nord) lag ein Weg auf einer Fußgänger-Fläche. Das war auch notwendig, da dort die tastbare Markierung (tactile_paving=yes) für Blinde angebracht war.

Ein Weg ohne Taggs für eine Routen-Relation ist im Grunde das gleiche, nur dass man es nicht auf der Karte sieht.

Hi Edbert,

Dein Beispiel leuchtet mir insofern ein, daß es ein Sonderfall ist, der mit Sicherheit auch entsprechende Tags enthält. Gleichwohl ist festzuhalten, daß im vorliegenden Fall die Tags an beiden Wegen identisch sind. Wenn das nicht doppelt gemoppelt ist, Und vor allem ist dieser Weg sichtbar, was für den Weg ohne Tags nicht gilt. Ob dies der richtige Ansatz ist? Deshalb auch 'könnte'.
Wenn schon (sichtbare) Wege in einer Fußgängerzone sein müssen (Dein Beispiel) müssen diese IMHO in der Wertigkeit gleich oder kleiner als der Weg der Fläche sein. Also z.B. kein Serviceweg.

Gruß
Josef

Radeln wrote:

redrace wrote:

Radeln wrote:

Hi,

einen virtuellen Weg (ohne Tags) über die area legen, und diesen in die Relation einbinden.

Gruß
Josef

HUHU
Wird der dann nicht als "Fehler" in Keepright oder osm-inspektor angezeigt?

Scxhöne Grüße
Meik

Weiß ich nicht. Habe dies vor längerer Zeit mal gesehen.
Habe eben die ganze Zeit versucht die Stelle in AFAIK Bonn zu finden. Leider vergeblich.

Bin doch noch fündig geworden:
http://www.openstreetmap.org/browse/way/30124236

Fehleranzeige in Keepright /OSMI konnte ich auf die Schnelle nicht feststellen.
BTW, enthält entgegen meiner Aussage (aus der Erinnerung heraus) doch Tags.

Gruß
Josef

Radeln wrote:

EvanE wrote:

Radeln wrote:

... Eine pedestrian area durch die auch noch ein pedestrian way führt. ...

Josef das kommt immer auf die Situation an.
Manchmal sind Vorzugswege auf einer Fläche markiert. Dann kann man das durchaus vertreten.
... Wegmarkierung für Blinde ...

Dein Beispiel leuchtet mir insofern ein, daß es ein Sonderfall ist, der mit Sicherheit auch entsprechende Tags enthält. ...
Wenn schon (sichtbare) Wege in einer Fußgängerzone sein müssen (Dein Beispiel) müssen diese IMHO in der Wertigkeit gleich oder kleiner als der Weg der Fläche sein. Also z.B. kein Serviceweg.

Hallo Josef

Es ist immer so eine Frage, was als 'höherwertig' betrachtet wird.
Es gibt auch markierte Zufahrten zu Geschäften und Gebäuden, ohne dass die Fläche mit Vorrang für Fußgänger durch diese unterbrochen wird. Das wäre dann so etwas wie highway=service, ... Einschränkungen ..., foot=designated. Das hängt dann von der Beschilderung vor Ort ab, welche Tagging-Variante dort engesetzt wird. Oft geht natürlich auch highway=pedestrian + motor_car/motor_vehicle=destination/delivery.

Dein Bonner Beispiel von heute hat zurecht das bicycle=yes. Über diesen Weg darf mit dem Rad gefahren werden, während die gesamte Fläche Fußgängerzone ist. In der Bonner Innenstadt muss man als Radfahrer echt aufpasen, da nur wenige Verbindungen für Radfahrer freigegeben sind. Die "Radfahrer verboten"-Schilder an den anderen Teilen sind recht hoch angebracht und werden daher leicht übersehen.

Edbert (EvanE)

Radeln wrote:

Radeln wrote:

redrace wrote:

HUHU
Wird der dann nicht als "Fehler" in Keepright oder osm-inspektor angezeigt?

Scxhöne Grüße
Meik

Weiß ich nicht. Habe dies vor längerer Zeit mal gesehen.
Habe eben die ganze Zeit versucht die Stelle in AFAIK Bonn zu finden. Leider vergeblich.

Bin doch noch fündig geworden:
http://www.openstreetmap.org/browse/way/30124236

Fehleranzeige in Keepright /OSMI konnte ich auf die Schnelle nicht feststellen.
BTW, enthält entgegen meiner Aussage (aus der Erinnerung heraus) doch Tags.

Gruß
Josef

HUHU
Das ist ja elegant gelöst. Ich werde das in der Fußgängerzone in Brühl auch so machen. Da ist Radfahren auch erlaubt.

Schöne Greüße Meik

EvanE wrote:

Radeln wrote:

EvanE wrote:

Josef das kommt immer auf die Situation an.
Manchmal sind Vorzugswege auf einer Fläche markiert. Dann kann man das durchaus vertreten.
... Wegmarkierung für Blinde ...

Dein Beispiel leuchtet mir insofern ein, daß es ein Sonderfall ist, der mit Sicherheit auch entsprechende Tags enthält. ...
Wenn schon (sichtbare) Wege in einer Fußgängerzone sein müssen (Dein Beispiel) müssen diese IMHO in der Wertigkeit gleich oder kleiner als der Weg der Fläche sein. Also z.B. kein Serviceweg.

Hallo Josef

Es ist immer so eine Frage, was als 'höherwertig' betrachtet wird.
Es gibt auch markierte Zufahrten zu Geschäften und Gebäuden, ohne dass die Fläche mit Vorrang für Fußgänger durch diese unterbrochen wird. Das wäre dann so etwas wie highway=service, ... Einschränkungen ..., foot=designated. Das hängt dann von der Beschilderung vor Ort ab, welche Tagging-Variante dort engesetzt wird. Oft geht natürlich auch highway=pedestrian + motor_car/motor_vehicle=destination/delivery.

Dein Bonner Beispiel von heute hat zurecht das bicycle=yes. Über diesen Weg darf mit dem Rad gefahren werden, während die gesamte Fläche Fußgängerzone ist. In der Bonner Innenstadt muss man als Radfahrer echt aufpasen, da nur wenige Verbindungen für Radfahrer freigegeben sind. Die "Radfahrer verboten"-Schilder an den anderen Teilen sind recht hoch angebracht und werden daher leicht übersehen.

Hi Edbert,

Weshalb nur über diesen Weg. Der ganze Platz ist doch für Radfahrer freigegeben. AFAIK wurde dieser Weg nur wegen der Radwegrelation gemappt. Weshalb dann der Münsterplatz selbst ebenfalls Bestandteil der Radwegrelation ist, ist die andere Frage. Dürfte wohl falsch sein.
Was ich ebenfalls für eine Fehler halte, ist, daß die Platz teilweise umlaufenden highway=pedestrian kein bicycle=yes haben. Sie gehören ja auch zum Platz. Gilt auch für den größeren Teil des Martinsplatzes.

Gruß
Josef

Radeln wrote:

EvanE wrote:

Dein Bonner Beispiel von heute hat zurecht das bicycle=yes. Über diesen Weg darf mit dem Rad gefahren werden, während die gesamte Fläche Fußgängerzone ist. In der Bonner Innenstadt muss man als Radfahrer echt aufpasen, da nur wenige Verbindungen für Radfahrer freigegeben sind. Die "Radfahrer verboten"-Schilder an den anderen Teilen sind recht hoch angebracht und werden daher leicht übersehen.

Weshalb nur über diesen Weg. Der ganze Platz ist doch für Radfahrer freigegeben. AFAIK wurde dieser Weg nur wegen der Radwegrelation gemappt. Weshalb dann der Münsterplatz selbst ebenfalls Bestandteil der Radwegrelation ist, ist die andere Frage. Dürfte wohl falsch sein.
Was ich ebenfalls für eine Fehler halte, ist, daß die Platz teilweise umlaufenden highway=pedestrian kein bicycle=yes haben. Sie gehören ja auch zum Platz. Gilt auch für den größeren Teil des Martinsplatzes.

Hallo Josef

Im Prinzip darf man auf dem ganzen Platz Radfahren solange dort keine Veranstaltung ist.
Der eingetragene Weg plus die Verlängerung bis zur Windeckstraße ist jedoch immer nutzbar (auch wenn Weihnachtsmarkt ist). Von daher hätte ich den eingetragenen Weg direkt bis zur Windeckstraße durch gezogen. Da das nicht erfolgte, musste auch der Platz als solcher in die NRW-Rad-Relation.

Edbert (EvanE)

EvanE wrote:

Radeln wrote:

EvanE wrote:

Dein Bonner Beispiel von heute hat zurecht das bicycle=yes. Über diesen Weg darf mit dem Rad gefahren werden, während die gesamte Fläche Fußgängerzone ist. In der Bonner Innenstadt muss man als Radfahrer echt aufpasen, da nur wenige Verbindungen für Radfahrer freigegeben sind. Die "Radfahrer verboten"-Schilder an den anderen Teilen sind recht hoch angebracht und werden daher leicht übersehen.

Weshalb nur über diesen Weg. Der ganze Platz ist doch für Radfahrer freigegeben. AFAIK wurde dieser Weg nur wegen der Radwegrelation gemappt. Weshalb dann der Münsterplatz selbst ebenfalls Bestandteil der Radwegrelation ist, ist die andere Frage. Dürfte wohl falsch sein.
Was ich ebenfalls für eine Fehler halte, ist, daß die Platz teilweise umlaufenden highway=pedestrian kein bicycle=yes haben. Sie gehören ja auch zum Platz. Gilt auch für den größeren Teil des Martinsplatzes.

Hallo Josef

Im Prinzip darf man auf dem ganzen Platz Radfahren solange dort keine Veranstaltung ist.
Der eingetragene Weg plus die Verlängerung bis zur Windeckstraße ist jedoch immer nutzbar (auch wenn Weihnachtsmarkt ist). Von daher hätte ich den eingetragenen Weg direkt bis zur Windeckstraße durch gezogen. Da das nicht erfolgte, musste auch der Platz als solcher in die NRW-Rad-Relation.

Hallo Edbert,

verstehe ich nicht. Die Verlängerung ist doch da. Es ist die Münsterplatzstraße als Begrenzung der Fläche. Da fehlte bloß bicycle=yes, habe ich eingefügt.

Auf die andere Geschichte bist Du leider nicht eingegangen, bicycle Tag für die anderen den Platz begrenzenden pedestrian ways. Oder dürffen die nicht mit dem Rad befahren werden, was ich mir nicht vorstellen kann.

Gruß
Josef

Hallo Josef

Radeln wrote:

EvanE wrote:

Im Prinzip darf man auf dem ganzen Platz Radfahren solange dort keine Veranstaltung ist.
Der eingetragene Weg plus die Verlängerung bis zur Windeckstraße ist jedoch immer nutzbar (auch wenn Weihnachtsmarkt ist). Von daher hätte ich den eingetragenen Weg direkt bis zur Windeckstraße durch gezogen. Da das nicht erfolgte, musste auch der Platz als solcher in die NRW-Rad-Relation.

verstehe ich nicht. Die Verlängerung ist doch da. Es ist die Münsterplatzstraße als Begrenzung der Fläche. Da fehlte bloß bicycle=yes, habe ich eingefügt.

JA, Weg über Weg ist in P2 schlecht zu erkennen. In JOSM habe ich das heute auch erkannt.

Wie bereits gesagt, ich hätte den 'virtuellen' Weg direkt bis zur Windeckstraße durchgezogen.
Das entspricht mehr der Realität, als ein Weg direkt an den Hauskanten entlang.

Radeln wrote:

Auf die andere Geschichte bist Du leider nicht eingegangen, bicycle Tag für die anderen den Platz begrenzenden pedestrian ways. Oder dürfen die nicht mit dem Rad befahren werden, was ich mir nicht vorstellen kann.

Diese anderen Wege auf dem Rand des Münsterplatzes stammen aus der Datenerfassung für Rollstuhl-Routing. Das kann man leicht am Tagg incline erkennen. Für einen Platz kann man kein Gefälle angeben. Daher brauchten die Leute einen eigenen Weg. Die Rollstuhl-Leute interessieren sich nicht für Radfahrer und haben daher auch keine Informationen zum Radfahren erfasst.

Wenn es dich stört, kannst du es ergänzen. Du kannst es jedoch auch lassen, da der ganze Platz bereits mit bicycle=yes getaggt ist und die Information daher redundant wäre.

Edbert (EvanE)

EvanE wrote:

Hallo Josef

Radeln wrote:

EvanE wrote:

Im Prinzip darf man auf dem ganzen Platz Radfahren solange dort keine Veranstaltung ist.
Der eingetragene Weg plus die Verlängerung bis zur Windeckstraße ist jedoch immer nutzbar (auch wenn Weihnachtsmarkt ist). Von daher hätte ich den eingetragenen Weg direkt bis zur Windeckstraße durch gezogen. Da das nicht erfolgte, musste auch der Platz als solcher in die NRW-Rad-Relation.

verstehe ich nicht. Die Verlängerung ist doch da. Es ist die Münsterplatzstraße als Begrenzung der Fläche. Da fehlte bloß bicycle=yes, habe ich eingefügt.

JA, Weg über Weg ist in P2 schlecht zu erkennen. In JOSM habe ich das heute auch erkannt.

Wie bereits gesagt, ich hätte den 'virtuellen' Weg direkt bis zur Windeckstraße durchgezogen.
Das entspricht mehr der Realität, als ein Weg direkt an den Hauskanten entlang.

Radeln wrote:

Auf die andere Geschichte bist Du leider nicht eingegangen, bicycle Tag für die anderen den Platz begrenzenden pedestrian ways. Oder dürfen die nicht mit dem Rad befahren werden, was ich mir nicht vorstellen kann.

Diese anderen Wege auf dem Rand des Münsterplatzes stammen aus der Datenerfassung für Rollstuhl-Routing. Das kann man leicht am Tagg incline erkennen. Für einen Platz kann man kein Gefälle angeben. Daher brauchten die Leute einen eigenen Weg. Die Rollstuhl-Leute interessieren sich nicht für Radfahrer und haben daher auch keine Informationen zum Radfahren erfasst.

Wenn es dich stört, kannst du es ergänzen. Du kannst es jedoch auch lassen, da der ganze Platz bereits mit bicycle=yes getaggt ist und die Information daher redundant wäre.

Hi Edbert,

So ist halt OSM, viel Kuddelmuddel, leider.

Gruß
Josef

Radeln wrote:

So ist halt OSM, viel Kuddelmuddel, leider.

Hallo Josef

In der Tat (TM Teal'c).
Und viele (berichtigte) Spezial-Interessen, die zu anderen Schwerpunkten bei der Erfassung führen.

Edbert (EvanE)

EvanE wrote:

Radeln wrote:

So ist halt OSM, viel Kuddelmuddel, leider.

Hallo Josef

In der Tat (TM Teal'c).
Und viele (berichtigte) Spezial-Interessen, die zu anderen Schwerpunkten bei der Erfassung führen.

Hallo Edbert,

Spezial-Interessen, andere Schwerpunkte nichts dagegen, aber bitte nicht unter der von vielen vertretenen OSM-Promisse.

Abschließende Bemerkung:
In das Wiki gehören IMHO nur eindeutige und mehrheitlich anerkannte Taggings, an die sich jeder halten muß. Dies müßte dann auch gesteuert und in Grenzen kontrolliert werden. Diskussionen/Proposals sollten zeitlich begrenzt werden. Wenn diese zu nichts führen, muß eben ein Gremium darüber entscheiden und dies im Wiki dokumentieren bis irgendwann eine andere Entscheidung getroffen wird.
Das O in OSM heißt IMHO eben nicht 'Jeder kann machen, was er will.' Mit den Daten, die jemand sich auf seinen Rechner lädt, kann er machen was er will. Die originären Daten selbst aber sollten nach eindeutigen Vorgaben zusammengetragen werden und dürfen nicht den 'Launen' einzelner User (da schließe ich mich nicht aus) ausgesetzt sein. Ob sich dies jemals in die Richtung bewegt, glaube ich inzwischen nicht mehr, SCHADE.

Gruß
Josef

Radeln wrote:

...
Abschließende Bemerkung:
In das Wiki gehören IMHO nur eindeutige und mehrheitlich anerkannte Taggings, an die sich jeder halten muß. Dies müßte dann auch gesteuert und in Grenzen kontrolliert werden. Diskussionen/Proposals sollten zeitlich begrenzt werden. Wenn diese zu nichts führen, muß eben ein Gremium darüber entscheiden und dies im Wiki dokumentieren bis irgendwann eine andere Entscheidung getroffen wird.
Das O in OSM heißt IMHO eben nicht 'Jeder kann machen, was er will.' Mit den Daten, die jemand sich auf seinen Rechner lädt, kann er machen was er will. Die originären Daten selbst aber sollten nach eindeutigen Vorgaben zusammengetragen werden und dürfen nicht den 'Launen' einzelner User (da schließe ich mich nicht aus) ausgesetzt sein. Ob sich dies jemals in die Richtung bewegt, glaube ich inzwischen nicht mehr, SCHADE.

Gruß
Josef

1+
Josef ich leide mit dir.

Aber leider verlaufen in diesem Forum Versuche, die Qualitätssicherung und eindeutige Regelungen zum Ziel haben, immer wieder so, dass zum Schuss meist nur "Hier kann jeder machen was er will" und "Nach uns die Sintflut (sprich:Renderer)" übrig bleibt.

Wenn ich mal auf's Ursprungsthema zurückkommen darf:
OSMI warnt bei diesem MP ein "Role mismatch":
http://www.openstreetmap.org/browse/relation/1307251
Ich konnte auch mit JOSM nix finden.
Wer weiß Rat?

Edit:
Und wenn wir schon dabei sind...
Österreichs Grenze ist im Südosten kaputt:
http://tools.geofabrik.de/osmi/?view=mu … ,way_nodes

hurdygurdyman wrote:

Wenn ich mal auf's Ursprungsthema zurückkommen darf:
OSMI warnt bei diesem MP ein "Role mismatch":
http://www.openstreetmap.org/browse/relation/1307251
Ich konnte auch mit JOSM nix finden.
Wer weiß Rat?

Hi hurdygurdyman,
ich kann auch nichts finden. Erscheint mir absolut sauber - und ich hab 3x hinhesehen.
ich würde den nächsten update von osmi abwarten; da könnte es eine zeitliche Überschneidung gegeben haben und die allerletzte Änderung vom 10.6 ist eventuell bei dem noch nicht drin.

Gruss
Walter

hurdygurdyman wrote:

Wenn ich mal auf's Ursprungsthema zurückkommen darf:
OSMI warnt bei diesem MP ein "Role mismatch":
http://www.openstreetmap.org/browse/relation/1307251
Ich konnte auch mit JOSM nix finden.
Wer weiß Rat?

Es gab da einige landuse, die zusätzlich mit type=multipolygon getaggt waren.
http://www.openstreetmap.org/browse/way/86982782
http://www.openstreetmap.org/browse/way/87965084

Ursache?

Eben gefunden, noch nicht geändert bitte checken, ob ich damit richtig liege:
http://www.openstreetmap.org/browse/way/83903838

Gruß
Josef

Radeln wrote:

Es gab da einige landuse, die zusätzlich mit type=multipolygon getaggt waren.
Ursache?

Eben gefunden, noch nicht geändert bitte checken, ob ich damit richtig liege:
http://www.openstreetmap.org/browse/way/83903838

hi,

sieht ja "richtig falsch" aus 😉
nen way mit type=multipolygon kannte ich auch noch nicht - will hier aber nicht wieder über Kreativität philosophieren.

ist definitiv Quatsch und könnte osmi zum Schleudern gebracht haben.

Gruss
Walter

@radeln und wambacher:
Vielen Dank fürs checken. Da muss man auch erst mal drauf kommen.
Ich gehe da heute Abend mit JOSM mal dran (läuft auf diesem Rechner nicht)

Bleibt nur noch das "grenzenlose" Österreich 🙄

wambacher wrote:

Radeln wrote:

Es gab da einige landuse, die zusätzlich mit type=multipolygon getaggt waren.
Ursache?

Eben gefunden, noch nicht geändert bitte checken, ob ich damit richtig liege:
http://www.openstreetmap.org/browse/way/83903838

hi,

sieht ja "richtig falsch" aus 😉
nen way mit type=multipolygon kannte ich auch noch nicht - will hier aber nicht wieder über Kreativität philosophieren.

ist definitiv Quatsch und könnte osmi zum Schleudern gebracht haben.

Gruss
Walter

Tag entfernt!
Da war evtl. mal eine Relation vorgesehen. Die anderen landuses sind ja richtig.

Gruß
Josef

hurdygurdyman wrote:

Bleibt nur noch das "grenzenlose" Österreich 🙄

hi,

16239 ist absolut ok.

gis=#␣select␣tstamp,version,summary(geom),isclosed(geom),isvalid(geom)from␣borders␣where␣id=16239;
tstamp␣␣␣␣␣␣␣␣|␣version␣|␣␣␣␣␣␣␣␣␣␣␣␣␣summary␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣isclosed␣|␣isvalid
---------------------+---------+----------------------------------+----------+---------
2011-05-22␣23:43:49␣|␣␣␣␣␣698␣|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣t␣␣␣␣␣␣␣␣|␣t
:␣MultiPolygon[BS]␣with␣1␣elements
:␣␣␣Polygon[]␣with␣1␣rings
:␣␣␣␣ring␣0␣has␣45217␣points

Gruss
Walter

wambacher wrote:

16239 ist absolut ok.
Gruss
Walter

Warum "meckert" OSMI denn dann?

hurdygurdyman wrote:

wambacher wrote:

16239 ist absolut ok.
Gruss
Walter

Warum "meckert" OSMI denn dann?

hi,

er "meckert" ja garnicht die Grenze von Österreich an (16239) sondern ein Teilstück davon (102896).

Leider sind viele Grenzen gestückelt; hier gibt es u.A. das GrenzSTÜCK zwischen Österreich und Slovenien.
Das ist als MP eingetragen aber logischerweise nicht geschlossen. Resultat: osmi meckert und das imho mit gutem Recht.

Ich würd die am liebsten rausschmeissen - aber ich lass das lieber , sonst gibt es Zoff mit den Nachbarn.

Gruss
Walter

p.s. in Hannover haben wir auch son Zeug; viele Admin-Grenzen der Stadtteile (al10) sind so erfasst; dafür fehlen dort aber die kompletten a10-Grenzen. Schade um die Arbeit 🙁

Was man so alles lernt, wenn man sich mit MP's befasst...

@wambacher:
Ich werde mich auch nicht in "Grenzkonflikte" anderer einmischen 😉

hurdygurdyman wrote:

Was man so alles lernt, wenn man sich mit MP's befasst...

ich lern auch fast jeden Tag was dazu - das macht OSM auch nach 1.5 Jahren immer noch spannend.

Rein theoretisch könnte man das mit den Grenzstücken auch so machen:

Die Grenze eines Landes oder Ortes besteht aus mehreren linearen Relationen - nicht MP, die sind ja nur für Polygone gedacht (?) - und diese Grenzstücke werden dann in einer Super-Relation als Member eingetragen.
Das hat/hätte den Vorteil, dass die Teilstrecke wirklich nur einmal in OSM drin ist und nicht redundant wie bei unseren Nachbarn.

Bevor ich hier virtuell erschlagen werde:

Ich hab das noch nie gemacht und auch noch nirgenswo bei Grenzen (*) gesehen - aber logisch erscheint es mir schon.
Wofür sind denn dann Relationen als Member von anderen Relationen erlaubt?

Gruss
Walter

• ) bei ÖPNV-Relationen kommt das schon mal vor.
  

hurdygurdyman wrote:

@radeln und wambacher:
Vielen Dank fürs checken. Da muss man auch erst mal drauf kommen.

Try and error.

Gruß
Josef

Radeln wrote:

hurdygurdyman wrote:

@radeln und wambacher:
Vielen Dank fürs checken. Da muss man auch erst mal drauf kommen.

Try and error.

Gruß
Josef

ist ja auch ein "relativ" komplexes Thema 😉

wambacher wrote:

Rein theoretisch könnte man das mit den Grenzstücken auch so machen:

Die Grenze eines Landes oder Ortes besteht aus mehreren linearen Relationen - nicht MP, die sind ja nur für Polygone gedacht (?) - und diese Grenzstücke werden dann in einer Super-Relation als Member eingetragen.
Das hat/hätte den Vorteil, dass die Teilstrecke wirklich nur einmal in OSM drin ist und nicht redundant wie bei unseren Nachbarn.

Hallo Walter

Das gibt es bereits und nennt sich http://wiki.openstreetmap.org/wiki/Rela … ry_segment boundary_segments. Bei den französischen Grenzen wird das wohl bereits eingesetzt.

Meines Erachtens werden Grenzen durch Multipolygone nicht adäquat abgebildet. Multipolygone setzen einseitig auf die Fläche, die durch die Gesamtheit der Grenzabschnitte umschlossen wird. Die Grenzabschnitte als solche sind lineare Strukturen, nämlich die Grenzlinie zwischen zwei Gebieten.

Ein sinnvoller Ansatz wäre meiner Meinung nach:
1 Grenzabschnitte als lineare Strukturen in einer Relation mit type=boundary_segment zu erfassen.
2 Die Fläche eines Gebietes als Multipolygon, deren Outer-Abschnitte durch boundary Segments gebildet werden erfassen.

So kann man beide wichtigen Erscheinungen einer Grenze nämlich einerseits die Grenzabschnitte als Grenzlinien und andererseits das Gebiet (und damit die Fläche), das durch die Gesamtheit aller Grenzabschnitte gebildet wird, erfassen.

Als vielleicht einfaches Beispiel hat Rheinlandpfalz Grenzen zu Frankreich, Luxemburg, Nordrheinwestfahlen, Hessen, das Saarland und Baden-Würtemberg. Warum soll man diese Grenzabschnitte nicht als eigene boundary_segment Relationen erfassen und mit diesen das Landesgebiet als Multipolygon?

Edbert (EvanE)

EvanE wrote:

Das gibt es bereits und nennt sich http://wiki.openstreetmap.org/wiki/Rela … ry_segment boundary_segments. Bei den französischen Grenzen wird das wohl bereits eingesetzt.

hi Edbert,

Froonk-Raiiich hatte ich mir noch nicht angesehen - da ist der sprachliche Tellerrand für mich etwas hoch. Aber dennoch interessant, dass andere Länder das schon so machen.

Ein sinnvoller Ansatz wäre meiner Meinung nach:
1 Grenzabschnitte als lineare Strukturen in einer Relation mit type=boundary_segment zu erfassen.
2 Die Fläche eines Gebietes als Multipolygon, deren Outer-Abschnitte durch boundary Segments gebildet werden erfassen.

So kann man beide wichtigen Erscheinungen einer Grenze nämlich einerseits die Grenzabschnitte als Grenzlinien und andererseits das Gebiet (und damit die Fläche), das durch die Gesamtheit aller Grenzabschnitte gebildet wird, erfassen.

ja, dann sind zumindest wir beiden hier der gleichen Meinnung.

Als vielleicht einfaches Beispiel hat Rheinlandpfalz Grenzen zu Frankreich, Luxemburg, Nordrheinwestfalen, Hessen, das Saarland und Baden-Würtemberg. Warum soll man diese Grenzabschnitte nicht als eigene boundary_segment Relationen erfassen und mit diesen das Landesgebiet als Multipolygon?

Im Prinzip schon, allerdings halte ich die "Hemmschwelle" unserer Mitstreiter aus verständlichen Gründen für etwas hoch.
Ich hab mich ja im Laufe fast eines Jahres über Wander-Routen, ÖPNV-Relationen (oxomoa sei Dank) und Administrative Grenzen so langsam hochgearbeitet - für mich wär das absolut kein Problem. Aber der breiten Masse möchte ich das nicht so zwischen Tür und Angel unterjubeln.

Es gibt noch mindestens zwei weitere Gründe dafür, das mit den Boundary-Segmenten zu machen:
- die Grenz-Relationen werden in mehrere kleiner Stücke aufgespalten - von einem 3-Ländereck zum nächsten.
Damit sind sie kleiner und besser zu verarbeiten (Weniger Ways pro Relation)
- Konflikte verringern sich, da verschiedene Leute gleichzeitig an unterschiedlichen Teilen arbeiten können.
- bestimmt noch mehr ...

Offene Fragen / Punkte:
- Bis zu welchem admin_level könnte das so gehen - 2+4 bestimmt aber auch noch weiter?
- Was macht osm2pgsql damit?
- Was machen die Entwickler? Die müssten dann ihre "Border-aus-MP-Relationen-Ways-Zusammenbastel-Software" auf verschachtelte Relationen erweitern.
Das gilt auch für mich (*)
- Schimpft OSM-Inspector darüber?

Insgesammt eine reizvolle Aktion: viel Arbeit - viel Ärger - wenig Ruhm 😉

Gruss
Walter

• ) Ich werde mal in Hannover auf Admin-Level 10 etwas rumbasteln; da kann ich nichts kaputt machen, da dort schon einige ungenutzte Boundary-Segmente mit Admin-Level 10 rumliegen, die eh zu nix gut sind.
  

Hallo Walter

wambacher wrote:

EvanE wrote:

Das gibt es bereits und nennt sich boundary_segments. Bei den französischen Grenzen wird das wohl bereits eingesetzt.

Froonk-Raiiich hatte ich mir noch nicht angesehen - da ist der sprachliche Tellerrand für mich etwas hoch. Aber dennoch interessant, dass andere Länder das schon so machen.

Das scheinen bisher die einzigen zu sein, die das machen. Es gibt Stand heute erst 26 Relationen mit type=boundary_segment.

wambacher wrote:

Ein sinnvoller Ansatz wäre meiner Meinung nach:
1 Grenzabschnitte als lineare Strukturen in einer Relation mit type=boundary_segment zu erfassen.
2 Die Fläche eines Gebietes als Multipolygon, deren Outer-Abschnitte durch boundary Segments gebildet werden erfassen.
...

ja, dann sind zumindest wir beiden hier der gleichen Meinnung.

Als vielleicht einfaches Beispiel hat Rheinlandpfalz Grenzen zu ... Warum soll man diese Grenzabschnitte nicht als eigene boundary_segment Relationen erfassen und mit diesen das Landesgebiet als Multipolygon?

Im Prinzip schon, allerdings halte ich die "Hemmschwelle" unserer Mitstreiter aus verständlichen Gründen für etwas hoch.
Ich hab mich ja im Laufe fast eines Jahres über Wander-Routen, ÖPNV-Relationen (oxomoa sei Dank) und Administrative Grenzen so langsam hochgearbeitet - für mich wär das absolut kein Problem. Aber der breiten Masse möchte ich das nicht so zwischen Tür und Angel unterjubeln.

Da es bisher überwiegend anders gemacht wurde, wäre das eine Menge Arbeit. Auf der anderen Seite macht eine Unterteilung nach Grenzabschnitten die einzelnen Teile wieder etwas übersichtlicher und damit leichter wartbar. Bei einigen Fern-Wander- und Fern-Rad-Wegen ist das ja bereits eine Aufteilung erfolgreich durchgeführt worden (eine Relation je Bundesland).

Auch die Handhabung von Exklaven und isolierten Inseln würde damit einfacher.

wambacher wrote:

Es gibt noch mindestens zwei weitere Gründe dafür, das mit den Boundary-Segmenten zu machen:
- die Grenz-Relationen werden in mehrere kleiner Stücke aufgespalten - von einem 3-Ländereck zum nächsten.
Damit sind sie kleiner und besser zu verarbeiten (Weniger Ways pro Relation)
- Konflikte verringern sich, da verschiedene Leute gleichzeitig an unterschiedlichen Teilen arbeiten können.
- bestimmt noch mehr ...

Offene Fragen / Punkte:
- Bis zu welchem admin_level könnte das so gehen - 2+4 bestimmt aber auch noch weiter?
- Was macht osm2pgsql damit?
- Was machen die Entwickler? Die müssten dann ihre "Border-aus-MP-Relationen-Ways-Zusammenbastel-Software" auf verschachtelte Relationen erweitern.
Das gilt auch für mich (*)
- Schimpft OSM-Inspector darüber?

Insgesamt eine reizvolle Aktion: viel Arbeit - viel Ärger - wenig Ruhm 😉

• ) Ich werde mal in Hannover auf Admin-Level 10 etwas rumbasteln; da kann ich nichts kaputt machen, da dort schon einige ungenutzte Boundary-Segmente mit Admin-Level 10 rumliegen, die eh zu nix gut sind.
  

Länder und deren unmittelbare Unterteilung (admin_level=2/4) sollten sicher als erste umgestellt werden. Große Verwaltungseinheiten wie Regierungsbezirke und Kreise kämen als nächstes dran. Allerdings sehe ich keinen Grund auf lange Sicht das nicht bis auf Gemeinde oder Stadteil-Ebene (admin_level=8/10) herunter zu verwenden.

Relationen in Relationen können für Auswertungen natürlich ein Problem bedeuten. Auf der anderen Seite funktioniert Frankreich auch in Mapnik. Wie immer werden die Anwendungsgrogramme der Tagging-Praxis hinterher hinken. Damit müsste man für eine Übergangszeit wohl leben.

Beim OSM-Inspector habe ich an der Grenze Frankreich/Italien nichts Spezielles entdecken können. Allerdings weis ich nicht, ob OSMI überhaupt type=boundary_segment betrachtet. Das kann wohl nur der Maintainer des Multipolygon-Views eindeutig klären.

Mit boundary_segment könnte auch den Streit zwischen den Befürwortern von type=boundary und type=multipolygon (hauptsächlich in Deutschland) entschärft werden, da beide Sichten ihre Berechtigung haben und enthalten sind.

PS: Eine Erklärung des hierarchischen Aufbaus der französischen Grenzen findet man im OSM-Wiki hier.

Edbert (EvanE)

Bevor wir hier diffus weitermachen...
Was haltet ihr davon, das Thema mal so anzugehen:
- Welche Vorgehensweise ist für den internationalen Mapper einfach und transparent?
- Welche eindeutige Erfassung ist in der Datenbank gut abbildbar?
- Lassen sich vorhandene Daten auf das einheitliche Schema automatisch umstellen?
- (OOOHHHMMM ignorierend) Wie können Renderer mit dieser methode umgehen?

P.S.:
Ich frage mich schon eine Weile, warum z.B. OSMI die französische Lösung mit warnings belegt 🙄

sorry, verklickt

Moin moin,Michael

hurdygurdyman wrote:

Bevor wir hier diffus weitermachen...

was ist denn hier diffus? ich denke, das mein kleiner Excurs mit Edbert wohl ziemlich konkret ist.
Es handelt sich aber um eine Diskusion der Möglichkeit - nicht der realen Realisierung.

Was haltet ihr davon, das Thema mal so anzugehen:
- Welche Vorgehensweise ist für den internationalen Mapper einfach und transparent?

genau die, die sich eventuell als Ergebnis ergibt.

- Welche eindeutige Erfassung ist in der Datenbank gut abbildbar?

Relationen mit Relationen als Member sind für die DB nicht das geringste Problem. Diese Konstruktion ist schon lange vorhanden, wird allerdings selten verwendet, wenn man sich die Taginfo-Werte ansieht.
Bedenkt man aber, dass für Frankreich ca 6 Grenzstücke auf AL 2 existieren und für Deuschland ca 10 erzeugt werden würden, kann man sich die kleinen Beträge wohl erlären.
Hier "zählt" die Klasse und nicht die Masse.

- Lassen sich vorhandne Daten auf das einheitliche Schema automatisch umstellen?

Bestimmt, da es sich um ein klar definierbares Verfahren handelt (Algorithmus), den man sicher in ein Programm packen könnte. Dies wäre mir aber derzeit zuviel Aufwand.
Hier kommt wieder mal der "deutsche Perfektionismus" zum Vorschein:
"wenn die Grenzen aufgesplittet werden sollen, dann unbedingt bis in das kleinste Kaff hinein --> das ist zuviel Aufwand --> wird brauchen ein Programm dafür und anders geht es nicht"

- (OOOHHHMMM ignorierend) Wie können Renderer mit dieser methode umgehen?

Mapnik hat laut Edbert kein Problem damit; das ist für mich ein Indiz dafür, dass osm2pgsql kein Problem damit hat, und nur was osm2pgsql "vorgekaut" hat, wird von den Standard-Renderen "gefressen"

Ich frage mich schon eine Weile, warum z.B. OSMI die französische Lösung mit warnings belegt 🙄

Warum wiederholst du eigentlich Fragen, die wir oben angeschnitten haben? Dieser Punkt ist offen aber nicht neu.

Zudem wäre es einfacher gewesen, auf deinen Post zu antworten, wenn du dich an kommentierte Zitate gewöhnen könntest.

Gruss
Walter

p.s. ich habe gestern Abend mein Programm zur Erstellung von Shape-Files und Poly-Files mal eben auf verschachtelte Relationen umgestellt:
eine schöne rekursive Funktion, 15 Zeilen Code, das wars.

NACHTRAG: OSMI hat nichts, aber auch garnichts gegen die "französchische Lösung". Zumindest kann ich nichts davon erkennen.
http://tools.geofabrik.de/osmi/debug.ht … _end_nodes

In Österreich sieht das schon anders aus:
http://tools.geofabrik.de/osmi/debug.ht … _end_nodes

Der Grund ist -dem aufmerksamen Anwender- klar erkennbar: Frankreich hält sich an das Proposal und taggt die Grenzstücke als type=boundary_segment und Österreich hat da type=boundary. Daher "motzt" OSMI dort zu recht.

@wambacher:
Es erschien mir diffus...
Meine Fragen zum Thema stellten meine Prämissen hierzu dar. Deine Antworten haben mir geholfen. Danke!!

Ich frage mich schon eine Weile, warum z.B. OSMI die französische Lösung mit warnings belegt

Ich habe mich gefragt und beziehe mich auf folgendes:
http://tools.geofabrik.de/osmi/?view=mu … s_boundary
(Häkchen bei "type=boundary" links 😉

wambacher wrote:
Zudem wäre es einfacher gewesen, auf deinen Post zu antworten, wenn du dich an kommentierte Zitate gewöhnen könntest.

Da stehe ich jetzt auf dem Schlauch. Was meinst du damit?

hurdygurdyman wrote:

Ich frage mich schon eine Weile, warum z.B. OSMI die französische Lösung mit warnings belegt

Ich habe mich gefragt und beziehe mich auf folgendes:
http://tools.geofabrik.de/osmi/?view=mu … s_boundary
(Häkchen bei "type=boundary" links 😉

JO, das ist ein anderes OSMI-Problem, zu dem sich eventuell Frederik(?) äußern kann.

Es geht hier um type=boundary versus type=multipolygon.
OSMI -oder besser der Autor- "mag" keine Grenzen mit type=boundary obwohl dies die weltweit verbreitetere Version des Taggings ist.

siehe: http://wiki.openstreetmap.org/wiki/Relation:boundary

"type multipolygon / boundary in Germany, Ecuador, Colombia and The Netherlands, multipolygon is used"

wambacher wrote:
Zudem wäre es einfacher gewesen, auf deinen Post zu antworten, wenn du dich an kommentierte Zitate gewöhnen könntest.

Da stehe ich jetzt auf dem Schlauch. Was meinst du damit?

Das ist die Sache mit dem quote ... /quote
Diesmal hat es ja geklappt.

Gruss
Walter

wambacher wrote:

...
Das ist die Sache mit dem quote ... /quote
Diesmal hat es ja geklappt.
Gruss
Walter

Hatte doch gar kein Zitat in dem post 🙄
Ansonsten: alles klar

EvanE wrote:

Das scheinen bisher die einzigen zu sein, die das machen. Es gibt Stand heute erst 26 Relationen mit type=boundary_segment.

Jetzt sind es einige mehr, da ich in Hannover -wie angedroht- zugeschlagen habe.

Die Franzosen haben neben den diversen boundary_segment-Relationen und der dazu passenden Super-Relation 1.362.232 auch noch eine Gesamt-Relation 1.403.916. Ist zwar unsinnig aber deren Sache. Da deren ID relativ frisch ist, nehme ich an, dass einige nicht mit der Super-Relation klar kamen und nach der "guten alten Relation" geschrien haben. Dafür spricht auch deren noch jüngeres Datum.

In Österreich ist es etwas anders: eine Gesamt-Relation 16239, mehrere Grenzstücke und keine Master-Relation. Zudem sind die Grenzstück-Relationen doppelt: einmal mit type=boundary getaggt und dann nochmal mit type=boundary_segment. Macht irgendwie keinen Sinn - was sollen die Grenzstücke denn dann? Eventuell äussert sich einer der östrreichischen Kollegen mal dazu.

Da damit schon mehrere Grenzstück-Relationen existieren, die für Deuschland verwendbar sind, erstelle ich mal eine Master-Relation und pack die da rein - schaden kann es nicht.

Länder und deren unmittelbare Unterteilung (admin_level=2/4) sollten sicher als erste umgestellt werden. Große Verwaltungseinheiten wie Regierungsbezirke und Kreise kämen als nächstes dran. Allerdings sehe ich keinen Grund auf lange Sicht das nicht bis auf Gemeinde oder Stadteil-Ebene (admin_level=8/10) herunter zu verwenden.

2 +4 halte ich auch für sinnvoll - natürlich parallel zu den bestehende "Vollgrenzen".

Auf der anderen Seite funktioniert Frankreich auch in Mapnik.

wäre gut, allerdings hab ich da noch meine Zweifel. In Hannover sehe ich da nicht das, was ich erwaretet habe.

Allerdings weis ich nicht, ob OSMI überhaupt type=boundary_segment betrachtet.

Nö,macht er nicht und das ist ok so.

Mit boundary_segment könnte auch den Streit zwischen den Befürwortern von type=boundary und type=multipolygon (hauptsächlich in Deutschland) entschärft werden, da beide Sichten ihre Berechtigung haben und enthalten sind.

da wär ich mir nicht so sicher - so genau hab ich den Unterschied eigentlich noch nicht erkannt.

Hier noch das Ergebnis meines Test in Hannover: http://wnordmann.homeunix.com/images/st … er-rel.png
Das shape für die Südstadt (rel 82728) ist nach der neuen Methode erstellt worden; die andern Stadtteile waren schon als normale Boundaries da. Meinem modifizierten Programm macht das nichts mehr aus. Mapnik ist noch unklar.

Gruss
Walter

Nachtrag: Boundary-Segmente und Master-Relation für Deutschland sind fertig. Wer will, kann sich ja mal die Relation http://www.openstreetmap.org/browse/relation/1111111 ansehen. - ja, die Nummer stimmt!