Meinst du die passende land_area-Relation als role “land_area”? Das beobachte ich seit einiger Zeit mit Verwunderung. Diese Rolle hat sich bei sehr vielen Grenzrelationen eingeschlichen.
ja , genau die meine ich - und halte die für totalen quatsch.
wo taucht der M… denn auch noch auf? bei uns oder auch in anderen Ländern?
wenn jetzt jemand z.b. die 51477 nimmt, und ALLE Member grafisch darstellt, hat er
a) Administrative Grenze Deutschland
b) Landarea Deuschland
UND
c) die Bundesländer.
Das darf es wohl nicht sein. Eine Relation, die die Administrative Grenze eines Landes beschreibt, sollte auch nur diese enthalten. genaugenommen ist sogar das admin_centre hier fehl am Platz.
Gruss
walter
Hybridwesen, die sowohl die kompletten Wege als auch die Teile einer Grenze bzw. Fläche beschreiben, finde ich auch sehr problematisch.
Aber, und das habe ich schonmal hinterfragt, ist es wirklich sinnvoll, Relationen mit so vielen Elementen zu haben (Rel. 51477 besteht aus 1282 ways, Rel. 62781 aus 1979 ways)?
Deutschland sollte doch durch seine Teile (Bundesländer) oder eben seine jeweiligen Außengrenzen zu anderen Ländern ausreichend spezifiziert sein. Ja, ich weiß, osm2pgsql kann das nicht verarbeiten. Aber das wäre ja keine Hexerei.
Relation 62781 ist übrigens die Landmasse Deutschlands. Hier kein osm/browse-Link sonst stürzt der Browser ab…
Auch schön: Die Marguerite-Route in Dänemark mit 4847 ways.
Habs nur in DE an den Küsten beobachtet (Länder, Kreise, kreisfreie Städte).
Habs nur in DE an den Küsten beobachtet (Länder, Kreise, kreisfreie Städte).
ok, dann schau ich mir die mal an und frage beim verursacher nach. der hat auch die subareas “verbrochen”
- wer hat da die sogenannten Subareas der Bundesländer “reingeschmuggelt” und warum überhaupt? Ich kann keinerlei nützliche Funktion für derartige Konstrukte in einer Grenzrelation entdecken und möchte die demnächst entsorgen.
Die Relationen mit Rollen subarea- und land_area tauchen erstmals in Version 1358 auf und stammen von demselben französischen Kollegen, der auch die Grenzlinien ab Bundeslandebene europaweit mit name-Tags versehen hat. Du kannst ihn gerne fragen, aber nach meiner Erfahrung kommt da keine Antwort.
Edit: Den Verursacher hast Du ja selbst schon herausgefunden. Dein letztes Posting hatte ich noch nicht gesehen.
Den Verursacher hast Du ja selbst schon herausgefunden. Dein letztes Posting hatte ich noch nicht gesehen.
alles klar,
war mir nur nicht sicher, dass der dahinter steckt. hab ihn zwar auf (naja-)Englisch angeschrieben und etwas deutsch aber von ihm erwarte ich wirklich nichts.
die landareas sind schon draussen und bei den subareas hab ich fast auch keine Bedenken, die rauszuschmeissen.
was nun? bin gerade so richtig in Killer-Laune
Gruss
walter
Aber, und das habe ich schonmal hinterfragt, ist es wirklich sinnvoll, Relationen mit so vielen Elementen zu haben (Rel. 51477 besteht aus 1282 ways, Rel. 62781 aus 1979 ways)?
Deutschland sollte doch durch seine Teile (Bundesländer) oder eben seine jeweiligen Außengrenzen zu anderen Ländern ausreichend spezifiziert sein.
Wie bei den Bundesstraßen-Routen bin ich der Meinung, dass eine Relation nicht mehr als etwa 2-300 Mitglieder haben sollte.
Bei den Grenzen sind für mich die Reg.bezirke o.ä. (admin_level=5) das Äußerste der Gefühle, schon die Bundesländer mit mehr als 500 fasse ich wenn möglich überhaupt nicht an. Deutschland und Frankreich mit über 1000 sind nicht mehr vernünftig wartbar.
Die einzige Lösung die mir einfällt, ist die Aufteilung in Relationen als Segmente, da am liebsten wie bei den Bundesstraßen so, dass die Master-Relation BRD nur noch Segment-Relationen und keine ways mehr enthält. Für die Segmente bieten sich als erster Schritt die Teilabschnitte der Bundesländer an (das sind **nicht **die subareas).
Dadurch ist die Grenze Deutschlands als Objekt komplett in der Datenbank und trotzdem noch wartbar (divide and conquer).
Der Nachteil der Segmentierung ist, dass die QA-Tools möglicherweise dann die Vollständigkeit der deutschen Grenze nicht mehr überprüfen, falls sie nicht mit Subrelationen umgehen können.
Zu den subareas: Die gehören mMn nicht in die admin_Relationen, sonst müssten konsequenterweise die Reg.bezirke in die Länder, die Kreise in die Reg.Bez., die Gemeinden in die Kreise …
Wer die Information, welche Areas in anderen enthalten sind, unbedingt braucht, sollte in der Lage sein, dies mit GIS-Tools aus den Daten extrahieren zu können.
Ich habe zwar begrenzt Verständnis dafür, dass manche häufiger(?) gebrauchte Informationen redundant an mehreren Stellen auftauchen (is_in_, addr:country), weil sie indirekt nur mit größerem Aufwand zu gewinnen sind, aber irgendwo muss Schluss sein.
Zu den subareas: Die gehören mMn nicht in die admin_Relationen, sonst müssten konsequenterweise die Reg.bezirke in die Länder, die Kreise in die Reg.Bez., die Gemeinden in die Kreise …
Ja, eben das. Wenn es denn so definiert ist. Das nennt man Induktion. Alles andere ist redundant und auch error-prone.
Das einzige Gegenargument für mich ist, dass die meisten Tools (im Moment) zu “dumm” sind. No offense.
Wer die Information, welche Areas in anderen enthalten sind, unbedingt braucht, sollte in der Lage sein, dies mit GIS-Tools aus den Daten extrahieren zu können.
Es geht nicht darum, dass jemand diese Area-Information braucht, sondern dass man die Grenzweg-Information nicht bis zu 5-fach braucht.
Die einzige Lösung die mir einfällt, ist die Aufteilung in Relationen als Segmente, da am liebsten wie bei den Bundesstraßen so, dass die Master-Relation BRD nur noch Segment-Relationen und keine ways mehr enthält. Für die Segmente bieten sich als erster Schritt die Teilabschnitte der Bundesländer an (das sind **nicht **die subareas).
siehe “mein baby” ab v9: ist inzwischen fast drei Jahre alt und kann schon laufen.
es gibt da leider einige “kleinere” technische Probleme:
- Josm lädt die 1111111 nicht vollständig, man muß manuell nachladen
- osm2pgsql kann keine Master/Slave-Relationen verarbeiten und diese stehen dann in der DB z.B. für Auswertungen oder zum Rendern mit Mapnik nicht zur Verfügung. Das erkennt man auch der oben verlinkten Seite - dort werden nur admin_centre und label angezeigt, der Rest fehlt.
Konkret: Ohne die ach so große 51477 wären die meissten aufgeschmissen, da wir dann überhaupt keine Grenze der BRD in der Datenbank hätten.
Man kann sich diese natürlich mit erheblichem Aufwand aus der Tabelle planet_osm_rels zusammenpfriemeln, aber das halte ich nicht für zumutbar.
Gruss
walter
Eine Relation, die die Administrative Grenze eines Landes beschreibt, sollte auch nur diese enthalten.
sowürde ich es auch sehen.
Deine Beschreibung:
wenn jetzt jemand z.b. die 51477 nimmt, und ALLE Member grafisch darstellt, hat er
a) Administrative Grenze Deutschland
b) Landarea Deuschland
UND
c) die Bundesländer.Das darf es wohl nicht sein.
Das sind doch nichts weiter als Sammelrelation, angewendet auf Grenzen… um anhand einer Relationsnummer die Grenzen zu bekommen. Leztendlich würde man das selbe Ergebnis mit einer entsprechenden Datenbankabfrage erhalten.
was nun? bin gerade so richtig in Killer-Laune
Saubere Grenzen? 100% dafür, leg los…
Sven
Leztendlich würde man das selbe Ergebnis mit einer entsprechenden Datenbankabfrage erhalten.
wie sagt man so schön: “Ich hätt’ da mal was vorbereitet”
planet2=# \set w -2370431
planet2=#
planet2=# select -(i.osm_id) "inner",i.admin_level,i.name,
planet2-# -(o.osm_id) "outer",o.admin_level,o.name
planet2-# from planet_osm_polygon o, planet_osm_polygon i
planet2-# where st_contains(o.way,i.pointonsurface)
planet2-# and i.pointonsurface && ((select way from planet_osm_polygon where osm_id=-51477))
planet2-# and i.boundary='administrative'
planet2-# and o.boundary='administrative'
planet2-# and i.osm_id = :w
planet2-# order by o.admin_level
planet2-# ;
inner | admin_level | name | outer | admin_level | name
---------+-------------+-----------------+---------+-------------+--------------------------
2370431 | 11 | Brackwede Mitte | 51477 | 2 | Deutschland
2370431 | 11 | Brackwede Mitte | 62761 | 4 | Nordrhein-Westfalen
2370431 | 11 | Brackwede Mitte | 73347 | 5 | Regierungsbezirk Detmold
2370431 | 11 | Brackwede Mitte | 62646 | 6 | Bielefeld
2370431 | 11 | Brackwede Mitte | 976442 | 9 | Stadtbezirk Brackwede
2370431 | 11 | Brackwede Mitte | 1014629 | 10 |
2370431 | 11 | Brackwede Mitte | 2370431 | 11 | Brackwede Mitte
(7 rows)
planet2=#
findet mal “so eben” alle Grenzen, in denen sich ein Punkt oder hier “Brackwede Mitte” befindet.
Gruss
walter
Saubere Grenzen? 100% dafür, leg los…
done.
Die, die ich finden konnte, sind weg.
Gruss
walter
Hannover wurde auch von einem gewissen Mapper mit subarea beglückt, löschen? behalten? http://www.openstreetmap.org/relation/62764
Edit, hier auch:
http://www.openstreetmap.org/changeset/18625336
http://www.openstreetmap.org/changeset/18528382
Mittelfranken: www.openstreetmap.org/relation/17614
Hamburg: http://www.openstreetmap.org/relation/451087
Leipzig: www.openstreetmap.org/relation/62434
Hannover wurde auch von einem gewissen Mapper mit subarea beglückt, löschen? behalten?
http://www.openstreetmap.org/relation/62764 Mapper A 2.12.2013
http://www.openstreetmap.org/changeset/18625336 Mapper B: 10.10.13,
http://www.openstreetmap.org/changeset/18528382 mapper B 25.10.13
Mittelfranken: www.openstreetmap.org/relation/17614 mapper B, 25.10.2013
Hamburg: http://www.openstreetmap.org/relation/451087 Mapper B 25.10.12
Leipzig: www.openstreetmap.org/relation/62434 ??? vor 19.7.2013
Nur den ersten Mapper solltest du anschreiben und auf diesen Thread hinweisen.
Die anderen scheinen Leichen zu sein, die wir noch nicht gefunden haben. Kannst du wohl wohl ungefragt bereinigen und im CS auf diesen Thread hinweisen (*) . Ich werde mich mal auf die Suche machen.
Gruss
walter
*) wenn du Ärger vermeiden willst, mach ich das gerne - bin da manchmal ziemlich stur.
Search done:
id | name
---------+----------------------------------------
1785578 | Altenpleen
30223 | Altona
403578 | Bad Doberan-Land
1356840 | Bad Lausick
2856440 | Bad Sulza
62646 | Bielefeld
62508 | Bonn
1863265 | Bothfeld-Vahrenheide
1014629 | Brackwede
1001322 | Brake
1862974 | Buchholz-Kleefeld
1958438 | Bützow-Land
1782772 | Carbäk
422336 | Colditz
2226718 | Eckardtsheim
1014604 | Gadderbaum
1356839 | Geithain
907212 | Gernsbach
1481720 | Grevesmühlen-Land
422342 | Grimma
1014620 | Großdornberg
59418 | Hannover
1001320 | Heepen
1863547 | Herrenhausen-Stöcken
953535 | Jöllenbeck
1479686 | Klützer Winkel
62512 | Koblenz
62779 | Kreis Coesfeld
367873 | Kücknitz
1355598 | Kühren-Burkartshain
62434 | Landkreis Leipzig
1739377 | Landkreis Rostock
62462 | Landkreis Weimarer Land
422918 | Lossatal
80107 | Mitte
17614 | Mittelfranken
1115389 | Münster - Altstadt
2984753 | Naunhof
1515662 | Neuburg
1863490 | Nord
1001325 | Oldentrup
418816 | Ortsamt Mitte
418811 | Ortsamt Nordwest 1
418812 | Ortsamt Nordwest 2
418818 | Ortsamt Ost
418815 | Ortsamt West
2984755 | Pegau
1014628 | Quelle
62764 | Region Hannover
2984756 | Regis-Breitingen
2984757 | Rötha
390043 | Saale-Wipper
367872 | Sankt Gertrud
367868 | Sankt Jürgen
2313918 | Stadtbezirk 17 Obergiesing-Fasangarten
2121824 | Stadtbezirk Bonn
976442 | Stadtbezirk Brackwede
976440 | Stadtbezirk Dornberg
976439 | Stadtbezirk Gadderbaum
975261 | Stadtbezirk Heepen
974940 | Stadtbezirk Jöllenbeck
976404 | Stadtbezirk Mitte
976422 | Stadtbezirk Schildesche
976441 | Stadtbezirk Senne
976380 | Stadtbezirk Sennestadt
976364 | Stadtbezirk Stieghorst
1014611 | Stieghorst
367874 | Travemünde
1014612 | Ubbedissen
1014627 | Ummeln
80152 | Vahrenwald-List
953520 | Vilsendorf
403570 | Warnow West
1177823 | Wedemark
73888 | Wunstorf
422917 | Wurzen
(76 rows)
josm: 1014628,907212,17614,403578,418812,418816,418815,403570,418811,418818,1863547,1782772,62434,422918,976439,1014604,80152,62764,59418,2313918,1479686,1958438,367874,367868,367872,62779,2984756,2984753,62462,2984755,1481720,974940,953535,390043,1785578,976440,976404,975261,1001325,62512,1739377,367873,62508,73888,976380,2226718,1862974,1115389,1863265,2984757,80107,1001322,1014612,953520,1177823,422342,422336,2121824,1356839,1356840,1515662,422917,1355598,976364,976442,62646,1014611,976441,1014627,1014629,2856440,30223,976422,1014620,1001320,1863490
wenn die heute abend noch so sind, schmeiss ich die raus.
Gruss
walter
http://www.openstreetmap.org/relation/62764 Mapper A 2.12.2013
Das war auch Mapper B soweit ich das erkennen kann?
Nur den ersten Mapper solltest du anschreiben und auf diesen Thread hinweisen.
Die anderen scheinen Leichen zu sein, die wir noch nicht gefunden haben. Kannst du wohl wohl ungefragt bereinigen und im CS auf diesen Thread hinweisen (*) .Ich werde mich mal auf die Suche machen.*) wenn du Ärger vermeiden willst, mach ich das gerne - bin da manchmal ziemlich stur.
Ich habe es hier angekündigt um einen etwaigen Shitstorm zu vermeiden Wenn es darauf ankommt stelle ich mich aber auch gerne der Diskussion. Werde aber heute nicht mehr dazu kommen, da irgendetwas zu verändern. Wenn du Lust hast kannst du es gerne übernehmen.
Gruß JohnDoe
Das war auch Mapper B soweit ich das erkennen kann?
hab ich mich wohl verguckt.
Ich habe es hier angekündigt um einen etwaigen Shitstorm zu vermeiden Wenn es darauf ankommt stelle ich mich aber auch gerne der Diskussion. Werde aber heute nicht mehr dazu kommen, da irgendetwas zu verändern. Wenn du Lust hast kannst du es gerne übernehmen.
Da befürchte ich keine Probleme. In diesem Thread wurde “beschlossen”, daß wir in Deutschland keine Subareas haben wollen. Das gleiche Ergebnis auf Talk-de. Und diese Subareas sind wohl alle älter als dieser Beschluß. Sind bestimmt übersehen worden.
Spätestens heute Abend sind die weg.
Gruß
walter
Subareas sollten weg sein. in ca 2 Stunden fahr ich nochmal ne Auswertung.
Gruss
walter