# Moving to GeometryBasics

**URL:** <https://discourse.julialang.org/t/moving-to-geometrybasics/40861>\
**Category:** Geo\
**Tags:** plotting, upgrades\
**Created:** [June 6, 2020, 11:24am UTC](https://discourse.julialang.org/t/moving-to-geometrybasics/40861 "2020-06-06T11:24:10Z")\
**Posts on this page:** 10\
**Page:** 1

<div class="post-metadata">

**Author:** ![arsh](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/arsh/32/9073_2.png) [@arsh](https://discourse.julialang.org/u/arsh)\
**Post date:** [June 6, 2020, 11:24am UTC](https://discourse.julialang.org/t/moving-to-geometrybasics/40861/1 "2020-06-06T11:24:10Z")

</div>

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](https://r-spatial.github.io/sf/index.html) and Python has [GeoPandas](https://geopandas.org/). In Julia there has been [interest in similar functionality](https://discourse.julialang.org/t/read-geopackage-layers-to-dataframe/35837), but so far no general solution. Thanks to the Tables interface for Shapefile and GeoJSONTables, with ArchGDAL as a [work in progress](https://github.com/yeesian/ArchGDAL.jl/pull/118) 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](https://discourse.julialang.org/t/juliageo-talk-at-foss4g-2019/28425/8) and a [GeoDataFrames package](https://docs.google.com/document/d/1hGc5Zs1uuJotSCOGBAzpLl5-2yPTAUEe4XAdu4o-c4M/edit#) borrowing the concept from GeoPandas in Python was thought of.

Currently many packages define their own geometry types, and rely on the [GeoInterface](https://github.com/JuliaGeo/GeoInterface.jl) 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](https://github.com/JuliaGeo/GeoInterfaceRFC.jl), 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](https://github.com/JuliaGeometry/GeometryBasics.jl) 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](https://github.com/JuliaGeo/Shapefile.jl/pull/39) and do the same for [GeoJSONTables](https://github.com/visr/GeoJSONTables.jl/pull/2).

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](https://github.com/yeesian/ArchGDAL.jl) that would obviously be possible with GeoInterfaceRFC and [Turf](https://github.com/philoez98/Turf.jl/)

There’s definitely a lot to do, the plans can certainly be improved and we welcome any suggestions, comments and PRs. 🙂

---

<div class="post-metadata">

**Author:** ![nilshg](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/nilshg/32/2283_2.png) [@nilshg](https://discourse.julialang.org/u/nilshg)\
**Post date:** [June 6, 2020, 12:14pm UTC](https://discourse.julialang.org/t/moving-to-geometrybasics/40861/2 "2020-06-06T12:14:59Z")

</div>

Sounds like something @juliohm might be interested in

---

<div class="post-metadata">

**Author:** ![yeesian](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/yeesian/32/652_2.png) [@yeesian](https://discourse.julialang.org/u/yeesian)\
**Post date:** [June 6, 2020, 8:11pm UTC](https://discourse.julialang.org/t/moving-to-geometrybasics/40861/3 "2020-06-06T20:11:37Z")

</div>

This is really exciting development, thanks for sharing!

---

<div class="post-metadata">

**Author:** ![ljwolf](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ljwolf/32/16223_2.png) [@ljwolf](https://discourse.julialang.org/u/ljwolf)\
**Post date:** [July 7, 2020, 4:00pm UTC](https://discourse.julialang.org/t/moving-to-geometrybasics/40861/4 "2020-07-07T16:00:57Z")

</div>

Indeed, this is very exciting! I am a `geopandas` maintainer who explored [early julia](https://github.com/ljwolf/spatialweights.jl) for graph-theoretic spatial statistics common in geography, econometrics, and statistics. I would be very interested in seeing a similar stable set of geographic geometric primitives + tabular interface land in Julia, and wish you luck! I will be following this thread, too.

---

<div class="post-metadata">

**Author:** ![arsh](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/arsh/32/9073_2.png) [@arsh](https://discourse.julialang.org/u/arsh)\
**Post date:** [August 24, 2020, 11:36am UTC](https://discourse.julialang.org/t/moving-to-geometrybasics/40861/5 "2020-08-24T11:36:55Z")

</div>

> [@arsh](#):
>
> Thanks to the Tables interface for Shapefile and GeoJSONTables, with ArchGDAL as a [work in progress](https://github.com/yeesian/ArchGDAL.jl/pull/118)

Hey all, the Tables interface for ArchGDAL is nearing completion, [https://github.com/yeesian/ArchGDAL.jl/pull/118](https://github.com/yeesian/ArchGDAL.jl/pull/118). We invite everyone to try it out. Any feedback regarding the same would be appreciated. 😄

---

<div class="post-metadata">

**Author:** ![phlavenk](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/phlavenk/32/1873_2.png) [@phlavenk](https://discourse.julialang.org/u/phlavenk)\
**Post date:** [August 26, 2021, 12:17pm UTC](https://discourse.julialang.org/t/moving-to-geometrybasics/40861/6 "2021-08-26T12:17:23Z")

</div>

I wanted to as, if there is somewhere a description of the GeometryBasics.AbstractMesh interface? At least the list of functions that should be implemented.

And, what is the relation between `Meshes.jl` and `GeometryBasics`? How is the interoperability between them accomplished? It doesn’t look like Meshes are build on top of GeometryBasics.AbstractMesh. Is that correct?

---

<div class="post-metadata">

**Author:** ![juliohm](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/juliohm/32/215266_2.png) [@juliohm](https://discourse.julialang.org/u/juliohm)\
**Post date:** [August 26, 2021, 12:38pm UTC](https://discourse.julialang.org/t/moving-to-geometrybasics/40861/7 "2021-08-26T12:38:50Z")

</div>

@ljwolf @phlavenk please watch my JuliaCon2021 talk for examples of tables with geometry columns:

[![](https://global.discourse-cdn.com/julialang/original/3X/8/6/86a1676a1da38b4db999abd19ef80e6819092e21.jpeg "Geostatistical Learning | Júlio Hoffimann | JuliaCon 2021") ](https://www.youtube.com/watch?v=75A6zyn5pIE)

---

<div class="post-metadata">

**Author:** ![phlavenk](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/phlavenk/32/1873_2.png) [@phlavenk](https://discourse.julialang.org/u/phlavenk)\
**Post date:** [September 2, 2021, 5:34am UTC](https://discourse.julialang.org/t/moving-to-geometrybasics/40861/8 "2021-09-02T05:34:25Z")

</div>

@juliohm , where can I found more details on how to plug-in to the Meshes / GeoStats ecosystem? I see GeometryBasics.jl is not used by Meshes.jl, however, MeshIO only depends on GeometryBasics. And, with GeometryBasics.jl documentation being pretty sparse, and my little knowledge of the Meshes.jl history and architecture, I’m pretty confused now.

My aim is to prepare code that reads several binary files produced by CST studio (a big commercial FEM) containing 3D volume mesh (tetrahedrons), surface meshes(triangles), field values, and particle trajectories (1D path) with various metadata at each node and also values inherent to whole bodies/trajectories. The end goal is to do the analysis in the way, you do it in your talk above.

Could you recommend a package or a part of code that I might follow to implement the required interfaces for the CST studio files?

---

<div class="post-metadata">

**Author:** ![phlavenk](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/phlavenk/32/1873_2.png) [@phlavenk](https://discourse.julialang.org/u/phlavenk)\
**Post date:** [September 2, 2021, 5:38am UTC](https://discourse.julialang.org/t/moving-to-geometrybasics/40861/9 "2021-09-02T05:38:47Z")

</div>

And, I’ve forgotten to to tell how I was amazed by your approach to treat the 2D/3D data as a DataFrame, basically having all the heavy group/combine machinery right on hand when doing spatially structured data analysis - a truly brilliant step. Thank you.

---

<div class="post-metadata">

**Author:** ![juliohm](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/juliohm/32/215266_2.png) [@juliohm](https://discourse.julialang.org/u/juliohm)\
**Post date:** [September 2, 2021, 10:42am UTC](https://discourse.julialang.org/t/moving-to-geometrybasics/40861/10 "2021-09-02T10:42:12Z")

</div>

> [@phlavenk](#):
>
> @juliohm , where can I found more details on how to plug-in to the Meshes / GeoStats ecosystem?

We are continuously improving the documentation, but I suggest reading the extensive test suite of Meshes.jl for examples of usage. We are quite pedantic with tests so you can learn a lot from there.

> [@phlavenk](#):
>
> My aim is to prepare code that reads several binary files produced by CST studio (a big commercial FEM) containing 3D volume mesh (tetrahedrons), surface meshes(triangles), field values, and particle trajectories (1D path) with various metadata at each node and also values inherent to whole bodies/trajectories. The end goal is to do the analysis in the way, you do it in your talk above.

Can you clarify the file format used by the software? Currently I am using [meshlab](https://www.meshlab.net/) to convert any file format to PLY and then using PlyIO.jl to read these meshes from disk.

> [@phlavenk](#):
>
> Could you recommend a package or a part of code that I might follow to implement the required interfaces for the CST studio files?

You mean a package to read the file format exported by CST studio? What is the format?

> [@phlavenk](#):
>
> And, I’ve forgotten to to tell how I was amazed by your approach to treat the 2D/3D data as a DataFrame, basically having all the heavy group/combine machinery right on hand when doing spatially structured data analysis - a truly brilliant step. Thank you.

Thank you, but I think this tabular approach is not that new 🙂 I think the novelty is in the unifying interface for all kinds of domains (2D/3D meshes, point sets, geometry collections, trajectories, …). It is pretty important to be able to discuss geostatistics without multiple complicated APIs that differ as a function of the domain type. 👍🏽