5

I know there are related questions like this one, this question, and this one all over this site. I have tried the many possible solutions I have seen at the point.

The problem: I am trying to make a basic overlay of 5 years of CA tree mortality data using QGIS 3.6. The data can be found here. The downloads are geodatabase format. Navigate to each year's page and scroll down to the data section for the corresponding gdb. Based on email conversation with folks at US Forest Service, this could possibly be a mismatched geometry and projection file issue, but I don't know how to confirm that.

OTF projection is default in this version of QGIS and works well when adding years 2014-2016 (projected in EPSG:3310 - NAD83 / California Albers) to an OSM basemap. However, when adding years 2017 and 2018, QGIS asks for a projection because there seems to be no associated or an incorrect .prj (or the gdb equivalent). Despite setting these layers to the same EPSG 3310 but they end up near Alaska.

enter image description here

Things I have tried:

  1. I emailed folks at the US Forest Service and they suggested trying EPSG:102003 - USA_Contiguous_Albers_Equal_Area_Conic. This brings the layer closer but still incorrect projection. enter image description here
  2. Exporting the layers as shapefiles with the CRS set to 3310 (and EPSG: 102003 CRS) and re-adding to QGIS. This does not work.
  3. Disabling OTF projection, setting the project CRS to 3310 and manually setting each layer CRS - 17/18 still end up near Alaska.

Another contact at USFS was able to successfully overlay 17/18 with the prior years data using ArcGIS, so maybe there is something that the QGIS software is missing?

I don't know enough about the inner workings of the software.

Maybe there is some implicit change that can be made to the data to correct the projection issue?

Does anyone have other suggestions?

  • 1
    Welcome to GIS SE! We're a little different from other sites; this isn't a discussion forum but a Q&A site. Please check out our short tour to learn about our focussed Q&A format. Please provide links to the "related questions all over this site" so that potential answerers do not have to volunteer additional time searching for them before deciding whether your question is new. – PolyGeo Jul 17 at 21:45
6

ArcGIS Pro and GDAL/OGR report the CRS as ESRI:102039 "USA Contiguous Albers Equal Area Conic USGS version". This is an ESRI code not standard EPSG. The WKT for this CRS is:

PROJCS["USA_Contiguous_Albers_Equal_Area_Conic_USGS_version",
    GEOGCS["GCS_North_American_1983",
        DATUM["North_American_Datum_1983",
            SPHEROID["GRS_1980",6378137.0,298.257222101]],
        PRIMEM["Greenwich",0.0],
        UNIT["Degree",0.0174532925199433]],
    PROJECTION["Albers_Conic_Equal_Area"],
    PARAMETER["False_Easting",0.0],
    PARAMETER["False_Northing",0.0],
    PARAMETER["longitude_of_center",-96.0],
    PARAMETER["Standard_Parallel_1",29.5],
    PARAMETER["Standard_Parallel_2",45.5],
    PARAMETER["latitude_of_center",23.0],
    UNIT["Meter",1.0],
    AUTHORITY["Esri","102039"]]

This CRS is very similar to the ESRI:102003 CRS that the US Forest Service advised you to try, however the central latitude differs (37.5 v.s 23.0) which is why the data was still shifted north.

My QGIS (3.6.3 using PROJ6.1.0) doesn't include ESRI:102039 but luckily the definition for ESRI:102039 is the same as NAD83 / Conus Albers (EPSG:5070) so you can just use that.

enter image description here

Alternatively (from my original answer), you can define a custom CRS with the following definition:

  • Name: USA_Contiguous_Albers_Equal_Area_Conic_USGS_version
  • Parameters: +proj=aea +lat_1=29.5 +lat_2=45.5 +lat_0=23.0 +lon_0=-96 +x_0=0 +y_0=0 +datum=NAD83 +units=m +no_defs

enter image description here

  • Thank you so much! This worked well. To confirm, the problem was that the CRS for these layers did not exist in QGIS, correct? So we just had to create a new CRS based on the correct parameters from ArcGIS. – cameron bronstein Jul 18 at 1:35
  • @cameronbronstein yes, that's right. The underlying GDAL/OGR OpenFileGDB driver that QGIS uses to read the data understands the CRS, but QGIS itself doesn't. – user2856 Jul 18 at 1:40
  • 1
    @cameronbronstein or you can just use NAD83 / Conus Albers (EPSG:5070) which is identical to ESRI:102039 and is understood by QGIS – user2856 Jul 18 at 21:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.