0

I am working with v1.4 .las files from El Paso County, CO, that individually appear without any reference to their projections (none that R sees, anyway). From the metadata I can see the following information:

<spref>
 <horizsys>
  <planar>
   <gridsys>
    <gridsysn>State Plane Coordinate System 1983</gridsysn>
     <spcs>
      <spcszone>0502</spcszone>
      <lambertc>
       <stdparll>38.450000</stdparll>
       <stdparll>39.750000</stdparll>
       <longcm>-105.500000</longcm>
       <latprjo>37.833333</latprjo>
       <feast>3000000.000316</feast>
       <fnorth>999999.999996</fnorth>
      </lambertc>
    </spcs>
   </gridsys>
  <planci>
   <plance>coordinate pair</plance>
    <coordrep>
     <absres>0.001</absres>
     <ordres>0.001</ordres>
    </coordrep>
    <plandu>survey feet</plandu>
  </planci>
</planar>
 <geodetic>
  <horizdn>D_NAD_1983_2011</horizdn>
   <ellips>Geodetic Reference System 80</ellips>
   <semiaxis>6378137.000000</semiaxis>
   <denflat>298.257222</denflat>
  </geodetic>
 </horizsys>
<vertdef>
 <altsys>
  <altdatum>North American Vertical Datum of 1988 Geoid12B</altdatum>
  <altres>0.001</altres>
  <altunits>feet</altunits>
   <altenc>
   Explicit elevation coordinate included with horizontal coordinates
   <altenc>
  </altsys>
 </vertdef>
</spref>

Nowhere in the metadata is any reference made to an epsg or to esri code

This appears to correspond to blocks of information for at least 5 of 12 "Colorado Central 502" projections I have identified on epsg.io. (2232, 3502, 2877, 6428, and 102654)

lasinfo returns the OGC COORDINATE SYSTEM WKT string, but no EPSG. (I'm not skilled with lastools, but I tried...)

My questions are:

  • How does one definitively identify the EPSG that goes with the projection content given in LiDAR metadata when the metadata omits the EPSG code?
  • If the content in the above metadata and that of any EPSG code all match, does it make any difference which EPSG code I chose? If so, what additional parameters matter?
  • Is there a site that receives the detail above as input and returns the EPSG code, not the other way around? "http://prj2epsg.org/search" appears to be dead.
1
  • The EPSG registry (epsg.org) provides a swagger API to query the database, you need to register to use it.
    – nmtoken
    Jul 12 at 13:12
0

Here's a semi-solution:

# find epsg
# https://www.earthdatascience.org/courses/earth-analytics/spatial-data-r/understand-epsg-wkt-and-other-crs-definition-file-types/

library(rgdal)
library(dplyr)
library(stringr)
epsg <- make_EPSG()
head(epsg)
epsg %>%
  filter(code == 2232)

epsg.step1 <- epsg %>%
   filter(str_detect(prj4, 'lat_0=37.8333333333333')) # 11 returns
epsg.step2 <- epsg.step1 %>%
  filter(str_detect(prj4, 'proj=lcc')) # 11 returns
epsg.step3 <- epsg.step2 %>%
  filter(str_detect(prj4, 'x_0=914401.828803658')) # 5 returns
epsg.step4 <- epsg.step3 %>%
  filter(str_detect(prj4, 'datum=NAD83')) # 2 returns, one of which is 2232
epsg.step5 <- epsg.step4 %>%
  filter(str_detect(prj4, 'ellps=GRS80')) # no returns, even though 2232 uses the GRS80 ellipse


# <gridsysn>State Plane Coordinate System 1983</gridsysn>
# <spcszone>0502</spcszone>
# <lambertc>
# <stdparll>38.450000</stdparll>
# <stdparll>39.750000</stdparll>
# <longcm>-105.500000</longcm>
# <latprjo>37.833333</latprjo>
# <feast>3000000.000316</feast>
# <fnorth>999999.999996</fnorth>
# <plance>coordinate pair</plance>
# <absres>0.001</absres>
# <ordres>0.001</ordres>
# <plandu>survey feet</plandu>
# <ellips>Geodetic Reference System 80</ellips>
# <semiaxis>6378137.000000</semiaxis>
# <denflat>298.257222</denflat>
# <altdatum>North American Vertical Datum of 1988 Geoid12B</altdatum>
# <altres>0.001</altres>
# <altunits>feet</altunits>

0

EPSG = 2232. Based on your LiDAR metadata your LiDAR references Colorado State Plane 0502 (Central) NAD 83 in US survey feet. See here for a map of this coordinate reference system, and here for details on the EPSG code.

3
  • @CBG - Yes, well-noted. Are you aware of any direct method for finding any EPSG code given only the LiDAR metadata, besides manually or semi-automatically grinding through each element of detail?
    – G. Moore
    Feb 7 at 1:06
  • No, sorry I don't. Not beyond writing the Python code to parse XML files.
    – GBG
    Feb 8 at 16:20
  • 1
    No, the metadata says it's NAD 1983 (2011) so 6428.
    – mkennedy
    Feb 16 at 21:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.