How to handle GeoSPAQL?

[areleu]

Hi again Magnus,

I used maplib for a journal submission last year, it is still under review. I tried to make justice to the capabilities of the library in the text. Here is the proof of concept I developed for the publication, it uses an old version of the library. I will keep you up to date in case it gets accepted.

I am working on a new publication, and there I would like to use maplib too (and maybe chronotext). This time I lean a lot towards geospatial analysis, so I was wondering if you already have a vision on how would the integration of geosparql would work in maplib.

Recently geopolars development was unblocked so I have high hopes this will boost the GIS ecosystem in polars in the short future.

[magbak]

Hi @areleu!
Congratulations on great work! Fingers crossed!

Sorry for getting back a bit late! We may do GeoSPARQL, but I have not been able to prioritize it over other features. With your collaboration in developing it we could move faster. Yes, we would like to of course have Arrow-native representations of geographical data, and would like operations to be as Polars-native as possible. We may however have to work using GeoRust to provide implementations of algorithms.

There are three things to do:

1. Parse WKT data into Arrow-native representations.
2. Serialize such Arrow-native representations back to their WKT-representation for RDF serialization purposes.
3. Implement various GeoSPARQL functions on these Arrow-native representations.

As for Chrontext, I will be integrating virtualization in maplib very soon, in which case we should be able to virtualize that data, but we will also be doing disk-based storage of materialized triples in maplib using e.g. Parquet.

We could set up a meeting to discuss this further?

[areleu]

I would love to help, lets talk and see how we can bring this forward. How can I contact you to arrange a call, should I use the public email of your company?

[magbak]

Sure, magnus@data-treehouse.com