@visr and me have presented the JuliaGeo ecosystem at the FOSS4G 2019 conference in Bucharest. You can find the video here and the slides (on NextJournal) here. This was the first talk about Julia at FOSS4G as far as we know.
A lot of people are interested in Julia, as both a large percentage of the room knew about it and we have been approached multiple times during the conference to talk about Julia. We take this as a good sign!
To make the introduction to Geo in Julia a bit easier, Iβve ported the JuliaGeo wiki to a github.io website at https://juliageo.org/ (juliageo.github.io). At NextJournal weβve also created the JuliaGeo organization for sharing notebooks. Last but not least, @visr updated the logo to follow the latest iteration of the Julia logo itself.
Most of this work can certainly be improved and we welcome any suggestions, comments and PRs.
Hi,
I would like to have GMT.jl also listed in JuliaGeo organisation, but it already belongs to the GMT organisation. Is it possible to a package to belong to more than one organisation?
I donβt think a package can belong to two GitHub organizations no. But for what itβs worth, GMT.jl is referred to on juliageo.org. I think you can see JuliaGeo in two ways. One is the list of packages under the GitHub organization. Packages are there because in some cases it makes sense to put them under an organization, for maintenance or whatever. But in my opinion JuliaGeo is all about making julia great for geospatial computing, and that will always transcend GitHub organization boundaries, since julia code just composes so well.
Sometimes, organizations hold a fork of a repository for additional exposure. Otherwise there should be little difference if the organization is not maintaining the package.
The idea of GeoDataFrames soundsβ¦ AMAZING! Itβd really help people (cough me! cough) port workflows from sp in R or geopandas in Python over to Julia!
Ha thanks, weβre slowly edging closer. One of the steps was to make existing vector files a Tables.jl table, which is now done in Shapefile.jl and GeoJSONTables.jl. From those I hid the geometry column to the Tables interface because I want to treat it specially later. We will need some work on an improved GeoInterface that @yeesian has done some thinking on lately. Then based on that interface perhaps we can set up a generic GeoTables interface for this kind of functionality.
Although besides the generic interfaces and types it might be good to also start working on a decent GeoDataFrame that just takes for instance a DataFrame and a vector of GEOS(?) geometries, and start defining some operations on them.
My understanding is thatβs how geopandas came into being β they inherited pandas, added the idea of a βgeometryβ column, and then added a few functions that are unique to tabular geo-spatial data (intersect, spatial join). I know you canβt βinherentβ per se, but would love to see this in julia!
I heard the guy who first did it give a talk, and he said it took a weekend, given everything that came for free from pandas, shapely, and pyproj.
