Die "Kooperation" existiert nur in der Pressemitteilung von OpenAddresses, die Golem abgeschrieben hat. In der Realität ist das momentan eine Einbahnstraße:
OpenAddresses hat Adressdaten aus OpenStreetMap übernommen. Das ist vermutlich unter Verletzung der Lizenzbestimmungen geschehen (vgl. [1] - Nichtbeachtung der Share-Alike-Bestimmung).
Ein Rückfluss nach OpenStreetMap existiert momentan nicht - er ist nach Aussage [2] "in Arbeit". Wie dabei die Probleme aufgrund der unterschiedlichen Datenabbildung ([3]) und der in OpenAddresses anders als bei OSM anscheinend fehlenden Verknüpfung von Adressen mit Gebäuden und POI statt einer bloßen Koordinate gelöst werden sollen, ist mir ohnehin unklar.
OpenAddresses ist wirklich sehr einfach und man kann mitmachen ohne sich registrieren zu müssen, sogar ohne nach draussen zu gehen: die Adressen, die man kennt kann man leicht eingeben. OpenAddresses ist daher wirklich aufs Sammeln von Adressen (nicht persönlichen Daten!) gedacht und ich denke, dass OSM davon auch profitieren wird. Ausserdem bietet OpenAddresses auch Services wie Geokodierung und Reverse Geokodierung - was für gewisse Anwendungen sehr hilfreich sein kann - ohne dass man sich die Daten zuerst runterladen und die Applikation dann selber bauen muss.
was ist daran http://osm.org/go/0JBl6pwRt- oder hier http://osm.org/go/0JEccLjir- ungenau? wenn die Adressen wirklich in OSM übertragen werden haben wir wohl eher doppelte Nodes durch einen "Import" und somit mehr Arbeit die nicht wirklich spass macht. Beispiele gibt es genug für schlechte Imports die nur einen deutlichen Mehraufwand bedeuten und User eher resignieren lässt (USA und Österreich mit ihren Straßen, Dänemark mit den Adressen....). Momentan sind etliche User damit beschäftigt doppelte Nodes aus der Weltkarte zu entfernen wegen dieser tollen Imports
http://matt.dev.openstreetmap.org/dupe_nodes/?zoom=5&lat=49.19977&lon=15.57872&layers=BT dank an die Importeure....
Also ich verstehe das auch nicht.. habe kürzlich einige Adressen in OSM eingetragen und zwar zunächst die Umrisse der Gebäude eingezeichnet und dann die Hausnummern, Straßennamen, PLZ und Ort für die Gebäude angegeben. Genauer kann man das einfach nicht machen.
Auch wenn man keine Lust oder nicht die nötigen Werkzeuge und Informationen zum Einzeichnen der Umrisse hat, so kann man immer noch einen beliebigen Punkt in der Karte mit einer Hausnummer versehen.
Meiner Meinung nach ist das neue Projekt überflüssig!
Von Hans-Jörg Stark am Di, 30. März 2010 um 15:47 #
Überflüssig würde ich nicht sagen - denn: OSM verlangt eine Registrierung und ist auch sonst nicht "ganz einfach" zu bedienen. da ist bzgl. user-friendliness doch ein grosser Unterschied zwischen OSM und OA. Auch bietet OA gleich noch eine API für die NUTZUNG der Daten - sonst macht die Erfassung ja auch nicht viel Sinn. Die Frage ob nötig / überflüssig - interessant! Weil rund um OSM gibt es ja bspw. auch nicht nur EINEN Editor und verschiedene Tools werden eingesetzt, obwohl hinsichtlich ihrer Funktionalität auch tlw. überlappend. Jammern da die Anwender auch so von wegen "überflüssig"??
Von maestro_alubia am Mi, 31. März 2010 um 11:27 #
Mehrere Editoren machen durchaus Sinn, denn jeder hat schließlich seine eigenen Vorlieben. Aber all diese Editoren greifen auf die selbe Datenbank zu! Ich fände es nicht kontraproduktiv, wenn OA nur eine andere Oberfläche und eine andere API auf die OSM-Daten böte, aber eine eigene Datenbank finde ich schon sehr sinnlos.
Den Zwang zur Registrierung bei OSM sehe ich weniger problematisch, das sollte keine Hürde für Leute sein, die wirklich zum Projekt beitragen wollen.
Von Hans-Jörg Stark am Do, 1. April 2010 um 09:22 #
Nun, die Erfahrung hat uns eines bessere belehrt: wir haben verg. Jahr eine Umfrage unter OSM und OA (=VGI volunteered geographic information) Anwendern durchgeführt bei der 421 vollständige Interviews durchgeführt wurden. Eines der Ergebnisse war: 95% der VGI user waren Männer mit einem auffällig hohen Bildungsniveau. An der FOSSGIS in Osnabrück vor ein paar Wochen haben wir das diskutiert und auch die OSM Leute haben zugegeben, dass für das Mitmachen bei OSM doch eine beträchtliche (technische) Hürde überwunden werden muss. Man kann nicht jede oder jeden einfach an einen PC setzen und sagen 'mal mal mit bei OSM'. Das ist zu kompliziert (das ist kein Vorwurf an OSM!!!). Und da meine ich, dass OA da wesentlich weniger von Anwendern verlangt. Was die Datenhaltung betrifft. Ja, da kann man wirklich drüber diskutieren. Der Hauptgrund, weshalb OA (vorerst) die Daten separat hält ist einzig die Performance für die Dienste, die wir rund um OA anbieten (vgl. http://code.google.com/p/openaddresses/wiki/RESTService) und die sind doch ordentlich schnell. Auch Openrouteservice (http://129.206.229.146/openrouteservice) greift nicht nativ auf die OSM Daten zurück, sondern prozessiert diese und speichert sie separat! Die Datenstruktur von OSM ist nicht ausgelegt für solche Dienste. Daher spricht schon einiges dafür, dass zwar Redundanz in Kauf genommen, dafür aber Performance gewonnen wird.
Das macht doch aber nur Sinn, wenn diese Adressen dann auch in OpenStreemap zu sehen sind. Warum nicht beide Projekte vereinen?
Ich kann mir vorstellen, dass beiden ein anderes Datenformat als Grundlage haben.
OpenAddresses braucht weniger Speicher in der Datenbank und dürfte daher effizienter sein.
Beides verknüpft dürfte zu einer sehr effektiven Routenplanung führen.
Golem http://www.golem.de/1003/74141.html schreibt, dass beide Projekte kooperieren.
Ich glaube das jetzt mal einfach.
Die "Kooperation" existiert nur in der Pressemitteilung von OpenAddresses, die Golem abgeschrieben hat. In der Realität ist das momentan eine Einbahnstraße:
OpenAddresses hat Adressdaten aus OpenStreetMap übernommen. Das ist vermutlich unter Verletzung der Lizenzbestimmungen geschehen (vgl. [1] - Nichtbeachtung der Share-Alike-Bestimmung).
Ein Rückfluss nach OpenStreetMap existiert momentan nicht - er ist nach Aussage [2] "in Arbeit". Wie dabei die Probleme aufgrund der unterschiedlichen Datenabbildung ([3]) und der in OpenAddresses anders als bei OSM anscheinend fehlenden Verknüpfung von Adressen mit Gebäuden und POI statt einer bloßen Koordinate gelöst werden sollen, ist mir ohnehin unklar.
OpenAddresses ist wirklich sehr einfach und man kann mitmachen ohne sich registrieren zu müssen, sogar ohne nach draussen zu gehen: die Adressen, die man kennt kann man leicht eingeben.
OpenAddresses ist daher wirklich aufs Sammeln von Adressen (nicht persönlichen Daten!) gedacht und ich denke, dass OSM davon auch profitieren wird. Ausserdem bietet OpenAddresses auch Services wie Geokodierung und Reverse Geokodierung - was für gewisse Anwendungen sehr hilfreich sein kann - ohne dass man sich die Daten zuerst runterladen und die Applikation dann selber bauen muss.
was ist daran http://osm.org/go/0JBl6pwRt- oder hier http://osm.org/go/0JEccLjir- ungenau? wenn die Adressen wirklich in OSM übertragen werden haben wir wohl eher doppelte Nodes durch einen "Import" und somit mehr Arbeit die nicht wirklich spass macht. Beispiele gibt es genug für schlechte Imports die nur einen deutlichen Mehraufwand bedeuten und User eher resignieren lässt (USA und Österreich mit ihren Straßen, Dänemark mit den Adressen....). Momentan sind etliche User damit beschäftigt doppelte Nodes aus der Weltkarte zu entfernen wegen dieser tollen Imports
http://matt.dev.openstreetmap.org/dupe_nodes/?zoom=5&lat=49.19977&lon=15.57872&layers=BT
dank an die Importeure....
Gruß
Jürgen
Also ich verstehe das auch nicht.. habe kürzlich einige Adressen in OSM eingetragen und zwar zunächst die Umrisse der Gebäude eingezeichnet und dann die Hausnummern, Straßennamen, PLZ und Ort für die Gebäude angegeben. Genauer kann man das einfach nicht machen.
Auch wenn man keine Lust oder nicht die nötigen Werkzeuge und Informationen zum Einzeichnen der Umrisse hat, so kann man immer noch einen beliebigen Punkt in der Karte mit einer Hausnummer versehen.
Meiner Meinung nach ist das neue Projekt überflüssig!
Überflüssig würde ich nicht sagen - denn: OSM verlangt eine Registrierung und ist auch sonst nicht "ganz einfach" zu bedienen. da ist bzgl. user-friendliness doch ein grosser Unterschied zwischen OSM und OA.
Auch bietet OA gleich noch eine API für die NUTZUNG der Daten - sonst macht die Erfassung ja auch nicht viel Sinn.
Die Frage ob nötig / überflüssig - interessant! Weil rund um OSM gibt es ja bspw. auch nicht nur EINEN Editor und verschiedene Tools werden eingesetzt, obwohl hinsichtlich ihrer Funktionalität auch tlw. überlappend. Jammern da die Anwender auch so von wegen "überflüssig"??
Mehrere Editoren machen durchaus Sinn, denn jeder hat schließlich seine eigenen Vorlieben. Aber all diese Editoren greifen auf die selbe Datenbank zu! Ich fände es nicht kontraproduktiv, wenn OA nur eine andere Oberfläche und eine andere API auf die OSM-Daten böte, aber eine eigene Datenbank finde ich schon sehr sinnlos.
Den Zwang zur Registrierung bei OSM sehe ich weniger problematisch, das sollte keine Hürde für Leute sein, die wirklich zum Projekt beitragen wollen.
Nun, die Erfahrung hat uns eines bessere belehrt: wir haben verg. Jahr eine Umfrage unter OSM und OA (=VGI volunteered geographic information) Anwendern durchgeführt bei der 421 vollständige Interviews durchgeführt wurden. Eines der Ergebnisse war:
95% der VGI user waren Männer mit einem auffällig hohen Bildungsniveau.
An der FOSSGIS in Osnabrück vor ein paar Wochen haben wir das diskutiert und auch die OSM Leute haben zugegeben, dass für das Mitmachen bei OSM doch eine beträchtliche (technische) Hürde überwunden werden muss. Man kann nicht jede oder jeden einfach an einen PC setzen und sagen 'mal mal mit bei OSM'. Das ist zu kompliziert (das ist kein Vorwurf an OSM!!!). Und da meine ich, dass OA da wesentlich weniger von Anwendern verlangt.
Was die Datenhaltung betrifft. Ja, da kann man wirklich drüber diskutieren. Der Hauptgrund, weshalb OA (vorerst) die Daten separat hält ist einzig die Performance für die Dienste, die wir rund um OA anbieten (vgl. http://code.google.com/p/openaddresses/wiki/RESTService) und die sind doch ordentlich schnell.
Auch Openrouteservice (http://129.206.229.146/openrouteservice) greift nicht nativ auf die OSM Daten zurück, sondern prozessiert diese und speichert sie separat! Die Datenstruktur von OSM ist nicht ausgelegt für solche Dienste. Daher spricht schon einiges dafür, dass zwar Redundanz in Kauf genommen, dafür aber Performance gewonnen wird.