JuliaGeo talk at FOSS4G 2019

Hi all,

@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.

16 Likes

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.

Congrats! I wish I knew FOSS4G, would definitely join as I mentioned on slack :slight_smile:

Next year for sure!

Best,

1 Like

OK, thanks.
… and have a look at my #78 issue in GDAL.jl

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.

1 Like

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! :slight_smile:

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.

:slight_smile:
2020 events:

And

#foss4ge2020 Europe : Call for Papers
“If you’re interested to present at the 𝐆𝐞𝐧𝐞𝐫𝐚𝐥 𝐓𝐫𝐚𝐜𝐤 or wish to hold a 𝐖𝐨𝐫𝐤𝐬𝐡𝐨𝐩, check our website for submission guidelines”
FOSS4G European Conference: Gathering of open source geospatial users, developers, and researchers.**
https://twitter.com/foss4ge/status/1224959486345076737

1 Like