<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Kirk,</p>
<p>this is tricky topic.</p>
<p>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.<br>
</p>
<p>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).</p>
<p>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.</p>
<p>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.</p>
<p>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.<br>
</p>
<p>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!</p>
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.<br>
<p>Hope that makes sense</p>
<p>Even<br>
</p>
<div class="moz-cite-prefix">Le 02/06/2021 à 21:33, Kirk Waters -
NOAA Federal via PROJ a écrit :<br>
</div>
<blockquote type="cite"
cite="mid:CADm=QrTcWBFYkfOAcZsr8y-rK08v9GJNasGBoZSC-umMTOJcsA@mail.gmail.com">
<div dir="ltr">Dear proj list,
<div>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.</div>
<div>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):</div>
<div><br>
</div>
<div>cs2cs EPSG:6570 EPSG:32033 << EOF</div>
<div>2320610.000 353815.000 0</div>
<div>EOF</div>
<div><br>
</div>
<div>which returns:</div>
<div>2320626.52 353751.41 0.00<br>
<div>
<div dir="ltr" data-smartmail="gmail_signature">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div><br>
</div>
<div>Using the NGS NCAT online program, that
should be:</div>
<div><span>2320568.869 </span><span>353687.842</span><br>
</div>
<div><span><br>
</span></div>
<div><span>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:</span></div>
<div>cs2cs EPSG:6318 EPSG:4267<span><br>
</span></div>
<div>with inputs of </div>
<div>32d48'4.701"N 79d57'23.546"W 0.000<br>
</div>
<div>has outputs of</div>
<div>32d48'4.701"N 79d57'23.546"W 0.000<br>
</div>
<div><br>
</div>
<div>If I use NAD83 (EPSG 4269) instead of
NAD83(2011), things look right and I get
output of:</div>
<div>32d48'4.066"N 79d57'24.227"W 0.000<br>
</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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?</div>
<div><br>
</div>
<div>Kirk Waters, PhD |
NOAA Office for Coastal Management<br>
</div>
<div>Applied Sciences Program | 2234
South Hobson Ave<br>
843-740-1227 (empty office) | Charleston,
SC 29405</div>
<div>843-324-2203 (cell during COVID)
<div><a
href="http://coast.noaa.gov/digitalcoast"
target="_blank" moz-do-not-send="true">coast.noaa.gov/digitalcoast</a><br>
</div>
</div>
<div><br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
PROJ mailing list
<a class="moz-txt-link-abbreviated" href="mailto:PROJ@lists.osgeo.org">PROJ@lists.osgeo.org</a>
<a class="moz-txt-link-freetext" href="https://lists.osgeo.org/mailman/listinfo/proj">https://lists.osgeo.org/mailman/listinfo/proj</a>
</pre>
</blockquote>
<pre class="moz-signature" cols="72">--
<a class="moz-txt-link-freetext" href="http://www.spatialys.com">http://www.spatialys.com</a>
My software is free, but my time generally not.</pre>
</body>
</html>