[R-sig-Geo] agenda for R's Geo capabilities?

Tim Keitt tkeitt at gmail.com
Sun Mar 18 21:14:17 CET 2007 

I agree GEOS support would be welcome. I'd be happy to help out if
anyone takes this on.

I've been thinking of a possibly quicker (devel time) solution lately
since I've been using PostGIS a lot. One could have a postgis package
that copies 'sp' object into postgis and then provides postgis
function equivalents that operate on the R proxy objects.

pgobj1 <- new('PostGISGeom', my.spatial.polygons)
pgobj2 <- somePostGISOp(pgobj1, ...)

res.spatial.polygons <- PGObj2SPObj(pgobj2)  # or 'as' generic

The pgobj? objects could be first class 'sp' members if it is possible
to subclass the 'sp' geometry classes -- may not be possible as I
don't think you can overload the S4 slot call.

THK

On 3/16/07, Edzer J. Pebesma <e.pebesma at geo.uu.nl> wrote:
> Although I'm interested many of the issues below, and also feel the
> attraction of the develop-it-ourself, my personal agenda is a bit more
> modest. Once we start with GEOS support (an idea mentioned every 6
> months on this list), the next thing we need for dealing with huge or
> massive data sets is a clever indexing structure. After that, full
> topology. I find it hard to imagine where the resources should come from
> for all these things that are available in OSGeo next door -- we can't
> settle with proof of concepts, but want quality stuff. OTOH, one day a
> student may come in who just finished two of these projects.
>
> My primary goal is to get sp stable, and adopted by more of the numerous
> packages for analyzing spatial data in R. And yes, I did introduce an
> instabillity this week -- try [ on a SpatialPolygonsDataFrame with NA
> values in the row index. There's a lot of code, much of which is little
> tested and/or not very clean. Another goals is to get a good and smooth
> system where R works as a back-end in interopable systems, possibly
> using PostGIS to transfer data. Finally: further proof that R is a
> increasingly wonderful system for analyzinig spatial data.
> --
> Edzer
>
> White.Denis at epamail.epa.gov wrote:
> > The thread below and many others in R-sig-Geo raise questions about
> > future directions.  In reinventing GIS there are a whole list of
> > capabilities and functions that would be helpful.  Some that I have
> > noticed include,
> >
> > Topological representation to enable
> >       Planar enforcement of boundary integrity of polygon tessellations
> >       "Dissolving" interior edges easily as in the thread below
> > Large problem computational geometry functions
> >       Identify many points inside of many polygons
> >       Intersections/overlays of two sets of many polygons
> >       Distances between all pairs of many polygons
> >
> > Are there members of the R Geo community working on any of these?
> > Are these issues seen as an exclusive focus of commercial GIS?
> > Are there discussions about these issues at relevant conferences?
> >
> > (I will be at AAG in San Francisco and would be happy to meet with
> > others if there is interest.)
> >
> > r-sig-geo-bounces at stat.math.ethz.ch wrote on 2007-03-16 07:52:59:
> >
> >
> >> Hi Tim,
> >> You could compute the convex hull first, and then iterate from points
> >> on the convex hull. That should be much faster already, especially
> >>
> > since
> >
> >> hexagons are convex and the perimeter will be locally convex around
> >>
> > all
> >
> >> the
> >> points touching the convex hull. You could do a variation
> >> of the "monotone pieces" algorithm that is used in computational
> >> geometry.
> >> But this is a simpler problem. Are there cases with interior holes?
> >>
> >> I have been meaning to write something like this for hexbin for a
> >>
> > while.
> >
> >> There
> >> are many cases where it would be nice to find approximations to the
> >> density contours
> >> and a quick and dirty way is to threshold the hexagon counts, find the
> >> hull and
> >> smooth the perimeter.
> >>
> >> Nicholas
> >>
> >> On Fri, 16 Mar 2007 08:34:20 -0500, "Tim Keitt" <tkeitt at gmail.com>
> >>
> > said:
> >
> >>> Hi Nic,
> >>>
> >>> The convex hull would be fast and easy to compute (there's existing
> >>> code in R). I want the ordinary hull which is the set of arcs
> >>>
> > forming
> >
> >>> the perimeters (inside and out). My crude and very slow solution was
> >>> to convert all the polygons (in this case hexagons on a lattice)
> >>>
> > into
> >
> >>> their constituent arcs and then for each arc count how many times it
> >>> occurs in the set (requires slightly fuzzy matching of points). Arcs
> >>> that occur more than once are removed. The remaining arcs form the
> >>> hull. Runs in about 20 minutes with a  few hundred hexagons.
> >>> Sufficient for the moment.
> >>>
> >>> THK
> >>>
> >>> On 3/16/07, Nicholas Lewin-Koh <nikko at hailmail.net> wrote:
> >>>
> >>>> Hi Tim,
> >>>> I am not quite sure what you are getting at here. Do you want to
> >>>> intersect
> >>>> polygons and then select the set of lines that form the outer
> >>>>
> > perimeter?
> >
> >>>> Do you wan the convex hull of a set of polygons. I guess I have
> >>>>
> > been out
> >
> >>>> of the
> >>>> GIS world to long. It seems to me that this would be something
> >>>>
> > easy to
> >
> >>>> solve,
> >>>> just tedious iteration of the polygon coordinates and some
> >>>> triangulation.
> >>>>
> >>>> Nicholas
> >>>>
> >>>>
> >>>>> Date: Thu, 15 Mar 2007 10:49:23 -0500
> >>>>> From: "Tim Keitt" <tkeitt at gmail.com>
> >>>>> Subject: [R-sig-Geo] polygons to arcs?
> >>>>> To: r-sig-geo at stat.math.ethz.ch
> >>>>> Message-ID:
> >>>>>
> >>>>>
> > <6262c54c0703150849qe60ab14nfef1eb3bf73dfb5d at mail.gmail.com>
> >
> >>>>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> >>>>>
> >>>>> Is there an 'sp' function that takes a polygon as its argument
> >>>>>
> > and
> >
> >>>>> returns a set of line objects corresponding to the arcs in the
> >>>>> polygon?
> >>>>>
> >>>>> Or better yet, a function that given a set of polygons, returns
> >>>>>
> > the
> >
> >>>>> hull? (ie the set of singleton arcs after applying the polys to
> >>>>>
> > arcs
> >
> >>>>> function)
> >>>>>
> >>>>> THK
> >>>>>
> >>>>> --
> >>>>> Timothy H. Keitt, University of Texas at Austin
> >>>>> Contact info and schedule at http://www.keittlab.org/tkeitt/
> >>>>> Reprints at http://www.keittlab.org/tkeitt/papers/
> >>>>> ODF attachment? See http://www.openoffice.org/
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>> --
> >>> Timothy H. Keitt, University of Texas at Austin
> >>> Contact info and schedule at http://www.keittlab.org/tkeitt/
> >>> Reprints at http://www.keittlab.org/tkeitt/papers/
> >>> ODF attachment? See http://www.openoffice.org/
> >>>
> >> _______________________________________________
> >> R-sig-Geo mailing list
> >> R-sig-Geo at stat.math.ethz.ch
> >> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
> >>
> >
> > _______________________________________________
> > R-sig-Geo mailing list
> > R-sig-Geo at stat.math.ethz.ch
> > https://stat.ethz.ch/mailman/listinfo/r-sig-geo
> >
>
> _______________________________________________
> R-sig-Geo mailing list
> R-sig-Geo at stat.math.ethz.ch
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>


-- 
Timothy H. Keitt, University of Texas at Austin
Contact info and schedule at http://www.keittlab.org/tkeitt/
Reprints at http://www.keittlab.org/tkeitt/papers/
ODF attachment? See http://www.openoffice.org/

More information about the R-sig-Geo mailing list