Re: [Talk-at] OGD (Wien) nützen
hoi nach dem überragend negativen feedback hab ich die android app dann nicht weiterentwickelt. um die mir bekannten bzw. durch andere quellen bestätigten rad-POIs einfach eintragen zu können habe ich jetzt ein script geschrieben, das sich die fahrradabstellanlagen vom wien.at server holt und in ein OSM konvertiert. das generierte OSM XML mit den abstellanlagen (falls es jemand direkt verwenden will) findet sich hier: http://openstreetmap.at/~stefanct/FAHRRADABSTELLANLAGEOGD.osm das script selbst residiert hier: https://github.com/stefanct/OGD_Wien_tools ich denke es hat potenzial zur weiterentwicklung, falls sich jemand an anderen OGD bedienen will. wenn schon nicht mein script, dann zumindest die ogr2osm translations, die es verwendet, nämlich: https://github.com/stefanct/ogr2osm-translations mir war ursprünglich nicht bewußt, daß man mit ogr2osm solche translations so einfach machen kann, weshalb das in der ersten version händisch mit ogr gemacht wird. in der aktuellen version greif ich komplett auf ogr2osm zurück, falls es vorhanden ist, ansonsten fällt es auf die manuelle methode zurück. noch ein kleines motivationsbild, wieso die OGD (zumindest in diesem datenset) allein aus quantitätsgründen* nicht so verschmät werden sollten: http://openstreetmap.at/~stefanct/FAHRRADABSTELLANLAGEOGD.png (blau ist aus der OSM db, grau die OGD). * von der qualität her sind sie den meisten daten in OSM ebenfalls bei weitem überlegen, was das bild nicht widerspiegelt. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] OGD (Wien) nützen
Ich möchte hier einen Datensatz einwerfen, mit dem ich mich in letzter Zeit ein wenig auseinandergesetzt habe und einen *manuellen *Import davon anstrebe: Der Baumkataster der Stadt Wien. Ein paar Analysen zur Abdeckung und Filterung von bereits eingetragenen Bäumen habe ich bereits gemacht und werde sie bekannt machen, wenn ich wieder Zugriff darauf habe (bin unterwegs). Auch mit deren Aufbereitung habe ich bereits begonnen. Die Integration des Baumkatasters macht schon alleine deswegen für mich Sinn, weil dort die botanisch korrekten Baumnamen als auch Maße eingetragen sind. Außerdem umfasst dieser Kataster nur die öffentlichen Bäume - das heißt, der Großteil aller Bäume würde sowieso noch fehlen. Insofern würde dies meiner Meinung nach ein weiteres Erfassen eher triggern als verhindern. ! Es würden keinerlei bestehende Bäume überschrieben werden ! Beste Grüße, Markus Am 9. Juli 2012 09:01 schrieb Andreas Trawoeger : > Am 6. Juli 2012 17:57 schrieb Andreas Labres : > > > > On 06.07.12 12:11, Boris Cornet wrote: > >> Äh, nein, so würde ich das nicht sehen. > > > > Doch, so war meiner Erinnerung nach schon das Ergebnis der > Podiumsdiskussion > > schon so in etwa: Kaum mehr Importe, wenn, nur unter größter > Bedachtnahme und in > > "leeren" Gebieten. > > > > Kannst Du ein konkretes Beispiel nennen, welcher Import wo noch > /denkbar/ wäre? > > Mir fällt da auch nach oftmaligem Nachdenken nix ein. > > Der OGD Wien Datensatz der noch auf Bearbeitung wartet sind die > Straßenampeln, vor allem die Straßenampeln mit Akustikkennung, weil es > die Basis für blindengerechte Routinganwendungen bieten würde. > > Nachdem aber in OSM schon sehr viele Wiener Ampeln eingetragen sind, > müsste man auch bei diesem Datensatz eine Möglichkeit zum finden einen > semi manuellen Abgleich durchzuführen. > > Ein anderer Kandidat sind Kindergärten, wo eventuell auch noch der > eine oder andere nicht in OSM eingetragen ist, weil er sich an einem > etwas versteckten Ort befindet. > > cu andreas > > ___ > Talk-at mailing list > Talk-at@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-at > ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] OGD (Wien) nützen
Am 6. Juli 2012 17:57 schrieb Andreas Labres : > > On 06.07.12 12:11, Boris Cornet wrote: >> Äh, nein, so würde ich das nicht sehen. > > Doch, so war meiner Erinnerung nach schon das Ergebnis der Podiumsdiskussion > schon so in etwa: Kaum mehr Importe, wenn, nur unter größter Bedachtnahme und > in > "leeren" Gebieten. > > Kannst Du ein konkretes Beispiel nennen, welcher Import wo noch /denkbar/ > wäre? > Mir fällt da auch nach oftmaligem Nachdenken nix ein. Der OGD Wien Datensatz der noch auf Bearbeitung wartet sind die Straßenampeln, vor allem die Straßenampeln mit Akustikkennung, weil es die Basis für blindengerechte Routinganwendungen bieten würde. Nachdem aber in OSM schon sehr viele Wiener Ampeln eingetragen sind, müsste man auch bei diesem Datensatz eine Möglichkeit zum finden einen semi manuellen Abgleich durchzuführen. Ein anderer Kandidat sind Kindergärten, wo eventuell auch noch der eine oder andere nicht in OSM eingetragen ist, weil er sich an einem etwas versteckten Ort befindet. cu andreas ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] OGD (Wien) nützen
On 06.07.12 11:36, Stefan Tauner wrote: > ich habe ein wenig das gefühl, daß das wort "import" in der > österreichischen osm community ein ultrarotes tuch ist Naja, das sowieso. Aber auch sonst braucht man in AT Importe nicht. Details siehe meine Antwort an Boris grade. /al ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] OGD (Wien) nützen
On 06.07.12 12:11, Boris Cornet wrote: > Äh, nein, so würde ich das nicht sehen. Doch, so war meiner Erinnerung nach schon das Ergebnis der Podiumsdiskussion schon so in etwa: Kaum mehr Importe, wenn, nur unter größter Bedachtnahme und in "leeren" Gebieten. Kannst Du ein konkretes Beispiel nennen, welcher Import wo noch /denkbar/ wäre? Mir fällt da auch nach oftmaligem Nachdenken nix ein. > Aber der community tools zur Verfügung zu stellen, damit ein echter community import durchgeführt werden kann, das halte ich absolut für unterstützenswert Natürlich, Tools sind immer nützlich, nur kaum für Importe. Wenn, könnte ich mir Tools vorstellen auf den Gebieten: a) Darstellungen von Daten, die ein Vergleichen möglich machen, OSMI, kartenwerkstatt.at, Transparenz-Vergleiche oder Grundkarten zum Abmalen oder sowas. b) Vergleichstools. Genauso, wie wir mal gecheckt hatten, ob wir in Wien alle Straßen haben (sollten wir mal wieder tun... da sind noch einige Änderungen offen...), könnte man auch andere Dinge auf Vollständigkeit und/oder Lage prüfen. Es gibt ja sogar das Angebot, man könnte den Wegegraphen Wiens mit dem der Stadt vergleichen (da bestünde auch Interesse an einem Datenfluss in die andere Richtung), da fand sich bisher noch niemand, sich damit zu beschäftigen. c) Vielleicht wären auch Erweiterungen eines Editors möglich, das so einen Schritt-für-Schritt Vergleich (und auf Knopfdruck setzt man das Objekt oder so) ermöglichen... auch da helfen oft am ehesten Hintergrund-Karten... Aber nicht für einen, wie Du es formuliert hast, "echten community Import". Das halte ich für verlorene Liebesmüh (bei uns; oder in DE; oder so). >> ich habe seit meiner ersten mail versucht klar zu machen, daß es sich >> nicht um einen blinden, halb blinden, automatischen oder teuflischen >> import dreht, sondern um eine crowdgesourcte verifikation von OGD, die OGD zu verifizieren, liegt nicht im Interesse von OpenStreetMap. Wir wollen /unsere/ offenen Daten aktuell halten und die Genauigkeit erhöhen. Zu den Citybike Stationen: das funktioniert deshalb halbwegs einfach, weil es immer nur POIs sind. Alles andere ist oftmals z.B. ein Gebäude (bevor ich einen Gasthaus-POI setzte, zeichne ich das Gebäude ein...). > OSM funktioniert nach dem > Wiki-Prinzip, über kurz oder lang wären die schon wieder auf der > Straße gelandet, mit oder ohne OGD. OSM funktioniert aber /nicht/ nach dem "ich importiere mal irgendwas irgendwie und irgendwer richtet's dann schon wieder"-Prinzip, vergiss das nicht! ;) /al ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] OGD (Wien) nützen
On 07/06/2012 11:18 AM, Stefan Tauner wrote: On Fri, 06 Jul 2012 11:01:37 +0200 Norbert Wenzel wrote: On 07/06/2012 10:46 AM, Stefan Tauner wrote: On Thu, 05 Jul 2012 08:11:30 +0200 Frederik Ramm wrote: 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? Wenn jemand manuell von Bing abpaust, dann soll er das tun. Selbst wenn Armeen von Abpausern damit beschäftigt sind Bing abzumalen, werden sie nie so schnell sein, wie der eine Mapper, der seine Programmierkenntnisse nimmt, öffentliche Datenquellen konvertiert und einfach auf einen Schlag einen Haufen Daten in die Datenbank kopiert. Etwas ähnliches gilt für semiautomatische Lösungen wie "Drücke den Button um zu bestätigen, dass die Daten stimmen und übertrage automatisch". Die Chance dass irgendwer dann mein besonders schnell und "fleißig" sein zu müssen und einfach mal etwas mehr importiert, als er wirklich bestätigen kann, ist dann relativ groß. Solang der User also etwas Aufwand hat um die Daten einzutragen, ist er nicht so sehr in Versuchung doch nur einmal öfter zu bestätigen und schon bspw. einen neuen Bezirk "verbessert" zu haben. die gefahr besteht natürlich, aber die "lösung" kann ja nicht sein, allen beteiligten steine in den weg zu schmeißen, um sie davon abzuhalten blödsinn zu machen. aber genau weil diese gefahr besteht, wenn projekt-ferne personen mitarbeiten, will ich keinen direkten oder automatischen upload machen. Das hab ich gelesen und find ich auch gut. Die Kritik betrifft auch deine geplante App gar nicht. Aber die Grenze beim Import ist halt imo genau dort zu ziehen, wo ein automatisierter Import großer Datenmengen, die in Wahrheit niemanden interessieren (denn sonst wären sie schon längst in der Datenbank) stattfindet. Das Problem ist dass sich jemand für die Daten interessieren muss um sie aktuell halten zu können. Dazu können Review und QA Tools natürlich beitragen, das ist sicher keine schlechte Idee. Aber wenn ich mich beim Eintragen nur mit dem Eintragen an sich, nicht aber mit den Daten beschäftige, dann ist die Chance gering diese Daten als "meine" Daten anzusehen und sie entsprechend zu pflegen. (Im Übrigen denk ich auch dass mit QA und Review Tools ein automatisiertes Einkübeln großer Datenmengen als unfreundlich zu bezeichnen wäre, da er die wirkliche Arbeit auf die Leut in den QA Tools abwälzt.) ps: wenn man mich fragen würde, bräuchte osm einen review prozess ähnlich dem sichtungsmechanismus bei wikipedia oder bei projekten mit (zb gerrit-unterstütztem) code review. Grundsätzlich geb ich dir Recht, dass es QA Tools braucht, aber Wikipedia würde ich jetzt nicht unbedingt als gutes Beispiel sehen. Weder für die Community noch für die (zumindest teilweise beobachtete) Qualität des Reviewprozess. Norbert ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] OGD (Wien) nützen
On Fri, 6 Jul 2012 12:11:53 +0200 Boris Cornet wrote: > > bzgl sinnhaftigkeit kann ich nur jedem empfehlen die ogd zu den > > radabstellplätzen mittels conflation plugin mit den bestandsdaten zu > > vergleichen: zb sind viele der nodes *JETZT* in häusern und wären nach > > OGD koordinaten außerhalb. > > Lass uns jetzt nicht Erbsenklauben. OSM funktioniert nach dem > Wiki-Prinzip, über kurz oder lang wären die schon wieder auf der > Straße gelandet, mit oder ohne OGD. mit erbsen zählen hat das nichts zu tun, ich war wirklich positiv überrascht, wie sehr die OGD daten die bestandsdaten verbessern würden und wie gut das plugin funktioniert und das visualisiert. das ist wirklich sehenswert und könnte den einen oder anderen von der sinnhaftigkeit von imports^Hder verwendung von ogd überzeugen ;) -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] OGD (Wien) nützen
Schönen guten Tag! > On Fri, 06 Jul 2012 11:15:57 +0200 Andreas Labres wrote: >> Importe - und das haben wir vor einem Jahr auf der SotM-EU ausgiebigst >> diskutiert - machen heute kaum mehr Sinn. Äh, nein, so würde ich das nicht sehen. Eine Grundskepsis ist gut (die haben wir dank des plan.at Desasters ohnehin), auch haben die Befürchtungen, dass man mit Imports das community building stört, durchaus eine Berechtigung, siehe TIGER (USA) oder cadastre (Frankreich). Aber der community tools zur Verfügung zu stellen, damit ein echter community import durchgeführt werden kann, das halte ich absolut für unterstützenswert, und es hilft auch, die Userbasis zu verbreitern. Heute (6. Juli) um 11:36 tippte Stefan Tauner: > ich habe seit meiner ersten mail versucht klar zu machen, daß es sich > nicht um einen blinden, halb blinden, automatischen oder teuflischen > import dreht, sondern um eine crowdgesourcte verifikation von OGD, die > man dann als "primärquelle" zum mappen verwenden kann, fall sinnvoll > mit tool/plugin/script unterstützung. So habe ich das auch verstanden, und ich finde den Ansatz gut. An Details wird man feilen müssen (Integration der Bestandsdaten, Konfliktmanagement, möglicherweise auch fake-data). Automatisch kann - fürchte ich - nichts gehen, denn die durchschnittliche Genauigkeit der Karte liegt im besten Fall bei +/- 5m (und das reicht!), im Schlimmsten bei +/-50m (plan.at). So rutscht dann eben mal ein cm-genau verorteter Radständer in ein Haus hinein. > bzgl sinnhaftigkeit kann ich nur jedem empfehlen die ogd zu den > radabstellplätzen mittels conflation plugin mit den bestandsdaten zu > vergleichen: zb sind viele der nodes *JETZT* in häusern und wären nach > OGD koordinaten außerhalb. Lass uns jetzt nicht Erbsenklauben. OSM funktioniert nach dem Wiki-Prinzip, über kurz oder lang wären die schon wieder auf der Straße gelandet, mit oder ohne OGD. -- Mit besten Grüßen, Boris ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] OGD (Wien) nützen
On Fri, 06 Jul 2012 11:15:57 +0200 Andreas Labres wrote: > On 06.07.12 10:46, Stefan Tauner wrote: > > der übergang ist halt fließend. wo fängt der import an und die nutzung auf? > > PMJI, aber mir fällt auf (bzw. vermute ich), Du siehst das aus einer falschen > Sichtweise (und ich bin da völlig bei Frederik). > > Es geht hier nicht um eine Lizenzfrage. Konkretes Beispiel: die Bezirksgrenzen > der Wiener Bezirke. Gäbe es auf wien.at, man könnte auf den Gedanken kommen, > man > importiert sie einfach. ABER: Das darfst Du nicht tun! Nicht aus > lizenzrechtlichen Gründen. Sondern aus Sicht der Community, weil da hat sich > jemand genau überlegt, wo er Straßenmitten nutzt, wo er eigene Ways zeichnet. > Da > darf man eben nicht einfach die Arbeit anderer zerstören (löschen). > > Boris wir Dir das eh schon erläutert haben, es gibt immer die Fragen: was gibt > es schon?, wie schließt Neues an Vorhandenes an?, was ist mit der > Genauigkeit?, > wie kriegt man die Schnittstelle zwischen Neuem und Vorhandenem hin > (automatisch? manuell?). -- Es wird zB oft so sein, dass man beim (manuellen) > Eintragen neuer Dinge feststellt, dass alte Dinge in OSM ungenau sind, daher > "rückt man das vielleicht auch gleich zurecht". > > Je dichter die aktuell vorhandenen Daten sind, umso unmöglicher ist es, > automatisiert zu importieren. Und wir sind vermutlich in ganz AT auf dem > Stand, > dass man eben nicht mehr "einfach so" importieren darf. > > Es wird vielleicht thematische Ausnahmen geben. Z.B. die Citybike Stationen > sind > zu einem Gutteil von Andreas M., d.h. werden mit dem Lizenzwechsel wegfallen. > Da > kann man sich überlegen, die OGD Daten zu importieren. Aber auch da wird es > vielleicht Punkte geben, die jemand anderer eingetragen hat -> Vorsicht vor > Doubletten! Was ist genauer? (auch: was passt besser zum Kartenbild: es macht > keinen Sinn, eine Station, die auf dem Gehsteig ist, in der Karte mitten auf > einem Haus einzuzeichnen, auch wenn /diese/ Koordinate "die richtige" wäre...) > > Importe - und das haben wir vor einem Jahr auf der SotM-EU ausgiebigst > diskutiert - machen heute kaum mehr Sinn. ich habe ein wenig das gefühl, daß das wort "import" in der österreichischen osm community ein ultrarotes tuch ist und bei dessen auftreten alles andere ausgeblendet wird. :( ich habe seit meiner ersten mail versucht klar zu machen, daß es sich nicht um einen blinden, halb blinden, automatischen oder teuflischen import dreht, sondern um eine crowdgesourcte verifikation von OGD, die man dann als "primärquelle" zum mappen verwenden kann, fall sinnvoll mit tool/plugin/script unterstützung. bzgl sinnhaftigkeit kann ich nur jedem empfehlen die ogd zu den radabstellplätzen mittels conflation plugin mit den bestandsdaten zu vergleichen: zb sind viele der nodes *JETZT* in häusern und wären nach OGD koordinaten außerhalb. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] OGD (Wien) nützen
On Fri, 06 Jul 2012 11:01:37 +0200 Norbert Wenzel wrote: > On 07/06/2012 10:46 AM, Stefan Tauner wrote: > > On Thu, 05 Jul 2012 08:11:30 +0200 > > Frederik Ramm wrote: > >> 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? > > Wenn jemand manuell von Bing abpaust, dann soll er das tun. Selbst wenn > Armeen von Abpausern damit beschäftigt sind Bing abzumalen, werden sie > nie so schnell sein, wie der eine Mapper, der seine > Programmierkenntnisse nimmt, öffentliche Datenquellen konvertiert und > einfach auf einen Schlag einen Haufen Daten in die Datenbank kopiert. > > Etwas ähnliches gilt für semiautomatische Lösungen wie "Drücke den > Button um zu bestätigen, dass die Daten stimmen und übertrage > automatisch". Die Chance dass irgendwer dann mein besonders schnell und > "fleißig" sein zu müssen und einfach mal etwas mehr importiert, als er > wirklich bestätigen kann, ist dann relativ groß. > > Solang der User also etwas Aufwand hat um die Daten einzutragen, ist er > nicht so sehr in Versuchung doch nur einmal öfter zu bestätigen und > schon bspw. einen neuen Bezirk "verbessert" zu haben. die gefahr besteht natürlich, aber die "lösung" kann ja nicht sein, allen beteiligten steine in den weg zu schmeißen, um sie davon abzuhalten blödsinn zu machen. aber genau weil diese gefahr besteht, wenn projekt-ferne personen mitarbeiten, will ich keinen direkten oder automatischen upload machen. ps: wenn man mich fragen würde, bräuchte osm einen review prozess ähnlich dem sichtungsmechanismus bei wikipedia oder bei projekten mit (zb gerrit-unterstütztem) code review. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] OGD (Wien) nützen
On 06.07.12 10:46, Stefan Tauner wrote: > der übergang ist halt fließend. wo fängt der import an und die nutzung auf? PMJI, aber mir fällt auf (bzw. vermute ich), Du siehst das aus einer falschen Sichtweise (und ich bin da völlig bei Frederik). Es geht hier nicht um eine Lizenzfrage. Konkretes Beispiel: die Bezirksgrenzen der Wiener Bezirke. Gäbe es auf wien.at, man könnte auf den Gedanken kommen, man importiert sie einfach. ABER: Das darfst Du nicht tun! Nicht aus lizenzrechtlichen Gründen. Sondern aus Sicht der Community, weil da hat sich jemand genau überlegt, wo er Straßenmitten nutzt, wo er eigene Ways zeichnet. Da darf man eben nicht einfach die Arbeit anderer zerstören (löschen). Boris wir Dir das eh schon erläutert haben, es gibt immer die Fragen: was gibt es schon?, wie schließt Neues an Vorhandenes an?, was ist mit der Genauigkeit?, wie kriegt man die Schnittstelle zwischen Neuem und Vorhandenem hin (automatisch? manuell?). -- Es wird zB oft so sein, dass man beim (manuellen) Eintragen neuer Dinge feststellt, dass alte Dinge in OSM ungenau sind, daher "rückt man das vielleicht auch gleich zurecht". Je dichter die aktuell vorhandenen Daten sind, umso unmöglicher ist es, automatisiert zu importieren. Und wir sind vermutlich in ganz AT auf dem Stand, dass man eben nicht mehr "einfach so" importieren darf. Es wird vielleicht thematische Ausnahmen geben. Z.B. die Citybike Stationen sind zu einem Gutteil von Andreas M., d.h. werden mit dem Lizenzwechsel wegfallen. Da kann man sich überlegen, die OGD Daten zu importieren. Aber auch da wird es vielleicht Punkte geben, die jemand anderer eingetragen hat -> Vorsicht vor Doubletten! Was ist genauer? (auch: was passt besser zum Kartenbild: es macht keinen Sinn, eine Station, die auf dem Gehsteig ist, in der Karte mitten auf einem Haus einzuzeichnen, auch wenn /diese/ Koordinate "die richtige" wäre...) Importe - und das haben wir vor einem Jahr auf der SotM-EU ausgiebigst diskutiert - machen heute kaum mehr Sinn. /al ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] OGD (Wien) nützen
On 07/06/2012 10:46 AM, Stefan Tauner wrote: On Thu, 05 Jul 2012 08:11:30 +0200 Frederik Ramm wrote: 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? Wenn jemand manuell von Bing abpaust, dann soll er das tun. Selbst wenn Armeen von Abpausern damit beschäftigt sind Bing abzumalen, werden sie nie so schnell sein, wie der eine Mapper, der seine Programmierkenntnisse nimmt, öffentliche Datenquellen konvertiert und einfach auf einen Schlag einen Haufen Daten in die Datenbank kopiert. Etwas ähnliches gilt für semiautomatische Lösungen wie "Drücke den Button um zu bestätigen, dass die Daten stimmen und übertrage automatisch". Die Chance dass irgendwer dann mein besonders schnell und "fleißig" sein zu müssen und einfach mal etwas mehr importiert, als er wirklich bestätigen kann, ist dann relativ groß. Solang der User also etwas Aufwand hat um die Daten einzutragen, ist er nicht so sehr in Versuchung doch nur einmal öfter zu bestätigen und schon bspw. einen neuen Bezirk "verbessert" zu haben. Norbert ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] OGD (Wien) nützen
On Thu, 05 Jul 2012 08:11:30 +0200 Frederik Ramm 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 , 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 > 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 sel
Re: [Talk-at] OGD (Wien) nützen
Den Ansatz die Importe mit dem Handy zu kontrollieren finde ich gut. Eine App ähnlich c:geo sollte dafür geeignet sein, nur dass diese leider nie platformunabhängig sind. Ich würde da ein Browser-Interface ähnlich openstreetbugs bevorzugen (ich weiß, reden ist leicht, programmieren dann die Arbeit). Mit Kommentarfunktion und einem "checked" Button. Dann "fehlt" nur noch eine Lösungen um doppelte Eintragungen zu verhindern. Und da sieht man schon an der wheelmap.org [1], dass dann ein Import immer nur sehr schleppend läuft. LG Jimmy [1] http://wiki.openstreetmap.org/wiki/Import_Wheelmap_Orte ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] OGD (Wien) nützen
Hallo, 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. 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 , ich hab bloss auf den Button gedrueckt". Solange das einigermassen gewaehrleistet ist, sind wir ueber jede zusaetzliche Datenquelle oder zusaetzliche Hilfsmittel fuer Mapper froh! 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). Es spricht sicher nichts dagegen, sowas auch als einfache Android-App zu haben - Du gehst irgendwo vorbei und das Ding piepst und sagt: "Laut Quelle 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. 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 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. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
[Talk-at] OGD (Wien) nützen
hi (für alle, die am vereinstreffen anwesend waren: ich war der gast). ich möchte als erstes voraus schicken, daß mir die problematik mit imports bewußt ist, ich mir auch das video von letztem jahr vollständig angesehen habe und auch die argumente in bezug auf das community-buildung aufgrund meiner erfahrung in der FOSS-entwicklung sehr gut nachvollziehen kann. ich bin allerdings mit dem (publiziertem bzw von mir so verstandenem) schluß nicht einverstanden, daß imports per se eine schlechte sache sind (man könnte darüber streiten, ob das wirklich der .at-community- konsens ist, aber diverse flames auf dieser ml zu mails, die "imports" nur am rande erwähnen, legen dies schon nahe ;). mMn sind schon bestehende datenbanken eine ausgezeichnete möglichkeit osm zu erweitern, allerdings unter der voraussetzung, daß die daten im detail verifiziert werden. aus diesem punkt ergibt sich dann auch automatisch, das eine ausreichende community vorhanden sein muß, um das umzusetzen. allerdings muß diese community nicht notwendigerweise dem entsprechen, was "echte" mapper als solche sehen würden. ähnlich wie in der open source szene, braucht es nicht nur die alteingesessenen hardcore geeks, sondern projekte können auch sehr von menschen mit anderen interessen profitieren, wenn sie diese richtig einbinden. damit kommen wir zu einem weiteren punkt, den ich ansprechen will. osm editieren ist nicht einfach. mal abgesehen von gui-unzulänglichkeiten der verschiedenen editoren, muß man sehr viel zeit in das richtige tagging und überhaupt wissensbeschaffung im vorfeld investieren, um wirklich positiv beizutragen. ich möchte helfen, beides (integration von fremddaten und community erweiterung) in eine positive richtung zu entwickeln. meine idee ist eine android app, mit der (fast) ein jeder verschiedene fremddaten verifizieren und berichtigen kann. diese datenpunkte können dann mit den bestandsdaten in osm abgeglichen oder importiert werden, falls sie noch nicht vorhanden sind. das interface soll ähnlich der live map von c:geo sein (eine, nein *die* geocaching app für android): im hintergrund befindet sich eine karte auf der überlagert datenpunkte anklickbar dargestellt werden (vgl screenshot [1]). wenn man einen dieser punkte anklickt, gibt es die möglichkeit die verschiedenen attribute zu verifizieren, zu korrigieren, einen freitext als kommentar hinzuzufügen und das ganze dann zu publizieren. was damit dann genau passiert, ist davon abhängig, wieviel hilfe ich bekomme. grundsätzlich wäre es optimal aus den daten upload-fähige changesets zu generieren, die dann nur mehr von einem "richtigen" mapper gecheckt und upgeloadet werden müssen. denkbar wäre dabei natürlich auch, daß einzelne datenpunkte mehrfach verifiziert werden müssen und dann automatisch upgeloadet werden, sofern keine bestandsdaten betroffen sind (nicht ganz einfach fest zu stellen). in einer ersten version könnten die ergebnisse auch einfach als text mail verschickt werden. der große vorteil liegt darin, daß man nicht selbst vor ort sein muß und das verifizieren der realität crowdsourcen kann und, daß man genau weiß, wo man nach neuen daten suchen muß. damit könnte man nicht nur weniger technikaffine menschen ansprechen und ihnen helfen beizutragen, sondern auch "echten" mappern denkanstöße geben, wo es sich lohnt mal genauer hin zu sehen. ich wollte mich als erstes auf die fahrradstellanlagen[2] konzentrieren, allerdings gibts da ein kleines problem[3]. dh momentan wären "nur" die koordinaten verifizierbar, da sonst keine daten vorhanden sind (adresse ist mMn uninteressant). das hätte man allerdings mit einer "finde mir einen (rad)parkplatz"-app verbinden können, was marketing-mäßig interessant gewesen wäre... alternativ könnte ich mir vorstellen eine auswahl der typen der "donauinsel" daten[4] zu bearbeiten. zu denen hab ich persönlich einen bezug, da ich vor 2 jahren die schwimmpontons der neuen donau in osm eingezeichnet habe :) WC-Anlagen, spielplätze wären auch noch alternativen (bzw erweiterungsmöglichkeiten) und ich bin sicher es gibt noch mehr, mal abgesehen von nationalen und internationelen OGD-beständen... momentan arbeite ich an der prototypen-android app (meine erste). kartendarstellung (offline mapsforge .map aus .osm generiert, tiles download von osm und ocm) funktioniert bereits, aber das ist ja nur der anfang... wo ich auf jeden fall hilfe brauchen könnte: - was sind eure erfahrungen mit den OGD wien daten im allgemeinen? - sind alle datenformate gleichwertig? ich neige dazu, die csv files zu parsen, statt den komplexeren formaten. für so einfache datensätze wie bei den fahrradabstellplätzen ist das sicher gut genug, aber bei anderen vl nicht. - bei ideen und der umsetzung der weiterverarbeitung der gesammelten daten. eine zentrale datenbank mit einem webfrontend oder einem josm plugin, wäre mein wunschtraum :) - falls android veteranen unter euch sind, können die am client sicher auch helfen. was hält ihr grundsätzlich
