<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">Hi,<div><br><div>There have been a lot of improvements in the way crs are handled by QGIS and Proj4. I expect that when a definition is not recognized by an older QGIS, this will happen.<br><br><div dir="ltr">Nicolas Cadieux<div><a href="https://gitlab.com/njacadieux">https://gitlab.com/njacadieux</a></div></div><div dir="ltr"><br><blockquote type="cite">Le 9 juill. 2021 à 10:38, Eric Seymour <ecseymour@gmail.com> a écrit :<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div>Hello, <br></div><div><br></div><div>I have layers stored in a Spatialite database with a defined CRS of 102707 (<a href="https://spatialreference.org/ref/esri/102707/">https://spatialreference.org/ref/esri/102707/</a>). When I select features from this layer and export them back to the database from within QGIS (3.4.4), using the same CRS, the resulting layer has a CRS of USER:100001. The parameters are the same, e.g., the same latitude of origin, but I want the exported tables to be clearly identified with the 102707 CRS. I have never encountered this problem with other CRSs. Does anyone have any idea why this would happen for some CRSs? </div><div><br></div><div>-Eric<br> </div></div>
<span>_______________________________________________</span><br><span>Qgis-user mailing list</span><br><span>Qgis-user@lists.osgeo.org</span><br><span>List info: https://lists.osgeo.org/mailman/listinfo/qgis-user</span><br><span>Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user</span><br></div></blockquote></div></div></body></html>