[ANN] spatialweights.jl

[Levi John Wolf]

Hey all,

I took a first jump into spatial weights construction in Julia.

https://github.com/ljwolf/SpatialWeights.jl

These weight matrices are integral to many common spatial statistical techniques. I'm benchmarking/validating against the [Python Spatial Analysis Library](https://github.com/pysal/pysal), a project I'm a developer on.

I aim to add other kinds of spatial weights construction techniques as I go, in addition to switching to GeoInterface types rather than GeoJSON types. All of this would target vector data, and could be incredibly benefited by a Julia wrapper for OGR (VectorIO.jl?) to match Will Kearny's great initial work on RasterIO.jl. So, I've been taking a look at that, too, and would love to coordinate with anyone else who's knowledgeable on OGR or wrapping C with Julia.

Really excited to start pushing up a strong JuliaGeo ecosystem!

[Martijn Visser]

Good to see more people interested in spatial analysis! Regarding you point on wrapping OGR; it is being worked on, see GDAL.jl. The idea is for this package to take care of the low-level wrapping of all of GDAL, including OGR. Other libraries, such as RasterIO.jl, can then build on this to provide a higher level API. This should have probably also gone on the mailing list, though it's recent development.

-Martijn

[Yeesian Ng]

That's great!

1. I'm afraid the GeoInterface.jl package is experimental at this point (only LibGEOS.jl requires it), and isn't quite mature enough for adoption yet, so

    - I recommend working with native Julia types for now.

    - but if you're interested in playing around with other packages (with no guarantees of permanence), I have also written GeoConverters.jl and Turf.jl

2. We're also working with the JuliaGeometry organization, so things are going to be shaken up at some point. Depending on the performance of OGR's geometries, we might depart from python, in emphasizing the use of OGR (rather than GEOS) for interoperability with everything else.

3. The longer term plan is to have a single package that provides the build script and wraps all of GDAL, and then have subsequent packages (e.g. RasterIO.jl) depend on it.

[Yeesian Ng]

Out of curiosity, since I haven't been following the development in python very closely for awhile, is there anything in common between python-rasterstats and PySAL?

On Sunday, 18 October 2015 18:02:41 UTC-4, Levi John Wolf wrote:

[Levi John Wolf]

Hey, thanks for the responses! I'm really excited to keep working in this community!

I've been watching this space very closely, and have used GDAL.jl. But, I think it's important to expose the functionalities like Will did in RasterIO.jl In my experience, that's the path to a healthy and vibrant user/developerspace.

So, that's what I meant by (hopefully) getting something slicker than raw GDAL up and running, like RasterIO.jl for OGR.

Seems like you and I are coming from a very similar place on Sean Gillies' work, Yeesian. I'd love to get some motion on them.

 It's unfortunate that most __geo_interface__ implementations in python don't try to use a flyweight design, keeping the data in one place and using pointers/getters to supply their api. Since many packages built up before Sean wrote that document, I feel like it was added as an afterthought to the core datastructure choices. I know that was the case for PySAL, and occurred well before I joined that project.

However, I do believe something like semi-structured Geo/topoJSON is the future of (at least) vector display, so making implementations of (some kind of) geointerface should have fast 1to1 mapping to Geo/TopoJSON as a high priority. I don't see anything lacking in the GeoJSON standard, aside from maybe the removal of the singly-typed instances [Point, Line, & Polygon].

With rasterstats & pysal, there's no overlap between functionalities. We're primarily focused on statitics for vector-based lattice data. The world of needs in Geo is big, and usually the support of the data (raster v. vector) suggests appropriate analytical techniques.

[Yeesian Ng]

Regarding priorities, I'd say OGR's the highest on the list now, and will be both high-impact to JuliaGeo, and educational* for whoever decides to work on it. I won't have time to work on a nicer package for OGR for a while, but will be happy to help you out and direct you to resources if you're interested.

Personally, I don't think it'll be productive to do any high-level architecting until at least after the dust on things in https://github.com/JuliaLang/julia/issues/13157 and https://github.com/JuliaGeometry/GeometryTypes.jl settles. Longer-term, we might want to think about how best to cooperate with the development in gdal/ogr, while exploring the possibility of using the juliageometry libraries: for now, we're completely surrendering ownership of the underlying objects to the C/C++ libraries (GDAL/OGR). It'll be nice if there is a way for them to expose ownership of the underlying as structs/arrays for direct use in Julia, to develop algorithms for. We should get in touch with https://github.com/rouault after we get our act together.

*It's always nice to have more developers who are familiar with both julia's C FFI, and the corresponding GDAL/OGR APIs.

[Levi John Wolf]

Hmm,I'll have to dig more into the JuliaGeometry stuff. That seems like a natural place to peg the primitives to, and then implementing stuff like Features, Collections, and coordinate system handling go over them.

I agree that arraypocalypse will probably throw specifics of implementation off. But, it can't hurt to think/discuss what a good Julian environment for statistics, modelling, and GIS would look like.

Maybe a different thread though :)