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-requ...@openstreetmap.org [mailto:talk-de-
requ...@openstreetmap.org]
Gesendet: Mittwoch, 21. September 2011 00:32
An: talk-de@openstreetmap.org
Betreff: Talk-de Digest, Vol 62, Issue 66
Send Talk-de mailing list submissions to
talk-de@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-requ...@openstreetmap.org
You can reach the person managing the list at
talk-de-ow...@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<andr...@an3as.eu>
To: OSM-de<talk-de@openstreetmap.org>
Subject: [Talk-de] Offizieller Satz von OSM Diensten
Message-ID:<20110920190400.gd24...@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<frede...@remote.org>
To: talk-de@openstreetmap.org
Subject: Re: [Talk-de] Offizieller Satz von OSM Diensten
Message-ID:<4e78f767.10...@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 frede...@remote.org ## N49?00'09" E008?23'33"
------------------------------
Message: 3
Date: Tue, 20 Sep 2011 23:21:57 +0200
From: Andreas Tille<andr...@an3as.eu>
To: talk-de@openstreetmap.org
Subject: Re: [Talk-de] Offizieller Satz von OSM Diensten
Message-ID:<20110920212157.gg24...@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<cmu...@gmx.de>
To: Martin Koppenhoefer<dieterdre...@gmail.com>
Cc: Openstreetmap allgemeines in Deutsch<talk-de@openstreetmap.org>
Subject: Re: [Talk-de] landuse=road War:[viel Text zu
landuse-handling..]
Message-ID:<4e79145b.4070...@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<cmu...@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@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
End of Talk-de Digest, Vol 62, Issue 66
***************************************
_______________________________________________
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
