<div dir="ltr"><div>Greg,</div><div><br></div><div>These are good questions. Hopefully my response will answer your questions.</div><div><br></div><div>In my old install of pyproj v2.2.2 the transformation from EPSG:3857 to UTM Z17N NAD83 Original (EPSG:26917) and UTMZ17N CSRS (EPSG:2958) would produce the same coordinate results.</div><div><br></div><div># python2.7 pyproj v2.2.2<br></div><div>from pyproj import CRS, Transformer<br>crs_3857 = CRS("EPSG:3857")<br>crs_26917 = CRS("EPSG:26917")<br>crs_2958 = CRS("EPSG:2958")</div><div>wmerc2utmOrg = Transformer.from_crs(crs_3857, crs_26917, always_xy=True)<br>wmerc2utmCSRS = Transformer.from_crs(crs_3857, crs_2958, always_xy=True)<br>wmerc2utmOrg.transform(-8851000, 5433000)<br>(619889.7678080541, 4849626.937111458)<br>wmerc2utmCSRS.transform(-8851000, 5433000)<br>(619889.7678080541, 4849626.937111458)<br></div><div><br></div><div>In this case the web mercator to utm nad 83 original is correct, however the CSRS result is off as both transformations are treated the same. I can determine a more accurate position for the CSRS coordinates by applying a gridshift using the proj cs2cs utility:</div><div><br></div><div>cs2cs +proj=utm +zone=17 +lat_0=0 +lon_0=-81 +k=0.9996 +x_0=500000 +y_0=0 +ellps=GRS80 +units=m +nadgrids=/home/grids/ON83CSv1.gsb +to +init=EPSG:2958 <<EOF<br>619889.76 4849626.93<br>EOF<br>619889.73 4849626.65 0.00</div><div></div><div><br></div><div>This is a shift of -0.03m X and 0.28m Y
from utm nad83 original to utm csrs.
</div><div></div><div><br></div><div>After I upgraded to pyproj v3.0.1 I'm seeing a different result for the Web Mercator to UTM CSRS transform <br></div><div><br></div><div># python.3.6.8 pyproj v3.0.1<br></div><div>from pyproj import CRS, Transformer<br>crs_3857 = CRS("EPSG:3857")<br>crs_26917 = CRS("EPSG:26917")<br>crs_2958 = CRS("EPSG:2958")<br>wmerc2utmOrg = Transformer.from_crs(crs_3857, crs_26917, always_xy=True)<br>wmerc2utmCSRS = Transformer.from_crs(crs_3857, crs_2958, always_xy=True)<br>wmerc2utmOrg.transform(-8851000, 5433000)<br>(619889.7678080541, 4849626.937111458)<br>wmerc2utmCSRS.transform(-8851000, 5433000)<br>(619890.0493627792, 4849625.986608229)<br></div><div><br></div><div>So I'm seeing a shift of -0.28m X and 0.95m Y from utm nad83 original to utm csrs which is off by -0.25m X and 0.67m Y from my expected result</div><div> <br></div><div></div><div>My guess this is due to how pyproj utilizing a helmert transformation</div><div><br>
</div><div># python.3.6.8 pyproj v3.0.1 <br></div><div>from pyproj.transformer import TransformerGroup</div><div>wmerc2utmOrg_tg = TransformerGroup("epsg:3857", "epsg:26917")</div><div>wmerc2utmOrg_tg.transformers[0].description<br>'Inverse of Popular Visualisation Pseudo-Mercator + Inverse of NAD83 to WGS 84 (1) + UTM zone 17N'<br>wmerc2utmOrg_tg.transformers[0].definition<br>'proj=pipeline step inv proj=webmerc lat_0=0 lon_0=0 x_0=0 y_0=0 ellps=WGS84 step proj=utm zone=17 ellps=GRS80'<br></div><div>wmerc2utmCSRS_tg = TransformerGroup("epsg:3857", "epsg:2958")<br></div><div>wmerc2utmCSRS_tg.transformers[0].description<br>'Inverse of Popular Visualisation Pseudo-Mercator + Inverse of NAD83(CSRS) to WGS 84 (2) + UTM zone 17N'<br>wmerc2utmCSRS_tg.transformers[0].definition<br>'proj=pipeline step inv proj=webmerc lat_0=0 lon_0=0 x_0=0 y_0=0 ellps=WGS84 step proj=push v_3 step proj=cart ellps=WGS84 step inv proj=helmert x=-0.991 y=1.9072 z=0.5129 rx=-0.0257899075194932 ry=-0.0096500989602704 rz=-0.0116599432323421 s=0 convention=coordinate_frame step inv proj=cart ellps=GRS80 step proj=pop v_3 step proj=utm zone=17 ellps=GRS80'<br></div><div><br></div><div><br></div><div>This should probably be posted to the proj community but any help would be great.<br></div><div><br></div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 16 Jun 2022 at 11:54, Greg Troxel <<a href="mailto:gdt@lexort.com">gdt@lexort.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
Travis Kirstine <<a href="mailto:traviskirstine@gmail.com" target="_blank">traviskirstine@gmail.com</a>> writes:<br>
<br>
> We have a fully seeded cache in a Google Maps / EPSG:3857 SRS and offer the<br>
> data up through a WMS with various SRS supported, MapProxy is handling the<br>
> reprojection. We've noticed that with our latest upgrade to mapproxy v14.0<br>
> with pyproj 3.0.1 / proj 7.2.1 there is an error with some SRS being<br>
> shifted incorrectly, specifically EPSG:2958 / UTM Zone17 CSRS. How does<br>
> mapproxy handle the image reprojection - is it using pyproj or some other<br>
> library?<br>
<br>
What do you think is happening, and why?<br>
What do you think shoudl be happening?<br>
<br>
CSRS is presumably NAD83(CSRSv?).<br>
<br>
3857 refers to the WGS84 ensemble, which includes WGS84(TRANSIT) which<br>
is approximately equal to NAD83(1986) and presumably then to NAD83(CSRS)<br>
(the unsuffixed version).<br>
<br>
So I'd expect no transform. Arguably, there should be one, as the<br>
imagery probably ought to be in spherical mercator from WGS84(G2139)<br>
which is distinct from NAD83(CSRSvRECENT).<br>
</blockquote></div>