Skip to content

wkbMultiPoint and rgdal

5 messages · Jonathan Greenberg, Dylan Beaudette, Roger Bivand +1 more

#
R-sig-geo'ers:

I have an ESRI shapefile which has multi-point geometry, and I'm
trying to get it into R for use with sp() and raster().  Using:

points=readOGR(dsn=getwd(),layer="tnf_sub_2_TreeDig_pts_110725_v02")
returns:

Error in readOGR(dsn = getwd(), layer = "tnf_sub_2_TreeDig_pts_110725_v02",  :
  Incompatible geometry: 4
In addition: There were 50 or more warnings (use warnings() to see the first 50)

the warnings all say:
...
50: In readOGR(dsn = getwd(), layer = "tnf_sub_2_TreeDig_pts_110725_v02",  ... :
  eType not chosen

What I really want is to, in the end, have a SpatialPointsDataFrame
where each multi-point feature is converted to individual points that
have the attribute of what multi-point feature it came from.  What is
the best way to do this?  I'm attaching the zipped shapefile to this
email (hopefully it won't get bounced).

--j
#
Hi Jonathan,

My tool of choice for this operation is PostGIS. If you happen to have
a postgis db ready to go, simply import your problem file using the
postgis shapefile import tool and process there. Some tips here:

http://amercader.net/blog/2011/04/exploding-multigeometries-with-postgis

Cheers,
Dylan

On Tue, Jul 26, 2011 at 2:13 PM, Jonathan Greenberg
<greenberg at ucdavis.edu> wrote:
1 day later
#
Hi Dylan:

Thanks -- I'm a bit of a PostGIS noob so I ended converting it to a
normal point file with the XTools extension in Arc.  I'm surprised
there is no support for this data type in any R package, since I would
think it is a fairly common type.  Ah well!

--j

On Tue, Jul 26, 2011 at 2:28 PM, Dylan Beaudette
<dylan.beaudette at gmail.com> wrote:

  
    
#
On Thu, 28 Jul 2011, Jonathan Greenberg wrote:

            
Jonathan,

Not really, as this is the first time I can recall it being mentioned in 8 
years. It is far from obvious what one could do with it that couldn't more 
properly be done with a SpatialPointsDataFrame with a grouping factor. 
What is the implied support of the data? What are the attributes attached 
to - say var1 was observed at which of the member points? All of them 
simultaneously? If they form a line or polygon, then support is clear(er), 
but if a multipoint observation is better handled as described above, then 
it should be. Support is absolutely crucial for clarity in analysis (and 
visualization), I think.

Roger

PS: this is a similar case to that of the unusual M coordinate in some 
shapefiles - if it cannot be shown how this relates consistently to 
support, it shouldn't be admitted, I think. If we lose clear understanding 
of support for observation attributes, we cease to be able to interact 
with statisticians, and that interaction really matters.

  
    
#
This is a fundamental philosophical point that I haven't seen made
explicitly before, and I appreciate hearing it and I'm sorry if I've
missed it being laid out previously.

There is another example, similar (I think) to the multipoint one
(you'll find an implementation of multipoint inheriting from lines in
the ASDAR book btw, similar to how 'polygons' inherit from lines in
almost all software I am aware of).

sp's data structures purposely do not support the Z attribute on
vertices either, let alone the M one. If it were up to me I would
stick to the the GDAL/OGR (or OGC model) and let users take the
responsibility of what sense it makes. Points and lines present
absolutely no topological problems for n-dimensional geometry -
polygons do but that's because they are not true 2D topology.

I work in data transfer far more than I do in statistical analytics so
I guess that is mainly where the difference in perspective comes from.
I've come close to being able to modify the designs to do things how I
would like but it's mostly beyond me, I'm not complaining I wish I had
the skills to branch and write my own versions.

Cheers, Mike.
On Fri, Jul 29, 2011 at 5:57 PM, Roger Bivand <Roger.Bivand at nhh.no> wrote: