On Sat, 16 Apr 2016 at 07:04 chris english <englishchristophera at gmail.com>
wrote:
Mike,
Reading this discussion lead me to finally visiting your github and
reading gris read.md. And of course installing it. I understand mostly
where you are going in the Needs section and were I to recommend a new,
fast friend, it would be Sandro Santilli, strk at keybit.net (
http://strk.keybit.net), who agonized over (I presume) and implemented
topology in PostGIS. While this is not R, the decisions and rigor are
informative. Perhaps you are fast friends already.
Thanks for the link, I know that PostGIS has some of this but I haven't
explored it. I've mostly gone on what is in "PostGIS in Action" - I need to
get familiar with that db - I just don't see it as "the solution" for R -
we can have a light-weight toolkit in R itself, and leverage heavy external
libraries only when desired.
I really appreciate allowing mixed objects in gris that seems informed by
spatstat rather more than sp and friends where one feels shackled to a
given representation of line or point or polygon & etc.. In an analysis of
eyetracking data which was initially informed by a mapping perspective (sp,
trajectories, trips), I have essentially had to rewrite sp to to dispense
with sp and many constraints imposed. Those constraints were theoretically
valid but constraining none the less when trying to implement some system
of proposed algorithms that took no heed of sp's object constraints.
Mostly I'm informed by the use of www.Manifold.net and the now-defunct
Eonfusion. MapInfo .tab and .mif formats also allow mixed topology, but I
never used MapInfo. Eonfusion was so radical it's very hard to describe
briefly, but essentially all storage is via relational tables - vertices,
primitives, and objects. All tables can have any attributes (or none) and
all operations have default choices of which attributes are used (i.e. x,
y, z, time or lon, lat, z, time - or whatever you want to call them). It's
very natural once you are familiar with it. Attribute flexibility on
vertices means you can manually set whatever you want. I.e. calculate then
triangulate in theta/phi, then process which triangles are "on top", and
voila you have a viewshed analysis. Manifold is stuck in 2D for now but the
editing tools, use of selections, natural use of layers not tied to files,
constrained triangulations, and general slickness and price put it way
ahead of other options IMO even before the new Radian engine is released.
When the eyetracking thing is finally put to bed and I get an rgl
compatible laptop that is not my wife's laptop (as things currently stand),
and when I'm a tad better at r, I'd be happy to help with the evolution of
this 3d.
That sounds great, I'm keen to find out what you are doing. That is another
very good point in the "spatial is not special" spectrum. "Spatial" is
really everything, maps are just one kind of "projection", long-lat, x-y-z,
and time are inherent to many things but not everything. Topology exists in
all kinds of applications. Date time metadata on numeric is a "projection"
for example.
I'd like to see a really general framework where geometry and topology are
the basis and things like sp (and now sfr) can be built on it. I see it as
inevitable that dplyr or its successor is where that's going to happen -
seamless back-ending with a data base is just one reason - and with ggvis
to replace ggplot2 it will be the go-to tool for visualization and
user-interaction with spatial data. Hopefully the ongoing modernization of
PROJ.4 will also assist in that being just a choice in a
"projection-engine" family.
At the moment I'm concentrating on https://github.com/mdsumner/spbabel
which shows some of the ways to nest spatial data in data frames (via
tidyr) , in a two-level way analogous to sp objects and an "inside-out" way
that's a better match for gris (nested data frames and the ggplot2::fortify
approach can't do this but it's a requirement for topological structures
including triangulation). It's all in-dev and unstable for now.
Finally, all of my work in this area relies on the tools in dplyr - for
table manipulations - and RTriangle - for constrained triangulation.
Cheers, Mike.
Chris
On Fri, Apr 15, 2016 at 10:06 PM, Eamon Caddigan <eamon.caddigan at gmail.com
wrote:
On Thu, Apr 14, 2016 at 9:30 PM, Michael Sumner <mdsumner at gmail.com>
wrote:
On Fri, 15 Apr 2016 at 10:36 Eamon Caddigan <eamon.caddigan at gmail.com>
wrote:
Hi all,
I am looking to extend the SpatialPoints and SpatialPointsDataFrame
classes
to include altitude information. Somebody recommended I check in with
this
group for pointers before getting too far along on this.
It's possible for Points in sp, but not for polygons or lines.
library(sp)
x <- matrix(rnorm(27), ncol = 3)
SpatialPoints(x)
But, the general support outside this in sp is very limited once you
break
out of the plane.
Thanks Mike!
I had no idea that coordinates() handled three-dimensional matrices
already. In that case, it looks like I don't have to do anything at all
(for now).
I'm working on tools to make this much easier, and to translate from sp
to
other forms and back.
I look forward to seeing what comes out of this!
-Eamon