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ß
_______________________________________________
Talk-de mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/talk-de
