grenzen - speziell 51477 für deutschland

hi, wegen der aktuellen Mapping-Unfälle und da ich mich gerade sowieso mit den administrativen Grenzen beschäftige, hab ich mir manche Grenzen mal näher angeschaut. Die für mich wohl am wichtigste (51477) von Deutschland hat ja arg gelitten. Ein Wunder fast, daß die noch sauber in der DB ankommt.

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

Derzeit ist es sogar so, daß es hierdurch zu Fehlermeldungen bein Hochladen mit Josm bei einigen “Subareas” kommt.

  • was hat verd… noch mal die Relation für das Landarea dort verloren? Das ist mMn totaler Quatsch und fliegt noch heute raus, wenn es nicht erheblichen gut begründeten Widerstand gibt.

Ansonsten gibt es wohl noch Überlappungen, die ich gerade beseitige.

Harschen Gruß
walter

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

ok, dann schau ich mir die mal an und frage beim verursacher nach. der hat auch die subareas “verbrochen”

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.

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

Gruss
walter

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.

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.

Es geht nicht darum, dass jemand diese Area-Information braucht, sondern dass man die Grenzweg-Information nicht bis zu 5-fach braucht.

ich hab auf talk-de auch nur (2x) volle Zustimmung bekommen und die fliegen bald raus.

Gruss
walter

siehe “mein baby” ab v9: ist inzwischen fast drei Jahre alt und kann schon laufen. :wink:

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

sowürde ich es auch sehen.

Deine Beschreibung:

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.

Saubere Grenzen? 100% dafür, leg los…

Sven

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

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

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

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

Das war auch Mapper B soweit ich das erkennen kann?

Ich habe es hier angekündigt um einen etwaigen Shitstorm zu vermeiden :wink: 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

hab ich mich wohl verguckt.

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