Quo vadis, OSM+?

Dieser Diskussionsstrang ist eine Fortsetzung der gleichnamigen Unterhaltung auf Trello.

@mi1 Könntest du onYOURway in zwei Repositories für jeweils Client und Server modularisieren? Dann könnte ich bequem forken und einen PR mit einem Datenadapter beisteuern. Benutzt du eigentlich PostGIS als geographische Datenbank?


“Einbringen neuer Nodes in das dezentrale Netzwerk von Geodaten im Feld Sharing Economy” klingt cool aber was heisst das konkret?

Als Anwendungsgebiet im Bereich “Web-Publishing” soll damit gesagt sein, dass unter Berücksichtigung der Fünf Linked Open Data Sterne wenigstens eine API zur Verfügung steht, mit der die Daten wandern können. Das semantische Sahnehäubchen ist dann die Kür.


Oder: inwiefern beschäftigst Du Dich mit Ziel 1? Ich hatte verstanden dass Du vor allem auf das Backend fokussiert?

Die von mir anvisierten “Endnutzer” (vielleicht war das Wort etwas unscharf gewählt) sind der Kreis von frühen Benutzern der Prototypen, um deren Anforderungen herauszukristallisieren und frühe Probleme abzufangen. Auch wird in einem solchen “internen Test” die Dokumentation wachsen. Reibung schafft Erfahrung ;).


Worauf beziehen sich die letzten zwei Punkte/Fragen? Welcher Wiederspruch aus wecher Frage?

Auf deine Meldung vom 7. Mai um 04:38:

Was hat die Beschreibung der API mit dem Thema mapping zu tun? Mir fehlt noch ein entscheidender Punkt.


Und…welche gute Bezahlung? Bis dato ist meine Arbeit unbezahlt. Vielleicht kannst Du mein Verständnis erhellen.

Huch, damit bin ich vielleicht auch etwas zu weit gegangen. Ich meinte damit, dass ich als Student und vor allem Autodidakt mitunter eigene Zugänge zu den Technologien anwende, die nicht zwingendermaßen mit der wirklichen Welt übereinstimmen. Ich taste mich Stück für Stück weiter und kann leider nicht auf einen zehnjährigen professionellen Hintergrund zurückblicken (okay, fünf). Dann war auch meine missverständliche Annahme, dass du von deinen Aufträgen gut leben kannst.


Summa summarum ist festzuhalten, dass ich heute (!) den Stack eingefroren habe, ergo für mich beschlossen habe meiner Intuition zu folgen, um im Endeffekt bequem mit der GeoCouch zu operieren:

  • uMap (auf (Geo)Django aufsetzend) als Bearbeitungs + Veröffentlichungsgrundlage
  • CouchDBKit als Python-CouchDB Adapter
  • und schließlich ein auf letzterem basierender Backend-Adapter für Geodjango, den ich werde schreiben müssen.

Sobald die Daten erst einmal in der DB sind, kann ich auch JSON-LD oder vielleicht sogar GeoJSON-LD ausspucken. Insofern ist der Document Store aus meiner Sicht ein guter Kompromiss, um zwischen der relationalen und der quad store Welt zu vermitteln.


Im weiteren Verlauf möchte ich natürlich auf die Dokumente direkt per GeoCouch zugreifen und in verschiedene Kontexte (=Karten) bringen (können). Auch liegt es mir sehr am Herzen, dass wir eine stabile, aber doch erweiterbare Datenbank für die MMM-Metadaten benutzen, die auch konventionell angesprochen werden kann. Für reine Quad Stores ist es einfach noch zu früh. Aber ein bisschen Semantik wäre später eben auch nicht schlecht.

Kompromisse an allen Ecken, aber dafür wenigstens die Anwendungsgebiete und Aufgaben klar getrennt.