[Talk-de] Offizieller Satz von OSM Diensten

Peter Wendorff wendorff at uni-paderborn.de
Mi Sep 21 09:21:40 UTC 2011


Dem kann ich zumindest teilweise zustimmen.
Ich bastle momentan an einem Portal und binde dafür Osmosis im Code ein.
Hier vermisse ich bisher eine Dokumentation der dahintersteckenden Library.
Das Wiki dokumentiert zwar sehr schön und vollständig die Verwendung von 
osmosis als Kommandozeilentool; die Einbindung in andere (Java)-Projekte 
ist aber nicht beschrieben.
Mit der Hilfe von Jan und seinem JXAPI-Code war das dann gar nicht so 
schwer, sich da durchzufuchsen; eine Dokumentation, welche Befehler aus 
der Kommandozeilen-Nutzung zu welchen Klassen im Java-Code passen, fehlt 
aber trotzdem; die muss man sich im Einzelnen zusammensuchen.

Ich denke, wir haben viele Teile von Software im OSM-Ökosystem, die gut 
funktionieren. Auch hier gilt mal wieder: man muss sie finden. Manches 
ist im OSM-SVN, andere wollen aber Git benutzen und hosten deshalb anderswo.
Wieder andere Projekte liegen bei sourceforge, in der Code-Verwaltung 
von Wiki(p|m)edia oder wo auch immer sonst noch.

Das ist nicht unbedingt ein Nachteil, aber es erfordert immer wieder 
Aufwand und manchmal eine Portion Glück, die richtigen Komponenten zu 
finden, um das Neuerfinden des Rades verhindern zu können.

Die "Library"-Idee könnte ich mir aber z.B. als eine Wiki-Seite 
vorstellen, die eine Liste von Aufgaben enthält, und dafür jeweils 
existierende Komponenten vorstellt.
Die allerdings übersichtlich und aktuell zu halten, ist eben auch wieder 
nicht ohne Investition von Zeit und Aufwand möglich.

Gruß
Peter

Am 21.09.2011 09:48, schrieb Adrian Stabiszewski:
> Hi!
>
> Die Idee mit den offiziellen Diensten ist reizvoll, leider auf freiwilliger
> Basis kaum umzusetzen. Als leidenschaftlicher Entwickler habe ich den
> Amenity Editor und den Relation Analyzer online gestellt. Beide Projekte
> entstanden aus der Idee etwas Neues zu lernen und etwas Nützliches zu
> schaffen. Für mich ist das eine Programmierübung in meiner Freizeit, für die
> anderen werden das unersetzliche Werkzeuge ;)
>
> Ich möchte hier jedoch einen anderen Ansatz anbieten. Beim Entwickeln vom AE
> und RA sind mir viele Ähnlichkeiten aufgefallen, die sich weiter zu einer
> netten Library zusammenführen lassen. Beispiele hierfür sind der Zugriff auf
> den OSM Server (upload+download), das Parsen von (relativ kleinen) OSM XML
> Dateien und das Producer-Consumer Pattern zum Verarbeiten von großen OSM XML
> Dateien (planet.osm). Diese Funktionen sind nicht trivial und bereiten immer
> wieder Einstiegshürden für Entwickler. Wenn wir eine Library hätten, die
> diese Funktionen sauber kapselt, dann würden vielleicht mehr Entwickler an
> OSM Open Source Projekten mitarbeiten. Natürlich könnte die Library weitere
> Funktionen enthalten, wie Routing-Algorithmen oder Import/Export von
> verschiedenen Geo-Formaten (beides im RA bereits implementiert).
>
> Ein weiteres Argument für eine Library wäre, dass ein Entwickler leichter
> ein anderes Projekt verstehen kann, da er bereits bekannte Muster und
> Funktionen wiederfindet. Dies würde dann auf Dauer zu einer besseren
> Wartbarkeit von Tools führen, weil mehr Entwickler überhaupt in der Lage
> sind ein Projekt zu verstehen.
>
> Es gibt bereits einige Tools, die in Java geschrieben sind (Josm, osmosis),
> die vielleicht weitere Funktionen für eine solche Library beitragen könnten.
>
> Vielleicht wäre das was für "Winter of Code" ;)
>
> Viele Grüße,
> Adrian.
>
>
>> -----Ursprüngliche Nachricht-----
>> Von: talk-de-request at openstreetmap.org [mailto:talk-de-
>> request at openstreetmap.org]
>> Gesendet: Mittwoch, 21. September 2011 00:32
>> An: talk-de at openstreetmap.org
>> Betreff: Talk-de Digest, Vol 62, Issue 66
>>
>> Send Talk-de mailing list submissions to
>> 	talk-de at openstreetmap.org
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>> 	http://lists.openstreetmap.org/listinfo/talk-de
>> or, via email, send a message with subject or body 'help' to
>> 	talk-de-request at openstreetmap.org
>>
>> You can reach the person managing the list at
>> 	talk-de-owner at openstreetmap.org
>>
>> When replying, please edit your Subject line so it is more specific than
> "Re:
>> Contents of Talk-de digest..."
>>
>>
>> Today's Topics:
>>
>>     1. Offizieller Satz von OSM Diensten (Andreas Tille)
>>     2. Re: Offizieller Satz von OSM Diensten (Frederik Ramm)
>>     3. Re: Offizieller Satz von OSM Diensten (Andreas Tille)
>>     4. Re: landuse=road War:[viel Text zu landuse-handling..]
>>        (Christian M?ller)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Tue, 20 Sep 2011 21:04:00 +0200
>> From: Andreas Tille<andreas at an3as.eu>
>> To: OSM-de<talk-de at openstreetmap.org>
>> Subject: [Talk-de] Offizieller Satz von OSM Diensten
>> Message-ID:<20110920190400.GD24562 at an3as.eu>
>> Content-Type: text/plain; charset=iso-8859-1
>>
>> Hallo,
>>
>> die Diskussion entz?ndete sich aktuell zwar am Relation Analyzer ist aber
>> irgendwie ins generelle abgedriftet und daher w?rde ich mir gern einmal
>> Klarheit verschaffen wollen.
>>
>> Ich halte es f?r f?rderlich, wenn im OSM Projekt ein stabiler Satz von
>> Werkzeugen etabliert wird, die fest sozusagen "offiziell" zum OSM Projekt
>> geh?ren und auf die man dann auch verweisen kann.  Ich sehe das deshalb
>> f?r notwendig an, weil meiner Meinung nach ein Gro?teil der Nutzer eine
>> gewisse Konsistenz und Stabilit?t sch?tzt und bei ernst zu nehmenden
>> Projekten erwartet (und IMHO auch erwarten darf).
>>
>> Zu diesen Werkzeugen w?re ich nat?rlich in erster Linie einen Standard
>> Renderer von Karten f?r das Web, einen Editor, eine Karte f?r GPS Ger?te,
>> aber auch solche Sachen wie den RA und weitere n?tzliche Tools z?hlen.
> Mir
>> ist auch bewu?t, da? es zu den oben genannten Dingen *immer* mehrere
>> L?sungen gibt, und das das auch von vielen als Vorteil angesehen wird.
> Das
>> wird z.B. an Diskussionen ?ber Renderer[1] oder die diversen Threads ?ber
>> die AIO in diesem Jahr deutlich.
>>
>> Mir ist durchaus bekannt, da? es keine optimale "eine f?r alles L?sung"
>> geben kann und da? es m?glicherweise sogar mehrere L?sungen geben mu?
>> - doch dann sollten diese L?sungen auch einem bestimmten Satz von
>> Qualit?tskriterien gen?gen, der verl??lich auch durch diese Alternativen
>> eingehalten wird.
>>
>> In meinen Augen sollten folgende Punkte Bestandteil dieser
>> Qualit?tskriterien sein:
>>
>>    1. Gehosted / downloadbar unter der Domain openstreetmap.org
>>    2. Zugeh?rige Komponente auf http://trac.openstreetmap.org/
>>    3. Version Control System unter openstreetmap.org, damit sich
>>       ein Entwicklerteam bilden kann
>>    4. Zugeh?rige Mailingliste unter openstreetmap.org
>>
>> In meinen Augen ist eine solche Formalisierung bei einem Projekt dieser
>> Gr??e und Bedeutung (beides nimmt ja nach wie vor zu) dringend
>> notwendig, um eine effektive Organisationsstruktur zu schaffen, die
> letztlich
>> Entwicklern und Nutzern zu Gute kommt, Neulingen den Einstieg erleichtert
>> und Kritikern die Argumente schwer werden l??t.
>>
>> Viele Gr??e
>>
>>         Andreas.
>>
>> [1] http://lists.openstreetmap.org/pipermail/talk-de/2011-July/087627.html
>>      ff
>>
>> --
>> http://fam-tille.de
>>
>>
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Tue, 20 Sep 2011 22:28:23 +0200
>> From: Frederik Ramm<frederik at remote.org>
>> To: talk-de at openstreetmap.org
>> Subject: Re: [Talk-de] Offizieller Satz von OSM Diensten
>> Message-ID:<4E78F767.10808 at remote.org>
>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>>
>> Hallo,
>>
>>> Ich halte es f?r f?rderlich, wenn im OSM Projekt ein stabiler Satz von
>>> Werkzeugen etabliert wird, die fest sozusagen "offiziell" zum OSM
>>> Projekt geh?ren und auf die man dann auch verweisen kann.
>> Ja. Solche Dienste stellen allerdings eine hohe Belastung fuer das
>> Projekt dar, denn sie muessen dann ja auch am Laufen gehalten werden.
>> Hat man erstmal allen Leuten erzaehlt, dass man z.B. ein XAPI betreibt,
>> dann erwarten die Leute auch, dass das tut.
>>
>> Dem einen oder anderen mag das verblueffend erscheinen, aber solche
>> Rechner warten sich auch nicht von allein. Mittlerweile hat OSM ja schon
>> einen gehoerigen Park zusammen, und ich kriege das manchmal mit, wenn
>> mal wieder abends ein Netzteil ausfaellt oder ein Rechner vom UCL zum IC
>> gefahren werden muss oder umgekehrt. Hardware muss gekauft, Prognosen
>> muessen gemacht werden, Logfiles ueberwacht, Beschwerden muss
>> nachgegangen werden und so weiter.
>>
>> Deswegen werden solche Dienste, von denen das Projekt verspricht, dass
>> sie laufen, ganz bewusst auf eine moeglichst kleine Liste beschraenkt.
>> Dazu gehoert ganz oben natuerlich Lese- und Schreibzugriff fuer
>> Editoren, und gleich danach die Planet-Dumps und Diffs. Dann kommen
>> Webseite, Mailinglisten, Wiki, Forum, help.openstreetmap.org - die sind
>> wichtig, aber zugleich ist es da auch nicht schlimm, wenn sie mal ne
>> Stunde nicht tun, daher machen die weniger Stress. Dann kommt der
>> Tileserver; das ist schon ein Punkt, an dem es einige Stimmen gibt, die
>> sagen, dass man den Tileserver langfristig abschaffen sollte und
>> mittelfristig bereits seine Nutzung strenger einschraenken (d.h. zum
>> Beispiel keine kostenlosen Kacheln mehr fuer iPhone-Applikationen, deren
>> Autoren damit Geld verdienen).
>>
>> Alles weitere - zum Beispiel OWL, oder Routing, oder Nominatim, oder
>> diverse Analyseprogramme oder OpenStreetBugs, der OSM-Inspector,
>> keepright, Relation Analyzer, Dupenode-Map, Garminkarten, taegliche
>> regionale Extrakte - sind nicht Teil von dem "stabilen Satz von
>> Werkzeugen", und das aus einem guten Grund - es waere naemlich zu viel
>> Arbeit, fuer diese Stabilitaet zu garantieren.
>>
>> Selbst bei den Kern-Services gehen die Meinungen ueber Stabilitaet
>> auseinander. Wir sind ein Projekt von Hobbyisten, und wenn die API
>> irgendwann von 0.6 auf 0.7 umgestellt wird, dann wird sie ein paar Tage
>> nicht erreichbar sein. Ebenso kann es bei Umzuegen oder Wartungsarbeiten
>> auch mal sein, dass der Tileserver einen Tag nicht geht.
>>
>> Es ist richtig, dass einige Leute "erwarten", dass sowas nicht passiert,
>> aber da muss man dann gegensteuern und die Erwartungen korrigieren; es
>> kann nicht angehen, dass man an unser freiwilliges und unbezahltes
>> Admin-Team in London Anforderungen stellt, als ob man mit denen einen
>> Wartungsvertrag abgeschlossen haette.
>>
>>> Zu diesen Werkzeugen w?re ich nat?rlich in erster Linie einen Standard
>>> Renderer von Karten f?r das Web, einen Editor, eine Karte f?r GPS
>>> Ger?te, aber auch solche Sachen wie den RA und weitere n?tzliche Tools
>>> z?hlen.
>> Es ist wuenschenswert, dass es solche Dinge gibt, und dass wir ein
>> Oekosystem haben, in dem Leute sowas bauen koennen, aber Kern-Dienste
>> des Projekts koennen das nicht werden, oder wir muessen gleich mehrere
>> Programmierer und Admins bezahlen. Und das wiederum wuerde das
>> Anspruchsdenken nur noch erhoehen ("wir bezahlen diese Leute, die sollen
>> das gefaelligst mal ordentlich machen").
>>
>> Ich bin heilfroh, dass es nicht "die offizielle Garminkarte" gibt, und
>> bei den Tile-Layern geht die Entwicklung zum Glueck auch weg von
>> "Mapnik-Standardkarte fuer alle". Sowas erstickt doch jede Innovation.
>>
>>> Mir ist durchaus bekannt, da? es keine optimale "eine f?r alles L?sung"
>>> geben kann und da? es m?glicherweise sogar mehrere L?sungen geben
>> mu? -
>>> doch dann sollten diese L?sungen auch einem bestimmten Satz von
>>> Qualit?tskriterien gen?gen, der verl??lich auch durch diese Alternativen
>>> eingehalten wird.
>> Beim Tile-Layer fuer die Startseite hat die OSMF ein paar
>> Qualitaetskriterien festgelegt und praktisch gesagt: Jeder, der einen
>> Layer baut, der diese Kriterien erfuellt, kann prinzipiell seinen Layer
>> auf der Startseite anbieten lassen. - Hosten und Rendern muss er
>> natuerlich selbst.
>>
>>> In meinen Augen ist eine solche Formalisierung bei einem Projekt dieser
>>> Gr??e und Bedeutung (beides nimmt ja nach wie vor zu) dringend
>>> notwendig, um eine effektive Organisationsstruktur zu schaffen, die
>>> letztlich Entwicklern und Nutzern zu Gute kommt, Neulingen den Einstieg
>>> erleichtert und Kritikern die Argumente schwer werden l??t.
>> Wir haben das mit dem FOSSGIS-Devserver ja probiert; es gibt da gute und
>> schlecht Erfahrungen. Der Plan war dort auch, dass man Leuten die
>> Ressourcen gibt, um ihre Sachen zu entwickeln und laufen zu lassen, und
>> dass durch gegenseitige Offenheit auch eine Zusammenarbeit entsteht.
>> Leider hat sich gezeigt, dass es fuer viele eben doch reizvoller ist,
>> was eigenes zu machen, als bei einem bestehenden Projekt mitzuarbeiten.
>> Diese Neuerfindung des Rads ist durchaus nicht immer schlecht und kann
>> dazu fuehren, dass radikale neue Ideen sich durchsetzen - wenn man die
>> Leute zwingt, alle am gleichen Seil zu ziehen, dann laufen einem die
>> wirklichen Genies vielleicht auch davon ;-)
>>
>> Mit auch deshalb ist der Devserver staendig mit der Kapazitaet am
> Anschlag.
>> Grundsaetzlich koennte ich mir vorstellen, dass diese Devserver-Idee
>> etwas verbessert wird und mit mehr Hardware unterfuettert, die eventuell
>> auch bei Sponsoren betrieben werden kann wie im Fall des von Strato
>> gesponsorten FOSSGIS-Devservers. Die Eigeniniative von Leuten muss
>> gefoerdert werden - die OSMF mit immer neuen Forderungen nach
>> verlaesslichem Infrastrukturbetrieb zuzuballern, das fuehrt nur zu einem
>> unbeweglichen, innovationsfeindlichen Verwaltungsapparat.
>>
>> Wenn wir etwas nicht selbst auf die Beine stellen koennen, besteht kein
>> berechtigter Grund zu der Annahme, dass es dann erfolgversprechend ist,
>> zu verlangen, "irgendjemand" ("das Projekt", "die OSMF") solle das
>> machen. Wir sind das Projekt. Entweder machen wir das oder keiner.
>>
>> Es gibt immer mal wieder Sponsor-Angebote, die im Sande verlaufen, weil
>> sich niemand drum kuemmert oder weil halt irgendein kleiner Server mit 8
>> GB in einem Rechenzentrum in Russland niemanden interessiert. Ein erster
>> Anfang koennte sein, dass sich jemand mal den Hut aufsetzt, dass er
>> diese Sponsor-Angebote registriert und auf der anderen Seite Anfragen
>> von Leuten entgegennimmt, die gern einen Service anbieten wuerden.
>> Eventuell kann daraus auch eine groessere "Plattform" werden, eventuell
>> kann auch einer sagen "ich bin bereit, einen Server zu administrieren,
>> auf dem jemand anders einen OSM-Dienst installiert" oder so. Damit
>> koennte man die weit verbreitete Eigenbroetlerei vielleicht ein bisschen
>> aufbrechen und den Leuten mit guten Ideen ueber die Anfangshuerden
>> hinweghelfen.
>>
>> Aber mehr als eine Katalysator-Funktion ist m.E. zentral nicht drin. Wer
>> "verlaessliche" Angebote braucht, der kann die nicht bei einem
>> Hobbyprojekt suchen.
>>
>> Bye
>> Frederik
>>
>> --
>> Frederik Ramm  ##  eMail frederik at remote.org  ##  N49?00'09" E008?23'33"
>>
>>
>>
>> ------------------------------
>>
>> Message: 3
>> Date: Tue, 20 Sep 2011 23:21:57 +0200
>> From: Andreas Tille<andreas at an3as.eu>
>> To: talk-de at openstreetmap.org
>> Subject: Re: [Talk-de] Offizieller Satz von OSM Diensten
>> Message-ID:<20110920212157.GG24562 at an3as.eu>
>> Content-Type: text/plain; charset=iso-8859-1
>>
>> On Tue, Sep 20, 2011 at 10:28:23PM +0200, Frederik Ramm wrote:
>>> Es ist richtig, dass einige Leute "erwarten", dass sowas nicht passiert,
>>> aber da muss man dann gegensteuern und die Erwartungen korrigieren; es
>>> kann nicht angehen, dass man an unser freiwilliges und unbezahltes
>>> Admin-Team in London Anforderungen stellt, als ob man mit denen einen
>>> Wartungsvertrag abgeschlossen haette.
>> Das ist klar.
>>
>>>> Zu diesen Werkzeugen w?re ich nat?rlich in erster Linie einen Standard
>>>> Renderer von Karten f?r das Web, einen Editor, eine Karte f?r GPS
>>>> Ger?te, aber auch solche Sachen wie den RA und weitere n?tzliche Tools
>>>> z?hlen.
>>> Es ist wuenschenswert, dass es solche Dinge gibt, und dass wir ein
>>> Oekosystem haben, in dem Leute sowas bauen koennen, aber Kern-
>> Dienste
>>> des Projekts koennen das nicht werden, oder wir muessen gleich mehrere
>>> Programmierer und Admins bezahlen.
>> Ich bin unsicher, ob das bezahlen notwendig ist.  Die Leute ansich sind
>> ja bereits da und tuen offensichtlich gute und n?tzliche Dinge.  Was
>> meiner Meinung nach fehlt ist eine effektivere Organisationsstruktur.
>>
>>> Ich bin heilfroh, dass es nicht "die offizielle Garminkarte" gibt, und
>>> bei den Tile-Layern geht die Entwicklung zum Glueck auch weg von
>>> "Mapnik-Standardkarte fuer alle". Sowas erstickt doch jede Innovation.
>> Das sehe ich anders, kann meinen Standpunkt aber zugegebenerma?en
>> nicht
>> beweisen.
>>
>>> Wir haben das mit dem FOSSGIS-Devserver ja probiert; es gibt da gute und
>>> schlecht Erfahrungen. Der Plan war dort auch, dass man Leuten die
>>> Ressourcen gibt, um ihre Sachen zu entwickeln und laufen zu lassen, und
>>> dass durch gegenseitige Offenheit auch eine Zusammenarbeit entsteht.
>>> Leider hat sich gezeigt, dass es fuer viele eben doch reizvoller ist,
>>> was eigenes zu machen, als bei einem bestehenden Projekt mitzuarbeiten.
>> Das "Leider" im letzten Satz nehme ich mal als teilweise/schwache
>> Zustimmung zu dem von mir gesagten.
>>
>>> Diese Neuerfindung des Rads ist durchaus nicht immer schlecht und kann
>>> dazu fuehren, dass radikale neue Ideen sich durchsetzen - wenn man die
>>> Leute zwingt, alle am gleichen Seil zu ziehen, dann laufen einem die
>>> wirklichen Genies vielleicht auch davon ;-)
>> Von Zwang w?rde ich nicht sprechen wollen.  Es hat sich an vielen
>> Stellen als sinnvoll erwiesen, Standards festzulegen und effektiv
>> verhindern kann und will ich nicht, da? das Rad hin und wieder neu
>> erfunden wird.  Es gilt allerdings zu vermeiden, da? es auf Grund einer
>> mangelhaften Struktur beinahe zwangsl?ufig geschieht, da? das Rad
>> st?ndig neu erfunden wird.
>>
>>> Wenn wir etwas nicht selbst auf die Beine stellen koennen, besteht kein
>>> berechtigter Grund zu der Annahme, dass es dann erfolgversprechend ist,
>>> zu verlangen, "irgendjemand" ("das Projekt", "die OSMF") solle das
>>> machen. Wir sind das Projekt. Entweder machen wir das oder keiner.
>> Vollkommen klar.  Ich kenne solche Mechanismen aus dem Debian Projekt,
>> das sich als Do-O-Cracy bezeichnet, sehr gut.
>>
>>> Es gibt immer mal wieder Sponsor-Angebote, die im Sande verlaufen, weil
>>> sich niemand drum kuemmert oder weil halt irgendein kleiner Server mit 8
>>> GB in einem Rechenzentrum in Russland niemanden interessiert. Ein erster
>>> Anfang koennte sein, dass sich jemand mal den Hut aufsetzt, dass er
>>> diese Sponsor-Angebote registriert und auf der anderen Seite Anfragen
>>> von Leuten entgegennimmt, die gern einen Service anbieten wuerden.
>>> Eventuell kann daraus auch eine groessere "Plattform" werden, eventuell
>>> kann auch einer sagen "ich bin bereit, einen Server zu administrieren,
>>> auf dem jemand anders einen OSM-Dienst installiert" oder so. Damit
>>> koennte man die weit verbreitete Eigenbroetlerei vielleicht ein bisschen
>>> aufbrechen und den Leuten mit guten Ideen ueber die Anfangshuerden
>>> hinweghelfen.
>> Soetwas in der Art schwebte mir vor.
>>
>>> Aber mehr als eine Katalysator-Funktion ist m.E. zentral nicht drin.
>> Das w?re aber schon mal was.
>>
>>> Wer
>>> "verlaessliche" Angebote braucht, der kann die nicht bei einem
>>> Hobbyprojekt suchen.
>> Ich bin mir nicht sicher, ob die Bezeichnung "Hobbyprojekt" noch korrekt
>> ist.  Bei Debian gibt es auch keine fest Angestellten und dennoch w?rde
>> ich nicht die Bezeichnung Hobbyprojekt w?hlen.  OSM scheint mir eher mit
>> WikiPedia vergleichbar zu sein, auch das ist kein Hobbyprojekt mehr (gut
>> hier werden wohl auch einige Leute f?r Ihre Arbeit daran bezahlt).  Die
>> Frage ist, von welchem Standpunkt aus OSM als Hobbyprojekt oder eben
>> nicht klassifiziert wird.  Aus Nutzersicht ist es das schon nicht mehr,
>> denn es wird durchaus zu professionellen Zwecken eingesetzt.  Ich glaube
>> beobachtet zu haben, da? bei Freien Projekten die Zunahme an Code /
>> Daten ?ber einen bestimmten Punkt hinaus zu einer neuen Qualit?t in der
>> Organisation f?hrt und IMHO auch f?hren mu?.  Dem gilt es in geeigneter
>> Weise Rechnung zu tragen - auch wenn ich hier die genaue Weise schuldig
>> bleiben mu?, was das vorher gesagte zugegebenerma?en entwertet.  Die in
>> diesem Thread angemahnte Standardisierung k?nnte dabei einen Baustein
>> bilden.
>>
>> Viele Gr??e
>>
>>          Andreas.
>>
>>
>> --
>> http://fam-tille.de
>>
>>
>>
>> ------------------------------
>>
>> Message: 4
>> Date: Wed, 21 Sep 2011 00:31:55 +0200
>> From: Christian M?ller<cmue81 at gmx.de>
>> To: Martin Koppenhoefer<dieterdreist at gmail.com>
>> Cc: Openstreetmap allgemeines in Deutsch<talk-de at openstreetmap.org>
>> Subject: Re: [Talk-de] landuse=road War:[viel Text zu
>> 	landuse-handling..]
>> Message-ID:<4E79145B.4070609 at gmx.de>
>> Content-Type: text/plain; charset=UTF-8; format=flowed
>>
>> Am 19.09.2011 20:16, schrieb Martin Koppenhoefer:
>>> Am 19. September 2011 19:34 schrieb Christian M?ller<cmue81 at gmx.de>:
>>>> Am 16.09.2011 11:16, schrieb Martin Koppenhoefer:
>>>>> Du t?uschst Dich hier. Siedlungsstellen lassen sich nicht automatisch
>>>>> errechnen, weil die Informationen dazu fehlen. Bei den landuses - so
>>>>> man sie alle erfasst hat - sind die ben?tigten Informationen hingegen
>>>>> vorhanden. Daher geht es da.
>>>> -1  Das ist, sorry, absoluter Unfug.
>>>>
>>>> /Erstens/ sind die ben?tigten Informationen f?r die Siedlungsstellen
>>>> existent, wenn landuses komplett erfasst sind.
>>> Du willst es nicht verstehen. Es ist nicht klar, zu _welcher_
>>> menschlichen Siedlung sie geh?ren. Das ist das Problem, nicht, ob sie
>>> besiedelt sind.
>> Nat?rlich ist das klar - anhand der Gemeinde, bzw. Gemarkungsgrenze,
>> innerhalb derer die landuses liegen.  Im allgemeinen umfassen politische
>> Grenzen einer Gemeinde einen gr??eren Bereich, mindestens aber den
>> Bereich der Siedlung.
>>
>> Selbst wenn eine politische Grenze aktuell nicht mehr zu finden ist,
>> wird es eine historische geben, die f?r die Ermittlung benutzt werden
> kann.
>> Die Information einer Siedlungsfl?chengrenze ist damit klar redundant
>> [[denn es gibt Regeln, mittels derer sie sich ausrechnen l?sst]].  Ich
>> vertrete aber die Auffassung, dass diese Regeln nicht au?erhalb der DB
>> stehen sollten.
>>
>> Schlie?lich ist sie ?ber eine Relation innerhalb OSM effizient pro Fall
>> abbildbar.  In gewisser Weise steckt Redundanz dann nur dadurch in der
>> DB, dass die Regel mehrmals angewandt wird.  Das hat aber eben auch den
>> Vorteil, dass Ausnahmen ohne weiteres abbildbar sind.
>>
>> Bisher standen dazu in unserer Debatte zwei Realisierungen zur Auswahl:
>> a) Erfassung ?ber (wiederbenutzte) Fl?chengrenzen  b) Erfassung ?ber
>> Sammelrelation aller Teilfl?chen der Siedlungsfl?che.  b) hat klare
>> Nachteile gegen?ber a), siehe Datenhaltungsmail.
>>
>> Das ist alles nur Wiederholung, siehe fr?here mails..
>>
>>
>>>> /Zweitens/, kannst Du aus einem Netz MICROgemappter Fl?chen _nicht_
>> oder nur
>>>> mit sehr hohem Aufwand (sprich komplexe, regelbasierte Algorithmen)
>> sinnvoll
>>>> auf ein Netz grobgranularer Fl?chen schlie?en.
>>> So kompliziert ist das nicht.
>> Du lehnst Dich hier viel zu weit aus dem Fenster.  /Wie/ kompliziert das
>> werden kann, ?berblickst Du gar nicht.  Ich ?berblicke das auch nicht,
>> behaupte aber auch nicht, dass ich das k?nnte.
>>
>>
>>> Der immense Vorteil ist aber dabei, dass
>>> alle Informationen vorliegen und ich selbst entscheide, was f?r mich
>>> unwesentlich ist, und was nicht.
>> Ich lese nur /ich/ in deinen S?tzen.  So funktioniert OSM nicht.  Um
>> /als Datennutzer/ entscheiden zu k?nnen, was f?r mich wesentlich ist,
>> muss ich aus einem Angebot /w?hlen/ k?nnen.  /Du/ bist hier gerade
>> derjenige der einem dieses Angebot vorschreiben will, weil /Du/ der
>> Meinung bist, dass ein Salat aus MICROgemappten Fl?chen ausreiche, um
>> sich alle erdenklichen gr?beren F?lle auszurechnen.
>>
>> Umgekehrt muss ich /als Mapper/ /w?hlen/ k?nnen, auf welcher Ebene ich
>> Informationen zum Projekt hinzuf?ge.  Nicht jeder hat die Muse, deinen
>> Vorstellungen von Gr??en, die "nicht weiter teilbar" sind,
>> nachzukommen.  Solche Leute d?rfen dann keine Fl?chennutzung mehr
>> erfassen, oder wie?  Und der n?chste MICROmapper, der kommt, und das
>> Gebiet der Forstwirtschaft dann "parzelliert" zerst?rt die Arbeit des
>> MACROmappers - weil eben das Gebiet der Forstwirtschaft _nicht_
>> notwendigerweise, wie Du schreibst, aus Mini-Parzellen zusammensetzbar
>> ist.
>>
>> Ich bin der Meinung, dass Du immer noch nicht durchdacht hast, welche
>> wirklichen Konsequenzen deine Streichung von "?berwiegend" aus der
>> Definition zur Fl?chennutzung hat.  Nochmal, wenn Du die "reine" statt
>> ?berwiegende Fl?chennutzung erfasst, hei?t das f?r Dich und alle, die Du
>> damit begeistern willst:
>>
>>       a) Erfassung aller erdenklichen Fl?chennutzungen einer Fl?che
>>       b) Unterteilung der vorhandenen Fl?che in kleinste Einheiten, die
>> eine __eindeutige__ Erfassung der Fl?chennutzung erm?glichen
>>
>> Ich bitte Dich nochmals, mitzudenken:  Eine Fl?che beliebiger Gr??e kann
>> _immer_ nochmal geteilt werden, um die Fl?chennutzung genauer zu
>> erfassen:  Selbst f?r einen Acker funktioniert das:  linienschmale
>> Fl?chen werden z.B. als Furche des Ackers genutzt.
>>
>> Bist Du allen Ernstes der Aufassung, dass aus diesen kleinsten,
>> MICROgemappten landuses, sich _jeder_ diese gr?beren Gebiete aus einem
>> komplexen Regelset "zusammenbauen" will?  Die Regel f?r den Acker w?re
>> dann:
>>
>>       Gruppiere alle Furchen, um das Gebiet des Ackers zu erhalten.
>> (Total einfach!  Da braucht man doch die ?berweigende Nutzung der
>> Gesamtfl?che als Acker gar nicht erfassen..)
>>
>> Ganze Softwareprojekte w?rden sich dann damit besch?ftigen, Regelwerke
>> zu pflegen, weil /Du/ der Auffassung warst, dass die Gruppierung
>> feingranularer Strukturen in "gr?bere" ja ein Kinderspiel sei (es aber
>> schon f?r die Berechnung der Siedlungsfl?chengrenze verneinst!).
>>
>>
>>>    Es geht n?mlich nicht nur um die
>>> Fl?chengr??e sondern auch um die Art der Nutzung. Eine kleine aber
>>> extreme Nutzung ist f?r bestimmte Fragestellungen interessant. Wenn
>>> man alles vermanscht, fehlen die Infos nachher.
>> Gerade ein Fl?chennetzwerk erlaubt, was jetzt nicht m?glich ist:
>> Extreme Nutzungs?nderungen f?r kleine Gebiete zu erfassen, ohne dabei
>> das gr?bere Gebiet zu zerst?ren.  /Ob/ die extreme Nutzungs?nderung
>> interessiert oder nicht, bestimmt
>>
>>       bei der Erfassung:  der/die MapperIn
>>       bei der Nutzung:  der Datennutzer
>>
>> und nicht /eine/ /einzige/ Person.   Momentan gibt es kein
>> Fl?chennetzwerk der Bodennutzung und wenn es existiert, dann an lokalen
>> Stellen, wo Mapper das Problem erkannt, aber dessen L?sung nicht
>> publiziert haben (Wiki, Mailingliste).  Das bedeutet:
>>
>>       MICROmapper  X  kommt, mappt die grob erfasste Bodennutzung von
>> MACROmapper Y neu und die (sinnvolle!) Gruppierungsinformation ist
>> verloren.  Y kann sich ja sein Zeug, aus den neuen Fl?chen schon
>> irgendwie errechnen -->  Super Einstellung, so macht zusammenleben und
>> -mappen Spa?..
>>
>> Dann sollten wir das aber auch f?r die Siedlungsfl?che so handhaben.
>> Schlie?lich kann sich auch Mapper Martin aus den MICRO-landuses
>> innerhalb irgendeiner politischen Grenze den landuse=settlement
>> zusammenrechnen..  Oder wollen wir f?r manche gr?bere landuses ein paar
>> Ausnahmen schaffen?
>>
>> Das ist alles vergebene Liebesm?h, denn wir haben schon festgestellt:
>>
>>       Der Mapper bestimmt, /was/ /wie/ gemappt wird.
>>       Der Nutzer bestimmt, /was/ er davon haben will.
>>
>> Ohne irgendwelche Verbote, kann OSM elegant beides bedienen, indem
>> einfach der Fakt anerkannt wird, dass auch bei der "?berwiegenden realen
>> Bodennutzung" Beziehungen zwischen den Einzelfl?chen bestehen und sich
>> Bodennutzungsfl?chen durchaus ?berlappen k?nnen.  Die Erfassung der
>> Bodennutzung muss nicht disjunkt erfolgen, das w?re eine Forderung nach
>> _unm?glicher_ Pedanterie.
>>
>> Beispiele:  Ein Gebiet wird ?berwiegend f?r das Wohnen verwendet, wir
>> erfassen es als landuse=residential.  Au?erdem gibt es eine kleine
>> Stelle innerhalb des Wohngebietes, wo die Fl?chennutzung "extrem" (was
>> extrem ist, ist auch Ansichtssache) schwankt, wir erfassen also
>> landuse=residential.
>>
>> Was bedeutet das?  Ich habe eine Information, mit der ich ein gro?es
>> Gebiet klassifizieren kann "_?berwiegend zum wohnen verwendet_".  Wenn
>> mich nur dieses Gebiet interessiert, interessiert es mich nicht, ob und
>> wieviele extreme Nutzungs?nderungen innerhalb winziger Teilfl?chen
>> dieses Gebietes stattfinden.  Gleichfalls muss ich den Fakt anerkennen,
>> dass sich andere evtl. f?r eine detailierte Fl?chennutzungsaufteilung
>> interessieren.  Gleichfalls m?ssen die, welche die detailierte
>> Fl?chennutzungsaufteilung interessiert, anerkennen, dass es Leute gibt,
>> die sich f?r gr?bere Strukturen interessieren, f?r die es also
>> vernachl?ssigbar ist, dass es extreme Nutzungs?nderungen innerhalb eines
>> Gebietes gibt.
>>
>> OSM kann beide Welten problemlos verbinden, indem Fl?chengrenzen als
>> /way/ und Fl?chen als /multipolygon/ erfasst werden.  Dann lassen sich
>> Fl?chen beliebiger Strukturgr??e nach bestem Wissen und Gewissen durch
>> Mapper bilden, ohne dass ein Mapper einem anderen Mapper /seine/
>> Vorstellung von "einer" "wahren" Fl?chengr??e aufdr?cken muss.  Es gibt
>> nicht die "wahre" Fl?chen, bzw. Strukturgr??e, auf der Daten erfasst
>> werden, sondern ein Spektrum, dass von der Gr??e eines Kontinents bis
>> zur Gr??e eines Wegweisers reicht.
>>
>> Solange Du behauptest, dass man "nur" Bodennutzungen MICROmappen
>> m?sste,
>> um alle gl?cklich zu werden, verschiebst Du die Diskussion, die wir
>> /hier/ f?hren, einfach nur in einen /anderen/ Gr??enbereich, um sie dort
>> zu wiederholen.
>>
>> ==>   Eventuell triffst Du dort dann NANOmapper, der Dir erkl?rt, dass es
>> Unfug ist, landuse=* MICRO zu mappen, weil MICROgemappte landuses ja
>> ohne Probleme aus NANOgemappten errechenbar seien..
>>
>>
>>>> Nat?rlich kann ich nur politische Gemeindegrenzen innerhalb der DB
>> pflegen
>>>> und dann extern die Bundesgrenze ausrechnen.  Das machen wir aber
>> eben
>>>> nicht, weil die Vorteile einer expliziten Erfassung innerhalb der DB
> (mit
>>>> Bez?gen der Grenzen untereinander) klar ?berwiegen!
>>> +1
>>> daher sind Siedlungen auch besser nicht die Summe verschiedener
>>> Landuses sondern ein extra Polygon.
>> Genau hier musst Du weiterdenken..  Das ist nicht die ganze Wahrheit,
>> denn die _gleiche_ Argumentationsweise, die Du verwendest, um Dich
>> gegen
>> die automatische Errechenbarkeit einer Siedlungsfl?chengrenze zu wehren,
>> z?hlt auch, wenn ich behaupte, dass der landuse=* eines
>> Forstwirtschaftsgebiet aus seinen MICRO oder NANOgemappten
>> Teilnutzungen
>> _nicht_ errechenbar ist, sondern ?ber "ein extra Polygon" (multipolygon)
>> erfasst werden soll.
>>
>> Egal ob das gr?bere Gebiet nun eine Siedlung darstellt, oder ein
>> Forstwirtschaftsgebiet - weshalb sollten gr?bere Gebiete jedes Mal, wenn
>> ein Nutzer sie braucht, berechnet werden?
>>
>> Wenn ich wei?, welche Wege zu einer Radroute geh?ren, kann ich mir das
>> auch jedes Mal aus OSM-Daten ausrechnen.  Das brauche ich aber nicht,
>> denn das Ergebnis dieser Rechnung ist Teil der Realit?t und damit Teil
>> von OSM  (vorgehalten durch eine type=route Relation).
>>
>> Falls man das Argument der Errechenbarkeit zu Ende denkt, kommt man
>> darauf, dass es eigentlich reicht, nur die nodes zu erfassen.  Alles
>> andere l?sst sich doch, entsprechendes externes Wissen vorrausgesetzt,
>> auch extern ausrechnen..
>>
>>
>>>> Betrachte bitte die Relationen in OSM.  Beziehungen zwischen den Daten
>> sind
>>>> nicht immanent und einfach so da!
>>> doch, die Lage ist einfach so da, genauso wie die Gr??e einer Fl?che,
>>> oder was innerhalb und ausserhalb einer Fl?che liegt, bzw. welche
>>> Fl?chen sich schneiden. Da musst Du z.B. nicht noch die Fl?chengr??e
>>> dazuschreiben, auch wenn manche das trotzdem machen.
>> Ja, was denkst Du wohl, weshalb einige die Fl?chengr??e dranschreiben?
>> Weil die Ermittlung des Ergebnisses wesentlich aufwendiger sein kann,
>> als einfach diesen Wert nachzuschlagen.
>>
>> Die Lagebeziehung zwischen zwei Fl?chen ist _nicht_ einfach so da!  DU,
>> als Mensch, kannst zwei Polygone zeichnen und dann sagen, das eine liegt
>> innerhalb des anderen  oder  meinetwegen auch, die beiden Polygone
>> schneiden sich.  Das kannst DU, als Mensch, recht schnell f?r kleinere
>> Polygone tun, aber auch nur dann, wenn Du eine visuelle Darstellung der
>> beiden Polygone vor Dir hast.
>>
>> F?r eine Maschine ist die Lagebeziehung der beiden Polygone solange
>> nicht gegeben, wie Du sie nicht explizit angibst (in Bezug setzt, eine
>> Relation erstellst) __oder__ durch ihre Koordinaten errechnest.  Das
>> kann, in Abh?ngigkeit der Menge der Polygone, die in Bezug zu setzen
>> sind, und ihrer einzelnen Gr??en sehr schnell sehr aufwendig werden.
>>
>> Deine Aussage, dass irgend zwei "closed ways" automatisch eine immanente
>> Beziehung zueinander in der DB h?tten, ist also schlichtweg falsch.  Die
>> Beziehung ist nicht immanent, sonder maximal "ermittelbar".
>>
>> Beziehungen zwischen Objekten innerhalb einer DB sind _nicht_ einfach so
>> da.  Sie m?ssen definiert werden  (entweder durch Algorithmen, die
>> Bez?ge ermitteln, oder durch Datenstrukturen, die Bez?ge
>> speichern/vorhalten).
>>
>> Immanent in der DB sind grunds?tzlich ersteinmal nur die Beziehungen
>> zwischen
>>
>>       node - lat,lon pair
>>       way - node list
>>       relation - way or node
>>       relation - relation
>>
>> Eventuell noch, aber da wird es schon wackelig:  closed way - area
>> Eine echte area (Fl?chentyp) kennt die DB ?berhaupt nicht!  Wie willst
>> Du da behaupten, dass Fl?chenbeziehungen untereinander immanent
>> w?ren?
>>
>> Einem multipolygon z.B. sind die Beziehungen zwischen seinen
>> innliegenden Polygonen und dem au?enliegenden Polygon "immanent".  Das
>> ist aber gerade, wovon ich rede:  Generell Fl?chen als multipolygon zu
>> erfassen, weil damit (einige) Fl?chenbeziehungen immanent gegeben
>> w?ren.  Das ist bis jetzt keine durchg?ngig angewandte Praxis (von
>> politischen Grenzen, auf die Du dich _nicht_ beschr?nkt hast, einmal
>> abgesehen).
>>
>>
>>>> Was aber nicht passieren darf (!), ist, dass sich unter den
> Render-Regeln,
>>>> Regeln befinden, wie Daten der Realit?t gruppiert werden, die schon in
>> der
>>>> Realit?t gruppiert werden.
>>> Die Renderregeln leisten das: Daten selektieren und ggf. gruppieren.
>> Der letzte Teilsatz war wichtig - ich schrieb ihn nicht zum Spa?.  ",
>> die schon in der Realit?t gruppiert werden."
>>
>> Das schlie?t eine ganze Menge an Renderregeln aus.
>>
>> /Falls/  Renderregeln   Daten der Realit?t   auf eine Art und Weise
>> gruppieren, so dass die Selektion, die der Renderer da t?tigt, einer
>> Selektion/Gruppierung gleicht, die bereits Teil der Realit?t ist, dann
>> hat diese Gruppierungsregel _nichts_ in den Renderregeln verloren.
>>
>> Das Ergebnis der Gruppe sollte _dann_ stattdessen als Relation innerhalb
>> der OSM-DB existieren.  Idealerweise sind Renderregeln reine
>> Layout-Regeln, es wird also nur des Layouts wegen gruppiert und nicht,
>> wenn Daten schon in der Realit?t gruppiert (lies: in Beziehung gesetzt)
>> werden.  Letzteres ist Teil von OSM.  Beispiel:
>>
>>       Es gibt mehrere Buslinien innerhalb eines Netzwerks.
>>       Der Renderer gruppiert sich diese Buslinien anhand des
>> network-Tags, um dann einen Stil zu definieren.
>>       Diese Gruppierung gibt es aber schon in der Realit?t, es w?re also
>> besser, das Netzwerk in OSM abzubilden:
>>           Relation type=network ...  mit den Buslinien als Mitglieder.
>>       .. und als Renderregel den Stil f?r das network festzulegen.
>>
>> Als Richtlinie kann man sich evtl. merken:  Solange eine Renderregel
>> /selektiert/, ist alles in Ordnung.  Sobald eine Renderregel
>> /gruppiert/, muss man sich als Layouter die Frage stellen, ob die
>> Gruppierung _wirklich nur_ f?r Layoutzwecke stattfindet,  _oder_ nicht
>> evtl. ein Workaround um eine fehlende Relation in OSM ist.
>>
>>
>>>> folgendes:
>>>>      - ein Renderer gruppiert sich die Elbe-Radroute aus den Wegen der
> DB
>> auf
>>>> die eine Art
>>>>      - der n?chste auf eine leicht andere Art
>>> sorry, aber irgendwo haben Vergleiche auch ein Ende, und ein linearer
>>> Radweg ist schlecht mit dem Problem hier vergleichbar.
>> Ich seh' schon - Du bist jemand, der nicht zwischen Radweg und Radroute
>> unterscheidet.  Dann trifft der Vergleich nat?rlich auch nicht ins
> Schwarze.
>> Und nein, Vergleiche m?ssen nicht /irgendwo/ ein Ende haben, sondern
>> dort, wo sie nicht mehr zutreffen.
>>
>>           Eine Radroute aus /ways/ in den Rollen 'Teilabschnitt' zu bilden.
>> ist vergleichbar mit
>>           Eine Fl?che aus /ways/ in den Rollen 'Fl?chengrenze' zu bilden.
>>
>> Wenn die Radroute ein Rundkurs ist, werden beide Sachverhalte sogar auf
>> identische Weise abgebildet:
>>
>>           Die Relation enth?lt dann in beiden F?llen
>> aneinandergeschlossene Wegsegmente.
>>           Es nehmen nur solche Wegsegmente Teil, deren Endpunkte auch
>> Anfangspunkte eines anderen teilnehmenden Wegsegmentes sind.
>>
>> Ob das ganze als Route  oder  Fl?che interpretiert wird, entscheiden
>> dann nur noch die Relations-Tags..
>>
>>
>>>> "richtig" im Sinne der Frage, ob die entstehende Gruppierung eine
>> Abbildung
>>>> der Realit?t ist [...]
>>> wie Frederik schon treffend sagte: um richtig und falsch geht es
>>> nicht, in jedem Fall machen wir hier ein Modell der Welt, das man
>>> nicht mit der Welt verwechseln sollte.
>> +1    "richtig im Sinne der Frage, ob [...] eine Abbildung der Realit?t
> ist"
>> "richtig" besch?ftigt sich mit der Realit?tstreue des Modells..  Ist die
>> Abbildung gut oder wird unzul?ssig abstrahiert, etc.
>>
>> Wenn ein Sachverhalt im Bezug auf das Modell "falsch" ist, aber in der
>> Realit?t existent, stellt sich die Frage, inwieweit das Modell angepasst
>> werden muss...
>>
>>
>>>    M.E. geht es in der Diskussion
>>> hier darum, herauszufinden, wie unser Modell am besten abbilden
>>> sollte, dass:
>>>
>>> - es Verwaltungseinheiten und dazugeh?rige Verwaltungsgrenzen gibt,
>>> - es davon unabh?ngig Siedlungen und Teile davon gibt,
>>> - dass jedes St?ck Land irgendwie genutzt wird, oder eben nicht
>> +1  Wenn Du aber dogmenartig am "Modell" h?ngst, wird daraus Mist.
>>
>> Du musst nicht nur herausfinden, wie die Realit?t in das Modell passt.
>> Du musst auch pr?fen, ob das Modell ?berhaupt geeignet ist, deine
>> genannten Aspekte der Realit?t zu erfassen.  Das ist eine Arbeit von
>> zwei Seiten.  OSM nutzt ein evolution?res Datenmodell, sprich, ein
>> Datenmodell, das sich fortentwickelt.  Es ist keine Vorschrift des
>> Projektes, dass der _jetzige_ Stand des Datenmodells f?r immer und ewig
>> aktueller Stand bleibt.
>>
>> Es gibt viele Stellen, an denen sich das Datenmodell bewiesen hat (true
>> and tested).  An denen ist es schwer Argumente f?r eine ?nderung zu
>> finden, weil die Argumente ja aufzeigen m?ssten, wie etwas, dass sich
>> bewiesen hat, noch besser geht.  Es gibt aber auch (nicht wenige)
>> Stellen, an denen es einfach nur Mist ist, weil Struktur fehlt, weil
>> Dinge vermischt werden, die in der Realit?t ausdifferenzierbar sind, etc.
>>
>> OSM kann die Realit?t nicht abbilden, ohne zu strukturieren.  Es ist ein
>> klares Strukturierungsprojekt.  Mischmasch, Brei und Chaos sind auch
>> Teile der Realit?t, die werden in OSM durch die ?nderungsrate eines
>> Gebietes abgebildet:  Ein Mapper, der mit der bestehenden
>> Ausdifferenzierung eines Gebietes nicht zufrieden ist, "strukturiert das
>> Gebiet um".  I.d.R. erh?ht er dabei Genauigkeits-, Detail- und
>> Strukturierungsgrad.  Die ?nderungsrate eines Gebietes erfasst in OSM
>> auch jenes Chaos der Realit?t, welches durch permanente
>> Gebietsumgestaltungen des Raumes (etwa in St?dten) entsteht.
>>
>>
>>> weiterhin w?ren noch jede Menge andere Betrachtungsweisen denkbar
>>> (aber nicht alle sinnvoll in OSM aufgehoben), z.B. die Bodenbedeckung,
>>> die Vegetation, der Feuchtigkeitsgehalt des Bodens, das Klima, der
>>> geologische Untergrund, die Bebauungstypologie, die Einwohnerdichte
>> +1  genau.  OSM l?sst sich f?r diese Anwendungsfelder ?ffnen.  Das ist
>> aber m.E. erst dann sinnvoll, wenn die Grundlage stimmt:
>>
>>       Bessere Unterst?tzung f?r Fl?chenerfassung in Editoren
>>       Multipolygone f?r die Zusammenarbeit von Makro-, Micro- und
>> Nanomappern (Fl?chennetzwerk..)
>>       Dokumentation und schl?ssige Definition im Wiki, wie Tags
>> Verwendung finden
>>
>> =Zukunftsmusik===========
>> Damit kann dann auch eine echte Zusammenarbeit zwischen Laie und
>> Spezialist klappen, ohne dass sich beide gegenseitig die Arbeit
>> zerst?ren, oder ein Disput enststeht, wo eine Fl?che erfasst werden
>> "darf" und wo nicht.  Die Chancen sind gro?, dass damit auch die
>> bestehende Datenqualit?t erh?ht wird und OSM zu dem Wiki ortsbezogener
>> Information wird.
>>
>> Es ist dann z.B. auch echt diskutierbar, /welche/ Fl?chengrenzen
>> zusammenfallen und welche nicht.  Man unterh?lt sich dann also nicht
>> mehr ?ber die Datenhaltung, ob Fl?chen zusammengepappt werden d?rfen,
>> oder an Wege geklebt, oder sonstwas, sondern um echte fachliche Fragen -
>> welche Spezialgebiete brauchen ein eigenes Fl?chennetzwerk, welche
>> k?nnen sich eins mit anderen Spezialgebieten teilen.  Welche Beziehungen
>> gibt es zwischen diesen entstehenden Fl?chennetzwerken, etc.  Auf diesem
>> Wege kann OSM helfen Zusammenh?nge zu entdecken, die bisher nicht
>> entdeckt werden, weil die Datenbasen von Spezialisten getrennt
>> voneinander gepflegt werden.
>> =Ende Zukunftsmusik===========
>>
>> Momentan w?rde ich mich auf den Bodennutzungsaspekt beschr?nken.
>> Wenn
>> es daf?r nicht gelingt, alle Anspr?che unter einen Hut zu bringen,
>> braucht man nicht weiter tr?umen.  Ohne irgendeinen Bezug (und damit die
>> M?glichkeit der Zusammenarbeit untereinander) zwischen Fl?chen wird es
>> nicht gehen.  Wenn wir da weiter mit "closed ways", "overlapping ways",
>> geklebten ways, dicht nebeneinanderliegenden doppelten ways, etc.
>> rummanschen und jeder sein eigenes S?ppchen kocht, bleiben
>> Sinnzusammenh?nge der Daten f?r/in OSM verborgen.  Diese dann
>> herzustellen, bleibt individuelle Aufgabe f?r clevere
>> Algorithmenschreiber, die aus dem Rausch-Salat ein bisschen Signal
>> herausholen.
>>
>> Ich komme nochmal auf die Radrouten-Analogie zur?ck:
>>
>> Aus dem Schatz _aller_ Wege innerhalb OSM (abz?glich derer, wo das
>> Radfahren verboten ist), k?nnen Wege ausgew?hlt werden, um eine Route
>> zu
>> bilden.  (Route - Relation mit type=route)
>>
>> Die Analogie f?r Fl?chen dazu:  Aus dem Schatz _aller_ Wege innerhalb
>> OSM, k?nnen die Wege ausgew?hlt werden, die eine Fl?che begrenzen.
>> (Multipolygon - Relation mit type=multipolygon)
>>
>>
>> Sp?ten Gru?
>> Christian
>>
>>
>>
>> ------------------------------
>>
>> _______________________________________________
>> Talk-de mailing list
>> Talk-de at openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-de
>>
>>
>> End of Talk-de Digest, Vol 62, Issue 66
>> ***************************************
>
> _______________________________________________
> Talk-de mailing list
> Talk-de at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de
>





Mehr Informationen über die Mailingliste Talk-de