vertical datums like "NAVD88 height - Geoid12A" in OGC WKT and GeoTIFFs

[Martin Isenburg]

Hello,

more and more often I see vertical datums in the OGC WKT strings that look like the one copied below. As far as I know the GeoTIFF tags only support the standard variant of NAVD88 in the current set of codes. Are there more NAVD88 variants that need to be supported in the OGC WKT strings than in the GeoTIFF tags for the vertical datum? And if yes, which ones? I have seen only a few very similar variant of the one below and only in the North American market. If this is something important there (latest USGS specification?) then I would like to add support for all commonly used ones to LAStools so that USGS specification conform OGC WKT strings can be produced with the free (also for commercial use) and open source las2las tool.

http://rapidlasso.com/las2las

http://lastools.org/download/las2las_README.txt

Can someone send me a comprehensive list of those used 99% of the time? 

Regards,

Martin @rapidlasso

COMPD_CS["NAD83(2011) / UTM zone 10N / NAVD88 height - Geoid12A (metres)",PROJCS["NAD83(2011) / UTM zone 10N",GEOGCS["NAD83(2011)",DATUM["NAD83_National_Spa

tial_Reference_System_2011",SPHEROID["GRS 1980",6378137,298.257222101,AUTHORITY["EPSG","7019"]],AUTHORITY["EPSG","1116"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG",

"8901"]],UNIT["degree",0.0174532925199433,AUTHORITY["EPSG","9122"]],AUTHORITY["EPSG","6318"]],PROJECTION["Transverse_Mercator"],PARAMETER["latitude_of_origin",0

],PARAMETER["central_meridian",-123],PARAMETER["scale_factor",0.9996],PARAMETER["false_easting",500000],PARAMETER["false_northing",0],UNIT["metre",1,AUTHORITY["

EPSG","9001"]],AXIS["Easting",EAST],AXIS["Northing",NORTH],AUTHORITY["EPSG","6339"]],VERT_CS["NAVD88 height - Geoid12A (metres)",VERT_DATUM["North American Vert

ical Datum 1988",2005,AUTHORITY["EPSG","5103"]],UNIT["metre",1.0,AUTHORITY["EPSG","9001"]],AXIS["Gravity-related height",UP],AUTHORITY["EPSG","5703"]]]

[Kirk Waters - NOAA Federal]

Martin,

I would say that there probably are. The addition of the Geoid12A is the indicator of which geoid model was applied to GPS measurements in order to arrive at an orthometric height. That is potentially (some would say certainly at the cm level) different from the NAVD88 datum arrived at through leveling. There isn't really another place to put information about the geoid model as far as I know. The current model is GEOID12B. Previous to GEOID12A were GEOID09 and several earlier models, but I don't think many people are/were trying to put those in WKT strings. I would expect something similar is true in other countries, though I'm not familiar with those cases. 

By the way, GEOID12B is almost the same as GEOID12A. I believe the primary difference is in Puerto Rico and USVI. There is also work going on to for a gravimetric geoid model (https://beta.ngs.noaa.gov/GEOID/xGEOID/). I haven't wrapped my head around the implications of that yet.

Regards,

Kirk Waters, PhD                     | NOAA Office for Coastal Management

Applied Sciences Program      | 2234 South Hobson Ave
843-740-1227                          | Charleston, SC 29405    

coast.noaa.gov/digitalcoast

--
Download LAStools at
http://lastools.org
http://rapidlasso.com
Be social with LAStools at
http://facebook.com/LAStools
http://twitter.com/LAStools
http://linkedin.com/groups/LAStools-4408378
Manage your settings at
http://groups.google.com/group/lastools/subscribe

[Vinopal, Matthew]

This is a requirement for Lidar Base Specification 1.2 for USGS submittals of LAS 1.4 files.

--

[Stoker, Jason]

Hi all- Forwarding a reply from Karl Heidemann on this topic:

NAVD88 is an orthometric datum.  As such, it incorporates a geoid model to adjust from ellipsoid heights to geoid )orthometric) heights.

For MOST users, this is of little concern, as their AOIs are relatively limited, their update cycles are long, and their references are well-known throughout their relatively small user community. 

The USGS, quite the other hand, actively manages elevation data covering several decades, several geoid models, thousands of stakeholders, and thousands of AOIs.  Knowing the the geoid model used in each dataset is critical to developing consistent models that span disparate collections from different time periods, and providing data to our customer with usable and detailed metadata on its spatial reference.  Thus, we MUST know the geoid model, and it must be reported in a consistent, machine-readable manner.

Unfortunately, none of the WKT standards, nor the EPSG database, provide clear and adequate means to record and report the geoid model.  Rather, NAVD88  is internally defined using a given geoid model. As new geoids are developed, the definition of NAVD88 is updated to reflect the new geoid. As noted, this may be fine for most users, but it is extremely problematic for an agency that manages data covering 3000 counties and 3.5M square miles. We cannot determine what geoid was used for the datum  on given (particularly older) datasets.  We therefore must impose an "additional" requirement in our WKT specification, to include the Geoid.

We cannot unilaterally create a special tag, as it would not be part of the WKT specifications and would not be interpreted (correctly) by software.  Our solution, for the present, is to append the Geoid model, by common name (e.g., "GEOID12B"), to the vertical datum name, as these entries are read only as a last resort in identifying the full CRS, at the failing of reading valid EPSG codes, and thus can be more tolerant of variation (a person will likely have to read it anyway).

I would recommend four changes to the WKT sample in the original message: [RED is deletion; Blue is addition, if you can see the colors.]

1. The only correct delimiter between Horizontal and Vertical CRS names in the COMPD_CS tag is the "+" sign. Software has to be programmed to look for a known delimiter to parse H from V.  In the original example, there are two "/"s. This will create either problems, or a lot of unnecessary and unpleasant coding.
   
2. In CRSs (both H & V), it is not necessary to write "metres" or "meters" (either spelling is fine), as meters is the the defined default unit for CRSs, and is thus understood. Plus, the units are given in the parameters, both as a name and as a code (if they are not, the data should be returned to the data producer anyway).
   
3. The "2005," in the VERT_DATUM tag is not part of the name.  It appears in some software, but not others. We rely on the epsg database as the authoritative source and reference, in which the VERT_DATUM is simply: "North American Vertical Datum 1988".
4. AXIS entries (as with all entries) must include the AUTHORITY entry, unless none exists (an unlikely-to-rare case in America).
   

COMPD_CS["NAD83(2011) / UTM zone 10N +/ NAVD88 height - Geoid12A (metres)",

PROJCS["NAD83(2011) / UTM zone 10N (metres)",

  GEOGCS["NAD83(2011)",

    DATUM["NAD83_National_Spatial_Reference_System_2011",

      SPHEROID["GRS 1980",6378137,298.257222101,

        AUTHORITY["EPSG","7019"]],

      AUTHORITY["EPSG","1116"]],

    PRIMEM["Greenwich",0,

      AUTHORITY["EPSG","8901"]],

    UNIT["degree",0.0174532925199433,

      AUTHORITY["EPSG","9122"]],

    AUTHORITY["EPSG","6318"]],

  PROJECTION["Transverse_Mercator"],

    PARAMETER["latitude_of_origin",0],

    PARAMETER["central_meridian",-123],

    PARAMETER["scale_factor",0.9996],

    PARAMETER["false_easting",500000],

    PARAMETER["false_northing",0],

    UNIT["metre",1,

      AUTHORITY["EPSG","9001"]],

  AXIS["Easting",EAST],

   AUTHORITY["EPSG","9906"]],

  AXIS["Northing",NORTH],

   AUTHORITY["EPSG","9907"]],

  AUTHORITY["EPSG","6339"]],

  VERT_CS["NAVD88 height - Geoid12A (metres)",

    VERT_DATUM["North American Vertical Datum 1988",2005,

      AUTHORITY["EPSG","5103"]],

    UNIT["metre",1.0,

      AUTHORITY["EPSG","9001"]],

    AXIS["Gravity-related height",UP],

     AUTHORITY["EPSG","9904"]]

    AUTHORITY["EPSG","5703"]]]

NOTES: 

1. Newlines are added for clarity only. The actual entries may not contain any non-printable characters. 
2. I am advocating that the adopted standard form for the geoid be:  "NAVD88(Geoid12A) height", with defined names for each geoid model, in keeping with the form used for horizontal datums, e.g., "NAD83(2011)".  But we'll all see what the EPSG and the OGC come up with.
3. At present, because the EPSG has not clearly defined geoid names and we don't want to pre-empt them, and because WKT specifications do not include any guidance on reporting geoid model, the USGS does not currently require the reporting of the geoid, much as we want it reported. THAT SAID, the requirement is coming and we encourage everybody to prepare in advance.

 As for a comprehensive list, the USGS requires all data be in NAVD88; the following are the geoids that have been used over the past couple of decades and may appear. I cannot imagine anybody would produce data in NGVD29, but stranger things have happened.

• GEOID12B
  
• GEOID12A
  
• GEOID12
  
• GEOID09
  
• GEOID06
  
• GEOID03
  
• GEOID99
  
• GEOID96
  

BTW, Geoid12A and Geoiod12B are identical except in the region of Puerto Rico and the US Virgin Islands. So unless the data is in those areas, Geoid12A can and should be reported as GEOID12B.

What is or is not possible or available in GeoTIFF tags is of little concern to the USGS when it comes to current lidar collections or delivery.   And to reiterate from above, the actual identification of the CRSs and their parameters is expected to be done first by using the EPSG codes (which should in virtually every case be complete and correct); secondly by the names of the parameter values, and finally --if all else fails-- by the names of the CRSs.

Hope this clarifies a few things,

Karl

H. Karl Heidemann, GISP, CMS

Physical Scientist, Lidar Science

U.S. Geological Survey

Mundt Federal Building

47914 252nd Street

Sioux Falls, SD  57198

605-594-2861

kheid...@usgs.gov

"Nothing matters very much, and very few things ... matter at all."

- Arthur James Balfour

Jason M. Stoker, Ph.D
US Geological Survey
National Geospatial Program
Office: 970-226-9227
Cell: 605-496-3513
My USGS Profile 

[Kirk Waters - NOAA Federal]

Jason and Karl,

The only thing I disagree with is the first paragraph. NAVD88 was/is defined by leveling, not by the application of a geoid model. Instead, the geoid model is defined through comparison of leveled points with GPS measurements (I'm sure that's simplifying). The geoid model isn't defining NAVD88, it's the other way around. However, the models get updated as we get more data, including more/better leveling. Our only way to move from GPS based measurements (e.g. lidar) to an orthometric datum like NAVD88 is through a geoid model. For most of the US, applying the geoid model should give you NAVD88 or the applicable island datum within a couple cm. In some places we know it is far worse (Hawaii and Alaska come to mind). 

All the rest is right on. As we've discussed before, the changing geoid model is why I prefer to store and archive the lidar data in ellipsoid heights. 

Kirk Waters, PhD                     | NOAA Office for Coastal Management

Applied Sciences Program      | 2234 South Hobson Ave
843-740-1227                          | Charleston, SC 29405    

coast.noaa.gov/digitalcoast

--

[Perdue, Michael]

Kirk is correct. NAVD88 is defined by the leveling network and the geoids (geoid03 geoid 09, geoid 12A, etc) are gravimetric geoid that has been warped to fit the leveling network. Work on NAVD88 was completed before geoids (or satellite based navigation techniques) were in common use.

 

This is why you will find that most CORS stations do not actually have a published NAVD88 value. Commonly, they have no physical tie to the leveling network.

PROGRAM = datasheet95, VERSION = 8.11

1        National Geodetic Survey,   Retrieval Date = JANUARY 10, 2017

DN5856 ***********************************************************************

DN5856  CORS        -  This is a GPS Continuously Operating Reference Station.

DN5856  DESIGNATION -  CANADIAN CORS ARP

DN5856  CORS_ID     -  TXCI

DN5856  PID         -  DN5856

DN5856  STATE/COUNTY-  TX/HEMPHILL

DN5856  COUNTRY     -  US

DN5856  USGS QUAD   -  CANADIAN WEST (1972)

DN5856

DN5856                         *CURRENT SURVEY CONTROL

DN5856  ______________________________________________________________________

DN5856* NAD 83(2011) POSITION- 35 55 13.07187(N) 100 22 41.90761(W)   ADJUSTED 

 DN5856* NAD 83(2011) ELLIP HT-   686.142 (meters)        (02/??/12)   ADJUSTED

DN5856* NAD 83(2011) EPOCH   -  2010.00

DN5856* NAVD 88 ORTHO HEIGHT -          **(meters)           **(feet)          

 DN5856  ______________________________________________________________________

DN5856  GEOID HEIGHT    -        -28.116 (meters)                     GEOID12B

DN5856  NAD 83(2011) X  -   -931,673.522 (meters)                     COMP

DN5856  NAD 83(2011) Y  - -5,087,136.505 (meters)                     COMP

DN5856  NAD 83(2011) Z  -  3,721,435.952 (meters)                     COMP

DN5856

DN5856.Formal positional accuracy estimates are not available for this CORS

DN5856.because its coordinates were determined in part using modeled

DN5856.velocities. Approximate one-sigma accuracies for latitude, longitude,

DN5856.and ellipsoid height can be obtained from the short-term time series.

DN5856.Additional information regarding modeled velocities is available on

DN5856.the CORS Coordinates and Multi-Year CORS Solution FAQ web pages.

 

 

While other stations that have been both leveled and surveyed in with GPS will often have both a NAVD88 elevation as well as a geodetic elevation (ellipsoidal).

PROGRAM = datasheet95, VERSION = 8.11

1        National Geodetic Survey,   Retrieval Date = JANUARY 10, 2017

GU4116 ***********************************************************************

GU4116  FBN         -  This is a Federal Base Network Control Station.

GU4116  TIDAL BM    -  This is a Tidal Bench Mark.

GU4116  DESIGNATION -  941 3450 M TIDAL

GU4116  PID         -  GU4116

GU4116  STATE/COUNTY-  CA/MONTEREY

GU4116  COUNTRY     -  US

GU4116  USGS QUAD   -  MONTEREY (1983)

GU4116

GU4116                         *CURRENT SURVEY CONTROL

GU4116  ______________________________________________________________________

GU4116* NAD 83(2011) POSITION- 36 36 05.25774(N) 121 53 33.77373(W)   ADJUSTED 

 GU4116* NAD 83(2011) ELLIP HT-   -30.885 (meters)        (06/27/12)   ADJUSTED

GU4116* NAD 83(2011) EPOCH   -  2010.00

GU4116* NAVD 88 ORTHO HEIGHT -     3.565 (meters)       11.70  (feet) ADJUSTED 

 GU4116  ______________________________________________________________________

GU4116  GEOID HEIGHT    -        -34.423 (meters)                     GEOID12B

GU4116  NAD 83(2011) X  - -2,708,465.659 (meters)                     COMP

GU4116  NAD 83(2011) Y  - -4,352,565.536 (meters)                     COMP

GU4116  NAD 83(2011) Z  -  3,781,960.817 (meters)                     COMP

GU4116  LAPLACE CORR    -          5.29  (seconds)                    DEFLEC12B

GU4116  DYNAMIC HEIGHT  -          3.562 (meters)       11.69  (feet) COMP

GU4116  MODELED GRAVITY -    979,893.8   (mgal)                       NAVD 88

GU4116

GU4116  VERT ORDER      -  FIRST     CLASS II

GU4116

GU4116  Network accuracy estimates per FGDC Geospatial Positioning Accuracy

GU4116  Standards:                                                        

 GU4116         FGDC (95% conf, cm)     Standard deviation (cm)     CorrNE

 GU4116            Horiz  Ellip           SD_N   SD_E   SD_h      (unitless)

GU4116  -------------------------------------------------------------------

GU4116  NETWORK    0.54   1.57           0.23   0.21   0.80     -0.22370380

GU4116  -------------------------------------------------------------------

GU4116  Click here for local accuracies and other accuracy information.

GU4116

GU4116

GU4116.The horizontal coordinates were established by GPS observations

GU4116.and adjusted by the National Geodetic Survey in June 2012.

GU4116

GU4116.NAD 83(2011) refers to NAD 83 coordinates where the reference frame has

 GU4116.been affixed to the stable North American tectonic plate. See

 GU4116.NA2011 for more information.

 GU4116

GU4116.The horizontal coordinates are valid at the epoch date displayed above

GU4116.which is a decimal equivalence of Year/Month/Day.

GU4116

GU4116.The orthometric height was determined by differential leveling and

GU4116.adjusted by the NATIONAL GEODETIC SURVEY

GU4116.in June 1991.

 

The astute user would also see that the GPS+geoid elevation ((-30.885)-(-34.423)=3.538m) does not match the published NAVD88 Ortho height. The published NAVD88 ortho height is the correct value. As Kirk has already stated, it is the leveling network that defines NAVD88, not the geoid. If one were performing a differential survey and it was important to tie your survey directly to the leveling network, then the technically correct thing to do is to use the published NAVD88 elevation and use a geoid to work backwards to the ellipsoidal elevation.

 

When following  such a workflow, the geoid used becomes largely irrelevant (if you’re only interested in the Orthometric values). In GNSS surveys, 10m of error in your base station coordinates will equate to ~1ppm of error in your baseline. As a result, even a comparatively large 10cm error in your derived ellipsoidal height translates to ~10ppb of error in your base line (5mm on a 50km baseline). This is much much smaller than other sources of error when processing GNSS.

 

However, as most users in the US ties their data to the CORS network, and CORS is seldom tied to NAVD88, I suspect that very few LiDAR surveys in the US have physical ties to the leveling network. Getting direct physical ties to the leveling network generally involves breaking out the pin finder, the shovel and getting boots on the ground. As a result, I understand that it is important for the USGS to know what geoid was used.

 

Additionally, as Kirk mentioned, the US is working on a new vertical datum which will be coincident with Canada’s CGVD2013 (2) (and defined by the equipotential surface W₀=62,636,856.0m²s^-2), which will be a purely gravimetric vertical datum. When that datum is realized, then NAD83 (20??) + a geoid will be the definition of the new vertical datum.

 

Cheers,

 

Mike

 

 

 

From: last...@googlegroups.com [mailto:last...@googlegroups.com] On Behalf Of Kirk Waters - NOAA Federal

Sent: Tuesday, January 10, 2017 1:39 PM
To: LAStools - efficient command line tools for LIDAR processing <last...@googlegroups.com>

[Karl Heidemann]

UPDATE--RETRACTION

All, I apologize for a spot of confusion I may have created.  

It has been brought to my attention that two of my statements in my previous comments (posted for me by Jason Stoker) conflict with details of the 2001 OGC WKT specification. 

1. The 2001 OGC WKT specification does not list AUTHORITY[] as either a Required OR OPTIONAL tag for AXIS[]. Thus, in order to remain strictly compliant with the 2001 OGC WKT specification, data producers SHOULD NOT include the AUTHORITY[] tag within an AXIS[] entry.  Nevermind that you will find EPSG codes for the various axes in the EPSG database.
2.  The 2001 OGC WKT specification lists DATUM_TYPE as a Required element of the VERTICAL_DATUM[]. The value 2005 indicates a geoid-derived model (it is not a year). Recalling that in most every case, data coming to the USGS is required to be in orthometric height, and will therefore be adjusted to a geoid model. Thus, every VERTICAL_DATUM[] entry must include the value 2005, as in the form:  VERT_DATUM["datum name",2005, AUTHORITY["EPSG","code"]].  Note that the 2005 is not an EPSG code; it is part of the OGC specification.

* The earlier notes on specifying "meters", and on the COMPD_CR delimiter stand.

* If it helps to know, the Name entries for the PROJCS and VERT_CS should exactly match the two elements listed in the COMPD_CS.

* Also, please bear in mind that the only definitive or official source of information regarding USGS lidar specifications is the Lidar Base Specification or other official USGS publications or communications. 

* Below is the pertinent section of the original post, corrected. 

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

I would recommend -two- changes to the WKT sample in the original message: [RED is deletion; Blue is addition, if you can see the colors.]

1. The only correct delimiter between Horizontal and Vertical CRS names in the COMPD_CS tag is the "+" sign. Software has to be programmed to look for a known delimiter to parse H from V.  In the original example, there are two "/"s. This will create either problems, or a lot of unnecessary and unpleasant coding.
   
2. In CRSs (both H & V), it is not necessary to write "metres" or "meters" (either spelling is fine), as meters is the the defined default unit for CRSs, and is thus understood. Plus, the units are given in the parameters, both as a name and as a code (if they are not, the data should be returned to the data producer anyway).
   

COMPD_CS["NAD83(2011) / UTM zone 10N +/ NAVD88 height - Geoid12A (metres)",

PROJCS["NAD83(2011) / UTM zone 10N (metres)",

  GEOGCS["NAD83(2011)",

    DATUM["NAD83_National_Spatial_Reference_System_2011",

      SPHEROID["GRS 1980",6378137,298.257222101,

        AUTHORITY["EPSG","7019"]],

      AUTHORITY["EPSG","1116"]],

    PRIMEM["Greenwich",0,

      AUTHORITY["EPSG","8901"]],

    UNIT["degree",0.0174532925199433,

      AUTHORITY["EPSG","9122"]],

    AUTHORITY["EPSG","6318"]],

  PROJECTION["Transverse_Mercator"],

    PARAMETER["latitude_of_origin",0],

    PARAMETER["central_meridian",-123],

    PARAMETER["scale_factor",0.9996],

    PARAMETER["false_easting",500000],

    PARAMETER["false_northing",0],

    UNIT["metre",1,

      AUTHORITY["EPSG","9001"]],

  AXIS["Easting",EAST],

  AXIS["Northing",NORTH],

  AUTHORITY["EPSG","6339"]],

  VERT_CS["NAVD88 height - Geoid12A (metres)",

    VERT_DATUM["North American Vertical Datum 1988", 2005,

      AUTHORITY["EPSG","5103"]],

    UNIT["metre",1.0,

      AUTHORITY["EPSG","9001"]],

    AXIS["Gravity-related height",UP],

    AUTHORITY["EPSG","5703"]]]

[Karl Heidemann]

Kirk and Michael,

Thanks to you both for the detailed insights and corrections.  I tend to over-simplify because I'm a simpleton not a geodesist, and certainly not a stute.   ;-)

The main point is how to properly identify and report whatever geoid a dataset was built with so the user knows.  Kirk makes it easy for himself by maintaining his data on the ellipsoid - which really is great. We'd be happy if we could just get this mess standardized enough to have a machine correctly read COMPLETE spatial reference information from the file. 

Michael, as you noted: "When that datum is realized, then NAD83 (20??) + a geoid will be the definition of the new vertical datum."  My problem is that once the "a geoid" you mention is updated, with the way things are reported now in WKT, I will not know that this or that dataset was adjusted using geoidA or geoidB.   

One day the geospatial industry will come to understand how important accurate, complete, standardized, and COMPLETE spatial reference information is.  I'm pretty certain I'll be long dead by then (or too demented to care), but it's still nice to hope.

[Thomas Knudsen]

Karl (and everyone)

You say that "Kirk makes it easy for himself by maintaining his data on the ellipsoid", somehow indicating that this is cheating, which it certainly isn't.

At SDFE, the Danish NMA, we also maintain the LiDAR point cloud data base in ellipsoidal coordinates, only transforming the heights to elevations (i.e. orthometric heights) as part of the distribution system, and at that point of time, using the most recent geoid model.

This makes extremely good sense, since a LiDAR measurement is a geoMETRIC, not geoPHYSICAL entity: Geophysics enters only indirectly through the IMU used for modelling the instrument positions at time of measurement.

Hence, you degrade your excellent geometrical measurements by transforming them to a geophysical system - and you make it pretty hard for yourself to combine different generations of LiDAR data, because you have degraded their quality to different degrees by using geoid models that, to different degrees of imperfection, predict the height of the datum plane that would be obtained by levelling methods.

Organizations like SDFE and USGS are data custodians: We are in the game to provide long time maintenance of the data that our great-grandchildren may need one day. 

Hence, we should maintain the data in a form compatible with that goal. And I believe that, for geometrical data, that would mean to maintain it in its original geometrical form, keeping the high geometrical accuracy.

Obviously, for the user's convenience, data should be *distributed* in orthometric heights (if that's what's needed). But distribution is not the same as maintenance.

/Thomas

[Martin Isenburg]

Hello,

thanks for this *very* useful information everybody. The next version of LAStools will have the possibility for our American friends to add the GEOID to the NAVD88 tag via the enhanced switches:

-vertical_navd88_geoid12b

-vertical_navd88_geoid12a

-vertical_navd88_geoid12

-vertical_navd88_geoid09

-vertical_navd88_geoid06

-vertical_navd88_geoid03

-vertical_navd88_geoid99

-vertical_navd88_geoid96

that will complement the existing option:

-vertical_navd88

it looks good to me so far and we hope to be crowd-testing this USA-specific feature with the next release. Here is what is produces so far:

E:\LAStools\bin>las2las -i ..\data\fusa.laz -epsg 26911 -vertical_navd88_geoid12b -set_ogc_wkt -odix _poop -olaz

E:\LAStools\bin>lasinfo -i ..\data\fusa_poop.laz

lasinfo (170109) report for ..\data\fusa_poop.laz

reporting all LAS header entries:

  file signature:             'LASF'

  file source ID:             0

  global_encoding:            0

  project ID GUID data 1-4:   00000000-0000-0000-0000-000000000000

  version major.minor:        1.1

  system identifier:          'LAStools (c) by rapidlasso GmbH'

  generating software:        'las2las (version 170109)'

  file creation day/year:     40/2010

  header size:                227

  offset to point data:       1266

  number var. length records: 2

  point data format:          1

  point data record length:   28

  number of point records:    277573

  number of points by return: 263413 13879 281 0 0

  scale factor x y z:         0.01 0.01 0.01

  offset x y z:               0 0 0

  min x y z:                  277750.00 6122250.00 42.21

  max x y z:                  277999.99 6122499.99 64.35

variable length header record 1 of 2:

  reserved             0

  user ID              'LASF_Projection'

  record ID            34735

  length after header  48

  description          'by LAStools of rapidlasso GmbH'

    GeoKeyDirectoryTag version 1.1.0 number of keys 5

      key 1024 tiff_tag_location 0 count 1 value_offset 1 - GTModelTypeGeoKey: ModelTypeProjected

      key 3072 tiff_tag_location 0 count 1 value_offset 26911 - ProjectedCSTypeGeoKey: NAD83 / UTM 11N

      key 3076 tiff_tag_location 0 count 1 value_offset 9001 - ProjLinearUnitsGeoKey: Linear_Meter

      key 4099 tiff_tag_location 0 count 1 value_offset 9001 - VerticalUnitsGeoKey: Linear_Meter

      key 4096 tiff_tag_location 0 count 1 value_offset 5103 - VerticalCSTypeGeoKey: VertCS_North_American_Vertical_Datum_1988

variable length header record 2 of 2:

  reserved             0

  user ID              'LASF_Projection'

  record ID            2112

  length after header  883

  description          'by LAStools of rapidlasso GmbH'

    WKT OGC COORDINATE SYSTEM:

    COMPD_CS["NAD83 / UTM 11N + NAVD88 height - Geoid12B",PROJCS["NAD83 / UTM 11N",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["EP

SG","9122"]],AUTHORITY["EPSG","4269"]],PROJECTION["Transverse_Mercator"],PARAMETER["latitude_of_origin",0],PARAMETER["central_meridian",-117],PARAMETER["scale_f

actor",0.9996],PARAMETER["false_easting",500000],PARAMETER["false_northing",0],UNIT["metre",1,AUTHORITY["EPSG","9001"]],AXIS["Easting",EAST],AXIS["Northing",NOR

TH],AUTHORITY["EPSG","26911"]]VERT_CS["NAVD88 height - Geoid12B",VERT_DATUM["North American Vertical Datum 1988",2005,AUTHORITY["EPSG","5103"]],UNIT["metre",1.0

,AUTHORITY["EPSG","9001"]]AXIS["Gravity-related height",UP],AUTHORITY["EPSG","5703"]]]

LASzip compression (version 2.5r2 c2 50000): POINT10 2 GPSTIME11 2

reporting minimum and maximum for all LAS point record entries ...

  X            27775000   27799999

  Y           612225000  612249999

  Z                4221       6435

  intensity          10      62293

  return_number       1          3

  number_of_returns   1          3

  edge_of_flight_line 0          0

  scan_direction_flag 0          0

  classification      1          6

  scan_angle_rank    79        103

  user_data           0        197

  point_source_ID     1          1

  gps_time 5880.963028 5886.739738

number of first returns:        263413

number of intermediate returns: 283

number of last returns:         263370

number of single returns:       249493

overview over number of returns of given pulse: 249493 27232 848 0 0 0 0

histogram of classification of points:

           17553  unclassified (1)

          180868  ground (2)

           37030  high vegetation (5)

           42122  building (6)

Now 26911 is UTM 11north with NAD83. Are there EPSG codes for UTM 11north with NAD83(2011) or NAD83(HARN)?

Did you know that "HARN" is not only the acronym for High Accuracy Reference Network but also the medical term used in German to refer to the liquid that has made such splash on the future US president in the much talked about buzzfeed report? It's not even January 20th and the incoming administration already has its first "Yellowwater scandal" ... (-;

[Kirk Waters - NOAA Federal]

Martin,

Of course there are separate codes. It would be too easy otherwise. Here's the ones I've gathered. Should all be from the EPSG database. 

EPSGcode EPSGname Zone

2195 NAD83(HARN) / UTM zone 2S -2

2955 NAD83(CSRS) / UTM zone 11N 11

2956 NAD83(CSRS) / UTM zone 12N 12

2957 NAD83(CSRS) / UTM zone 13N 13

2958 NAD83(CSRS) / UTM zone 17N 17

2959 NAD83(CSRS) / UTM zone 18N 18

2960 NAD83(CSRS) / UTM zone 19N 19

2961 NAD83(CSRS) / UTM zone 20N 20

2962 NAD83(CSRS) / UTM zone 21N 21

3154 NAD83(CSRS) / UTM zone 7N 7

3155 NAD83(CSRS) / UTM zone 8N 8

3156 NAD83(CSRS) / UTM zone 9N 9

3157 NAD83(CSRS) / UTM zone 10N 10

3158 NAD83(CSRS) / UTM zone 14N 14

3159 NAD83(CSRS) / UTM zone 15N 15

3160 NAD83(CSRS) / UTM zone 16N 16

3372 NAD83 / UTM zone 59N 59

3373 NAD83 / UTM zone 60N 60

3706 NAD83(NSRS2007) / UTM zone 59N 59

3707 NAD83(NSRS2007) / UTM zone 60N 60

3708 NAD83(NSRS2007) / UTM zone 1N 1

3709 NAD83(NSRS2007) / UTM zone 2N 2

3710 NAD83(NSRS2007) / UTM zone 3N 3

3711 NAD83(NSRS2007) / UTM zone 4N 4

3712 NAD83(NSRS2007) / UTM zone 5N 5

3713 NAD83(NSRS2007) / UTM zone 6N 6

3714 NAD83(NSRS2007) / UTM zone 7N 7

3715 NAD83(NSRS2007) / UTM zone 8N 8

3716 NAD83(NSRS2007) / UTM zone 9N 9

3717 NAD83(NSRS2007) / UTM zone 10N 10

3718 NAD83(NSRS2007) / UTM zone 11N 11

3719 NAD83(NSRS2007) / UTM zone 12N 12

3720 NAD83(NSRS2007) / UTM zone 13N 13

3721 NAD83(NSRS2007) / UTM zone 14N 14

3722 NAD83(NSRS2007) / UTM zone 15N 15

3723 NAD83(NSRS2007) / UTM zone 16N 16

3724 NAD83(NSRS2007) / UTM zone 17N 17

3725 NAD83(NSRS2007) / UTM zone 18N 18

3726 NAD83(NSRS2007) / UTM zone 19N 19

3740 NAD83(HARN) / UTM zone 10N 10

3741 NAD83(HARN) / UTM zone 11N 11

3742 NAD83(HARN) / UTM zone 12N 12

3743 NAD83(HARN) / UTM zone 13N 13

3744 NAD83(HARN) / UTM zone 14N 14

3745 NAD83(HARN) / UTM zone 15N 15

3746 NAD83(HARN) / UTM zone 16N 16

3747 NAD83(HARN) / UTM zone 17N 17

3748 NAD83(HARN) / UTM zone 18N 18

3749 NAD83(HARN) / UTM zone 19N 19

3750 NAD83(HARN) / UTM zone 4N 4

3751 NAD83(HARN) / UTM zone 5N 5

3761 NAD83(CSRS) / UTM zone 22N 22

6328 NAD83(2011) / UTM zone 59N 59

6329 NAD83(2011) / UTM zone 60N 60

6330 NAD83(2011) / UTM zone 1N 1

6331 NAD83(2011) / UTM zone 2N 2

6332 NAD83(2011) / UTM zone 3N 3

6333 NAD83(2011) / UTM zone 4N 4

6334 NAD83(2011) / UTM zone 5N 5

6335 NAD83(2011) / UTM zone 6N 6

6336 NAD83(2011) / UTM zone 7N 7

6337 NAD83(2011) / UTM zone 8N 8

6338 NAD83(2011) / UTM zone 9N 9

6339 NAD83(2011) / UTM zone 10N 10

6340 NAD83(2011) / UTM zone 11N 11

6341 NAD83(2011) / UTM zone 12N 12

6342 NAD83(2011) / UTM zone 13N 13

6343 NAD83(2011) / UTM zone 14N 14

6344 NAD83(2011) / UTM zone 15N 15

6345 NAD83(2011) / UTM zone 16N 16

6346 NAD83(2011) / UTM zone 17N 17

6347 NAD83(2011) / UTM zone 18N 18

6348 NAD83(2011) / UTM zone 19N 19

6634 NAD83(PA11) / UTM zone 4N 4

6635 NAD83(PA11) / UTM zone 5N 5

6636 NAD83(PA11) / UTM zone 2S -2

6650 NAD83(CSRS) / UTM zone 7N + CGVD2013 height 7

6651 NAD83(CSRS) / UTM zone 8N + CGVD2013 height 8

6652 NAD83(CSRS) / UTM zone 9N + CGVD2013 height 9

6653 NAD83(CSRS) / UTM zone 10N + CGVD2013 height 10

6654 NAD83(CSRS) / UTM zone 11N + CGVD2013 height 11

6655 NAD83(CSRS) / UTM zone 12N + CGVD2013 height 12

6656 NAD83(CSRS) / UTM zone 13N + CGVD2013 height 13

6657 NAD83(CSRS) / UTM zone 14N + CGVD2013 height 14

6658 NAD83(CSRS) / UTM zone 15N + CGVD2013 height 15

6659 NAD83(CSRS) / UTM zone 16N + CGVD2013 height 16

6660 NAD83(CSRS) / UTM zone 17N + CGVD2013 height 17

6661 NAD83(CSRS) / UTM zone 18N + CGVD2013 height 18

6662 NAD83(CSRS) / UTM zone 19N + CGVD2013 height 19

6663 NAD83(CSRS) / UTM zone 20N + CGVD2013 height 20

6664 NAD83(CSRS) / UTM zone 21N + CGVD2013 height 21

6665 NAD83(CSRS) / UTM zone 22N + CGVD2013 height 22

26901 NAD83 / UTM zone 1N 1

26902 NAD83 / UTM zone 2N 2

26903 NAD83 / UTM zone 3N 3

26904 NAD83 / UTM zone 4N 4

26905 NAD83 / UTM zone 5N 5

26906 NAD83 / UTM zone 6N 6

26907 NAD83 / UTM zone 7N 7

26908 NAD83 / UTM zone 8N 8

26909 NAD83 / UTM zone 9N 9

26910 NAD83 / UTM zone 10N 10

26911 NAD83 / UTM zone 11N 11

26912 NAD83 / UTM zone 12N 12

26913 NAD83 / UTM zone 13N 13

26914 NAD83 / UTM zone 14N 14

26915 NAD83 / UTM zone 15N 15

26916 NAD83 / UTM zone 16N 16

26917 NAD83 / UTM zone 17N 17

26918 NAD83 / UTM zone 18N 18

26919 NAD83 / UTM zone 19N 19

26920 NAD83 / UTM zone 20N 20

26921 NAD83 / UTM zone 21N 21

26922 NAD83 / UTM zone 22N 22

26923 NAD83 / UTM zone 23N 23

Kirk Waters, PhD                     | NOAA Office for Coastal Management

Applied Sciences Program      | 2234 South Hobson Ave
843-740-1227                          | Charleston, SC 29405    

coast.noaa.gov/digitalcoast

[Martin Isenburg]

Hello,

all those codes that Kirk has listed as well as the Geoid strings in the OGC WKT descriptions should not be functional in the latest release of LAStools (version 170122) of today.

Other changes are:

20 January 2017 -- las2shp: ability to output other LAS attributes to corresponding DBF file 

16 January 2017 -- LASlib: support for NAVD88 Geoids when generating OGC WKT string via '-vertical_navd88_geoid12b' 

11 January 2017 -- txt2las: 'k'/'h'/'o' for <k>eypoint/with<h>eld/<o>verlap flag and 'l' for scanner channe<l>

10 January 2017 -- las2txt: parse option 'h'/'o' for with<h>eld/<o>verlap flag and 'l' for scanner channe<l>

10 January 2017 -- LASlib: new '-merge_scanner_channel_into_point_source' '-split_scanner_channel_from_point_source'

10 January 2017 -- LASlib: new transform '-copy_scanner_channel_into_point_source'

10 January 2017 -- LASlib: new filters '-keep_scanner_channel 2' and '-drop_scanner_channel 1'

Regards,

Martin @rapidlasso

[Martin Isenburg]

Hello Karl,

so I assume the new USGS specification will "fail" any OGC WKT string that looks like the one below? Mainly because a UTM 32N projection with WGS84 datum should include the obvious EPSG code using the AUTHORITY field but probably also for other reasons such as the odd vertical datum (and maybe also the fact that the USGS does not yet collect data from UTM zone 32N (-;). This is test data I got from Leica for experiments with the native LAS 1.4 compressor.

Maybe it should contain something about using "nice" offsets in the LAS header because such an offset here

 offset x y z: 553461.19999999995 5258928.7999999998 0

is just nasty. My recommendation is to set the 5 or 6 lowest digits (of the un-scaled integer) to zero so for scale factors of 0.001 0.001 0.001 this would give the following offset.

 offset x y z: 553000.000 5258000.000 0.000

E:\LAStools\bin>lasinfo -nc -i e:\LAS14\PRDF6\Leica_CloudPro_160701_095814_13mROA_6.LAS

lasinfo (170203) report for e:\LAS14\PRDF6\Leica_CloudPro_160701_095814_13mROA_6.LAS

reporting all LAS header entries:

  file signature:             'LASF'

  file source ID:             0

  global_encoding:            16

  project ID GUID data 1-4:   00000000-0000-0000-0000-000000000000

  version major.minor:        1.4

  system identifier:          'ALSXX'

  generating software:        'CloudPro1.2.3.101746'

  file creation day/year:     263/2016

  header size:                375

  offset to point data:       43476

  number var. length records: 8

  point data format:          6

  point data record length:   30

  number of point records:    0

  number of points by return: 0 0 0 0 0

  scale factor x y z:         0.001 0.001 0.001

  offset x y z:               553461.19999999995 5258928.7999999998 0

  min x y z:                  553163.373 5258547.308 283.720

  max x y z:                  555815.757 5261671.374 613.683

  start of waveform data packet record: 0

  start of first extended variable length record: 1194337956

  number of extended_variable length records: 1

  extended number of point records: 39809816

  extended number of points by return: 36991808 2541338 232220 36442 6263 1200 347 118 45 21 9 3 2 0 0

variable length header record 1 of 8:

  reserved             43707

  user ID              'LeicaGeo'

  record ID            1002

  length after header  22

  description          'MissionInfo'

variable length header record 2 of 8:

  reserved             43707

  user ID              'LeicaGeo'

  record ID            1003

  length after header  54

  description          'UserInputs'

variable length header record 3 of 8:

  reserved             43707

  user ID              'LeicaGeo'

  record ID            1005

  length after header  1536

  description          'IbrcInfo'

variable length header record 4 of 8:

  reserved             43707

  user ID              'LeicaGeo'

  record ID            2001

  length after header  32

  description          'PulseWidthTable'

variable length header record 5 of 8:

  reserved             43707

  user ID              'LeicaGeo'

  record ID            1008

  length after header  64

  description          'IntScaleAndOffset'

variable length header record 6 of 8:

  reserved             43707

  user ID              'LeicaGeo'

  record ID            1009

  length after header  1

  description          'Number of bits for the intensity'

variable length header record 7 of 8:

  reserved             43707

  user ID              'LeicaGeo'

  record ID            1001

  length after header  20480

  description          'Intensity Histogram'

variable length header record 8 of 8:

  reserved             43707

  user ID              'LeicaGeo'

  record ID            1101

  length after header  20480

  description          'Corrected Intensity Histogram'

extended variable length header record 1 of 1:

  reserved             43707

  user ID              'LASF_Projection'

  record ID            2112

  length after header  637

  description          'WKT Information'

    OGC COORDINATE SYSTEM WKT:

    COMPD_CS["Projected", PROJCS["UTM_32N", GEOGCS [ "WGS84", DATUM [ "WGS84", SPHEROID ["WGS 84", 6378137.000, 298.257223563 ], TOWGS84 [ 0.000, 0.000, 0.000, 0.0000000000, 0.0000000000, 0.0000000000, 0.0000000000 ] ], PRIMEM [ "Greenwich", 0.000000 ], UNIT [ "metres", 1.00000000] ], PROJECTION["Transverse_Mercator"], PARAMETER["Latitude_of_Origin",0.0000000000], PARAMETER["Central_Meridian",9.0000000000], PARAMETER["Scale_Factor",0.9996000000], PARAMETER["False_Easting",500000.000], PARAMETER["False_Northing",0.000], UNIT [ "metres", 1.00000000]] ], VERT_CS["ellipsoid", VERT_DATUM["ellipsoid", 0 ], UNIT [ "metres", 1.00000000] ] ]

On Wed, Jan 11, 2017 at 2:32 AM, Karl Heidemann <brude...@gmail.com> wrote: