[Qgis-user] QGIS exported layers lose defined CRS definition

Neil B osgeo+qgis at benneb.ca
Fri Jul 9 17:10:39 PDT 2021


Following up from Nicolas' response. QGIS 3.4 used EPSG and IGNF CRS
definitions. As the definition you have for Arizona is ESRI's version of
the CRS, it will not match with what's in PROJ on your current install.
QGIS assigns it a 100001 number because it thinks the CRS is a user custom
definition and QGIS (in older versions) assigns numbers beginning at 100000
to store the user definitions. (There's a high probability that if you
brought the same layer into your project again or in a new project in QGIS
3.4, it would be assigned the number 100002.)

If you have no specific reason to use ESRI's CRS number (meaning you're not
using any ESRI software with the Spatialite database), you may want to use
the EPSG Code 3421 which is US State Plane NAD83 in US ft for Nevada East
which should greatly increase the reliability of maintaining the same CRS
Code between newer and older versions of QGIS due to different versions of
PROJ on the back end.

For your project in QGIS 3.4.4, you can go in to the properties for the
layer and explicitly set which CRS you want to use for that layer.

Cheers!
~Neil B.

On Fri, Jul 9, 2021 at 11:51 AM Nicolas Cadieux <njacadieux.gitlab at gmail.com>
wrote:

> Hi,
>
> 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.
>
> Nicolas Cadieux
> https://gitlab.com/njacadieux
>
> Le 9 juill. 2021 à 10:38, Eric Seymour <ecseymour at gmail.com> a écrit :
>
> 
> Hello,
>
> I have layers stored in a Spatialite database with a defined CRS of 102707
> (https://spatialreference.org/ref/esri/102707/). 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?
>
> -Eric
> _______________________________________________
> Qgis-user mailing list
> Qgis-user at lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user
>
> _______________________________________________
> Qgis-user mailing list
> Qgis-user at lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-user/attachments/20210709/589b92b2/attachment.html>


More information about the Qgis-user mailing list