Hilfe bei Mulipolygonen benötigt / Fehler in JOSM korrigieren

Communities Deutschland (Germany)
61

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.

62

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=multipolygon&lon=15.75862&lat=47.26690&zoom=8&overlays=invalid_geometry_hull,duplicate_ways,intersections,intersection_lines,ring_not_closed_hull,ring_not_closed,unconnected_end_nodes,touching_inner_rings_hull,touching_inner_rings,role_mismatch_hull,role_mismatch,duplicate_tags_hull,duplicate_tags,multipolygons_type_is_boundary,type_is_boundary,ways,role_markers,way_end_nodes,way_nodes

63

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

64

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

65

hi,

sieht ja “richtig falsch” aus :wink:
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

66

@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 :roll_eyes:

67

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

Gruß
Josef

68

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

69

Warum “meckert” OSMI denn dann?

70

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 :frowning:

71

Was man so alles lernt, wenn man sich mit MP’s befasst…

@wambacher:
Ich werde mich auch nicht in “Grenzkonflikte” anderer einmischen :wink:

72

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.

73

Try and error.

Gruß
Josef

74

ist ja auch ein “relativ” komplexes Thema :wink:

75

Hallo Walter

Das gibt es bereits und nennt sich http://wiki.openstreetmap.org/wiki/Relations/Proposed/boundary_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)

76

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.

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

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 :wink:

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.

77

Hallo Walter

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

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.

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)

78

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 :roll_eyes:

79

sorry, verklickt

80

Moin moin,Michael

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.

genau die, die sich eventuell als Ergebnis ergibt.

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.

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”

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”

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.html?view=multipolygon&lon=8.10961&lat=48.31966&zoom=8&opacity=0.80&overlays=ring_not_closed_hull,ring_not_closed,unconnected_end_nodes

In Österreich sieht das schon anders aus:
http://tools.geofabrik.de/osmi/debug.html?view=multipolygon&lon=11.92736&lat=47.58293&zoom=8&opacity=0.80&overlays=ring_not_closed_hull,ring_not_closed,unconnected_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.