[PROJ] proj8 and NAD27 <-> NAD83 transform

Thu Jun 3 03:37:54 PDT 2021

Even,
Thank you very much, that's very helpful. It's along the lines of what I
was thinking was the problem, but I hadn't gotten far enough to realize I
could add an entry in the database. The other option is to figure out the
right EPSG code to pass to GDAL to pretend the transform has already
happened.

Kirk

On Wed, Jun 2, 2021 at 4:17 PM Even Rouault <even.rouault at spatialys.com>
wrote:

> Kirk,
>
> this is tricky topic.
>
> Prerequisite knowledge: when transforming between datums A and B, PROJ can
> obviousl use transformations present in its database that have A as source
> and B as target (or the reverse), as well chaining 2 transformations going
> through one intermediate datum C: A -> C followed by C -> B. It can't do A
> -> C -> D -> B.
>
> In the NAD83(2011) to NAD27 case, there is no direct transformation
> registered between both datum. So PROJ has to go through the intermediate
> datum way, and NAD83 can be a possibility (likely the only one, but I
> didn't check).
>
> For NAD27 to NAD83, for the US, PROJ only handles NADCON4 grids for Conus
> and Alaska. NADCON5 is registered in our database, but we don't have the
> code yet to handle it.
>
> For NAD83 to NAD83 (2011), there is a single transformation registered in
> EPSG, EPSG:8971, and it is only valid for Gulf of Mexico and it is a
> 0-meter shift between both datums.
>
> So when chaining the 2 steps and intersecting the validity extent of the
> available transformations, NAD27 to NAD83 (2011) has a known accuracy only
> for Gulf of Mexico. For other areas, PROJ can't really know that taking as
> approximation NAD83 ~= NAD83 (2011) and using the NAD27 to NAD83
> transformation would give something that is (likely) better than just
> giving up and considering that NAD27 -> NAD83(2011) is a no-op with a
> unknown accuracy.
>
> If NADCON5 grids were implemented, we could potentially use the NAD83 ->
> NAD83 (HARN) -> NAD83 (NSRS2007) -> NAD83 (2011) transformations that are
> valid for CONUS, but that would require extra logic in code or adding
> concatenated transformations in the database so that PROJ doesn't have to
> figure all those intermediates!
> If for your purpose NAD83 ~= NAD83 (2011) is a reasonable approximation,
> you could potentially add an entry in the database similar to EPSG:8971 but
> with a validity area that encompasses whole CONUS.
>
> Hope that makes sense
>
> Even
> Le 02/06/2021 à 21:33, Kirk Waters - NOAA Federal via PROJ a écrit :
>
> Dear proj list,
> I'm having a bit of trouble with proj and I'm hoping someone can tell me
> where I've gone wrong. For context, my primary issue is converting a raster
> from NAD83 state plane to NAD27 state plane using GDAL, which uses proj
> under the hood. It looks like it's proj that is causing me problems. I used
> conda to install a fresh environment with proj8 and proj-data on a RHEL7
> machine.
> Here's the conversion that I think is giving the wrong answers (EPSG 6570
> is NAD83(2011) South Carolina State Plane (ft) and EPSG 32033 is NAD27
> South Carolina South):
>
> cs2cs EPSG:6570 EPSG:32033 << EOF
> 2320610.000 353815.000 0
> EOF
>
> which returns:
> 2320626.52      353751.41 0.00
>
> Using the NGS NCAT online program, that should be:
> 2320568.869   353687.842
>
> I did the transform in parts and found that the issue is in the reference
> frame transform between NAD83(2011) lat lon and NAD27 lat lon, where no
> change happens, but it should. That is:
> cs2cs EPSG:6318 EPSG:4267
> with inputs of
> 32d48'4.701"N   79d57'23.546"W 0.000
> has outputs of
> 32d48'4.701"N   79d57'23.546"W 0.000
>
> If I use NAD83 (EPSG 4269) instead of NAD83(2011), things look right and I
> get output of:
> 32d48'4.066"N   79d57'24.227"W 0.000
>
> Trying to change from NAD83(2011) to NAD83 (EPSG 6318 to 4269) gives no
> change, so I'm assuming PROJ doesn't know that transform. I'm guessing that
> because it doesn't know that transform, it can't figure out that it should
> do the NAD83 to NAD27 part, so instead of being a couple meters off, it's
> off by 50 meters or so. If I do the transforms in parts, SP83 to
> NAD83(2011), NAD83(2011) to NAD83, NAD83 to NAD27, NAD27 to SP27, I get the
> right answer within the couple meters due to the missing transform.
>
> Is the transform from NAD83(2011) to NAD83 something I just missed
> installing? Without it, it looks like my GDAL process will be painful. Is
> there a better way to handle it?
>
> Kirk Waters, PhD                     | NOAA Office for Coastal Management
> Applied Sciences Program      | 2234 South Hobson Ave
> 843-740-1227 (empty office)   | Charleston, SC 29405
> 843-324-2203 (cell during COVID)
> coast.noaa.gov/digitalcoast
>
>
> _______________________________________________
> PROJ mailing listPROJ at lists.osgeo.orghttps://lists.osgeo.org/mailman/listinfo/proj
>
> -- http://www.spatialys.com
> My software is free, but my time generally not.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20210603/48be926d/attachment-0001.html>