[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