Klipphausen?

Bei regio-osm http://regio-osm.de/listofstreets/hierarchy?country=Bundesrepublik%20Deutschland tauchen in der Liste der Sub-Hierarchien unten zwei Einträge auf, die sich mir nicht erschließen: Deutschland und Klipphausen.
Wie kommen die da hin, wie bekommt man sie wieder weg?

Ich würde den Macher der Seite fragen oder auf diesen Thread hinweisen. Er ist in diesem Forum als okilimu registriert.
Die Seite, die du verlinkst, hat gut sichtbar links unten einen Link namens “Kontakt”, unter der man hilfreiche Daten findet…

Hallo Miple,

Klipphausen: es gibt für den Subbereich Klipphausen OT Triebischtal eine eigene Auswertung aus der Zeit, als diese eine eigene Gemeinde war.
Die dazugehörende Relation #549801 hatte im Tag is_in die Schreibweise mit Semikolon als Trenner für einzelnen Ebenen bis Europe am Ende. Ich habe eben die Semikolons in Kommata umgewandelt, dann wird das richtig ausgewertet.
Eigentlich hätte ich die umgebende nächsthöhere Adminrelation ausgewertet, aber die o.g. Relation hat den Namen Triebischtal nur noch in old_name, daher habe ich die nicht als Start für die höhere Adminrelation herangezogen und bin auf das is_in zurückgefallen.
In der nächsten Auswertung morgen (Mi) wird die Korrektur noch nicht sichtbar sein, weil die lokale DB noch etwa 18h hintendran ist.

Der Eintrag “Deutschland” innerhalb Bundesrepublik Deutschland:
Es gibt 10 Berliner Stadtbezirke (s.u.), bei denen in diversen is_in:… Tags die administrative Hierarchie aus meiner Sicht falsch enthalten ist.
Der Fehler ist vermutlich immer gleich, so wie ich ihn nach der Auswertung bei mir gesehen habe, hier ein Beispiel:
(SB) “Friedrichshain-Kreuzberg” mit Relations-Id 55764, dort ist in “is_in:country” nur “Deutschland”, es müsste aus meiner Sicht “Bundesrepublik Deutschland” sein. Der Teil “Bundesrepublik” ist stattdessen in “is_in:country_prefix” enthalten, aber das werte ich nicht aus.
In “is_in:continent” steht noch “Europa” drin statt normal “Europe”, das berücksichtige ich.

Ich habe die Werte in “is_in:country” nicht geändert, da will ich den Berlinern nicht reinfuschen.

Schade ist dabei, das die Berliner SB Auswertungen dort im Auswertungsbereich nicht bei "Bundesrepublik Deutschland > Deutschland > Berlin > Berlin > Berlin gesucht werden.
(Die mehrfachen “Berlin” kommen übrigens von den dortigen is_in:state=Berlin (für Bundesland), is_in:region für die nächste Ebene und is_in:county für Kreisebene.)


                 name                 | osm_relation_id 
--------------------------------------+-----------------
 Berlin SB Charlottenburg-Wilmersdorf | 404538
 Berlin SB Friedrichshain-Kreuzberg   | 55764
 Berlin SB Lichtenberg                | 404554
 Berlin SB Marzahn-Hellersdorf        | 164712
 Berlin SB Neukölln                   | 162902
 Berlin SB Reinickendorf              | 16334
 Berlin SB Spandau                    | 16343
 Berlin SB Steglitz-Zehlendorf        | 55734
 Berlin SB Tempelhof-Schöneberg       | 158437
 Berlin SB Treptow-Köpenick           | 55754

viele Grüße

Dietmar

Du wertest is_in aus? Mann, bist du mutig.

Fährst du zufälligerweise PostGIS oder auch nur PostgreSQL ohne GIS? Dann hätte ich was für dich. - Nein, kein Tip wie man das besser machen kann, sondern fertige Live-Daten.


select id,value "name",level,path
from boundaries
where country='DEU' and id < 1000000000;
   id    |                                  name                                  | level |                               path                                
---------+------------------------------------------------------------------------+-------+-------------------------------------------------------------------
 1946220 | Ehrenkirchen                                                           | 8     | {0,51477,62611,2106112,1946367,68454,1946220}
  554826 | Arnach                                                                 | 9     | {0,51477,62611,2811874,2808774,2806738,554826}
 1433099 | Usedom-Süd                                                             | 7     | {0,51477,28322,1431517,1433099}
 1785578 | Altenpleen                                                             | 7     | {0,51477,28322,1739379,1785578}
 1444879 | Rehna                                                                  | 8     | {0,51477,28322,1739380,1444916,1444879}
 2676470 | Grabowhöfe                                                             | 8     | {0,51477,28322,1739376,1424300,2676470}
  449916 | Goldberg                                                               | 8     | {0,51477,28322,1739381,449791,449916}
  418664 | Bernstadt / Schönau-Berzdorf                                           | 7     | {0,51477,62467,62345,418664}
  418716 | Herrnhut                                                               | 8     | {0,51477,62467,62345,418716}
 2678596 | Malschwitz                                                             | 8     | {0,51477,62467,62384,2678596}
....
  156532 | Bartenshagen-Parkentin                                                 | 8     | {0,51477,28322,1739377,403578,156532}
  394346 | Stäbelow                                                               | 8     | {0,51477,28322,1739377,403570,394346}
  394344 | Kritzmow                                                               | 8     | {0,51477,28322,1739377,403570,394344}
(20757 Zeilen)

Die ganze wirkliche Verschachtelung der Grenzen in DEU.

Gruss
walter

Hallo Walter,

ich verwende die Postgresql inkl. Postgis und im besten Fall werte ich auch die umschließenden Grenzpolygone aus.
Dazu brauche ich aber einen Treffer beim Namen des eigentlichen Grenzpolygons und in diesem Fall gibt es kein name=Triebischtal, nur old_name=Triebischtal.

Deshalb weiche ich in zweiter Prio nach diversen is_in Angaben (erst am Polygon, dann an einem Gemeinde Knoten place=*) und der letzte Notanker wäre eine Nominatim Suche.

Du meinst vermutlich Deine Boundaries, oder?
Wertest Du im konkreten Fall von Triebischtal auch old_name aus?

Wie sieht denn Dein Tipp aus?

(edit ergänzt) Bis zu welchem admin_level wertest Du aus?

Deine Live-Daten könnten bald spannend sein für meine Auswertungen, weil ich vorerst zumindest bei den Hausnummerauswertungen unabhängig von einer lokalen Postgresql Datenbank Auswertungen machen möchte.

viele Grüße

Dietmar

edit: Nachfrage nach Auswertung tiefstem admin_level

Vielen Dank, Dietmar, für diese erschöpfende Auskunft!
Viele Grüße
Michael

Lob, Lob :wink:

ok, das liest sich schon besser.

Klaro, obwohl das nicht “meine” Boundaries sind, sondern das was meine Auswertung aus OSM rauskitzelt. :wink: Und old_name werte ich auch nicht aus. Wüsste auch nicht wieso, da ich nur die aktuellen Werte brauche, oder?

R/O-Remotezugang auf meine DB und dort Zugriff auf die Boundaries-Tabelle. Im obigen Post siehst du die Verschachtelung aufgrund der Topologie (path) - aber das hast du anscheinen ja auch gut im Griff.

15 - so hab ich auch die Gemarkungen “erwischt” :wink:

Kein Problem. Naja “Live” ist ein wenig übertrieben. Die Auswertung läuft ab 2:00 Uhr ca 2 Stunden und dann sollten die aktuellen Daten drin sein. Läßt sich aber wohl auf 0:00 vorverlegen. Ach ja: Weltweit natürlich - bis auf Kosovo ;(

Gruss
walter

ps: jetzt schau ich mir Triebischtal mal näher an.

Hab mal kurz die #549801 geprüft: Da die kein name=* und kein admin_level (mehr) hat, “kenne” ich die auch nicht in meiner Grenzauswertung.

Gruss
walter

Ich würde in einer kleinen Josm-Aktion den Namen in den Adressen tilgen und dann sollte Ruhe sein.