[Liblas-devel] las2las2 vertical crs VerticalCitationGeoKey

Allan Adair allan.m.adair at gmail.com
Tue Oct 5 10:47:01 EDT 2010


*I ran across something when defining and retrieving spatial/vertical
reference information using las2las2 and lasinfo. I grabbed the source
yesterday and did a build. Here is an example of using the las2las2 utility:
*

las2las2.exe --input LID35094D7NEC.las --a_srs PROJCS["NAD83 / UTM zone
15N",GEOGCS["NAD83",DATUM["North_American_Datum_1983",SPHEROID["GRS
1980",6378137,298.257222101,AUTHORITY["EPSG","7019"]],AUTHORITY["EPSG","6269"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.01745329251994328,AUTHORITY["EPSG","9122"]],AUTHORITY["EPSG","4269"]],UNIT["metre",1,AUTHORITY["EPSG","9001"]],PROJECTION["Transverse_Mercator"],PARAMETER["latitude_of_origin",0],PARAMETER["central_meridian",-93],PARAMETER["scale_factor",0.9996],PARAMETER["false_easting",500000],PARAMETER["false_northing",0],AUTHORITY["EPSG","26915"],AXIS["Easting",EAST],AXIS["Northing",NORTH]]
--a_vertcs 5703 "North American Vertical Datum of 1988 (NAVD88)" 5103 9001

*This creates an "output.las" by default with the new spatial/vertical
reference information. Here is part of the output when using the lasinfo to
retrieve the spatial/vertical reference information:*

C:\>lasinfo output.las
ERROR 4: Unable to open EPSG support file gcs.csv.
Try setting the GDAL_DATA environment variable to point to the
directory containing EPSG csv files.
ERROR 4: Unable to open EPSG support file gcs.csv.
Try setting the GDAL_DATA environment variable to point to the
directory containing EPSG csv files.

---------------------------------------------------------
  Header Summary
---------------------------------------------------------
  File Name: output.las
  Version:                    1.0
  Source ID:                  0
  Reserved:                   0
  Project ID/GUID:           '00000008-001e-07d1-0000-000000000000'
  System Identifier:         ''
  Generating Software:       'Merrick LiDAR Processing System'
  File Creation Day/Year:    83/2006
  Header Size                227
  Offset to Point Data       17143
  Number Var. Length Records 47
  Point Data Format          1
  Point Data Record Length   28
  Number of Point Records    396899
  Number of Points by Return 343468 47125 6107 199 0
  Scale Factor X Y Z         0.001 0.001 0.001
  Offset X Y Z               0.000000 3000000.000000 0.000000
  Min X Y Z                  335523.597000 3925299.686000 156.189000
  Max X Y Z                  336171.654000 3926537.052000 192.926000
 Spatial Reference           +proj=utm +zone=15 +ellps=GRS80 +datum=NAD83
+units
=m +no_defs
Geotiff_Information:
   Version: 1
   Key_Revision: 1.0
   Tagged_Information:
      End_Of_Tags.
   Keyed_Information:
      GTModelTypeGeoKey (Short,1): ModelTypeProjected
      GTRasterTypeGeoKey (Short,1): RasterPixelIsArea
      GTCitationGeoKey (Ascii,17): "NAD83/UTMzone15N"
      GeogCitationGeoKey (Ascii,6): "NAD83"
      GeogAngularUnitsGeoKey (Short,1): Angular_Degree
      ProjectedCSTypeGeoKey (Short,1): PCS_NAD83_UTM_zone_15N
      ProjLinearUnitsGeoKey (Short,1): Linear_Meter
      VerticalCSTypeGeoKey (Short,1): Unknown-5703
      VerticalCitationGeoKey (Ascii,47): "North American Vertical Datum of
1988
(NAVD88╠"
      VerticalDatumGeoKey (Short,1): Unknown-5103
      VerticalUnitsGeoKey (Short,1): Linear_Meter
      End_Of_Keys.
   End_Of_Geotiff.

*Ignoring the error messages at the beginning of the output, I see that
there is a symbol at the end of the "VerticalCitationGeoKey". I get the same
issue if I alter the text, the last character is not visible and is replaced
with the same unwanted piece of data. Outside of aesthetics, will this
affect how the vertical reference information is interpreted by software
that supports these tags?


Thanks,

Allan Adair*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/liblas-devel/attachments/20101005/4115d9e8/attachment.html


More information about the Liblas-devel mailing list