CRS interpretation in QGIS?Problem with spatial reference system / shapefile projectionHow to correct a wrong projection of shapefile?How do I Fix Projection Issues in QGISQGIS CRS correct, but layers appear warpedQGIS area calculation differs when on the fly CRS transformation enabledAdding OpenLayers basemap to a QGIS project changes the CRS to WGS 84 / Pseudo MercatorShapefile CRS conundrumQGIS - CRS setting for Slovenia national agency dataUnable to modify the QGIS project CRSAccuracy of “on-the-fly” CRS transformation in QGISQGIS changing canvas CRS defaults to imported layerCan't find OTF (on the fly) check box in QGIS 3Aligning Vector Data with Basemap in QGIS?

What is this green alien supposed to be on the American covers of the "Hitchhiker's Guide to the Galaxy"?

How possible is a successful landing just with 1 wing?

CRS interpretation in QGIS?

How many bits in the resultant hash will change, if the x bits are changed in its the original input?

Optimising the Selection of MaxValue in Association

What would be the safest way to drop thousands of small, hard objects from a typical, high wing, GA airplane?

What is the difference between a Hosaka, Ono-Sendai, and a "deck"?

Using SPID in DB Tables (instead of Table Variable)

Why does "git status" show I'm on the master branch and "git branch" does not in a newly created repository?

Generating a PIN from cryptographic bytes

How can I obtain a complete list of the kinds of atomic expressions in the Wolfram Language using only the language itself?

Wordplay addition paradox

Create Array from list of indices/values

What are the basics of commands in Minecraft Java Edition?

A Table Representing the altar

Kepler space telescope undetected planets

What are "full piece" and "half piece" in chess?

How do aircraft making HF transmissions avoid stepping on other HF users?

Why do so many pure math PhD students drop out or leave academia, compared to applied mathematics PhDs?

What are the first usages of "thong" as a wearable item of clothing, both on the feet and on the waist?

What "fuel more powerful than anything the West (had) in stock" put Laika in orbit aboard Sputnik 2?

What is the word for "event executor"?

Why doesn't philosophy have higher standards for its arguments?

Is it rude to refer to janitors as 'floor people'?



CRS interpretation in QGIS?


Problem with spatial reference system / shapefile projectionHow to correct a wrong projection of shapefile?How do I Fix Projection Issues in QGISQGIS CRS correct, but layers appear warpedQGIS area calculation differs when on the fly CRS transformation enabledAdding OpenLayers basemap to a QGIS project changes the CRS to WGS 84 / Pseudo MercatorShapefile CRS conundrumQGIS - CRS setting for Slovenia national agency dataUnable to modify the QGIS project CRSAccuracy of “on-the-fly” CRS transformation in QGISQGIS changing canvas CRS defaults to imported layerCan't find OTF (on the fly) check box in QGIS 3Aligning Vector Data with Basemap in QGIS?






.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty margin-bottom:0;








3















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?










share|improve this question









New contributor



cameron bronstein is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.














  • 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
    8 hours ago

















3















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?










share|improve this question









New contributor



cameron bronstein is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.














  • 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
    8 hours ago













3












3








3








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?










share|improve this question









New contributor



cameron bronstein is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











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?







coordinate-system qgis-3 file-geodatabase






share|improve this question









New contributor



cameron bronstein is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.










share|improve this question









New contributor



cameron bronstein is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.








share|improve this question




share|improve this question








edited 7 hours ago







cameron bronstein













New contributor



cameron bronstein is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.








asked 8 hours ago









cameron bronsteincameron bronstein

214 bronze badges




214 bronze badges




New contributor



cameron bronstein is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.




New contributor




cameron bronstein is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









  • 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
    8 hours ago












  • 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
    8 hours ago







1




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
8 hours ago





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
8 hours ago










1 Answer
1






active

oldest

votes


















3














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






share|improve this answer

























  • 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
    4 hours ago












  • @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
    4 hours ago













Your Answer








StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "79"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);






cameron bronstein is a new contributor. Be nice, and check out our Code of Conduct.









draft saved

draft discarded


















StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fgis.stackexchange.com%2fquestions%2f329123%2fcrs-interpretation-in-qgis%23new-answer', 'question_page');

);

Post as a guest















Required, but never shown

























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes









3














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






share|improve this answer

























  • 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
    4 hours ago












  • @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
    4 hours ago















3














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






share|improve this answer

























  • 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
    4 hours ago












  • @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
    4 hours ago













3












3








3







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






share|improve this answer















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







share|improve this answer














share|improve this answer



share|improve this answer








edited 2 hours ago

























answered 4 hours ago









user2856user2856

32.3k2 gold badges63 silver badges112 bronze badges




32.3k2 gold badges63 silver badges112 bronze badges












  • 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
    4 hours ago












  • @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
    4 hours ago

















  • 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
    4 hours ago












  • @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
    4 hours ago
















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
4 hours ago






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
4 hours ago














@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
4 hours ago





@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
4 hours ago










cameron bronstein is a new contributor. Be nice, and check out our Code of Conduct.









draft saved

draft discarded


















cameron bronstein is a new contributor. Be nice, and check out our Code of Conduct.












cameron bronstein is a new contributor. Be nice, and check out our Code of Conduct.











cameron bronstein is a new contributor. Be nice, and check out our Code of Conduct.














Thanks for contributing an answer to Geographic Information Systems Stack Exchange!


  • Please be sure to answer the question. Provide details and share your research!

But avoid


  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fgis.stackexchange.com%2fquestions%2f329123%2fcrs-interpretation-in-qgis%23new-answer', 'question_page');

);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

Canceling a color specificationRandomly assigning color to Graphics3D objects?Default color for Filling in Mathematica 9Coloring specific elements of sets with a prime modified order in an array plotHow to pick a color differing significantly from the colors already in a given color list?Detection of the text colorColor numbers based on their valueCan color schemes for use with ColorData include opacity specification?My dynamic color schemes

Invision Community Contents History See also References External links Navigation menuProprietaryinvisioncommunity.comIPS Community ForumsIPS Community Forumsthis blog entry"License Changes, IP.Board 3.4, and the Future""Interview -- Matt Mecham of Ibforums""CEO Invision Power Board, Matt Mecham Is a Liar, Thief!"IPB License Explanation 1.3, 1.3.1, 2.0, and 2.1ArchivedSecurity Fixes, Updates And Enhancements For IPB 1.3.1Archived"New Demo Accounts - Invision Power Services"the original"New Default Skin"the original"Invision Power Board 3.0.0 and Applications Released"the original"Archived copy"the original"Perpetual licenses being done away with""Release Notes - Invision Power Services""Introducing: IPS Community Suite 4!"Invision Community Release Notes

199年 目錄 大件事 到箇年出世嗰人 到箇年死嗰人 節慶、風俗習慣 導覽選單