[Talk-at] OGD (Wien) nützen

Stefan Tauner stefan.tauner at gmx.at
Fri Jul 6 08:46:18 UTC 2012


On Thu, 05 Jul 2012 08:11:30 +0200
Frederik Ramm <frederik at remote.org> wrote:

> On 07/05/12 00:45, Stefan Tauner wrote:
> > ich bin allerdings mit dem (publiziertem bzw von mir so verstandenem)
> > schluß nicht einverstanden, daß imports per se eine schlechte sache
> > sind
> 
> Der Konsens ist glaube ich weitgehend so:
> 
> Die *Nutzung* fremder Datenquellen als (eines von vielen) Hilfmitteln 
> fuer Mapper ist voellig ok und auf jeden Fall sinnvoll.
> 
> Lediglich das - oft blinde - *Importieren* fremder Datenquellen ist es 
> nicht.

der übergang ist halt fließend. wo fängt der import an und die
nutzung auf? wenn jemand grundstückgrenzen von bingmaps abpaust, ohne
vor ort gewesen zu sein, ist das noch nutzen oder schon import? was
ist, wenn er eine 2. unabhängige quelle miteinbezogen hat? usw usf.
aber ich bin sicher diese diskussion wurde schon etliche male geführt
und ich hab nicht nur deshalb nicht wirklich lust da großartig drüber
zu diskutieren :)

> Es gibt da viele Feinheiten und Detail-Unterschiede, aber man kann es 
> lezten Endes grob auf einen einzigen Punkt reduzieren: Derjenige, der 
> die Daten in OSM eintraegt, soll ihr Autor sein und sich auch als der 
> fuehlen. Wenn ich eine Rueckfrage an den stelle, darf nicht 
> zurueckkokmmen "aeh, weiss nicht, die Daten hab ich von <X>, ich hab 
> bloss auf den Button gedrueckt".

die definition ist halt ebenfalls problematisch... wie definiert man
"autor"? das wort ist eigentlich sehr unpassend, da keine neuen inhalte
geschaffen werden, sondern nur beobachtungen bzw datenquellen
zusammengetragen, interpretiert und verknüpft werden. urheberrechtlich
führt dies natürlich zu einer urheberschaft, aber ich würde es nie als
solche bezeichnen. wenn ich koordinaten mit einem gps-gerät messe, bin
ich dann der autor oder das gerät oder der autor der firmware des
geräts oder die regierung der usa, weil sie die satelliten
betreibt...? :)

ich denke, man kann das so handhaben wie viele open source projekte mit
signed-off und committed-by unterscheidung. die leute, die daten
"generieren", müssen bezeugen, daß sie lizenzrechtlich dazu ermächtigt
sind. sprich entweder die daten selbst erstellt zu haben, oder sie von
jemandem bekommen zu haben, der die weitergabe erlaubt (oder eine
mischung davon). siehe zb
http://www.coreboot.org/Development_Guidelines#Sign-off_Procedure
zusätzlich könnte man noch einen "daten nach bestem wissen und gewissen
ermittelt" hinzufügen.

derjenige, der die daten dann in die osm datenbank committed, ist
natürlich verantwortlich gegenüber dem projekt, daß die daten
zumindest plausibel sind und sich nicht offensichtlich negativ
auswirken, aber er muß nicht im detail jeden einzelnen
entstehungsschritt kenn oder bezeugen können. ich denke eine
entwicklung in diese richtung ist zielführender, als wenn man von jedem
beitragenden verlangt, daß er selbst uploadet. mehr betragende,
trotzdem bessere datenqualität...

> Es gibt schon einige Entwicklungen in die Richtung, von der Du 
> schreibst, allerdings nicht fuer Android, sondern fuer Potlatch (das 
> Laden von Shapefiles in den Hintergrund oder sogar der "Snapshot 
> Server", bei dem man zu mehreren einen Fremddatenbestand sichten und 
> "abarbeiten" kann) und fuer JOSM (das "Conflation"-Plugin).

das conflation plugin ist *genial*, wenn auch komplett hinnig :)
https://github.com/joshdoe/josm-conflation-plugin/issues/3

ich hab mal stichprobenartig die bestehenden
fahrradabstellmöglichkeiten mit den OGD verglichen, und man sieht
ausgezeichnet, daß die OGD koordinaten bei weitem besser sind, als die
bestehenden (verifiziert durch bing, ogd orthofotos und eigene
ortskenntnis).

> Es spricht 
> sicher nichts dagegen, sowas auch als einfache Android-App zu haben

oja. die implmentierung dessen und die unmöglichkeit vernünftig mit
konflikten umzugehen. 1. ist natürlich eine ausrede, aber letzteres
entspricht nicht dem, was ich einem user der app am handy antun will.

> - Du 
> gehst irgendwo vorbei und das Ding piepst und sagt: "Laut Quelle <X> 
> muesste hier eine Toilette mit Muenzeinwurf und folgenden 
> Oeffnungszeiten sein, willst Du die in OSM eintragen" oder so. Dabei ist 
> darauf zu achten, dass vom Workflow her eine echte Ueberpruefung 
> stattfindet und keine blinde Uebernahme.

alle tags und die position müssen einzeln abgesegnet werden +
kommentarfunktion (schriftlich oder auch wie boris cornet in einer
pm vorgeschlagen hat: als voice kommentare).

> Wichtig waere bei so einer 
> Sache auch, dass die Leute einen OSM-Account haben und das unter ihrem 
> Account eintragen, anstatt dass es in einen Pool fliesst und spaeter von 
> jemand Drittem, der nicht der Autor ist, eingetragen wird.

das hat mehrere probleme
- konfliktbearbeitung mit bestanddaten
- registrierungszwang
- mangelnde QA für leute, die sich nicht die zeit dafür nehmen wollen
  OSM im detail zu verstehen

boris hat vorgeschlagen dem user die wahl zu lassen und optional
ein .osm generieren zu lassen, daß der user dann zuhause nachbearbeiten
und selbst uploaden kann. finde ich eine hervorragende idee.

> Das Neueintragen (nicht aendern oder loeschen) von Punkten (nicht Linien 
> oder Flaechen) ist natuerlich gleich auf zwei Achsen das Simpelste, aber 
> jeder faengt mal klein an ;) bei der Pruefung, ob ein bestimmtes Objekt 
> in OSM bereits enthalten ist, muessen natuerlich auch Flaechen 
> beruecksichtigt werden, damit ein bereits als Flaeche vorhandenes 
> Klohaeuschen nicht erneut als Punkt eingetragen wird.

das simpelste ist die OGD-daten einfach nur verifizieren und
korrigieren zu lassen und die komplizierten sachen nicht nochmal auf
android zu implementieren und zu benutzen, sondern am desktop mit den
bestehenden tools und von leuten, die wissen, was sie tun ;)
ich bin ziemlich sicher, daß ich eine komplettlösung für android
niemals fertig stellen würde.

vielen dank für dein feedback! boris hat mir noch viel weiteren input
gegeben (aus mir unverständlichen gründen off list) und ich melde mich,
wenn es etwas berichtenswertes gibt.

-- 
Kind regards/Mit freundlichen Grüßen, Stefan Tauner




More information about the Talk-at mailing list