Hey,Hey,Hey! Das sind Thüringen und Sachsen auch. :D:cool:
@dieterdreist Full ACK.
Ja schon. Aber nur in Bayern gehen die Uhren anders 
Vielleicht wird es Zeit, dass sich die Freistaaten und BaWü zusammentun (an dieser Stelle ein freundlicher Gruß an die Österreicher. 
) und sich vom Flachland trennen.
über ein EU Objekt kann man ja grundsätzlich diskutieren finde ich, was ist eurer Meinung nach die bessere Abbildung: nur die Außengrenzen oder bestehend aus den Flächen (admin Relationen) der einzelnen Länder (oder Teile, falls es Teile gibt die nicht dazu gehören)?
Seit die Briten raus sind dürfte das ja prinzipiell übersichtlicher geworden sein, da hat der Brexit auch sein Gutes 
Zu den Währungen ist mir eingefallen dass es ja auch Länder geben kann die den Euro als offizielle Währung (bzw. Zahlungsmittel) haben und trotzdem nicht in der Eurozone sind (gibt es vielleicht auch derzeit nicht), wobei man die dadurch finden würde dass sie außerhalb der EU sind, oder?
Update: es gibt jede Menge Länder
Andorra
Monaco
San Marino
Vatikanstadt
„passive“ Euronutzer:
(ohne eigene Euromünzen)
Kosovo
Montenegro
Ehe BaWü Freistaat wird, wird sich die Republik Baden wieder von Württemberg ablösen 
Aus meiner Sicht macht es zumindest keinen Sinn, das als Multipolygon oder boundary darzustellen. Ein neues(?) tag wie eu-member=true oder so würde doch völlig reichen.
Der Eintrag als admin-Objekt mit AL=1 wäre zwar logisch, aber würde einen Riesen-Umriss erzeugen, der die meiste Zeit kaputt ist.
Man könnte auch eine Super-Relation erstellen, die nur die Relationen der Mitgliedsstaaten als member haben. Diese Relationen mögen aber nicht alle.
Ein Tag in der AL2-Relation wäre ein Ausweg. Damit geht aber der Relationenwahn in eine Taggeritis über.
Ketzerische Frage: Muss das in OSM rein?
Das ist ja bei allen politischen Grenzen die Frage. admin_level=2 als Fläche ist zumindest für Router hilfreich, um länderspezifische Regeln implementieren zu können. Ein Router wird auch vermutlich eine Überquerung von Ländergrenzen eher vermeiden wollen. Hier könnte man sich vorstellen, dass das unnötige Verlassen der EU dann noch “teurer” wäre.
Nüchterne Antwort:
Nein.
Die wenigen Anwender, die tatsächlich eine Karte der Länder mit EUR oder andere derartige Dinge (alle Hochrisikostaaten, alle Staaten, für die Visumpflicht für Land X besteht etc.) erstellen wollen, können das mit eigenen “Mini”-Listen per Abfrage selber organisieren. Die Mitglieder der EU wechseln ja nicht soo häufig und die Liste mit Visumpflicht wäre auch in OSM spätestens nach zwei Jahren wieder komplett umorganisiert. Oder Bayern fehlt in der Relation und keiner merkt es 
ich würde als erstes die subareas aus den Relationen nehmen, wenn es dazu weiterhin keinen Widerspruch gibt…
Die schleppen wir schon seit 25.10.2013 mit uns rum.
Über die diversen Europarelationen müsste man wohl auf tagging sprechen.
Tja, ich fand die Landmassen-Relationen bislang schon sehr hilfreich, beispielsweise beim Zeichnen von Deutschlandkarten. Da hat man durch diese Relation sehr einfach einen schönen Rahmen, den man mal eben um Deutschland drum rum malen kann. (Siehe https://wiki.openstreetmap.org/wiki/File:Speed-index-germany.png für ein Beispiel.)
Du schreibst, man könne das “problemlos” ausrechnen. Hast du schon mal ein Programm geschrieben, welches das Schnitt-Multi-Polygon zweier Multi-Polygone berechnet? Ich habe das gemacht (für die Karten oben brauchte ich das) und etwa vier Monate harte Arbeit dafür benötigt. Ergebnis: Akzeptabel, aber ich bin nicht glücklich damit, weil es immer noch Fälle gibt, bei denen das Ergebnis nicht ganz stimmt. Es war mit Abstand das aufwändigste Programmierprojekt in meinem Leben… Ich hab’ den Algorithmus jetzt und kann ihn natürlich dafür nutzen, die Landmassen selber zu bestimmen; aber es wäre nochmal zusätzlicher Aufwand und andere Leute haben das nicht…
Ich kann verstehen, dass man redundante Daten loswerden möchte. Schön wäre es beispielsweise, wenn es einen Server gäbe, der die Landmassen für diverse Gebiete automatisch berechnet und diese dann der Öffentlichkeit bereitstellt. Solange es den aber nicht gibt, wäre ich dafür, trotz unerwünschter Redundanz, die Landmassenpolygone drin zu lassen…
Kommt wahrscheinlich auf die verwendete Sprache bzw. die Bibliotheken an. In Java ist es sehr simpel, Auszug aus JOSM:
Area inter = new Area(a1);
inter.intersect(a2);
Der Code, der die jeweiligen Areas der Multipolygone a1 und a2 berechnet ist allerdings erheblich komplexer
Und ja, es gibt Sonderfälle, wo nicht ganz das rauskommt, was man gerne hätte, insbesondere, wenn a1 und a2 in etwa die gleiche Flähe beschreiben, dann kann gerne mal am Rand ein Stück stehenbleiben, das man eigentlich nicht möchte. Das sind dann winzige Dreiecke, die praktisch unsichtbar sind, aber gerne mal Ärger machen, wenn man vergleichen will, ob ein Polygon innerhalb eines anderen ist oder nicht.
OK, dann nächste Frage: Was ist a1? Laut Java-Spec muss es eine Klasse sein, die das Interface Shape implementiert. Dort finde ich allerdings kein Multipolygon im Bereich “All Known Implementing Classes”.
Hilfreich sind sie ja nur, wenn sie auch richtig und vollständig sind. Und irgendwie denke ich, man sollte auch den Nutzen den sie für eine bestimmte spezielle Fragestellung bieten, gegenrechnen mit dem Schaden den sie dadurch anrichten, dass sie durch ihre Komplexität Mapper davon abhalten, bestimmte Edits zu tun.
Für das Berechnen muss man das Rad nicht neu erfinden, das können übliche, auch freie, Tools wie QGis, GrassGIS, ogrtools etc.
Es gibt kein “Deutschland Landmasse”, es gibt Deutschland, und benötigte Teile davon muss man jeweils nach Bedarf filtern. Wir machen ja auch keine Multipolygone “Deutschland Wasserflächen”, oder “Deutschland Waldflächen”. Das sind Sammelrelationen.
https://gdal.org/programs/ogr2ogr.html
Um das zu erhalten was in der Landmasse-Relation ist (sein sollte), könnte man z.B. Gesamtdeutschland (inkl. Inseln und Wasser) nehmen und die Meeresflächen abziehen, und dann in einem zweiten Schritt die Inseln im Meer heraussuchen, und in einem dritten Schritt die Inseln mit der Festlandfläche kombinieren.
Klar, Ich habe das schon in #15 geschrieben.
Edit: Bezog sich auf #16.
Das beantwortet meine Frage allerdings nicht. Ich finde in Java die Klasse “Multipolygon” nicht. Was ist also a1?
a1 und a2 sind auch vom Typ Area. Der Code, der aus den OSM Daten die Areas berechnet, ist halt komplexer. Aber den braucht man ja sowieso.
Wenn die das können, was man am Ende haben will? Ich hab’ sie mir jetzt noch nicht im Detail angeschaut und auch nicht ausprobiert, ob ich sie zum Laufen bekomme - hab’ grad andere Projekte um die ich mich kümmern muss - ein erster Blick auf ogrtools sagt mir aber, dass ich damit osm-Daten nur importieren, nicht aber exportieren kann… Aber wahrscheinlich gibt es dafür auch eine Lösung, mir schon klar. Danke jedenfalls erst einmal für den Hinweis auf die Tools. Kannte ich alle drei bislang nicht.
Hier ist auch so ein Kandidat, was haltet ihr von solchen network relationen?
https://www.openstreetmap.org/relation/7884303
Diese Information kann an die einzelnen Objekte und dafür brauchen wir keine Sammelrelationen.