Importionitis und Relationenwahn

dieterdreist · 2021-12-01 10:50:51

Wir haben in einem Parallelthread über place-Repräsentationen von admin Objekten gesprochen, und aus diesem Anlass hatte ich mir ein bisschen den derzeitigen Stand des tagging solcher Objekte angesehen.

Zuerst die leichtere Kost, hier ist "Deutschland" als Punkt:
https://www.openstreetmap.org/node/1683325355

Die ganzen Namen, Abkürzungen und IDs mal weggelassen, bleiben diese tags übrig:
capital_city Berlin
currency EUR
place country
population 81879976
source OS OpenData StreetView
source:sqkm CIA World Factbook
sqkm 357022
wikidata Q183
wikipedia de:Deutschland

Als Kartenanbieter der selbst die Grunddaten erhebt, haben wir einen tag mit einer Flächenangabe von der CIA?
Abgesehen davon dass man hier gut sehen kann, wie wenig Sinn "source" als Objekttag macht, sind da zwar ein paar Wiederholungen (im Abgleich zum Rest von OSM) drin (z.B. capital city obwohl das auch schon an anderer Stelle mind. 2x steht), aber eigentlich ist das noch ziemlich niederschwellig und so 1-2 tags mehr sind vom Ressourcenbedarf nicht der Rede wert.

Jetzt zu den härteren Brocken:
Deutschland als administrative Fläche (relation type=boundary)
https://www.openstreetmap.org/relation/51477
gefilterte tags:
admin_level 2
border_type country
boundary administrative
currency EUR
default_language de
flag http://upload.wikimedia.org/wikipedia/c … ermany.svg
note this is the full administrative area including borders in territorial waters
note:2 see also relation id:1111111 for the equivalent relation using multilinestrings
note:3 see relation id:62781 for the landmass only (multipolygon, not boundary)
timezone Europe/Berlin
type boundary
wikidata Q183
wikipedia de:Deutschland

Semantisch dachte ich bisher, type=boundary wäre für eine Fläche, aber mit dem tag "border_type" bezieht man sich explizit auf die Grenzlinie, oder? Der border_type tag ist für unterschiedliche Arten von Grenzen, laut Wiki z.B. maritime Grenzen, importierte Grenzen, laut taginfo aber real wohl vorwiegend als Redundanzebene von admin_level benutzt? https://taginfo.openstreetmap.org/keys/ … ype#values
Scheint jedenfalls ein tag für Linien zu sein und nicht für Flächen. Hier löschen, ok?

place=country scheint zu fehlen, ist auch nicht ganz klar, was das mehr aussagen würde im Vergleich zu admin_level=2 und boundary=administrative. Sollte man das ergänzen?

Die Relation 1111111 ist seit 4 Jahren gelöscht, vermutlich gute Entscheidung damals, danke WB.

Die Relation 62781 (D. Landmasse) ist dagegen bereits in der epischen Version 2325, und erwartungsgemäß unvollständig (nicht die komplette Landmasse). Da es sich hier um ein theoretisches Konstrukt handelt, das man problemlos aus Deutschland minus die Seeflächen berechnen kann, plädiere ich mal wieder dafür, die Relation ersatzlos zu löschen. Einspruch?

Richtig krass redundant sind die Member von Deutschland, weil da alle Bundesländer nochmal als "subarea" drin sind. Komplett mit ihrer ganzen Geometrie. Wieso das denn? Das braucht man doch explizit nicht, darum haben wir doch eine räumliche Datenbank und hierarchische admin_level tags?

Die Deutschlandrelation (51477) ist ihrerseits auch Mitglied in unterschiedlichen Relationen, z.B. gibt es die redundante Relation "Eurozone" https://www.openstreetmap.org/relation/12729625 die alle Geometrien der Länder beinhaltet, in denen der Euro eingeführt ist, obwohl es dafür bereits den schlichten tag "currency" gibt, der genau gleich viel Informationen enthält (ausser dem Link zu https://www.wikidata.org/wiki/Q8268 evtl. ist das der Grund für die Relation?). Da fehlt übrigens noch ein name:de, falls sich jemand verewigen will.

Weitere Relationen in denen Deutschland Mitglied ist:
Organisation des Nordatlantikvertrags (steht so in OSM) https://www.openstreetmap.org/relation/12733310
EU https://www.openstreetmap.org/relation/2668952 (laut description ohne Überseeterritorien und andere Teile die nicht zur EU gehören)
Mitgliedstaaten der Europäischen Union https://www.openstreetmap.org/relation/13376469 (Gesamtgebiet aller Länder die zur EU gehören, also auch Gebiete die nicht zur EU gehören sondern nur zu einem Mitgliedsstaat).

Fehlt da nicht noch eine Relation für die assoziierten Länder?
Im Ernst, wozu brauchen wir eine Relation, die Mitgliedsstaaten der EU heißt und wo alle Gebiete drin sind, auch die die nicht zur EU gehören? Denselben Effekt könnte man doch auch mit einem einfachen tag erzielen, oder? Und eine für die Eurozone, obwohl bereits ein einfacher tag etabliert ist, der das Problem löst? Die type=treaty Relationen, genauso wie die default Speedlimits und bundeseinheitlichen Feiertage halte ich andererseits für relativ harmlos, weil diese exotischen Relationstypen von den meisten Anwendungen vermutlich übersprungen werden, aber wer sich ein räumliches Extrakt mit allem erzeugt, wird die natürlich auch verarbeiten müssen, und die Hauptdb wird natürlich auch damit belastet und muss Änderungen an den Membern verfolgen etc.

Wie steht ihr zu diesen Relationen, bringen die irgendwem was? Wollen wir demnächst alle Handelsverträge auch noch einpflegen in OSM?

Last edited by dieterdreist (2021-12-01 10:57:04)

MKnight · 2021-12-01 13:27:07

Unabhängig ob die Relationen für irgendwas gut sind...

dieterdreist wrote:

Im Ernst, wozu brauchen wir eine Relation, die Mitgliedsstaaten der EU heißt und wo alle Gebiete drin sind, auch die die nicht zur EU gehören?

Überseegebiete gehören grossteils auch zur EU.

dooley · 2021-12-01 13:46:23

dieterdreist wrote:

Richtig krass redundant sind die Member von Deutschland, weil da alle Bundesländer nochmal als "subarea" drin sind. Komplett mit ihrer ganzen Geometrie. Wieso das denn? Das braucht man doch explizit nicht, darum haben wir doch eine räumliche Datenbank und hierarchische admin_level tags?

Das ist mal wirklich seltsam. Zumal Bayern da nicht aufgeführt ist (oder bin ich blind).

pyram · 2021-12-01 21:46:20

dooley wrote:

Zumal Bayern da nicht aufgeführt ist (oder bin ich blind).

Bayern gehört nicht wirklich dazu. Ist schließlich ein Freistaat

aeonesa · 2021-12-01 22:15:29

Hey,Hey,Hey! Das sind Thüringen und Sachsen auch.

@dieterdreist Full ACK.

Last edited by aeonesa (2021-12-01 22:19:04)

pyram · 2021-12-01 22:34:05

aeonesa wrote:

Hey,Hey,Hey! Das sind Thüringen und Sachsen auch. big_smilecool

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.

dieterdreist · 2021-12-02 00:07:43

ü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

Last edited by dieterdreist (2021-12-02 00:14:46)

FraukeLeo · 2021-12-02 09:35:38

pyram wrote:

dass sich die Freistaaten und BaWü zusammentun

Ehe BaWü Freistaat wird, wird sich die Republik Baden wieder von Württemberg ablösen

GerdP · 2021-12-02 12:41:45

dieterdreist wrote:

über ein EU Objekt kann man ja grundsätzlich diskutieren finde ich,

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.

seichter · 2021-12-02 13:08:21

GerdP wrote:

dieterdreist wrote:
über ein EU Objekt kann man ja grundsätzlich diskutieren finde ich,
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?

GerdP · 2021-12-02 14:50:50

seichter wrote:

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.

pyram · 2021-12-02 18:43:41

seichter wrote:

Ketzerische Frage: Muss das in OSM rein?

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

dieterdreist · 2021-12-06 00:03:45

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.

Last edited by dieterdreist (2021-12-06 00:32:24)

kumakyoo · 2021-12-06 11:46:50

dieterdreist wrote:

Die Relation 62781 (D. Landmasse) ist dagegen bereits in der epischen Version 2325, und erwartungsgemäß unvollständig (nicht die komplette Landmasse). Da es sich hier um ein theoretisches Konstrukt handelt, das man problemlos aus Deutschland minus die Seeflächen berechnen kann, plädiere ich mal wieder dafür, die Relation ersatzlos zu löschen. Einspruch?

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/Fil … ermany.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...

GerdP · 2021-12-06 12:43:48

kumakyoo wrote:

Hast du schon mal ein Programm geschrieben, welches das Schnitt-Multi-Polygon zweier Multi-Polygone berechnet?

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.

kumakyoo · 2021-12-06 13:01:08

GerdP wrote:

kumakyoo wrote:
Hast du schon mal ein Programm geschrieben, welches das Schnitt-Multi-Polygon zweier Multi-Polygone berechnet?
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);

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".

Last edited by kumakyoo (2021-12-06 13:01:57)

dieterdreist · 2021-12-06 13:02:18

kumakyoo wrote:

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/Fil … ermany.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?

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

-clipsrc [xmin ymin xmax ymax]|WKT|datasource|spat_extent
Clip geometries to the specified bounding box (expressed in source SRS), WKT geometry (POLYGON or MULTIPOLYGON), from a datasource or to the spatial extent of the -spa.. option if you use the spat_extent keyword. When specifying a datasource, you will generally want to use it in combination of the -clipsrclayer, -clipsrcwhere or -clipsrcsql options

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.

Last edited by dieterdreist (2021-12-06 13:09:20)

GerdP · 2021-12-06 13:05:45

Klar, Ich habe das schon in #15 geschrieben.
Edit: Bezog sich auf #16.

Last edited by GerdP (2021-12-06 13:07:34)

dieterdreist · 2021-12-06 13:13:05

Zur Info, ich habe hier https://www.openstreetmap.org/changeset/114616683 die subareas entsorgt

kumakyoo · 2021-12-06 13:28:56

GerdP wrote:

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?

GerdP · 2021-12-06 13:33:43

kumakyoo wrote:

GerdP wrote:
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.

kumakyoo · 2021-12-06 13:37:23

dieterdreist wrote:

Für das Berechnen muss man das Rad nicht neu erfinden, das können übliche, auch freie, Tools wie QGis, GrassGIS, ogrtools etc.

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.

dieterdreist · 2021-12-06 23:53:24

Hier ist auch so ein Kandidat, was haltet ihr von solchen network relationen?
https://www.openstreetmap.org/relation/7884303

oder Öpnv https://www.openstreetmap.org/relation/389557

Last edited by dieterdreist (2021-12-06 23:55:21)

skyper · 2021-12-07 18:11:17

dieterdreist wrote:

Hier ist auch so ein Kandidat, was haltet ihr von solchen network relationen?
https://www.openstreetmap.org/relation/7884303
oder Öpnv https://www.openstreetmap.org/relation/389557

Diese Information kann an die einzelnen Objekte und dafür brauchen wir keine Sammelrelationen.

Announcement

#1 2021-12-01 10:50:51

Importionitis und Relationenwahn

#2 2021-12-01 13:27:07

Re: Importionitis und Relationenwahn

#3 2021-12-01 13:46:23

Re: Importionitis und Relationenwahn

#4 2021-12-01 21:46:20

Re: Importionitis und Relationenwahn

#5 2021-12-01 22:15:29

Re: Importionitis und Relationenwahn

#6 2021-12-01 22:34:05

Re: Importionitis und Relationenwahn

#7 2021-12-02 00:07:43

Re: Importionitis und Relationenwahn

#8 2021-12-02 09:35:38

Re: Importionitis und Relationenwahn

#9 2021-12-02 12:41:45

Re: Importionitis und Relationenwahn

#10 2021-12-02 13:08:21

Re: Importionitis und Relationenwahn

#11 2021-12-02 14:50:50

Re: Importionitis und Relationenwahn

#12 2021-12-02 18:43:41

Re: Importionitis und Relationenwahn

#13 2021-12-06 00:03:45

Re: Importionitis und Relationenwahn

#14 2021-12-06 11:46:50

Re: Importionitis und Relationenwahn

#15 2021-12-06 12:43:48

Re: Importionitis und Relationenwahn

#16 2021-12-06 13:01:08

Re: Importionitis und Relationenwahn

#17 2021-12-06 13:02:18

Re: Importionitis und Relationenwahn

#18 2021-12-06 13:05:45

Re: Importionitis und Relationenwahn

#19 2021-12-06 13:13:05

Re: Importionitis und Relationenwahn

#20 2021-12-06 13:28:56

Re: Importionitis und Relationenwahn

#21 2021-12-06 13:33:43

Re: Importionitis und Relationenwahn

#22 2021-12-06 13:37:23

Re: Importionitis und Relationenwahn

#23 2021-12-06 23:53:24

Re: Importionitis und Relationenwahn

#24 2021-12-07 18:11:17

Re: Importionitis und Relationenwahn

Board footer