[Talk-de] Übersicht zur Debatte um die Boden/Flächennutzung (landuse=) und Orte/Toponyme (place=)

Do Sep 22 14:58:46 UTC 2011

Hi,

Am 22.09.2011 10:16, schrieb Martin Koppenhoefer:
>>         - bessere Strukturierung der tag-values nach ISIC, etc.
> das war immer nur zusätzlich gedacht, zumindest hatte ich das so
> verstanden und unterstütze es auch nur parallel aber nicht als values
> für landuse

da hat ein "z.B."  gefehlt ..  Frederik ging es ja um die Senkung von 
Eintrittsbarrieren, um das mappen für Einsteiger verständlicher zu 
machen, daher der Wunsch ein paar values aus landuse zu entfernen und 
diese stattdessen in subtags oder sub-sub-tags zu modellieren..  dazu 
gab es auch von anderen Leuten Zustimmung, die fanden, dass die values 
liste für key:landuse bereits zu lang ist..   ISIC war nur eine 
Anregung, wie man das sinnvoll machen kann, wenn man bestehende Arbeit 
(der UNO) in diesem Fall wiederverwendet..

Für eine Ausdifferenzierung der obersten Ebene von landuse ist die 
oberste Ebene von ISIC vermutlich nicht zu gebrauchen.  So wie ich es 
verstanden habe, bildete sich für die oberste Ebene von key:landuse  
residential, commercial, industrial, ((mixed)) heraus, wobei ich den 
mixed-Typ für überflüssig hielt.  Für alle anderen values von 
key:landuse müsste man schauen, ob die wirklich berechtigt _neben_ 
diesen Werten stehen, oder eher _unter_, also eine Spezialisierung eines 
dieser Werte sind (also in einen subtag gehören..)

>>             - Bedingung: Datenhaltung von Flächen als multipolygons
> wie es Sinn macht, bei kleinen landuse-Flächen aus meiner Sicht
> unnötig und schädlich, da es unnötig das Mappen verkompliziert.

+/- 1.  Jein.  Das ist ja momentan nur deshalb komplizierter, weil die 
Tools dafür zu schlecht sind.  Ich schrieb in einer meiner mails:  
multipolygons müssen so einfach werden, wie einen "closed way" zu 
zeichen.  Das erachte ich als Vorraussetzung und letztlich /sind/ 
multipolygons DAS Flächentool in OSM schlechthin.  Nur werden sie noch 
nicht so eingesetzt, stattdessen beschränkt man sich auf ihre Verwendung 
für Spezialfälle.

Die Vergangenheit zeigt aber, dass öfter als weniger, einfache Fälle zu 
Spezialfällen mutieren.  Clevere Leute mappen ihre Flächen dann mit 
multipolygons neu (obwohl das umständlich ist, Du schreibst es selbst), 
andere behelfen sich damit, "overlapping ways" zu bilden (was ich selbst 
lange Zeit gemacht habe, da ich noch nicht wußte, wie die eigentliche 
Lösung aussieht), oder damit, überhaupt keinen Flächenbezug herzustellen 
(geschachtelte "closed ways") - was keine vernünftige Abbildung der 
Realität ist.

In der Realität gibt es ohne Ende Bezüge zwischen den Flächen (das 
Wohngebiet liegt __innerhalb__ der Gemeindefläche, der Bäcker liegt 
__innerhalb__ des Wohngebiets, das Feld _grenzt_ an Weg- oder Wald- 
-fläche -- und das sind nur Beispiele für eine Lagebeziehung).

Natürlich kann ich mir die Lagebeziehungen auch erst ausrechnen, anstatt 
sie ordentlich mitzumodellieren, für viele Lagebeziehungen wird aber 
diese Rechnung sehr komplex - betrachte z.B. die Lagebziehung 
"Gemeindefläche __innerhalb__ Bundesgebietsfläche":

     Wenn diese Beziehung nicht durch Datenstrukturen zu ermitteln ist 
(wie das jetzt der Fall ist), müsste ich für die gesamte bundesdeutsche 
Grenze (a lot of nodes) algorithmisch prüfen, ob die Gemeindefläche 
(less nodes but still a lot) komplett inkludiert ist.  Wenn ich diese 
Lagebeziehung dann für _alle_ Gemeindeflächen brauche, wird meine CPU 
schwitzen.  OSM sei Dank muss ich aber nur wissen, /wie/ ich die 
entsprechende Datenstruktur auslesen muss.

Dieses Problem lässt sich für jedwede Lagebeziehung von Flächen 
aufzeigen.  Das ist, weshalb ich schon die ganze Zeit nicht müde werde, 
zu erzählen, dass Beziehungen zwischen Flächen "nicht _einfach so_ da 
sind".  Es ist besser, wenn insbes. die Lagebeziehungen innerhalb OSMs 
Datenstrukturen vorhanden sind:

         Das geht nicht mit "closed ways", das geht auch nicht mit 
"overlapping ways" sondern nur mit zueinander in Beziehung stehenden 
Multipolygons (ich habe das als 'Flächennetzwerk' bezeichnet).

Es nützt auch nichts zu argumentieren, dass manche Polygone ja "viel 
kleiner" seien und nicht so viele nodes hätten, wie andere und damit die 
Rechnung in der Tat einfacher sei..  Eine Lagebeziehung kann ich nur 
zwischen mindestens zwei Polygonen bilden, d.h. ich beschränke mich mit 
dieser Argumentation dann schon auf Lagebeziehungen zwischen zwei _viel 
kleineren_ Polygonen.

Natürlich sind Algorithmen denkbar, die den Rechenaufwand für viele 
solcher Berechnungen wieder reduzieren, indem z.B. entsprechend bounding 
boxes gebildet werden und dann erstmal nur gegen diese gerechnet wird, 
anstatt gegen den kompletten Streckenzug.

Warum sollte aber jemand diesen Aufwand betreiben, wenn er durch bessere 
Datenlage nicht bestünde?  Mehr noch, warum sollte ihn _jeder_ _separat_ 
betreiben, der an Lagebeziehungen zwischen Flächen interessiert ist?

Mit ein bisschen Javascript, und dem entsprechenden Flächennetzwerk, 
kann ich auf jedem Client echt komplexe Lagebeziehungen aufzeigen, wenn 
die Datenstruktur im Hintergrund (multipolygons) die Information vorhält 
- traversieren statt rechnen.

Zwischenergebnisse geometrischer Berechnungen "cachen" etc. sind 
üblicherweise Gedanken, die Leute für "fat clients" hegen, aber nicht 
für ein bisschen JavaScript Mash-Up.  Das bedeutet, dass die 
Möglichkeiten, mit OSM Mash-Ups zu entwickeln, die Flächenbeziehungen 
aufzeigen, arg begrenzt ist.  Folgendes Beispiel:

         - eine auf OpenLayers basierte Seite, erlaubt Dir an einen 
beliebigen Punkt der Erde zu klicken, um die politisch kleinste Fläche 
zu wählen
         - angezeigt werden soll die Beziehung dieser Fläche zu höher 
administrierten Flächen und alle benachbarten Flächen
         - das ist so einfach, dass ich dazu auf fast keine weiteren 
Dienste zurückgreifen muss, es reicht, die entsprechenden Relationen zu 
bewandern, und mir die entsprechenden Daten abzugreifen, anstatt 
/jedesmal/ geometrische Berechnungen anstellen zu müssen
         --> man denke auch, wieviel Watt an Rechenleistung dadurch 
eingespart werden können.. (das ist Ernst gemeint)

>>     2) die Bedeutung von landuse=residential im Speziellen
>>         - darf da nun ein /Gebiets/name dran?
> da kann auch ein Gebietsname ran, aber der wird sich i.d.R. nicht auf
> die Bodennutzung sondern auf das "Gebiet an sich" beziehen, in dem
> eben u.a. auch die Nutzung einheitlich ist. Das Objekt, das den Namen
> trägt, ist m.E. ein Siedlungsteil, nicht eine Bodennutzung.

+1  genau so ist das.  da werden verschiedene Dinge, die in der Realität 
/in Bezug zueinander/ stehen, innerhalb OSM in ein Ding 
/zusammengemanscht/, ohne das dieser Bezug, den Du eben aufgezeigt hast, 
noch erkennbar wäre.  -> schlechte Abbildung, deswegen die Frage.

>>         - Wohngebiete sind aber dadurch charakterisiert, dass sie einen Namen
>> tragen und der Grenzverlauf amtlich dokumentiert ist
> -1. Da täuscht Du Dich, bzw. ist das keine generelle Regel sondern
> kann sein, muss aber nicht

Vielleicht ist es auch eher eine generelle Regel, mit Ausnahmen, die 
historisch begründbar sind?  Gib mir doch einfach ein nachprüfbares 
Gegenbeispiel zu meiner Aussage, dass nicht auf "m.E." hinausläuft.  Die 
Aufgabe ist, ein (benanntes natürlich) Wohngebiet zu finden, welches 
keine amtlichen Grenzen hat (und nie hatte!).

     Nehmen wir an, wir haben es mit einem sehr alten WG zu tun.
     Nehmen wir weiter an, dass die amtliche Grenze dazu irgendwann aus 
dem Kataster flog.
     Nehmen wir weiter an, dass sich die Grenzen dieses WG, nachdem sie 
obsolet waren, weiter entwickelt haben.
         -> das ist m.E. schon arg unwahrscheinlich - das bedeutet:
                 - jemand baut ein Haus in einem Gebiet, welches nicht 
durch ein Amt benannt wurde,
                 aber an ein WG grenzt, dass nicht mehr durch das Amt 
gepflegt wird / bekannt ist
                 - die "Alt-Bewohner" des WG integrieren dieses Haus in 
ihr WG (nur dadurch verschiebt sich die Grenze)
     Nehmen wir also nun an, wir hätten ein WG mit Namen und Grenze, das 
nicht amtlich vermerkt ist:

         Was hat diese Grenze dann mit der Bodennutzungsgrenze zu tun?
         Was hat diese Gebietsgrenze, die gefühlt durch die Menschen vor 
Ort vorhanden ist, mit einer Grenze zu tun, welche die 
Bodennutzungsfläche begrenzt?
         Klar, diese beiden Grenzen /können/ sich decken, /müssen/ sie 
aber nicht.

Deshalb sollten Gebietsgrenzen getrennt von Bodennnutzungsflächen 
erfasst werden und _nur_ wenn der Speziallfall eintritt, dass diese 
zusammenfallen, die Grenzen des einen für die Grenzen des anderen 
wiederverwendet werden.

Gebiete, die der Mensch /irgendwann/ bildet und bezeichnet, um darüber 
zu reden, müssen nicht notwendigerweise die gleichen Grenzen haben, die 
vor Ort und /jetzt/ anhand _eines einzigen_ Kriteriums (der 
Bodennutzung) beobachtbar sind.  Das kann der Fall sein, muss aber nicht.

>
>>             ->  in einem strengen Sinne sind Wohngebietsgrenzen
>> boundary=administrative (Verwaltungsgrenzen)
> -1
>
>
>>     3) place-tag  Verwendung auf   nodes   zurückfahren
> -1, was meint "zurückfahren"? Löschen?

Nein.  Während das durchaus eine Interpretation meiner Aussage sein 
kann, ist es keine die ich im Sinn hatte und eigentlich auch keine, die 
man hätte durch die bisherige Debatte hätte ableiten müssen.  Aber gut, 
Du gehst eben immer erstmal vom worst case aus - das ist zwar ziemlich 
stressig, aber was solls..

     Ich /meinte/ mit zurückfahren, dass die bisherigen place-polygone 
als das getaggt werden, was sie sind:  Siedlungsgrenzen.

Rhinhold und Du hatten herausgefunden, dass /eine/ Ortsgrenze nicht 
wiss. definiert ist (Ortsgrenze ist eine loser Sammelbegriff,  
Siedlungsgrenze und Gemeindegrenze sind hingegen wiss. oder rechtl. 
greifbar).

     Mit "zurückfahren" /meine/ ich also, dass man das als das taggt, 
was es genau ist.  Ob Du das nun über eine Grenzbezeichnung löst 
(boundary=settlement) oder über eine Flächenbezeichnung 
(landuse=settlement) ist mir nicht so wichtig.  Für mich ist wichtig, 
dass ich den realen Bezug abbilden kann:  "Diese Siedlungsfläche (oder 
-grenze) gehört/bezieht sich auf diesen Ort"  oder auf englisch:

             "This settlement relates to this place."

So wie das jetzt in der DB ist, degeniert das zu

             "This place relates to this place."  und das ist in dem 
Kontext der hier gemeint ist (Siedlung zu Ort) , Unsinn.

Auch (Ort zu Ort) Beziehnungen machen Sinn, z.B.:

             "This place relates to another place."
>
>>         - alle geografischen Orte haben eine unbestimmte Lage (node =
>> ausdehnungslos)
> in erster Näherung ist das z.B. fürs Rendern schonmal viel besser als
> gar nichts. Nochmal besser sind Flächen.

Ja, bestimmte Flächen.  Und nicht ORTsflächen, die es nicht gibt - wie 
implizit auch schon durch Dich festgestellt.

Bestimmte Flächen -> bestimmte Tags.

> "Hauptsache, da taucht kein place auf". Sorry, aber jetzt wirds m.E.
> kindisch.

Du hast das (schon) wieder aus dem Kontext gerissen.  Der Satz bezieht 
sich darauf, dass place in OSM keinen /Siedlungs/bezug im Speziellen, 
sondern einen /Orts/bezug im Allgemeinen hat.  Ich weiß nicht, wie oft 
ich Dir das noch erzählen soll, aber wenn Du Dir taginfo anschaust, 
wirst auch Du das feststellen.

Siedlungsgrenzen sind nunmal nichts Allgemeines, sondern etwas 
Spezielles.  Warum willst Du also darauf beharren, an etwas Spezielles, 
einen allgemeinen Tag zu vergeben?   Das wäre nicht nur kindisch, 
sondern kontraproduktiv.

Wir können nicht auf /nodes/ die allgemeine Deutung anwenden und auf 
areas plötzlich eine /speziellere/.

Der Sinn des Tags wohnt dem Tag selbst inne, der Sinn des Tags entsteht 
nicht erst, wenn ich das Tag an eine Geometrie vergebe.

Es ist in OSM egal an welche Art Geometrie Du ein Tag hängst, es ändert 
seinen Sinn dadurch nicht  (ein Geschäft /shop/ bleibt ein Geschäft, 
egal ob ich /node/ oder /way/ oder /relation/ damit tagge).

/Du/ brichst diesen Konsens auf, indem Du eine Sinnwandlung des Tags 
/place/, _in Abhängigkeit_ der Geometrie welche Du betaggst, 
befürwortest.  Bei Dir (und denen, die deiner Auffassung folgen)  ist 
/place/  am way vom Sinn her etwas anderes, als /place/ am node.  Das 
ist keine Kleinigkeit!!!

Dieser "Fehler" setzt sich bei allem fort, was dann Bezug auf dieses Tag 
nimmt - Du müsstest für jeden Bezug auf das Tag nicht nur das Tag selbst 
betrachten, sondern Tag+Geometrie.  Weil Du Analogien vielleicht eher 
verstehst, habe ich noch eine im Angebot:

         natural=tree  (üblicherweise auf  /nodes/)

Du würdest nun verfechten:

         natural=tree  auf areas

Letzteres macht in OSM niemand:  natural=tree auf areas  /kann/ einen 
Wald meinen, das wäre sogar recht intutitiv.  Ein Wald ist aber etwas 
anderes als ein Baum, wenn Du darauf Bezug nimmst:

         Im Wald steht ein Baum.
         Im Wald gibt es eine Siedlung.

sind andere Aussagen als

         Im "Baum als Fläche" steht ein Baum.
         Im "Baum als Fläche" gibt es eine Siedlung.

Wie gesagt, kann man machen, ist aber nicht intuitiv und sehr, sehr 
aufwändig zu pflegen.  Der Sinn eines Tags hängt in OSM am TAG und nur 
daran, und _nicht_ an welche Geometrie es gepappt ist.  Oder anders:  
Egal an welche Geometrie ein TAG gepappt wird, es hat immer den gleichen 
Sinn.  /Das/ verletzt Du, wenn Du sagst:

     place an nodes  ist ein Ort  (im geographischen Sinne:  beliebige 
Orte: Seen, Fluren, Landstriche, Kontinente, Siedlungen, etc..)
     place als area ist eine Siedlung

Bevor ich deine nächste mail erhalte, prophezeie ich, dass Du den 
letzten Punkt umdeformierst zu

     place als area ist auch ein Ort  (im geographischen Sinne: für 
Seen, Fluren, Siedlungen, etc. pp.)

Das funktioniert aber eben gerade für Siedlungen nicht, /weil/ diese 
mehrere Flächen haben, die gleichberechtigt nebeneinanderstehen und als 
"Ortsfläche" gelten können:  Die Gemeindefläche ist eine Ortsfläche, die 
Siedlungsfläche ist eine Ortsfläche,  etc. pp. pp. pp.

Gruß