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;
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.
Things I have tried:
- 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.
- Exporting the layers as shapefiles with the CRS set to 3310 (and EPSG: 102003 CRS) and re-adding to QGIS. This does not work.
- 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
New contributor
add a comment |
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.
Things I have tried:
- 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.
- Exporting the layers as shapefiles with the CRS set to 3310 (and EPSG: 102003 CRS) and re-adding to QGIS. This does not work.
- 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
New contributor
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
add a comment |
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.
Things I have tried:
- 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.
- Exporting the layers as shapefiles with the CRS set to 3310 (and EPSG: 102003 CRS) and re-adding to QGIS. This does not work.
- 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
New contributor
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.
Things I have tried:
- 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.
- Exporting the layers as shapefiles with the CRS set to 3310 (and EPSG: 102003 CRS) and re-adding to QGIS. This does not work.
- 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
coordinate-system qgis-3 file-geodatabase
New contributor
New contributor
edited 7 hours ago
cameron bronstein
New contributor
asked 8 hours ago
cameron bronsteincameron bronstein
214 bronze badges
214 bronze badges
New contributor
New contributor
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
add a comment |
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
add a comment |
1 Answer
1
active
oldest
votes
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.
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
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
add a comment |
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.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
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.
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
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
add a comment |
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.
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
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
add a comment |
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.
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
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.
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
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
add a comment |
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
add a comment |
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.
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.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
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