[Liblas-devel] updating liblas dependencies to support EPSG:2966

[Charles Cowart]

Hi Howard,

We modified the /share data in proj and was able to reproject successfully, but the geotiff tags themselves are missing TM projection info, etc. We're currently reviewing the /share data in gdal and libgeotiff as well. The projection info is missing whether or not we include the vertical.

Charles

On May 16, 2012, at 8:20 AM, Howard Butler wrote:

> Assuming you're using the latest liblas/gdal/proj/geotiff, there must be something in mapping the GeoTIFF keys to EPSG lookups of 2966.  If you don't add the +5703, do you get legit DATUM and SPHEROID entries?
> 
> 
> On May 11, 2012, at 2:05 PM, Crosby, Christopher wrote:
> 
>> Hi Everyone,
>> I just wanted to follow up on this inquiry from Charlie last week regarding using libLAS to assign coordinate information to a batch of LAS files.  The dataset is in EPSG: 2966 (http://spatialreference.org/ref/epsg/2966/ - note spatialreference.org appears to be down at the moment ), but when libLAS is used to generate the VLRs it appears to be writing an incomplete definition (DATUM and SPHEROID are "unknown" / "unretrievable") and thus later operations such as projection fail. 
>> 
>> Is this problem related to libLAS, or the underlying GDAL/proj4 libraries? Does anyone have a recommendation for a work around?
>> 
>> Thanks,
>> 
>> -Chris
>> 
>> On May 4, 2012, at 3:57 PM, Charles Cowart wrote:
>> 
>>> Hi Howard,
>>> 
>>> We've recently tried to annotate a dataset with EPSG:2966+5703 and liblas inserts the following into the VLRs:
>>> 
>>> LOCAL_CS["NAD83 / Indiana West (ftUS) + VERT_CS",
>>>  GEOGCS["NAD83",
>>>      DATUM["unknown",
>>>          SPHEROID["unretrievable - using WGS84",6378137,298.257223563]],
>>>      PRIMEM["Greenwich",0],
>>>      UNIT["degree",0.0174532925199433]],
>>>  AUTHORITY["EPSG","2966"],
>>>  UNIT["US survey foot",0.3048006096012192]]
>>> 
>>> 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,38): "NAD83 / Indiana West (ftUS) + VERT_CS"
>>>    GeogCitationGeoKey (Ascii,6): "NAD83"
>>>    GeogAngularUnitsGeoKey (Short,1): Angular_Degree
>>>    ProjectedCSTypeGeoKey (Short,1): Unknown-2966
>>>    ProjLinearUnitsGeoKey (Short,1): Linear_Foot_US_Survey
>>>    VerticalCSTypeGeoKey (Short,1): Unknown-5703
>>>    VerticalCitationGeoKey (Ascii,14): "NAVD88 height"
>>>    VerticalDatumGeoKey (Short,1): Unknown-5103
>>>    VerticalUnitsGeoKey (Short,1): Linear_Meter
>>>    End_Of_Keys.
>>> End_Of_Geotiff.
>>> 
>>> This doesn't reflect what is listed in spatial reference.org (http://spatialreference.org/ref/epsg/2966/), and doesn't appear to be enough to reproject the data into other coordinates systems. Do you know if it's possible to insert the information found in spatial reference.org into proj so that it will insert VLR data like that found in the link?
>>> 
>>> Best Regards,
>>> 
>>> Charles
>>> 
>>> _______________________________________________
>>> Liblas-devel mailing list
>>> Liblas-devel at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/liblas-devel
>> 
>> _______________________________________________
>> Liblas-devel mailing list
>> Liblas-devel at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/liblas-devel
> 
> _______________________________________________
> Liblas-devel mailing list
> Liblas-devel at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/liblas-devel