Thanks for sharing RasterDataSources.jl, it looks really interesting. The STAC specification could help to channel the different efforts and help provide a uniform (or at least more uniform) API to different datasets. The pangeo community did some really interesting work in this direction.
I’m looking through your links, stacspec is great 
I agree it would be good to have a structured approach to getting files. RasterDataSources.jl is written how it is because a lot of these data sets currently have no metadata like that - so it just constructs urls with known patterns based on the arguments to getraster.
Do you mean we should start a package that can digest this JSON spec and provide a syntax for downloading files from it?
Do you mean we should start a package that can digest this JSON spec and provide a syntax for downloading files from it?
Yes, I think that would be the best way forward. I would propose to put it directly on a julia orginization. JuliaClimate has already some packages related to data access ( ClimateSatellite.jl, INMET.jl, CDSAPI.jl from @natgeo-wong and @juliohm ). Maybe you are interested to join this organization? Otherwise there is also JuliaGeo (both of us are already member there).
I have some prototype code that I can share based on this python example.
Any suggestions about the name? STAC.jl is probably to short. STACatalogs.jl?
Ok that sounds good to me too, not sure on the name! STAC.jl is clean but the STAC ancronym is probably unfamiliar to for most of the Julia community. Maybe that doesn’t matter…
As to where it goes, it does seem like a lot of climate related data sources, but then JuliaGeo is the most generic place. So up to you. I wont have a lot of free time to put into it in the near term, but I can review PRs and give feedback.
Funny,
I’ve been working the last couple of says in porting this python tutorial to Julia with GMT. I advanced till the point where the three bands are read only partially (load only the ROI) but got stuck in GMT/GDAL problems.
I (and others before me) had GDAL issues with reading data from authenticated sites that will be of interest of others that follow this path. See this and related post in GDAL list
1 Like
@joa-quim @Alexander-Barth Are there any news regarding accessing STACs? We are thinking about deploying a sentinel-2 datacube for Germany plus making it easily accessible via a STAC. It would be cool to have access to it from the julia universe as well. I just wish I could split myself in 3 to handle all the programming…
I finished the conversion of that tutorial. You can find it in the RemotS package examples.
Unfortunately RemoteS is blocking the update of GMT.jl to latest because of this long lasting Julia issue, which blocks the automatic registering of new GMT.jl & RemoteS.jl versions.
I put my code in this repository
I think it should already be useful to access a STAC repository. (Unfortunately, it is not registred New package: STAC v0.1.0 by JuliaRegistrator · Pull Request #59089 · JuliaRegistries/General · GitHub , despite there are many other packages with similar short names)
I would be quite interested in this STAC end-point for for sentinel-2 data. Which processing level and parameters are you targeting for the Sentinel-2 data?
Are you providing also a search functionality for your STAC server?
@Alexander-Barth could you re-trigger the registration on a more recent commit? Let’s try to get it registered. Often if PRs that need manual actions get forgotten I ask for help in the pkg-registration channel in Slack.
Definitely level 2, maybe time series interpolation as well. We’ll probably be using force for processing. Today I heard the first time of STAC, nothing is settled yet, not even the processing engine. So I can’t really comment on the search functionality. But I’m really happy to see STAC being covered already, thanks for the effort guys!