You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am looking for a developer who would be interested in porting the GVRS API to the Rust programming language.
Recently, we completed a port from Java to C. Having access to both the Java and C code bases should make it easier to scope out how to port the code base to Rust. To give some sense of the general approach and level-of-effort, we've posted a report describing the tasks that we performed as part of the Java to C port at https://gwlucastrig.github.io/GridfourDocs/notes/PortingTheGvrsAPI.pdf. We also have lots of project documentation on the Gridfour Project Notes page and on the wiki's for the Gridfour Java and GVRS C API project pages.
Although I am only a beginner when it comes to Rust, I would be available to assist in the porting effort by creating test resources, answering questions, and providing code and architecture reviews.
About GVRS
The GVRS API offers four capabilities that may be useful for the Rust community:
It provides a “virtual raster” that would assist Rust programs processing very large gridded data products, especially those that might be too large to be conveniently kept in memory.
GVRS provides a testbed for developers who are experimenting with data compression techniques for raster data products (that was, in fact, the original reason I wrote it).
GVRS provides a persistent data store for raster products. It is particularly well suited to geophysical data.
A GVRS port would provide Rust programs with access to the global elevation and bathymetry data sets that already exist for the Java API.
Now, before I go on, I have to qualify claims 3 and 4 by pointing out that there are many raster data products out there and virtually all of them have wider user bases than GVRS (NetCDF and HDF5, for example). In terms of sheer availability of data, those other products have distinct advantages over GVRS. So I don’t want to oversell my project.
On the other hand, I wrote GVRS with the idea that the code would be ported to other languages, and I tried to organize it in such a way that it a port could be executed quickly and well. If you want to port GVRS to Rust, my attitude is that it would be your project and I would try not to interfere in the design or direction of the porting effort. Of course, I am highly motivated to have someone succeed in porting GVRS to Rust. So I would be available to answer questions, explain concepts, and to help smooth over any code incompatibilities that might arise between the Rust and Java implementations.
An earlier effort to port GVRS to Rust was begun in 2022, but is currently on hiatus. You may read more at Gridfour Issue #28.
I am looking for a developer who would be interested in porting the GVRS API to the Rust programming language.
Recently, we completed a port from Java to C. Having access to both the Java and C code bases should make it easier to scope out how to port the code base to Rust. To give some sense of the general approach and level-of-effort, we've posted a report describing the tasks that we performed as part of the Java to C port at https://gwlucastrig.github.io/GridfourDocs/notes/PortingTheGvrsAPI.pdf. We also have lots of project documentation on the Gridfour Project Notes page and on the wiki's for the Gridfour Java and GVRS C API project pages.
Although I am only a beginner when it comes to Rust, I would be available to assist in the porting effort by creating test resources, answering questions, and providing code and architecture reviews.
About GVRS
The GVRS API offers four capabilities that may be useful for the Rust community:
Now, before I go on, I have to qualify claims 3 and 4 by pointing out that there are many raster data products out there and virtually all of them have wider user bases than GVRS (NetCDF and HDF5, for example). In terms of sheer availability of data, those other products have distinct advantages over GVRS. So I don’t want to oversell my project.
On the other hand, I wrote GVRS with the idea that the code would be ported to other languages, and I tried to organize it in such a way that it a port could be executed quickly and well. If you want to port GVRS to Rust, my attitude is that it would be your project and I would try not to interfere in the design or direction of the porting effort. Of course, I am highly motivated to have someone succeed in porting GVRS to Rust. So I would be available to answer questions, explain concepts, and to help smooth over any code incompatibilities that might arise between the Rust and Java implementations.
An earlier effort to port GVRS to Rust was begun in 2022, but is currently on hiatus. You may read more at Gridfour Issue #28.
To learn more about GVRS, visit our Project Wiki or read our Frequently Asked Questions page.
The specification for the GVRS file format at https://gwlucastrig.github.io/GridfourDocs/notes/GvrsFileFormat_1_04.pdf
The text was updated successfully, but these errors were encountered: