On Fri, Jun 16, 2017 at 11:04:27AM +0200, Christoph Hormann wrote:
> On Friday 16 June 2017, Jochen Topf wrote:
> >
> > Es gibt da eine Tendenz immer komplexere Dinge zu mappen, ohne dass
> > irgendwer diese Daten auch sinnvoll nutzt. Auf der einen Seite ist es
> > ja gut, wenn wir mehr Details und mehr Zusammenhänge erfassen, weil
> > nur Daten, die da sind, auch genutzt werden können. Aber auf der
> > anderen Seite schreckt die Komplexität doch die Entwickler ab.
>
> In diesem Fall gibt es ein recht klares (wenn auch nicht immer einfach
> bestimmbares) Kriterium: Wenn es für den Entwickler einfacher ist sich
> den Zusammenhang aus den übrigen Daten herzuleiten, sollte man
> gewöhnlich auf die Erfassung verzichten. In diesem Fall ist role
> admin_centre von der Bedeutung äquivalent mit
> capital=yes/capital= auf dem entsprechenden Element. Und
> da der Entwickler letzteres aufgrund der Unvollständigkeit der
> admin_centre eh auswerten wollen wird ist das Ganze am Ende meist
> ziemlich überflüssig.
>
> Ansonsten ist das "denkt denn niemand an die armen Entwickler"-Argument
> mit Vorsicht zu genießen, wenn die Bequemlichkeit der Entwickler über
> die Bequemlichkeit der Mapper gestellt wird und dem Mapper sinnlose
> Arbeiten aufgedrückt werden nur weil der Entwickler sich keine Arbeit
> machen möchte oder seine Arbeit teurer ist als die des Mappers (was
> insbesondere bei OSM ein sehr verbreitetes Problem ist).
Es wäre ja schön, wenn wir die Arbeit der Mapper und der Entwickler
irgendwie verrechnen könnten und schauen, was "unterm Strich" am
effizientesten ist oder so. Das könnte man machen, wenn OSM eine Firma
ist, die ihre Leute passend einteilen kann. Aber so ist das halt nicht.
Das Problem ist ein anderes: Der Mapper denkt, sein komplexes Mapping
würde auch magisch irgendwie verwendet. Es erscheint auf der Karte oder
ist findbar im Nominatim oder wird beim Routing verwendet. Das ist aber
häufig nicht der Fall. Wir sind meilenweit hinten dran mit der
Entwicklung. Es gibt wahnsinnig viele Sachen, die theoretisch vielleicht
möglich wären, die praktisch aber nicht funkionieren. Vielleicht gibts
sogar Versuche hier oder dort, aber praktisch ist das, was wir von den
OSM-Daten wirklich nutzen, ziemlich klein.
Dadurch fehlt hier aber ein ganz wichtiges Korrektiv: Klassisch ist das
so, dass der Mapper sich auf das stützen kann, was auf der Karte
erscheint. Mapper mappen solche Sachen konsistent und qualitativ
einigermaßen gut, wo sie das Ergebnis anschauen können. Ob das nun gut
ist oder nicht, Mapper orientieren sich an der Karte (und auch an der
Visualisierung der diversen Tools zur Qualitätssicherung). Aber da, wo
es diese "guidance" durch solche Karten und Tools nicht gibt, gibt es
einen unglaublichen Wildwuchs. Der Wildwuchs ist gut, wenn aktiv in dem
Bereich etwas voran geht. So kann man nämlich verschiedene Dinge
ausprobieren und dann das, was am besten funktioniert, systematischer
umsetzen. Dazu braucht es aber irgendwen, der die Daten auch nutzt und
sagt, was funktioniert und was nicht. Und das fehlt halt in vielen
Bereichen. Beim public transport z.B. ist diese "Diskussion" noch voll
im Gange, da bewegt sich was und neue Dinge werden probiert. Aber in
ganze vielen anderen Bereichen, gerade was komplexe Relationen angeht,
da passiert das nicht.
Damit OSM als System funktioniert, das sich fortentwickelt und
praktische Lösungen liefert, braucht es beides. Die Mapper, die Daten
sammeln und erfassen und die Nutzer, die aus den Daten etwas machen. Aus
dieser Zusammenarbeit entsteht eine nützliche Datensammlung. Fehlt das
eine oder das andere, dann geht es nicht voran.
Jochen
--
Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de
