Thanks to @maxlenormand.bsky.social , Soumya ranjan from @developmentseed.org , my colleague Gajesh Ladhar from Satsure , for thier early feedbacks.

Sorry to hear about this. Take care.

True totally agreed that its tough. But im wondering how PyPI gets funded by donations from both community developers and companies like Meta and so on, i guess it just due to sheer numbers? Geo is pretty small compared to general Python.

It doesn't need to another private company setting it up and owning it. It can be truly open and community + private industry funded. Unlike PyPI which hosts full libraries, the geo dataset registry doesn't need to keep STACs or any datasets inside it. A few Postgres/ES instances might be enough.

I mean PyPI registry's framework/design and governance is close to what can be done for geo as well.

I think PyPI is interesting. Its completely funded by donations. Controlled by python software foundation. Also, since I thinking there will just be pointers to STACs and Non-STACs I don't think it will be costly to maintain.

Similar to PyPI, data producers can push just metadata of datasets in toml files, to a central registry. It would only contain a "summary metadata" of entire STACs, parquet/csv files, APIs like OSM. With thier total bbox, quality metrics etc. A registry like this can be more easily governed i feel?

@cbed.bsky.social had put up a question on LinkedIn about finding all datasets STAC or not. And his idea was an aggregator of datasets in YAML. Similarly I feel PyPI registry is a good thing to emulate, with geopip to get data and pass it to pystac/duckdb/requests based on details sent via toml

I know it shouldn’t but this bit is so petty it made me lol

The completely open source code of iceberg and the basic REST catalog still provides great features for most people. Read/filter, write/append cloud based data (usually parquet) using just Pyiceberg. Merge/update rows are possible via Trino/Spark engines, it should come soon to Pyiceberg as well.

Could you add me please? Thanks