I love working with Meshes.jl and GeoTables.jl.
I would like to be able to export a GeoTable object to a standard GIS format (e.g. shapfile, gpkg, so on) so my collaborators can handle the results of my analysis. What would be the suggested approach to export a GeoTable?
Also I was wondering how people are handling projection to CRS using GeoTables.jl and Meshes.jl.
Glad to hear it has been a good experience @ErickChacon 
We are working really hard to lower the barriers to entry in GIS. Let me try to address your questions:
Notice that a GeoTable is a type that implements the Tables.jl API. Try to check which packages (Shapefiles.jl, GeoJSON.jl, ArchGDAL.jl) provide a write or save function to write to disk and we can work on the final ingredients to make it function. We will probably need to write a small code to convert Meshes.jl geometries to whatever geometry types are used by the IO package. The GeoInterface.jl package can be useful to write this conversion code.
We are currently working on a generalization in Meshes.jl to lower the barrier to entry here as well. The plan is to have some innovative solutions coming out by the beginning of next year.
Yes Meshes.jl needs to implement GeoInterface at some stage. I’ve had a look at doing this but there have been too many small things with all of the other packages and GeoInterface 1.0 for me to get it finished.
@juliohm If you have time with your understanding of the objects in Meshes.jl would probably be faster at getting the bulk of it in place. I can work with you with more specific details of GeoInterface.jl , as I’ve done a few of these by now.
@Raf I don’t have the bandwidth right now to work on this, but the implementation should probably live in a separate package given that Meshes.jl is a more general project that goes beyond 2.5D geometries used in GIS. We are still evolving our own geometry types to accommodate more complex use cases and algorithms.
Ok, I get that its a broader package. But you have real users in threads like this asking for interop, and it could “just work” without much effort.
GeoInterface is a tiny dependency, at 0.01 seconds using time on my laptop. Even Geometry basics is fine having as a dep:
A scalable solution here is to create a package GeoConversions.jl (or similar name) that is maintained by people that are interested in converting back and forth between different geometry types that implement the GeoInterface.jl.
The code doesn’t need to live in Meshes.jl, that is what I am saying. Maintaining this interface is not our priority so people who actually need it can take the lead and implement it in a separate package that others can review and contribute over the years.
You can already do conversion just with GeoInterface.jl, we don’t need another package for that.
If anyone is willing to submit a PR, I am happy to assess the alternatives. I don’t have the time to work on this myself.
Well, I started a PR a while ago, I’m just also very squeezed for time. I would look at finishing it if it is something wanted in Meshes.jl and will have a good chance of being merged.
(I can’t actually maintain a separate package for this tho)
If you can share the PR you have started that would be helpful. It would even help com OP with his specific problem right now.
It’s not really at a helpful state at this point as I don’t fully have my head around Meshes.jl types
@ErickChacon please update to GeoTables.jl v1.1, I’ve implemented the minimum interface necessary to save to disk as illustrated in the following example:
julia> using GeoStats
julia> geotable = georef((a=1:4, b=1:4))
4 MeshData{1,Float64}
variables (rank 1)
└─a (Int64)
└─b (Int64)
domain: 4 CartesianGrid{1,Float64}
julia> using GeoTables
julia> GeoTables.save("analysis.geojson", geotable)
"analysis.geojson"
julia> GeoTables.load("analysis.geojson")
4 GeoTable{1,Float64}
variables (rank 1)
└─a (Int64)
└─b (Int64)
domain: 4 GeometrySet{1,Float64}
Notice a few things:
The GeoInterface.jl cannot represent rich topological information that is needed for geometric processing. Notice how the original CartesianGrid is reloaded from disk as a GeometrySet, i.e. a soup of disconnected geometries. Many algorithms in Meshes.jl rely on neighborhood information, so I highly recommend that you stay away as much as possible from these geometry types used for IO. My general advise is to design your workflow in terms of Meshes.jl geometries, and only resort to the GeoInterface.jl for loading/saving data from/to disk.
The only package I could find that provides the “save” functionality for the GeoInterface.jl is the GeoJSON.jl package. That means that you can only export to geojson at the moment.
You may encounter issues saving some types of geometries that are not supported by the GeoInterface.jl. If you have any trouble, please reach out in our community channel:
https://juliaearth.github.io/GeoStats.jl/stable/about/community.html
@juliohm Thank you so much for the quick implementation. I agree with you that Meshes.jl is a more general approach than classical GIS but still there is the need to share our data with other colleagues that are just interested in visualising or performing simple analysis of our results with their own GIS tools. Thank you again for providing a simple way to share our data.
Thank you so much for your advises, I agree with the points you made. In particular, the point 1 is quite interesting and clearly indicates that in several cases this approach would not be ideal. In case of sharing data with Julia users, do you think it is sensible to use JLD2? I have some additional questions with respect to this, I will probably continue the discussion in the GeoStats community.
Depending on the geometries you have in mind, you can maybe use a more standard format like VTK (WriteVTK.jl) or PLY (PlyIO.jl) for your mesh data. I think JLD2.jl is a good fallback for Julia collaborators who just need to load your results and continue the work with all the data structures preserved.
Happy to continue it over there 
ArchGDAL.jl can write to other formats, although its not as easy as it could be. GeoParquet.jl can also write. I would like to add write to Shapefile.jl as well, if people think that’s useful.
Also @juliohm nice work on GeoTabels.jl! There are more efficient methods than using GI.coordinates, which will allocate a bunch of Vectors. I can PR at some point to make this more efficient if you like.
Yes, that would be helpful.
Update for those coming late here:
Please replace GeoTables.load by GeoIO.load.