[R-sig-Geo] problem extracting Z value from line shapefile

Barry Rowlingson b.rowlingson at lancaster.ac.uk
Wed Jul 25 11:13:18 CEST 2012


On Wed, Jul 25, 2012 at 8:22 AM, zbynek.janoska at centrum.cz
<zbynek.janoska at centrum.cz> wrote:

> Warning message:
> In readOGR("C:/Users/Janoska/Documents/GPS", "tesikov") :
>   Z-dimension discarded
>
> Clearly, Z dimension is stored in the data, but readOGR does not read it.
> Hence, I followed this post:
> https://stat.ethz.ch/pipermail/r-sig-geo/2007-March/001847.html
>
> data <- coordinates(readShapeLines('path/tesikov.shp'))
>> str(data)
> List of 1
>  $ :List of 1
>   ..$ : num [1:335, 1:2] -540376 -540369 -540361 -540353 -540344 ...
>
> Resulting coordinates have only two dimensions.
>
> I am wondering, whether Z dimension can be extracted only from points?

 It looks that way. SpatialPoints can have more than two coordinates:

 > SpatialPoints(cbind(1:10,1:10,1:10))
SpatialPoints:
      coords.x1 coords.x2 coords.x3
 [1,]         1         1         1
 [2,]         2         2         2

But Line objects cant:

 > Line(cbind(1:10,1:10))
An object of class "Line"
Slot "coords":
      [,1] [,2]
 [1,]    1    1
 [2,]    2    2
 [3,]    3    3

> Line(cbind(1:10,1:10,1:10))
Error in Line(cbind(1:10, 1:10, 1:10)) :
  coords must be a two-column matrix

 - so its not possible to store a third dimension in a
SpatialLinesDataFrame that way.

 You can do horrible things to Line objects once they've been created,
and add extra columns, but there's some validation code you'd be
bypassing, and all sorts of bad things could happen if code assumes
Line objects have two columns and you go sticking your extra column in
there.

 What you could do is...

 * convert to GML ( ogr2ogr -f "GML" rivers3.gml rivers3.shp - will do
this on the linux command line, Windows versions may vary), then:
 * read the GML in using an XML-reading package for R. The Z
coordinates are then right there in a space and comma-separated
string.

OR

 * dump the shapefile using "ogrinfo -al -geom=YES rivers3.shp" and
parse out the x,y,z coords from the LINESTRINGs

 You've then got the issue of how to store them and how to work with
them. The safest way might be as an extra attribute on each Line
element rather than an extra column.

 This probably needs a lot more thought, but these 3d shapefiles are
usually quite rare in the wild so they don't get a lot of attention.
Unlike rare wildlife...

Barry



More information about the R-sig-Geo mailing list