Skip to content

Subject: RE: [R-sig-Geo] maptools package rejects some polygon shapefiles?

5 messages · Nicholas Lewin-Koh, Roger Bivand

#
Hi,
Wouldn't it make more sense to handle 3d file as 3d?
In outher words store 3d poionts as 3d points. For dealing 
with this in R, we could write methods that would display the 
3rd dimension as an attribute. I don't think it would be hard to change
the
underlying C code to reade shape 3d files. I think the challange would
be in the
R data structure and methods.

Nicholas

Date: Thu, 12 May 2005 10:58:31 +0200 (CEST)
From: Roger Bivand <Roger.Bivand at nhh.no>
Subject: RE: [R-sig-Geo] maptools package rejects some polygon
        shapefiles?
To: Rick Reeves <reeves at nceas.ucsb.edu>
Cc: r-sig-geo at stat.math.ethz.ch
Message-ID: <Pine.LNX.4.44.0505121055521.11044-100000 at reclus.nhh.no>
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Wed, 11 May 2005, Rick Reeves wrote:

            
Rick:

(I'm replying to the list too to ask for comments)

The file is recognised by ogrinfo as:

$ ogrinfo NorthAmericaBest.shp
INFO: Open of `NorthAmericaBest.shp'
using driver `ESRI Shapefile' successful.
1: NorthAmericaBest (3D Polygon)

It should not be too difficult to change read.shape to read 3D points as
3D, and 3D lines and polygons as 2D. I guess that stripping the Z values
is not a problem for anybody (excepting points I think)?

Thanks for your help - with a sample file to study, making this work
will
be much easier. Does anyone have 3D lines and 3D points files?

Best wishes,

Roger

  
    
#
On Thu, 12 May 2005, Nicholas Lewin-Koh wrote:

            
For points, 3D will be OK, one Z value per point, hence an attribute. But 
with lines and polygons, is anyone likely to need all three dimensions? 
The attributes are attached to each shape, which implies that a per vertex 
attribute would be a different kind of thing, wouldn't it? Which research 
situations might need 3D for anything other than points? It can probably 
be done, but the sp package lines and rings are 2D, and they would be the 
containers I would look at first (unless persuaded otherwise).

Roger

  
    
#
Hi,
No I actually meant to have a slot, or place for the 3rd dimension. and
for plotting methods treat it like an attribute. I was trying to think
of situations where 
3d lines or polygons would be useful, admittedly I am a little stumpped,
but I am sure
there must be something other than pretty flythroughs :) Maybe a polygon
view of a surface 
where thew polygon heights are interpolated from binned data to the
vertices of the polygon?

Nicholas

On Thu, 12 May 2005 18:09:45 +0200 (CEST), "Roger Bivand"
<Roger.Bivand at nhh.no> said:
#
On Thu, 12 May 2005, Nicholas Lewin-Koh wrote:

            
I can see why visualising points is worth the trouble, and by extension 
voxels. Maybe even for polylines, such as showing the gradient of a 
stream by plotting z against the (x,y) distances. But plotting the varying 
z of a polygon boundary (this is a 2.5D object, I think, not CAD/CAM, 
non-self-intersecting?)? 

Maybe go by steps and see how easy it is to return the line and polygon z
values in the matrix of coordinates, and strip them by default? Something
like that? The z values in the original posting were spurious, ArcGIS just
output them, the data were decimal degree lat-long of a coastline.

Shall I put the maptools package code on sourceforge?

Roger

  
    
12 days later
#
Calling Arc users!

Could somebody please make available some small example 3D points and arcs
for me to try out on read.shape() (or a link to a public repository of
type POINTZ, ARCZ, and POLYGONZ shapefiles). 3D polygons now work, thanks
to an example file from Rick Reeves, but I have no way of creating 3D
points or lines to check the function in action, and I don't want to 
release an untried function (inviting seg.faults).

The idea is to support 3D points directly, but to drop the Z values for 
lines and polygon boundaries - the original example was anyway for the 
coastline of North America in latlong, so the Z value wasn't so important. 
Having discussed transect or track data at the Valencia "sp" meeting, we 
think that a transect should be a SpatialPoints object (which can take 3D 
points), not a line; this will need extra attention when plotting.

Roger
On Thu, 12 May 2005, Nicholas Lewin-Koh wrote: