Michael Krabbe Borregaard

Yes, you could easily grid occurrences by using a modification of `SpatialEcology.creategrid` (https://github.com/EcoJulia/SpatialEcology.jl/blob/master/src/Constructor_helperfunctions.jl#L135-L162). Interesting idea with the auto-binsize! We plan to put the auto-binning code from Plots into StatsBase, so...

Yes, we may have to handle the repeats of polygon attributes ourselves internally here - like I did for the multi lines that constitute branches on a phylogenetic tree https://github.com/EcoJulia/Phylo.jl/blob/dev/src/plot.jl#L180-L189

Yup, there is no doubt that the spatial (coordinate) types internally should be explicitly geographical types consistent with the framework being developed at JuliaGeo. To explain how it is now:...

It should be - here is some spaghetti code that does the trick, an `Assemblage` method based on that would be straightforward. There are a few things that make it...

Perhaps we could define stubs for all the types we use in an EcoBase package imported by all the other packages, so SpatialEcology wouldn't need to depend on GBIF.jl to...

The constructor should also extract the taxonomic information and site information from the `Occurrences` object and put them in the `.occ.traits` and `.site.sitestats` DataFrames of the Assemblage object.

Is it correctly understood that this issue means that no packages can depend on e.g. FFTW for internal (non-exported) functionality, because that would break the FFT workflow for any package...

I think this is GR side

I'm guessing @lewisl means gks window not gtk?

If it's about the display stack then that is not GR - Plots handles that here: https://github.com/JuliaPlots/Plots.jl/blob/master/src/init.jl#L22-L29