Hi all! I am Arsh Sharma, an electronics undergraduate and I am working on the geospatial ecosystem, in this year’s JSoC under the mentorship of Martijn Visser @visr, Bogumił Kamiński @bkamins and Maarten Pronk @evetion .
I’ll be talking about my work and the future possibilities, and invite feedback.
Packages like Shapefile/GeoJSON/ArchGDAL have been the prime parsers for geospatial data into Julia. But there have been a lot of discussions about having a tabular representation for the geospatial data. R has sf and Python has GeoPandas. In Julia there has been interest in similar functionality, but so far no general solution. Thanks to the Tables interface for Shapefile and GeoJSONTables, with ArchGDAL as a work in progress we are getting closer.
One of the main features of GeoPandas and sf is their special treatment of geometry columns.
This is quite helpful in performing spatial operations like joins on the geometry and has been under discussion for quite sometime now. In this JSoC we’d like to work towards an implementation.
@visr initially had plans of having metadata support specific to the geospatial ecosystem, treating geometry as a speciality and a GeoDataFrames package borrowing the concept from GeoPandas in Python was thought of.
Currently many packages define their own geometry types, and rely on the GeoInterface to exchange between different representations. Two downsides to this approach are that conversions are often needed, and that these go through an inefficient GeoJSON based nested array representation that lives in GeoInterface. So at the same time we are working on renewing this approach in GeoInterfaceRFC, which removes the central nested array representation. At the same time we want to strive to reduce the number of conversions that are needed, by promoting packages to adopt GeometryBasics when it is a good fit, and saving the conversions for when there is a good reason for an alternative representation, for example because geometries are defined in a C++ library like GDAL.
GeometryBasics has been designed by @sdanisch from the beginning to work well for geospatial applications. It has well defined standard geometry types along with a good metadata support. Currently my plan is migrate Shapefile from using its own geometry types to GeometryBasics types and do the same for GeoJSONTables.
In addition to that, GeometryBasics supports attaching metadata (attributes/properties) to geometries, and supports the Tables interface through StructArrays. So geospatial data based on GeometryBasics type can be converted to a DataFrame through the Tables interface.
Currently Makie supports GeometryBasics, so much of the plotting can be done with it. I still want to work the possibility of having GeoMakie support GeometryBasics types since that would be an additional perk!
The above features pretty much add up to support going against the Python/R convention, i.e. having a different GeoDataFrames package since that functionality can now be made available in individual packages via GeometryBasics.
Other interesting plans include having GeometryBasics support for ArchGDAL that would obviously be possible with GeoInterfaceRFC and Turf
There’s definitely a lot to do, the plans can certainly be improved and we welcome any suggestions, comments and PRs. 
