Geodesk ... eine neue geospatiale Datenbank für OSM-Daten?

Im Wiki wurde wohl ganz frisch diese Seite angelegt: GeoDesk

Demnach wurde die Version 0.1 dieser geospatialen Datenbank jetzt erst am 19.10.2022 veröffentlicht.

Vorteile sollen sein: Java-basiert für alle Plattformen, maßgeschneidert auf OSM-Daten, sehr schneller Import, schlanke Dateigrößen, geringe Hardware-Ansprüche

Kann das jemand testweise bestätigen? (OSM-Datenbanken sind leider aktuell nicht mein Thema)

Quellcodes auf GitHub verfügbar … @wambacher : wäre das was für die Software-Watchlist?

2 Likes

Meine Browser-History sagt mir, dass ich die geodesk.com Seite vor ziemlich genau einem halben Jahr schon mal besucht haben soll. Damals sah das alles sehr ähnlich aus, alle Links führten ins Nirgendwo, IIRC. Auch die Github-Seite sieht noch recht leer aus, außer Doku und Webseite finde ich da keinen Code: clarisma · GitHub

1 Like

Moin,

wollte das Teil gerade am heutigen “Watchlist-Sunday” in die OSM-Watchlist aufnehmen, aber da ist ja wirklich Tote Hose.

Nun denn, kommt jetzt in die Watchlist-Watchlist (mein Todo) rein :wink:

Gruß
walter

3 Likes

Seit gestern ist jetzt auch der Code da… und seit heute ein Announcement: GeoDesk: A fast and compact database engine for OSM features

2 Likes

Ich hab mal einen Germany import probiert. Der lief hier in 5 Minuten, 10 Sekunden durch und hat im Schnitt ~ 8 CPU belegt und 20G Speicher.

2 Likes

Hallo,

Erstmals danke für euer Interesse, und auch vielen Dank für eure Geduld, unsere erste Veröffentlichung dauerte länger als geplant. Mein Deutsch ist leider nur gut genug zu einer Radtour am Rhein, deshalb werde ich meinen Beitrag auf Englisch fortsetzen…

Now that our first release is out, I wanted to add some quick comments regarding our roadmap.

Our focus for Version 0.2 is shipping the features we’ve had to defer, namely:

  • Broad support of spatial predicates: Currently, only intersects, within and maxMetersFrom are supported. Version 0.2 will support a richer set (overlaps, contains, etc.). Unlike bbox queries, the Filter-based queries haven’t seen much in terms of optimization, so performance should increase as well.

  • Ability to query relation members based on role.

  • Regex support for queries.

  • Simplifications and general cleanup of the API.

  • Maintenance commands for the GOL tool: copy, remove, retain and vacuum

On a longer time horizon (more than 3 months out), we plan to support the ability to incrementally update GOLs, which has been the most requested feature so far (but is also among the more complex ones).

Some things we don’t plan to implement:

  • Metadata: A GeoDesk import discards edit metadata (user and timestamp of last change, object version). If there’s enough demand, we may offer an option to convert metadata into tags, but we don’t foresee adding metadata support to the API itself.

  • Historical data: GOLs aren’t designed to store multiple versions of features. Users can query multiple GOLs of different versions and compare the results, but there are no plans to offer built-in support.

We don’t intend GeoDesk to be all things to all people. It is aimed at users who need to work with larger datasets than what they can (or should) download from Overpass, but who don’t want to (or are unable to) deal with the complexity and system requirements of a full-blown PostGIS setup. Our key focus continues to be on keeping hardware requirements to a minimum, in order to lower the barriers to entry for people developing OSM-based applications, and thereby drive higher adoption of OSM.

We’d love to hear your thoughts (and would be honored to be included in the Wambacher OSM-Watchlist). We always welcome questions, new issues on Github (and comments on existing ones). That’s especially true for roadmap items, as feedback helps us prioritize and enables our user community to shape the direction of the project.

Thanks again, and keep us posted!

8 Likes

Wird wirklich java 16 benötigt?

1 Like

@chris66 : welche Version vom Java hättest du denn zur Verfügung?
Wenn es z.B. die 15er ist, hast du mal probiert, z.B. das gol-tool zu starten? Müsste es dann Fehlermeldungen geben?


Wohl auch ganz frisch gibts eine neue Version “GeoDesk 0.1.2 Early Access” … siehe https://github.com/clarisma/geodesk/releases

1 Like

Für JOSM hab ich java11. Das jdk17 habe ich mir jetzt einfach mal lokal in den gol-tool Ordner getan. Germany Bau läuft gerade.

EDIT: Built germany.gol in 9m 9s

1 Like

BUG?
bin\gol query germany "na[amenity=telephone]" -f xml
ergibt folgende Fehlermeldung:
f: Expected value (csv|xml|geojson|...)

We ended up deferring OSM-XML output to Version 0.2, but I forgot to mark it in the documentation.

Danke, allerdings funzt --format=xml bei mir problemlos, nur die Kurzform geht net.
Installiert ist die 0.1.2.

Doku:

Note: Output is not suitable for editing, since the IDs for untagged nodes won’t match the original OSM data (You can open these XML files in JOSM, but please don’t upload them).

Ich weiß nicht, was passiert wenn man das trotzdem versehentlich hochlädt, nur zur Info: es gibt ein Tag upload="false" wo dann zumindest eine dicke Warnung im JOSM käme.

2 Likes

Naja, der Way referenziert dann beliebige Knoten von irgendwo auf dem Planeten. Eben ziemlicher Datenmüll. Mit etwas Glück passen die Versionsnummern nicht oder die Nodes existieren nicht. Der upload wird dann von der API abgelehnt. Ich würde mich aber nicht darauf verlassen.

Die Freude ist dann sicherlich riesengroß, wenn quer über den Planeten Tiles unbrauchbar werden. Also: don’t try this at home.

1 Like

Und wenn man schon damit rumexperimentiert sollte man wohl auch noch überprüfen ob die Koordinaten nach der Wandlung WGS84 → Web Merc → WGS84 tatsächlich unverändert sind.

Das sollte als Feature in geodesk / gol-tool eingebaut werden, dass jedes produzierte XML-file dieses upload=false enthält! …oder?

1 Like

Ja, macht Sinn. :slightly_smiling_face:

Für die --area Option braucht man ein POLY File. Wie kann man das nochmal erstellen (zB. aus einer GPX Datei)?

1 Like

Das kannst du auch mit gol machen, indem du die Fläche mit --format=poly speicherst.

1 Like

Gibt da auch ein jOSM plugin “poly”…
https://josm.openstreetmap.de/wiki/Plugins

2 Likes