[OSM-Augsburg] Planungsraum, Stadtbezirke, Ortsteile

Sa Aug 9 20:02:17 CEST 2014

Hallo Eckhart,

Am 09.08.2014 16:57, schrieb Eckhart Wörner:
> Hallo Dietmar,
>
> Am Samstag, 9. August 2014, 16:30:49 schrieb Dietmar Seifert:
>> gemäß der OSM Wikiseite [1] sind unsere Ebenen 10 (Göggingen, diese
>> Ebene haben wir aber noch nicht flächendeckend erstellt) und 11 (die
>> Stadtbezirke) ok.
> Die Frage ist natürlich, ob die Seite richtig ist. ;-)
> Wenn ich mir die anderen Städte in Bayern so ansehe, sind wir die einzige Stadt, die Stadtbezirke als 11 einordnet, der Rest ordnet sie als 10 (Fürth, Würzburg) oder 9 (Ingolstadt, München) ein. Kann natürlich auch eine Frage der Nomenklatur sein.

In München gibt es Bezirksausschüsse (BA), siehe [1], deshalb sind deren
Stadtbezirke admin_level=9 (in der Überschrift zu 9 steht ja auch
Funktion: "polit. Selbstverwaltung").

Bei uns in Augsburg haben beide Unterbereiche keine politische
Bedeutung. Die Stadtteile sind eher im Volksmund bekannt (Göggingen,
Kriegshaber, Oberhausen), während das statistische Amt vor allem die
Stadtbezirke für Auswertungen nimmt (Göggingen-Nordwest...Süd, ...) und
die Überschrift zu admin_level=11 sagt sogar "statistische Unterteilung".

Von daher sehe ich die Wiki-Seite diesmal als korrekt an (kann man ja
eher selten sagen, leider).

>
>> Es ist auf der Seite zwar keine admin_level=12 angegeben, weltweit gibt
>> es aber einige (32) Grenzrelationen damit.
> Ich habe in dem Zusammenhang leichte Probleme, 32 als "einige" zu betrachten. ;-)
weltweit 32 in OSM ist gar nichts und die waren bei meiner
Overpass-Anfrage auch noch über Europa relativ wahllos verteilt.

>
>> Die spannende Frage ist für mich eher, wie Du die angegebenen Gebiete
>> räumlich abgrenzen willst. Hast Du was offizielles von heute oder was
>> von früher dazu vorliegen oder willst Du die grob selbst definieren?
> Grob selbst definieren, zuerst mal über die bebauten Flächen.
> Ist immer noch wesentlich sinnvoller als die Nodes, die im Moment da sitzen, und dafür sorgen, dass solche Adressen rauskommen:
> http://nominatim.openstreetmap.org/search.php?q=Hauptstra%C3%9Fe+1+Augsburg
Das ist ja wohl eher ein Bug von Nominatim, wenn die als Hierarchie
sowas nehmen

1 (Type: place:house_number, 0 GOTO
<http://nominatim.openstreetmap.org/details.php?place_id=78910513>)
Hauptstraße (Type: highway:tertiary, way 156484919
<http://www.openstreetmap.org/browse/way/156484919>, 15, 0 GOTO
<http://nominatim.openstreetmap.org/details.php?place_id=87326769>)
Bergheim (Type: boundary:administrative, relation 384191
<http://www.openstreetmap.org/browse/relation/384191>, 11,
0.0151907153959524 GOTO
<http://nominatim.openstreetmap.org/details.php?place_id=97551886>)
Bergheim (Type: place:suburb, node 263745211
<http://www.openstreetmap.org/browse/node/263745211>, 15,
0.00233364205695838 GOTO
<http://nominatim.openstreetmap.org/details.php?place_id=687397>)
Wellenburg (Type: place:hamlet, node 297279275
<http://www.openstreetmap.org/browse/node/297279275>, 15,
0.0151496629777699 GOTO
<http://nominatim.openstreetmap.org/details.php?place_id=1276965>)
Augsburg (Type: place:city, relation 62407
<http://www.openstreetmap.org/browse/relation/62407>, 6,
0.0685517572580319 GOTO
<http://nominatim.openstreetmap.org/details.php?place_id=97379984>)
Swabia (Type: boundary:administrative, relation 17657
<http://www.openstreetmap.org/browse/relation/17657>, 5,
0.341337284375049 GOTO
<http://nominatim.openstreetmap.org/details.php?place_id=97531947>)
Free State of Bavaria (Type: place:state, relation 2145268
<http://www.openstreetmap.org/browse/relation/2145268>, 4,
0.86595729524563 GOTO
<http://nominatim.openstreetmap.org/details.php?place_id=98101689>)
86199 (Type: boundary:postal_code, relation 1112832
<http://www.openstreetmap.org/browse/relation/1112832>, 15,
0.00882993850651096 GOTO
<http://nominatim.openstreetmap.org/details.php?place_id=98221421>)
86199 (Type: place:postcode, 0 GOTO
<http://nominatim.openstreetmap.org/details.php?place_id=>)
Germany (Type: place:country, relation 51477
<http://www.openstreetmap.org/browse/relation/51477>, 2,
3.03105456250802 GOTO
<http://nominatim.openstreetmap.org/details.php?place_id=97944985>)

a) Warum nimmt nominatim nach der gefundenen admin-Relation
admin_level=11 erst noch die place:suburb und dann place:hamlet Knoten
in der Hierarchie dazu, statt dann nur noch die Relation admin_level=6
zu nehmen, dann stände 
1, Hauptstraße, Bergheim, Augsburg, Swabia, Free State of Bavaria,
86199, Germany, European Union
(ich hab englisch im Browser bevorzugt eingestellt)
Nominatim ist halt so gestrickt, das es weltweit irgendwie immer
irgendwie eine Hierarchie zurückbringt, das ist in o.g. Fall sicher
nicht optimal gelöst und auch schwierig, immer gut zu lösen.

b) warum hat Bergheim place:suburb, während Wellenburg place:hamlet hat?
Letzterer müsste dann eher auch place:suburb bekommen und würde dann
vermutlich von selbst aus der Hierarchie verschwinden? Auch dann sähe
die Hierarchie schon besser aus.

c) warum machen wir die ganzen admin_level=10 nicht mal rein?

>
>> Wenn Du die Gebiete im angegebenen Bereich definierst, dann ist die
>> Frage, ob wie nicht dann auch noch andere Gebiete definieren sollten?
> Was schwebt dir da konkret vor?
keine Ahnung: Siebenbrunn gibt es als Stadtbezirk und hat dann ja
relative großes Ausmaß, für mich persönlich würde ich Siebenbrunn nur
als die Anordnung der Straßen rum um die alte Schule in dem Bereich
ansehen mit denen nach Osten noch.

Und eine Schadweidsiedlung hat auch erheblich mehr Einwohner als die
paar Wellenburg-Häuser und einen eigenständigen Namen. Da könnten wir
uns etliche ausdenken, aber ob das dann noch Sinn machen würde?

viele Grüße

Dietmar

[1] http://de.wikipedia.org/wiki/Bezirksausschuss

>
> Eckhart
> _______________________________________________
> Augsburg mailing list
> Augsburg at lists.openstreetmap.de
> http://lists.openstreetmap.de/mailman/listinfo/augsburg
>

-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <https://lists.openstreetmap.de/pipermail/augsburg/attachments/20140809/db3501f9/attachment-0001.htm>