Provide support for Geospatial Operations?

JuliaGeo / GeoJSON.jl

Utilities for working with GeoJSON data in Julia

https://juliageo.org/GeoJSON.jl/stable/

MIT License

68 stars 10 forks source link

Provide support for Geospatial Operations? #6

Closed yeesian closed 9 years ago

yeesian commented 9 years ago

I had been porting the functionality for Turf in a separate repository, but that codebase had been designed for javascript apps, and there's [significant] overlap in functionality with DataFrames-type operations, and other packages (in interpolations, etc).

Does it make sense to

support a small set of core operations (union/convexhull/within/etc) on individual geometries in GeoJSON.jl, and
use DataFrames.jl (see https://github.com/JuliaGeo/GeoJSON.jl/pull/5) to perform more sophisticated queries/operations?

If so, I'll migrate the relevant portions of the code over from Turf.jl to this repo (to src/turf.jl) through a PR. Your thoughts?

cc @garborg

garborg commented 9 years ago

@yeesian My thought is that GeoJSON.jl should stay light, basically i/o only, and eventually have types moved out elsewhere, where supported geometries and features may be a superset of what GeoJSON supports. That new package (GeoShapes.jl, or whatever) will be a dependency of GeoJSON.jl as well as of packages that handle i/o of shapefiles, kml, etc., and core operations (convexhull, etc.) would be either in the new package, or in Turf.jl. Then analysis w/o DataFrames both depend on those same core functions.

yeesian commented 9 years ago

Okay, I've been independently converging towards the same design too. See https://github.com/yeesian/GeoInterface.jl.

We should probably have a JuliaGeo meta wiki/discussion about these stuff, but I'll just experiment with what I have for now, to see what works and what doesn't

garborg commented 9 years ago

That sounds great! I've done some work making Geodesy.jl more powerful, too -- if I can finish a couple things there soon, I'll try to come experiment on the interface with you soon.

yeesian commented 9 years ago

I saw, and have provided an AbstractPosition in anticipation (:

garborg commented 9 years ago

Ah, cool! I was wondering how that would work but hadn't stopped to try to puzzle it out yet.

yeesian commented 9 years ago

It's meant to replace code like type XYZhere, for subsequent code to be able to

deal with ENU, LLA, ECEF, etc through an AbstractPosition interface
be able to access individual coordinates through (i) getter methods (x,y,z), or (ii) an array-like interface

I have provided an example implementation in GeoJSON.jl.