[R-sig-Geo] Extending sp's SpatialPoints with altitude information
englishchristophera at gmail.com
Sat Apr 16 06:39:10 CEST 2016
Eonfusion sounds interestingly reminiscent of Ted Nelson's Project Xanadu,
though finding a nearly working version is a very rare bird in the wild.
On Sat, Apr 16, 2016 at 1:15 AM, Michael Sumner <mdsumner at gmail.com> wrote:
> On Sat, 16 Apr 2016 at 07:04 chris english <englishchristophera at gmail.com>
>> 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.
>> 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>
>>> > 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
>>> >> 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
>>> > 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!
>> [[alternative HTML version deleted]]
>>> R-sig-Geo mailing list
>>> R-sig-Geo at r-project.org
> Dr. Michael Sumner
> Software and Database Engineer
> Australian Antarctic Division
> 203 Channel Highway
> Kingston Tasmania 7050 Australia
[[alternative HTML version deleted]]
More information about the R-sig-Geo