which EPSG codes are missing

2221 views
Skip to first unread message

Martin Isenburg

unread,
Nov 18, 2013, 6:29:27 PM11/18/13
to last...@googlegroups.com
Hello,

occasionally I get requests to add more EPSG codes to LAStools. And yes, I am taking requests. What is your favorite EPSG code that is not yet supported by LAStools and who is using it. Let me know and if there is sufficient data in this projection I will add support for it. Recent additions are:

* France 3942 to 3950 (GF93 / CC42-50 Reseau_Geodesique_Francais_1993)
* Poland 2180 (ETRS89 / Poland CS92)
* UK 27700 (OSGB 1936 / British National Grid)
* Canada 3154 - 3160: (NAD83(CSRS) / UTM zones 8-10,14-16)

Cheers,

Martin

Kirk Waters - NOAA Federal

unread,
Nov 19, 2013, 8:00:09 AM11/19/13
to last...@googlegroups.com
Martin,
We could use 2195 (NAD83(HARN) UTM zone 2 south). This covers American Samoa.

Thanks,
Kirk
--

Kirk Waters, PhD
Applied Sciences Program
NOAA Coastal Services Center
843-740-1227


Baltrusch, Sven

unread,
Nov 19, 2013, 1:34:50 AM11/19/13
to last...@googlegroups.com

Hello Martin,

 

attached you can find a list of EPSG-codes, which are used in german mapping agencies.

 

Best regards, Sven

 

Landesamt für innere Verwaltung Mecklenburg-Vorpommern

Amt für Geoinformation, Vermessungs- und Katasterwesen

Fachbereich 322

Lübecker Str. 289

19059 Schwerin

 

Tel.: 0385 588-56322

Fax: 0385 588 482 56039 

 

E-Mail: sven.ba...@laiv-mv.de

--

EPSG-Codes-EmpfehlungMV.pdf

Žiga Kokalj

unread,
Nov 19, 2013, 5:06:31 PM11/19/13
to last...@googlegroups.com

Dear Martin,

 

for Slovenia we use:

 

3912  ; SI-D48, Slovene National Grid, »old« but still mostly used

3794  ; SI-D96, Slovenia 1996 / Slovene National Grid, new and should be used (ETRS89)

 

It would be great to have them in LAStools.

 

Best wishes,

 

Ziga

Martin Isenburg

unread,
Nov 19, 2013, 5:39:08 PM11/19/13
to LAStools - efficient command line tools for LIDAR processing
Hello Ziga,

I added the newer projection. Not so sure about the older one. I see a
whole bunch of different codes referring to it. See:

http://www.spatialreference.org/ref/sr-org/6769/

I like to focus on the most relevant and newer ones to keep LAStools
light and tight. To convert legacy projections to current workflows
there are other tools such as las2las from libLAS as well as
commercial "projection transform engine" ...

Martin

Toon Petermans

unread,
Nov 20, 2013, 8:37:24 AM11/20/13
to last...@googlegroups.com

Hello Martin,

 

That is very good news to incorporate more epsg codes.

For Belgian users, we could use the EPSG 31370 for the Belgian Lambert 72 CRS.

http://www.spatialreference.org/ref/epsg/31370/

 

An important issue is the +towgs84 parameters which is necessary for datum conversions between Belgian datum 72 and ETR89 (WGS84) and vice versa. To make things more complicated the signs of the +towgs84 parameters has to change whether you do a datum transformation from WGS84 to Belgian datum 1972 or from Belgian datum 1972 to ETRS89 datum.

Another complexity is the sign of the rotation parameters which can change depending on the use of the coordinate frame transformation  convention (positive counterclockwise – mainly used in the US) and the Position vector transformation convention (mainly used in Europe and also In the epsg codes). It is crucial that sign convention is conform the algorithm in the application.  

 

From ETRS89 datum to Belgian datum72 in Position vector transformation :  towgs84= 106.869,-52.2978,103.724,-0.33657,0.456955,-1.84218,1

ð  These are the parameters that the epsg database uses

From ETRS89 datum to Belgian datum 72 in Coordinate frame transformation  :  towgs84= 106.869,-52.2978,103.724,0.33657,-0.456955,1.84218,1

From Belgian datum 72 to ETRS89 datum in Position vector transformation :  towgs84= -106.869,52.2978,-103.724,0.33657,-0.456955,1.84218,1

From Belgian datum 72 to ETRS89 datum in Coordinate frame transformation  :  towgs84= -106.869,52.2978,-103.724,-0.33657,0.456955,-1.84218,1

 

A third complication is that the National Geographic Institute of Belgium uses parameters (with coordinate frame transformation convention) with more detail than the ones in the espg code:

NGI_projParams.jpg

 

 

So in the end it would be very helpful to choose an epsg code but to have the ability to manually modify the towgs84 parameters (the signs for whatever transformation convention you want). But in the first place, will lastools be able to use the towgs parameters for datum shifts in the future or to manually introduce it?

 

Best regards,

Toon

 

 

Toon Petermans

Afdeling Geodiensten – Dienst IT/Development

T 09 261 7217 | F 09 261 52 99 | toon.pe...@agiv.be | www.agiv.be

Vrijdag 4/5de verlofdag

 

Description: Description: AGIV-Banner

--

Thomas Knudsen

unread,
Nov 20, 2013, 10:38:28 AM11/20/13
to last...@googlegroups.com
Support for the 4 "Danish Transverse Mercator" zones and their EPSG brethren with the DVR90 "Danish Vertical Reference 1990" associated, would be quite useful.

The relevant EPSG codes are:

4093   ETRS89/DKTM1
4094   ETRS89/DKTM2
4095   ETRS89/DKTM3
4096   ETRS89/DKTM4

4097   ETRS89/DKTM1+DVR90
4098   ETRS89/DKTM2+DVR90
4099   ETRS89/DKTM3+DVR90
4100   ETRS89/DKTM4+DVR90

DKTM is used in Denmark for construction engineering, including road and railroad work, where LiDAR scanning is in widespread use (for planning as well as maintenance purposes).

Since the DKTMs are plain TM projections, they should be quite straightforward to add to the existing UTM code.

/thomas


2013/11/19 Martin Isenburg <martin....@gmail.com>

Kramer, Henk [Alterra]

unread,
Nov 21, 2013, 8:10:07 AM11/21/13
to last...@googlegroups.com

Hi Martin,

 

Could you add EPSG:28992 (amersfoort / RDnew) for the Netherlands?

 

http://spatialreference.org/ref/epsg/28992/

 

Thanks,

Henk

 

Henk Kramer
Centrum Geo-informatie
Alterra
Wageningen

tel. 0317-481816

--

Jonathan Dash

unread,
Nov 24, 2013, 4:38:09 PM11/24/13
to last...@googlegroups.com

Hi Martin

 

EPSG:2193  - (NZGD2000 / New Zealand Transverse Mercator 2000) covers the North and South islands of New Zealand and would be a useful addition.

http://spatialreference.org/ref/epsg/2193/

 

Thanks

Jonathan

 

Jonathan Dash
Scientist, Forest Operations and Management, Scion

--





This e-mail and any attachments may contain information which is confidential or subject to copyright. If you receive this e-mail in error, please delete it.
Scion does not accept responsibility for anything in this e-mail which is not provided in the course of Scion’s usual business or for any computer virus, data corruption, interference or delay arising from this e-mail.

sh...@shaunlevick.com

unread,
Nov 25, 2013, 5:36:17 AM11/25/13
to last...@googlegroups.com
Thanks Martin

EPSG 31494 and 31495 (Germany 4 and 5 / DHDN 4 and 5)

Cheers,
Shaun

John Scrivani

unread,
Nov 25, 2013, 7:37:34 AM11/25/13
to last...@googlegroups.com
Hello Martin,

The most common EPSG code for publicly available LiDAR for the Commonwealth of Virginia are:
 
  EPSG:2924  NAD_1983_HARN_StatePlane_Virginia_North_FIPS_4502_Feet  
  EPSG:2925  NAD_1983_HARN_StatePlane_Virginia_South_FIPS_4502_Feet

Most, if not all, Virginia state and local governments, use these two.

In addition, this one is commonly used for statewide projects, although no lidar data has been delivered  in it:

  EPSG:3969 NAD_1983_HARN_Virginia_Lambert

It would be great to have the first two, and if possible, the third, supported in lastools.

Many thanks - John

John Scrivani,
Geospatial Projects Manager
Virginia Geographic Information Network


On Mon, Nov 18, 2013 at 6:29 PM, Martin Isenburg <martin....@gmail.com> wrote:

Andreas Røstad

unread,
Nov 27, 2013, 3:51:11 AM11/27/13
to last...@googlegroups.com
Hello

Support for the "Norwegian Transverse Mercator" zones and the Norwegian vertical references would be great.

Transformation is not important, but they should be recognized in lasinfo and lascontrol. 

The horisontal EPSG codes are:

5105   ETRS89 / NTM zone 5
5106   ETRS89 / NTM zone 6
5107   ETRS89 / NTM zone 7
5108   ETRS89 / NTM zone 8
5109   ETRS89 / NTM zone 9
5110   ETRS89 / NTM zone 10
5111   ETRS89 / NTM zone 11
5112   ETRS89 / NTM zone 12
5113   ETRS89 / NTM zone 13
5114   ETRS89 / NTM zone 14
5115   ETRS89 / NTM zone 15
5116   ETRS89 / NTM zone 16
5117   ETRS89 / NTM zone 17
5118   ETRS89 / NTM zone 18
5119   ETRS89 / NTM zone 19
5120   ETRS89 / NTM zone 20
5121   ETRS89 / NTM zone 21
5122   ETRS89 / NTM zone 22
5123   ETRS89 / NTM zone 23
5124   ETRS89 / NTM zone 24
5125   ETRS89 / NTM zone 25
5126   ETRS89 / NTM zone 26
5127   ETRS89 / NTM zone 27
5128   ETRS89 / NTM zone 28
5129   ETRS89 / NTM zone 29
5130   ETRS89 / NTM zone 30


NTM is used in Norway for construction engineering, including road and railroad work, where LiDAR scanning is in widespread use (for planning as well as maintenance purposes).


The vertical crs EPSG codes are:

5776   NN54 height
5941   NN2000 height  (”NN2000 height” based on ”Norway Normal Null 2000” datum)

We are converting to NN2000, but both will be used for some years more.

Andreas

Martin Isenburg

unread,
Dec 10, 2013, 8:21:04 AM12/10/13
to LAStools - efficient command line tools for LIDAR processing
Hello,

I have added support for certain EPSG codes in th latest version of
LAStools from today (131210). You can access (and add) them either via
the GUI or directly via the command line using the '-epsg' and
'-target_epsg' flags. Note that it is still not possible to do a
ellispoid transform ...

Let me know if there are additional codes dear to your heart (that are
used in LiDAR). I appreciate a small example LAZ file using the
projection for testing purposes.

Regards,

Martin

D:\lastools\bin>las2las -epsg help
set_epsg_code: look-up for 0 not implemented
ERROR: bad ESPG code in '-epsg help'.
2180 - ETRS89 Poland CS92
2193 - NZGD2000
2195 - Amer. Samoa UTM2
2924 - NAD83-H Virginia N
2925 - NAD83-H Virginia S
3034 - ETRS89 LCC
3046 - ETRS89 TM34
3047 - ETRS89 TM35
3048 - ETRS89 TM36
3067 - ETRS89 TM35FIN
3141 - Fiji 1956 UTM60
3142 - Fiji 1956 UTM1
3460 - Fiji Map Grid 1986
3794 - Slov. Nat. Grid 1996
3912 - Slov. Nat. Grid 1901
3942 - RGF93 CC42
3943 - RGF93 CC43
3944 - RGF93 CC44
3945 - RGF93 CC45
3946 - RGF93 CC46
3947 - RGF93 CC47
3948 - RGF93 CC48
3949 - RGF93 CC49
3950 - RGF93 CC50
4093 - ETRS89 DKTM1
4094 - ETRS89 DKTM2
4095 - ETRS89 DKTM3
4096 - ETRS89 DKTM4
4647 - ETRS89 UTM32 zE-N
5105 - ETRS89 NTM5
5106 - ETRS89 NTM6
5107 - ETRS89 NTM7
5108 - ETRS89 NTM8
5109 - ETRS89 NTM9
5110 - ETRS89 NTM10
5111 - ETRS89 NTM11
5112 - ETRS89 NTM12
5113 - ETRS89 NTM13
5114 - ETRS89 NTM14
5115 - ETRS89 NTM15
5116 - ETRS89 NTM16
5117 - ETRS89 NTM17
5118 - ETRS89 NTM18
5119 - ETRS89 NTM19
5120 - ETRS89 NTM20
5121 - ETRS89 NTM21
5122 - ETRS89 NTM22
5123 - ETRS89 NTM23
5124 - ETRS89 NTM24
5125 - ETRS89 NTM25
5126 - ETRS89 NTM26
5127 - ETRS89 NTM27
5128 - ETRS89 NTM28
5129 - ETRS89 NTM29
5130 - ETRS89 NTM30
5650 - ETRS89 UTM33 zE-N
27700 - OSGB 1936
31370 - Belgian Lambert 1972
las2las_gui_espg.png

Henrik Persson

unread,
Jan 15, 2014, 10:33:16 AM1/15/14
to last...@googlegroups.com
Hello Martin,

in Sweden we would be happy to get support for SWEREF99TM, EPSG:3006

Thanks,
Henrik


On Tuesday, November 19, 2013 12:29:27 AM UTC+1, Martin Isenburg wrote:

david.herries

unread,
Aug 6, 2014, 10:28:40 PM8/6/14
to last...@googlegroups.com
Hi Martin

Also a vertical datum option for EPSG Projection 5764 - Moturiki 1953 height


VERT_CS["Moturiki",
    VERT_DATUM["Moturiki",2005,
        AUTHORITY["EPSG","5162"]],
    UNIT["m",1.0],
    AXIS["Gravity-related height",UP],
    AUTHORITY["EPSG","5764"]]

Noted also the las2las readme needs updating with the -epsg which for horizontal datum.

Hope this helps
Thanks
Dave

carolin...@gmail.com

unread,
Aug 7, 2014, 9:11:03 AM8/7/14
to last...@googlegroups.com
Hello Martin,

Could you also add the 2972 RGFG95 / UTM zone 22N, which is used in French Guiana?

Thanks for your great job with LAStools.

Caroline


Caroline Bedeau
Chargée d'études Géomatique & Télédétection

Département R&D Pôle de Cayenne
Office National des Forêts
Réserve de Montabo, 97300 Cayenne
0594 25 53 92
carolin...@onf.fr


Kirk Waters - NOAA Federal

unread,
Aug 9, 2014, 5:50:14 AM8/9/14
to last...@googlegroups.com
Given the number of EPSG codes that are out there, I wonder if it might be easier to incorporate something like proj4 into lastools. I know it handles EPSG codes. Not sure how up to date it is as new ones come out. Might not be the way to go, but might save Martin a bit of work.

Kirk

Kirk Waters, PhD                     | NOAA Coastal Services Center
Applied Sciences Program       | 2234 South Hobson Ave
843-740-1227                          | Charleston, SC 29405    


Martin Isenburg

unread,
Aug 9, 2014, 6:49:36 AM8/9/14
to LAStools - efficient command line tools for LIDAR processing
Hello,

currently the "free" and open source code in LAStools (see the source
files geoprojectionconverter.cpp and geoprojectionconverter.hpp) only
supports geographic coordinates (aka longlat ot latlong) and any
lambert conformal conic (lcc) or transverse mercator (tm) projection,
hence all UTM projections and most stateplanes. If you can point me to
(easy-to-read) open C/C++ source code that implements the transforms
between geographic coordinates and Oblique Stereographic or the
various Albers flavours then I will add them as time permits.

The proj4 library is already incorporated in Howard's libLAS version
of las2las but linking to external libraries would destroy the
"ultra-easy to compile and port" nature of the LGPL LASlib library and
the basic open source tools built upon them. As these more exotic
projections seem to make only a tiny portion of the LiDAR processed by
LAStools it would seem a lot of complexity added for everyone to the
benefit of only few use cases.

All requested lambert conformal conic (lcc) or transverse mercator
(tm) projections were either already supported (2193, 28348, 28349,
28350, 28351, 28352, 28353, 28354, 28355, 28356) or have been added
(e.g. 2972,,2991, 2992,3006) to be part of the next release.

All the above pertains to horizontal datums. It seems the support for
vertical datums is rather spotty across LiDAR software, so I do not
really see the need to add EPSG codes like
http://spatialreference.org/ref/epsg/5764/

VERT_CS["Moturiki",
VERT_DATUM["Moturiki",2005,
AUTHORITY["EPSG","5162"]],
UNIT["m",1.0],
AXIS["Gravity-related height",UP],
AUTHORITY["EPSG","5764"]]

What are people doing with those?

Martin @rapidlasso

Heidemann, Hans

unread,
Aug 11, 2014, 10:20:35 AM8/11/14
to LAStools
The spotty support for vertical reference information in LAS (for that matter, all of lidar-dom) is a a chicken-egg issue.

Not much worth the effort to implement the functionality when it is so infrequent that you ever see files with the required metadata.

Kinda like end-to-end swath-based lidar data management: until people actually see it work, they'll never grasp its advantages.

Karl

H. Karl Heidemann, GISP
Physical Scientist, Lidar Science
U.S. Geological Survey
Mundt Federal Building
47914 252nd Street
Sioux Falls, SD  57110

"Nothing matters very much, and very few things ... matter at all."
- Arthur James Balfour

Angenent, Arnout [FGBV]

unread,
Aug 12, 2014, 2:52:35 AM8/12/14
to last...@googlegroups.com
Hi,


Is there a way to manually enter the vlr contents? I am not looking to execute a transformation with las2las, but just enter the text in the las files; my client requires the vlr information in the las file:

variable length header record 1 of 2:
reserved 43707
user ID 'LASF_Projection'
record ID 34735
length after header 48
description 'GeoKeyDirectoryTag (mandatory)'
GeoKeyDirectoryTag version 1.1.0 number of keys 5
key 1024 tiff_tag_location 0 count 1 value_offset 1 - GTModelTypeGeoKey: ModelTypeProjected
key 2050 tiff_tag_location 34737 count 1 value_offset 6019 - GeogGeodeticDatumGeoKey: DatumE_GRS1980
key 2052 tiff_tag_location 0 count 1 value_offset 9001 - GeogLinearUnitsGeoKey: Linear_Meter
key 3073 tiff_tag_location 0 count 16 value_offset 0 - PCSCitationGeoKey: Projection 1992
key 4097 tiff_tag_location 0 count 14 value_offset 16 - VerticalCitationGeoKey: Kronsztadt 86
variable length header record 2 of 2:
reserved 43707
user ID 'LASF_Projection'
record ID 34737
length after header 29
description 'GeoASCIIParamsTag (optional)'
GeoAsciiParamsTag (number of characters 29)
Projection 1992 Kronsztadt 86

Kind regards,
Fugro Geospatial B.V.

Arnout Angenent
Processing Supervisor

Telephone: +31 (0)70 31 70780 / Mobile: +31 (0)6 29 53 75 04 / Fax: +31 (0)70 31 70750
E-mail: a.ang...@fugro.com / Website: www.fugrogeospatial.com
Address: Dillenburgsingel 69, 2263 HW Leidschendam /
P.O. Box 3000, 2260 DA Leidschendam, The Netherlands
Trade Register Nr: 27152156 / VAT Nr: NL005621409B29
-----Original Message-----
From: last...@googlegroups.com [mailto:last...@googlegroups.com] On Behalf Of Martin Isenburg

Susana Gonzalez

unread,
Aug 18, 2014, 7:55:33 PM8/18/14
to last...@googlegroups.com
Hi,

The New Zealand Vertical Datum 2009 (NZVD2009) is the official vertical datum for New Zealand but there are 13 local mean sea level vertical datums. We would like to define Maturiki 1953 to eliminate the need for vertical reference alignment when conflating disparate datasets from another level vertical datum (LVD).
According to the Standard LiDAR Specifications in New Zealand, the Adjustment to local vertical datum is required in these circumstances:
. Where the vertical accuracy is exceeded when the Geoid derived orthometric heights are validated against LVD.
. Where a bias in the vertical validation resulting from anomalies in the Geoid model or other sources is identified across the whole project area.

Cheers

Susana Gonzalez
Forest Engineer, LiDAR Science
 
Interpine Group Ltd
NZ Office :  07 350 3209 extn 722
Australia:    02 8011 3645
Fax :             07 345 7571
Address :     99 Sala Street, PO Box 1209, Rotorua 3010, New Zealand
Website :     www.interpine.co.nz

Dennis Shimer

unread,
Oct 15, 2014, 12:19:44 PM10/15/14
to last...@googlegroups.com
A couple I have tried and not found are

EPSG:3728: NAD83(NSRS2007) / Ohio North (ftUS)
EPSG:3729: NAD83(NSRS2007) / Ohio South (ftUS)
EPSG:3734: NAD83 / Ohio North (ftUS)
EPSG:3735: NAD83 / Ohio South (ftUS)
EPSG:3753: NAD83(HARN) / Ohio North (ftUS)
EPSG:3754: NAD83(HARN) / Ohio South (ftUS)

http://spatialreference.org/ref/?search=ohio+ftus&srtext=Search

a...@uni-muenster.de

unread,
Nov 27, 2014, 10:02:05 AM11/27/14
to last...@googlegroups.com
Hi Martin,

it would be great if you could add the EPSG 3763 (ETRS89 / Portugal TM06) code which is used for Portugal.

Thanks,
André

Matt Weber

unread,
Feb 24, 2015, 11:28:49 PM2/24/15
to last...@googlegroups.com
Hi Martin, 

Thank you for taking requests. For research we are in the process of converting our old LiDAR data into EPSG 6418 - NAD83 (2011) California State Plane II (US Feet). It would be tremendously helpful to have that supported in las2las!

Best,
-Matt

carlisle haworth

unread,
May 7, 2015, 12:45:04 PM5/7/15
to last...@googlegroups.com
Hi Martin,
We are receiving data from surveyors here in California using 3494 for State Plane (NAD83_NSRS2007_California_zone_3).

thanks!


On Monday, November 18, 2013 at 3:29:27 PM UTC-8, Martin Isenburg wrote:

Martin Isenburg

unread,
Jun 5, 2015, 2:25:42 PM6/5/15
to LAStools - efficient command line tools for LIDAR processing
The EPSG codes 3494 and 3496 as well as support for several Albers Equal Area Conic projections is available in the latest version (150605).

luke dow

unread,
Jul 22, 2015, 4:59:25 PM7/22/15
to LAStools - efficient tools for LiDAR processing
Hi Martin, 

I work with Bob McGaughey at the University of Washington, and we are interested in a range of projections including: 

EPSG::2855: NAD83(HARN) Washington North
EPSG::2926: NAD83(HARN) Washington South
EPSG::2856: NAD83(HARN) Washington North (ftUS)
EPSG::2927: NAD83(HARN) Washington South (ftUS)

Additional projections of interest are:

NAD_1983_2011_USFS_R6_Albers. The projection information is below.
PROJCS["NAD_1983_2011_USFS_R6_Albers",GEOGCS["GCS_NAD_1983_2011",DATUM["D_NAD_1983_2011",SPHEROID["GRS_1980",6378137.0,298.257222101]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]],PROJECTION["Albers"],PARAMETER["False_Easting",600000.0],PARAMETER["False_Northing",0.0],PARAMETER["Central_Meridian",-120.0],PARAMETER["Standard_Parallel_1",43.0],PARAMETER["Standard_Parallel_2",48.0],PARAMETER["Latitude_Of_Origin",34.0],UNIT["Meter",1.0]]

Oregon Statewide Lambert Conformal Conic. The projection information is below.
PROJCS["NAD_1983_HARN_Oregon_Statewide_Lambert_Feet_Intl",GEOGCS["GCS_North_American_1983_HARN",DATUM["D_North_American_1983_HARN",SPHEROID["GRS_1980",6378137.0,298.257222101]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]],PROJECTION["Lambert_Conformal_Conic"],PARAMETER["False_Easting",1312335.958005249],PARAMETER["False_Northing",0.0],PARAMETER["Central_Meridian",-120.5],PARAMETER["Standard_Parallel_1",43.0],PARAMETER["Standard_Parallel_2",45.5],PARAMETER["Latitude_Of_Origin",41.75],UNIT["Foot",0.3048]]

I am new to LAStools so my apologies if any of these projections have already been addressed. 

Thank you,

Luke

Evon Silvia

unread,
Jul 23, 2015, 4:52:45 PM7/23/15
to last...@googlegroups.com
Yes! I've attached a full set of state plane EPSG codes for NAD83(HARN), in meters. I haven't gotten around to tabulating the feet versions.

Small correction to the codes Luke listed:
EPSG::2855: NAD83(HARN) Washington North
EPSG::2856: NAD83(HARN) Washington South
EPSG::2926: NAD83(HARN) Washington North (ftUS)
EPSG::2927: NAD83(HARN) Washington South (ftUS)

Evon

harn.csv

Kim Mantey

unread,
Jul 25, 2015, 5:04:51 AM7/25/15
to LAStools - efficient tools for LiDAR processing, martin....@gmail.com
Hi Martin,

We could use EPSG code 6543.  NAD 83(2011)/North Carolina (ftUS). 

Thanks!

Kim 

Martin Isenburg

unread,
Aug 4, 2015, 8:42:17 AM8/4/15
to Kim Mantey, LAStools - efficient tools for LiDAR processing
All (individually requested) EPSG codes have been added to the latest LAStools release (150803) from yesterday.

BarendErasmus

unread,
Sep 2, 2015, 7:51:37 AM9/2/15
to LAStools - efficient tools for LiDAR processing
Dear Martin
Could you please consider adding EPSG 2054? http://epsg.io/2054 It is a country-specific projection for South Africa.
'best
Barend Erasmus

Wimala van Iersel

unread,
Nov 13, 2015, 7:19:00 PM11/13/15
to LAStools - efficient tools for LiDAR processing

Hi Martin,

 

Could you please add EPSG:28992 (Amersfoort / RD New) for the Netherlands? The Dutch national LiDAR data set is in this coordinate system.

 

http://spatialreference.org/ref/epsg/28992/

 

Thank you,

Wimala


Op dinsdag 19 november 2013 00:29:27 UTC+1 schreef Martin Isenburg:

Martin Isenburg

unread,
Nov 13, 2015, 9:21:29 PM11/13/15
to LAStools - efficient command line tools for LIDAR processing
Hello Wimala,

the EPSG:28992 (Amersfoort / RD New) for the Netherlands uses a Oblique_Stereographic projection. I currently do not have source code to deal with this type of projection. If anyone can point me to an implementation of the Oblique_Stereographic projection that I could add to the geographicconverter.cpp and geographicconverter.h classes ... please contact me.

Regards,

Martin @rapidlasso


Wimala van Iersel

unread,
Nov 16, 2015, 9:12:23 AM11/16/15
to last...@googlegroups.com
Hi Martin,

Thanks for your reply. Could you specify a little bit more what kind of code or information you need to implement the Oblique_Stereographic projection? I can ask internally at the university here if anyone has a solution or piece of code that might be useful.

Kind regards,
Wimala (PhD @ Utrecht University)
--
Vriendelijke groeten,

Wimala van Iersel

Howard Butler

unread,
Nov 16, 2015, 5:21:39 PM11/16/15
to last...@googlegroups.com

Dennis Shimer

unread,
Dec 2, 2015, 2:25:11 PM12/2/15
to last...@googlegroups.com
All the data freely available in the U.S. State of Ohio is currently in
3753 and 3754.  Could those be added?

Michal Gallay

unread,
Dec 3, 2015, 3:38:02 PM12/3/15
to last...@googlegroups.com
Dear LAStools Community,

with regard to the missing EPSG codes, I would like to ask if the EPSG
5514 (Krovak EastNorth projections) could be added to the list of
projections.
It is the projection of lidar data distributed as DMR4G (Digital Model
of Relief 4th generation) for the Czech Republic.

http://www.gisat.cz/images/upload/c3256_petr-dusanek-prezentace-pro-gisat-130925.pdf
(presentation in Czech language)

Czech National Surveying and Cadastral Office
http://geoportal.cuzk.cz/%28S%28cfdqoze12z4wcv1kbk32igal%29%29/Default.aspx?mode=TextMeta&metadataXSL=full&side=vyskopis&metadataID=CZ-CUZK-DMR4G-V

The EPSG 5514 code is also relevant for the territory of Slovak
Republic, for which no national coverage exists but we have some
custom data from tailored missions also other research institutions in
Slovakia.

Thanks for consideration

Michal Gallay

Pavol Jozef Šafárik University in Košice, Slovakia
Mgr. Michal Gallay, PhD.
zástupca riaditeľa pre vedecko-výskumnú činnosť a zahraničné vzťahy
výskumný pracovník
Ústav geografie, Prírodovedecká fakulta
Univerzita Pavla Jozefa Šafárika v Košiciach
Jesenná 5
040 01 Košice

Deputy director for research and foreign relations
Research assistant
Institute of Geography
Faculty of Natural Sciences
Pavol Jozef Šafárik University in Košice
Jesenná 5
040 01 Košice, Slovakia

Tel: 00421 (0) 55 234 2352
Web: http://geo.ics.upjs.sk/
Web:http://www.upjs.sk/prirodovedecka-fakulta/

Martin Isenburg

unread,
Dec 3, 2015, 3:50:15 PM12/3/15
to LAStools - efficient command line tools for LIDAR processing
Hello,

it seems the "Krovak" projection is not a "standard projection" like UTM, traverse mercator, or lambert conic conformal. I don't plan to add the more rare projections to my simple geoprojectionconverter.[cpp/h] code unless there is a big incentive to do so. Eventually I will be handling those via an external call to an (optionally) present proj4 library. It seems like currently your best option would be to use las2las from libLAS to handle (re-)projections:


Regards,

Martin

Petr.D...@cuzk.cz

unread,
Dec 4, 2015, 3:30:28 PM12/4/15
to last...@googlegroups.com

Hallo Martin and Michal,

 

Martin I understood you do not want to add Krovak, it is really rear and strange projection. Even you apply the results will not be good enough for such precise data like LiDAR is.

 

For you Michal. Even if you use classical transformation like you find in proj 4 library, You will get bad results (In CZ mistake can by up to 3-5 meters, I do not know it in Slovakia). The problem is that JTSK network is inhomogenous so you need to apply so cold “Grid shift transformation”. It means you apply classical transformation and then you have some grid of X, Y corrections. Precision of corrections depends on density of that grid nad quality of geodetical observations. This grid should be provided by your national Land Survey Office (Úrad geodézie, kartografie a katastra Slovenskej republiky).

 

Best Results,

Petr       

 

From: last...@googlegroups.com [mailto:last...@googlegroups.com] On Behalf Of Martin Isenburg


Sent: Thursday, December 03, 2015 9:48 PM
To: LAStools - efficient command line tools for LIDAR processing

Martin Isenburg

unread,
Dec 28, 2015, 5:51:24 AM12/28/15
to LAStools - efficient command line tools for LIDAR processing
Hello Dennis,

done. This is now supported in the current release (151227)

las2dem -i BS827766.las -first_only -hillshade -step 2 -epsg 3754 -opng

see attached GE screen shot.

Martin @rapidlasso

--
support_for_ohio_epsg_3753_3754.jpg

Luiz Carlos Estraviz Rodriguez

unread,
Dec 29, 2015, 9:01:10 AM12/29/15
to last...@googlegroups.com
Hi Martin,

starting Feb 25th 2015, the official coordinate reference system in Brazil is SIRGAS 2000.
  (for more on this and a list of replaced systems: https://wiki.osgeo.org/wiki/Brazilian_Coordinate_Reference_Systems)

SIRGAS 2000 specs are:
Projection: longlat
EPSG code: 4989 (3D) or 4674 (2D)
PROJ string: '+proj=longlat +ellps=GRS80 +towgs84=0,0,0 +no_defs'
Reference: http://www.epsg-registry.org/ (unofficial reference)
Note: Considered identical to WGS84

It would be nice to have these codes included in the las2las list of EPSG projections.
Would that be possible to have it available in future releases of las2las?
Best wishes,

Luiz Carlos Estraviz Rodriguez (lc...@usp.br)
Departament of Forest Sciences
University of Sao Paulo


Luiz Carlos Estraviz Rodriguez

unread,
Dec 30, 2015, 2:25:07 AM12/30/15
to last...@googlegroups.com
Hello,
adding to the previous message
instead of code 4989 (that encompasses all Latin America countries) a more usefull set of EPSG codes for projects in Brazil would be:

<EPSG code>
31973: SIRGAS 2000 / UTM zone 19N
31974: SIRGAS 2000 / UTM zone 20N
31975: SIRGAS 2000 / UTM zone 21N
31976: SIRGAS 2000 / UTM zone 22N
31978: SIRGAS 2000 / UTM zone 18S
31979: SIRGAS 2000 / UTM zone 19S
31980: SIRGAS 2000 / UTM zone 20S
31981: SIRGAS 2000 / UTM zone 21S
31982: SIRGAS 2000 / UTM zone 22S
31983: SIRGAS 2000 / UTM zone 23S
31984: SIRGAS 2000 / UTM zone 24S

Thanks,

Luiz Carlos Estraviz Rodriguez (lc...@usp.br)
Departament of Forest Sciences
University of Sao Paulo


Martin Isenburg

unread,
Jan 6, 2016, 9:22:41 PM1/6/16
to LAStools - efficient command line tools for LIDAR processing
Hello,

all remaining EPSG codes that have some kind of standard datum and standard projection are now also supported by LAStools (version 160106) . The geoprojectionconverter simply parses the 'pcs.csv' of GDAL to get those EPSG codes that are not hard-coded.  Other new features in the 160106 release are:

- lasgrid, las2dem: can raster '-attribute [0|1|2...]' stored as "Extra Bytes"
- lasground: option '-by_flightline' allows to ground-classify flightlines separately
- LAStools: parse 'pcs.csv' file whenever an unknown EPSG code is encountered
- las2las & txt2las: create OGC WKT string for CRS for full LAS 1.4 compliance 
- all GUIs: can create a directory when browsing for one via pop-up window

There is also the prototype of a new tool called "laspublish" that is based on Potree. This had been announced here [1] and more on that one later but give it a try if you are curious ...


Martin @rapidlasso

lanc...@unavco.org

unread,
Apr 18, 2018, 7:11:05 AM4/18/18
to LAStools - efficient tools for LiDAR processing
Martin,

Please add Wellington, NZ 5770. 

Thanks,
Matt Lancaster
UNAVCO, Inc.

On Monday, November 18, 2013 at 4:29:27 PM UTC-7, Martin Isenburg wrote:

Mark Levitski

unread,
Apr 18, 2018, 9:30:16 AM4/18/18
to last...@googlegroups.com
Martin,

EPSG now has codes for the NAD 83 (2011) Wisconsin counties for both US survey feet and meters. Most surveyors, civil engineers and the Department of Transportation currently use these projections. A lot of work but would be nice to have them on the list so we don't have to manually enter the parameters. 

7528-7586 for meters
7587-7645 for US survey feet

Thanks,
Mark

Martin Isenburg

unread,
Apr 19, 2018, 11:16:56 AM4/19/18
to LAStools - efficient command line tools for LIDAR processing
Hello Mark,

you just need to update to the latest LAStools version. Yours must be quite old if those are not supported. At the end of this message are some examples (that make no sense but) that show support for  epsg 7528 and epsg 7587. Download the latest version from


and also get all these recent changes:

 9 April 2018 -- lasclip, las2las, lasheight, lasnoise: remove empty files unless '-dont_remove_empty_files'
 7 April 2018 -- lasview: also display point source ID (aka flightline number) for points picked with 'i'
 6 April 2018 -- las2iso and lasboundary: adding '-odbf' to the command line produces a 'z' attribute
 3 April 2018 -- lascolor: ability to process entire folders of LAS/LAZ and corresponding TIF files
 2 April 2018 -- blast2dem, blast2iso: improved generation of *.prj files
30 March 2018 -- laspublish: support recently released version 1.6 of Potree via command switch '-potree16' 
30 March 2018 -- blast2dem, blast2iso: support for input LASlayers '-ilay', '-ilaydir e:\layers', and '-ilay 2'
29 March 2018 -- LASlib, all LAStools: fix for "missing points" when writing just decompressed "native" LAS 1.4
28 March 2018 -- lasinfo: also report TOWGS84 Helmert transform stored in GeoTIFF key 2062 (GeogTOWGS84GeoKey)
27 March 2018 -- lasground, lasnoise, lasheight, lasthin, ... : also allow '-ignore_class 0' for classification 0
23 March 2018 -- LASlib, all LAStools: more checks for correct arguments for LAStransforms 
25 March 2018 -- NEW: lasvoxel computes a number of different summarizing 3D voxelizations for high-density LiDAR 
23 March 2018 -- lasvalidate: fixing bug introduced in LAStools release version 180322
22 March 2018 -- lascanopy, lasgrid, las2dem: fix for bug in writing TIF rasters that appeared in version 180303
21 March 2018 -- lasheight (and others): also allow '-ignore_class 2 5 0' to include classification 0
20 March 2018 -- LASlib: new '-transform_helmert 598.1,73.7,418.2,0.202,0.045,-2.455,6.7' for ECEF coordinates 
15 March 2018 -- lasvalidate: validation of files compressed with "native LAS 1.4 extension" of LASzip possible
[...]

Regards,

Martin @rapidlasso

e:\LAStools\bin>las2las -version
LAStools (by mar...@rapidlasso.com) version 180418

e:\LAStools\bin> las2las -i ..\data\test.laz -target_epsg 7528 -o mist.laz

e:\LAStools\bin>lasinfo -i mist.laz
lasinfo (180419) report for 'mist.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.0
  system identifier:          'LAStools (c) by rapidlasso GmbH'
  generating software:        'las2las (version 180418)'
  file creation day/year:     1/1
  header size:                227
  offset to point data:       467
  number var. length records: 3
  point data format:          0
  point data record length:   20
  number of point records:    11781
  number of points by return: 8513 2693 575 0 0
  scale factor x y z:         0.01 0.01 0.01
  offset x y z:               1300000 -100000 0
  min x y z:                  1334001.78 -148206.05 1480.88
  max x y z:                  1334153.85 -148061.19 1581.78
variable length header record 1 of 3:
  reserved             0
  user ID              'LASF_Projection'
  record ID            34735
  length after header  40
  description          'by LAStools of rapidlasso GmbH'
    GeoKeyDirectoryTag version 1.1.0 number of keys 4
      key 1024 tiff_tag_location 0 count 1 value_offset 1 - GTModelTypeGeoKey: ModelTypeProjected
      key 3072 tiff_tag_location 0 count 1 value_offset 7528 - ProjectedCSTypeGeoKey: NAD83(2011) / WISCRS Adams and Juneau (m)
      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
variable length header record 2 of 3:
  reserved             43707
  user ID              'NIIRS10'
  record ID            1
  length after header  26
  description          'NIIRS10 Tile Index'
variable length header record 3 of 3:
  reserved             43707
  user ID              'NIIRS10'
  record ID            4
  length after header  10
  description          'NIIRS10 Timestamp'
the header is followed by 2 user-defined bytes
LASzip compression (version 3.2r3 c2 50000): POINT10 2
reporting minimum and maximum for all LAS point record entries ...
  X             3400178    3415385
  Y            -4820605   -4806119
  Z              148088     158178
  intensity           0        194
  return_number       1          3
  number_of_returns   1          3
  edge_of_flight_line 0          0
  scan_direction_flag 0          1
  classification      1         15
  scan_angle_rank    10         15
  user_data           0          0
  point_source_ID   238        239
number of first returns:        8513
number of intermediate returns: 866
number of last returns:         7489
number of single returns:       5087
overview over number of returns of given pulse: 5087 4226 2468 0 0 0 0
histogram of classification of points:
            2020  unclassified (1)
            4597  ground (2)
             668  keypoint (8)
              27  water (9)
            4292  overlap (12)
             177  tower (15)


e:\LAStools\bin> las2las -i ..\data\test.laz -target_epsg 7587 -o mist.laz

e:\LAStools\bin>lasinfo -i mist.laz
lasinfo (180419) report for 'mist.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.0
  system identifier:          'LAStools (c) by rapidlasso GmbH'
  generating software:        'las2las (version 180418)'
  file creation day/year:     1/1
  header size:                227
  offset to point data:       467
  number var. length records: 3
  point data format:          0
  point data record length:   20
  number of point records:    11781
  number of points by return: 8513 2693 575 0 0
  scale factor x y z:         0.01 0.01 0.01
  offset x y z:               4300000 -400000 0
  min x y z:                  4376637.50 -486239.36 1480.88
  max x y z:                  4377136.41 -485764.08 1581.78
variable length header record 1 of 3:
  reserved             0
  user ID              'LASF_Projection'
  record ID            34735
  length after header  40
  description          'by LAStools of rapidlasso GmbH'
    GeoKeyDirectoryTag version 1.1.0 number of keys 4
      key 1024 tiff_tag_location 0 count 1 value_offset 1 - GTModelTypeGeoKey: ModelTypeProjected
      key 3072 tiff_tag_location 0 count 1 value_offset 7587 - ProjectedCSTypeGeoKey: NAD83(2011) / WISCRS Adams and Juneau (ftUS)
      key 3076 tiff_tag_location 0 count 1 value_offset 9003 - ProjLinearUnitsGeoKey: Linear_Foot_US_Survey
      key 4099 tiff_tag_location 0 count 1 value_offset 9001 - VerticalUnitsGeoKey: Linear_Meter
variable length header record 2 of 3:
  reserved             43707
  user ID              'NIIRS10'
  record ID            1
  length after header  26
  description          'NIIRS10 Tile Index'
variable length header record 3 of 3:
  reserved             43707
  user ID              'NIIRS10'
  record ID            4
  length after header  10
  description          'NIIRS10 Timestamp'
the header is followed by 2 user-defined bytes
LASzip compression (version 3.2r3 c2 50000): POINT10 2
reporting minimum and maximum for all LAS point record entries ...
  X             7663750    7713641
  Y            -8623936   -8576408
  Z              148088     158178
  intensity           0        194
  return_number       1          3
  number_of_returns   1          3
  edge_of_flight_line 0          0
  scan_direction_flag 0          1
  classification      1         15
  scan_angle_rank    10         15
  user_data           0          0
  point_source_ID   238        239
number of first returns:        8513
number of intermediate returns: 866
number of last returns:         7489
number of single returns:       5087
overview over number of returns of given pulse: 5087 4226 2468 0 0 0 0
histogram of classification of points:
            2020  unclassified (1)
            4597  ground (2)
             668  keypoint (8)
              27  water (9)
            4292  overlap (12)
             177  tower (15)

Mark Levitski

unread,
Apr 19, 2018, 11:49:16 AM4/19/18
to last...@googlegroups.com
Thanks, Martin. Yes, I am an old guy. :) 
However I did have the latest version. I just now understood that you don't have all projections available in the GUI dropdown, which I use for a starting point most of the time. I need some more experience with the code to be natural with writing the commands.

Martin Isenburg

unread,
Apr 19, 2018, 12:00:35 PM4/19/18
to LAStools - efficient command line tools for LIDAR processing
Hello,

my (mediocre) GUI exposes only a small subset of EPSG codes. Given that you probably only need to use a handful you can simply edit this file here:

E:\LAStools\bin\serf\geo\my_epsg.csv

to contain only the codes that you really care about and then only those will show up in the GUI. You can name them however you please, only the code need to be the correct one according to the EPSG that you intend to use. By default ' my_epsg.csv' file contains this random smorgasboard of EPSG codes that were relevant at one point or another during the development of LAStools and that are currently shown by default in the GUI.

e:\LAStools\bin> more serf\geo\my_epsg.csv
EPSG CODE,PROJECTION NAME
2157,Irenet95
2180,ETRS89 Pol. CS92
2193,NZGD2000
2225,NAD83 Cali 1 ft
2226,NAD83 Cali 2 ft
2227,NAD83 Cali 3 ft
2228,NAD83 Cali 4 ft
2229,NAD83 Cali 5 ft
2230,NAD83 Cali 6 ft
2248,NAD83 Maryland ft
2277,NAD83 Texas C ft
2855,NAD83-H Wash N
2856,NAD83-H Wash S
2875,NAD83-H Cali 6 ft
2924,NAD83-H Virg N ft
2925,NAD83-H Virg S ft
2926,NAD83-H Wash N ft
2927,NAD83-H Wash S ft
2945,NAD83 CSRS MTM 3
2946,NAD83 CSRS MTM 4
2947,NAD83 CSRS MTM 5
2948,NAD83 CSRS MTM 6
2949,NAD83 CSRS MTM 7
2972,RGF Guyane 1995
2991,NAD83 Oreg Lamb
3005,NAD83 BC Albers
3006,SWEREF99 TM
3034,ETRS89 ETRS LCC
3046,ETRS89 ETRS TM34
3047,ETRS89 ETRS TM35
3048,ETRS89 ETRS TM36
3116,MAGNA SIRGAS Bog
3141,Fiji 1956 UTM60 S
3142,Fiji 1956 UTM1 S
3308,GDA94 NSW Lamb
3414,SVY21 Sing TM
3460,Fiji Grid 1986
3753,NAD83-H Ohio N ft
3754,NAD83-H Ohio S ft
3763,ETRS89 Port TM06
3794,Slovak Grid 1996
3878,ETRS89 GK24FIN
3912,MGI 1901 Slovak
3944,RGF93 CC44
3945,RGF93 CC45
3946,RGF93 CC46
3947,RGF93 CC47
4093,ETRS89 DKTM1
4094,ETRS89 DKTM2
4095,ETRS89 DKTM3
4096,ETRS89 DKTM4
5071,NAD83-H Albers
5072,NAD83-2007 Albers
5105,ETRS89 NTM 5
5106,ETRS89 NTM 6
5107,ETRS89 NTM 7
5108,ETRS89 NTM 8
5109,ETRS89 NTM 9
5110,ETRS89 NTM 10
5111,ETRS89 NTM 11
5112,ETRS89 NTM 12
5113,ETRS89 NTM 13
5114,ETRS89 NTM 14
5115,ETRS89 NTM 15
5116,ETRS89 NTM 16
5117,ETRS89 NTM 17
5118,ETRS89 NTM 18
5119,ETRS89 NTM 19
5120,ETRS89 NTM 20
5121,ETRS89 NTM 21
5122,ETRS89 NTM 22
5123,ETRS89 NTM 23
5124,ETRS89 NTM 24
5125,ETRS89 NTM 25
5126,ETRS89 NTM 26
5127,ETRS89 NTM 27
5128,ETRS89 NTM 28
5129,ETRS89 NTM 29
5130,ETRS89 NTM 30
5650,ETRS89 UTM33 zE N
6350,NAD83-2011 Albers
21781,CH1903 LV03
23700,EOV HD72
27700,OSGB 1936
31370,Belge Lamb 1972

Regards,

Martin @rapidlasso

Mark Levitski

unread,
Apr 24, 2018, 11:58:32 AM4/24/18
to last...@googlegroups.com
Martin, I seem to be having some trouble with las2las in reprojecting using epsg codes. I downloaded the latest version and changed the my_epsg file. It is attached. I ran lasinfo for you on the file that I used:

lasinfo (180422) report for 'E:\LidarUSA\Springbreeze Redo noisy to groups.las'
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.2
  system identifier:          ''
  generating software:        'TerraScan'
  file creation day/year:     210/2017
  header size:                227
  offset to point data:       229
  number var. length records: 0
  point data format:          1
  point data record length:   28
  number of point records:    71701916
  number of points by return: 71701916 0 0 0 0
  scale factor x y z:         0.001 0.001 0.001
  offset x y z:               3000000 0 0
  min x y z:                  2216284.885 496016.682 1568.680
  max x y z:                  2218683.344 498993.706 1699.179
the header is followed by 2 user-defined bytes
reporting minimum and maximum for all LAS point record entries ...
  X          -783715115 -781316656
  Y           496016682  498993706
  Z             1568680    1699179
  intensity           4        255
  return_number       1          1
  number_of_returns   1          1
  edge_of_flight_line 0          0
  scan_direction_flag 0          0
  classification      1         18
  scan_angle_rank     7         90
  user_data           0          0
  point_source_ID     0         31
  gps_time 580106.815653 580921.985016
number of first returns:        71701916
number of intermediate returns: 0
number of last returns:         71701916
number of single returns:       71701916
overview over number of returns of given pulse: 71701916 0 0 0 0 0 0
histogram of classification of points:
        30806117  unclassified (1)
         7149900  ground (2)
        29077414  low vegetation (3)
          104853  medium vegetation (4)
           10016  high vegetation (5)
         2408764  building (6)
          119925  water (9)
         1327214  rail (10)
             818  overlap (12)
           44338  wire guard (13)
          512940  wire conductor (14)
           17556  tower (15)
          118282  bridge deck (17)
            3779  Reserved for ASPRS Definition (18)

Yes, I know the scale factor xyz should be 0.01 for this. I remember this data was post processed in NAD 83 Wisconsin Central, US survey feet and it shows up in the right place on the earth using that projection, but I need it reprojected into the 7616 code for our Wisconsin county CRS. I keep getting lat long as a result (and of course I get meters instead of survey feet, but you explained that will be fixed in a future release).

What am I doing wrong?

Thanks,
Mark

On Thu, Apr 19, 2018 at 11:12 AM, Mark Levitski <northe...@gmail.com> wrote:
Yay!  I should have thought there was a library somewhere for that. 
You have created such a wonderful life for yourself!  Thanks, Martin.

Mark
my_epsg.csv

Martin Isenburg

unread,
Apr 24, 2018, 7:31:29 PM4/24/18
to LAStools - efficient command line tools for LIDAR processing
Hello,

to do a reprojection for files that do not have geo-referecing information in the file (and the lasinfo report shows that evidently you do not have that) you have to specify both the source and the target projection 

Your source projection seems to be EPSG code 2288:

Your target projection will be EPSG code 7616:

las2las -i wisc.laz ^
            -epsg 2288 ^
            -target_epsg 7616 ^
            -i wisc_new.laz

Now be advised that there is also a datum change from NAD83 to NAD83(2011) and LAStools will not do that for you. You will stay on the NAD83 datum as far as the coordinates are concerned. You should read through these discussions on the topic of how much of a shift in the coordinates you can expect:


Kirk Waters from NOAA has a nice blog article about that


Regards,

Martin

PS: It seems rather odd that your LiDAR file has only *single* returns. I doubt that this should be like that. Export / processing error?


Mark Levitski

unread,
Apr 24, 2018, 7:50:01 PM4/24/18