writeRaster() not writing datum informationwriteOGR() not writing out datum of shpProjecting sp objects in...
Gear reduction on large turbofans
What is the difference between rolling more dice versus fewer dice?
How would an AI self awareness kill switch work?
Consequences of lack of rigour
Why exactly do action photographers need high fps burst cameras?
What is a good reason for every spaceship to carry a weapon on board?
Is it a fallacy if someone claims they need an explanation for every word of your argument to the point where they don't understand common terms?
Increment each digit in a number to form a new number
Does every functor from Set to Set preserve products?
Early credit roll before the end of the film
What are "industrial chops"?
Non-Cancer terminal illness that can affect young (age 10-13) girls?
Removing disk while game is suspended
Can I make estimated tax payments instead of withholding from my paycheck?
How to tell if a BJT is PNP or NPN by looking at the circuit?
Why do neural networks need so many training examples to perform?
Difference between i++ and (i)++ in C
How do I append a character to the end of every line in an Excel cell?
Quickly creating a sparse array
A Missing Symbol for This Logo
In Linux what happens if 1000 files in a directory are moved to another location while another 300 files were added to the source directory?
Aligning symbols underneath each other neatly
How can I play a serial killer in a party of good PCs?
Move fast ...... Or you will lose
writeRaster() not writing datum information
writeOGR() not writing out datum of shpProjecting sp objects in RCalculating points in the USDA's Cropland Data Layer coordinate systemtowgs Definition for European Datum 1950projection differences in RWrong area using Albers Equal Area Projection in GRASS for Java, IndonesiaManually adding spatial reference information for FEWS rainfall data using QGIS?Reprojecting a rasterWhy is .prj file not being retrieved by QGIS?Reprojecting a large raster using Python and rasterioUSA Albers Equal Area Conic USGS version (LANDFIRE) projection not read by R?
I am trying to reproject a raster to the USGS version of the Albers Equal Area Conic projection. Following this post, which talks about projecting vectors by adding the +datum=NAD83 and writing it out, I did the same for the raster and wrote it out using writeRaster().
However, the resulting raster still has no NAD83 datum when viewed in Arc or QGIS or when read back into R (i.e. the +datum=NAD83 doe snot appear in the projection string). How do I project the raster to the USGS Albers Equal Area Conic projection with the NAD83 datum and write the raster out?
Also, I am writing out the output in tif format, which I don't think can store projection information. Should I be writing out the raster in another format that can store projection information? Which one?
raster coordinate-system r reprojection-mathematics
asked Aug 14 '18 at 12:48
tg110tg110
357110
bumped to the homepage by Community♦ 9 mins ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
|
show 2 more comments
I am trying to reproject a raster to the USGS version of the Albers Equal Area Conic projection. Following this post, which talks about projecting vectors by adding the +datum=NAD83 and writing it out, I did the same for the raster and wrote it out using writeRaster().
However, the resulting raster still has no NAD83 datum when viewed in Arc or QGIS or when read back into R (i.e. the +datum=NAD83 doe snot appear in the projection string). How do I project the raster to the USGS Albers Equal Area Conic projection with the NAD83 datum and write the raster out?
Also, I am writing out the output in tif format, which I don't think can store projection information. Should I be writing out the raster in another format that can store projection information? Which one?
raster coordinate-system r reprojection-mathematics
asked Aug 14 '18 at 12:48
tg110tg110
357110
bumped to the homepage by Community♦ 9 mins ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
GeoTIFF files, which is what you get if youwriteRaster(foo, "foo.tif")do store projection info,
– Spacedman
Aug 14 '18 at 13:40
@Spacedman- the written rasters in tif format does not have the datum information i.e +datum=NAD83 when read back into R or when viewed in QGIS or Arc (comes up as D_unknown)
– tg110
Aug 14 '18 at 13:49
The information about the datum is written to the TIFF, and read back in, its just the name of the datum that isn't recognised. That doesn't matter much.
– Spacedman
Aug 14 '18 at 14:06
That is hard to believe! And very misdirecting since there is no mention of the datum in the projection string. So if I were to pass this product on to somebody else, they would think it is wrong because the datum info does not come up in the string when read into R or QGIS and comes up as unknown in Arc. Also as mentioned in the post linked in the question, including +datum and writing out the shps works, so why cannot it work with rasters?
– tg110
Aug 14 '18 at 14:32
The datum info DOES come up in the string. Its the+ellpsand the+towgs84parameters. The NAD83 datum is defined here: epsg-registry.org/export.htm?wkt=urn:ogc:def:crs:EPSG::4269.
– Spacedman
Aug 14 '18 at 14:40
|
show 2 more comments
I am trying to reproject a raster to the USGS version of the Albers Equal Area Conic projection. Following this post, which talks about projecting vectors by adding the +datum=NAD83 and writing it out, I did the same for the raster and wrote it out using writeRaster().
However, the resulting raster still has no NAD83 datum when viewed in Arc or QGIS or when read back into R (i.e. the +datum=NAD83 doe snot appear in the projection string). How do I project the raster to the USGS Albers Equal Area Conic projection with the NAD83 datum and write the raster out?
Also, I am writing out the output in tif format, which I don't think can store projection information. Should I be writing out the raster in another format that can store projection information? Which one?
raster coordinate-system r reprojection-mathematics
asked Aug 14 '18 at 12:48
tg110tg110
357110
I am trying to reproject a raster to the USGS version of the Albers Equal Area Conic projection. Following this post, which talks about projecting vectors by adding the +datum=NAD83 and writing it out, I did the same for the raster and wrote it out using writeRaster().
However, the resulting raster still has no NAD83 datum when viewed in Arc or QGIS or when read back into R (i.e. the +datum=NAD83 doe snot appear in the projection string). How do I project the raster to the USGS Albers Equal Area Conic projection with the NAD83 datum and write the raster out?
Also, I am writing out the output in tif format, which I don't think can store projection information. Should I be writing out the raster in another format that can store projection information? Which one?
raster coordinate-system r reprojection-mathematics
raster coordinate-system r reprojection-mathematics
asked Aug 14 '18 at 12:48
tg110tg110
357110
asked Aug 14 '18 at 12:48
tg110tg110
357110
edited Aug 14 '18 at 12:57
tg110
asked Aug 14 '18 at 12:48
tg110tg110
357110
asked Aug 14 '18 at 12:48
tg110tg110
357110
asked Aug 14 '18 at 12:48
tg110tg110
357110
357110
bumped to the homepage by Community♦ 9 mins ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
bumped to the homepage by Community♦ 9 mins ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
GeoTIFF files, which is what you get if youwriteRaster(foo, "foo.tif")do store projection info,
– Spacedman
Aug 14 '18 at 13:40
@Spacedman- the written rasters in tif format does not have the datum information i.e +datum=NAD83 when read back into R or when viewed in QGIS or Arc (comes up as D_unknown)
– tg110
Aug 14 '18 at 13:49
The information about the datum is written to the TIFF, and read back in, its just the name of the datum that isn't recognised. That doesn't matter much.
– Spacedman
Aug 14 '18 at 14:06
That is hard to believe! And very misdirecting since there is no mention of the datum in the projection string. So if I were to pass this product on to somebody else, they would think it is wrong because the datum info does not come up in the string when read into R or QGIS and comes up as unknown in Arc. Also as mentioned in the post linked in the question, including +datum and writing out the shps works, so why cannot it work with rasters?
– tg110
Aug 14 '18 at 14:32
The datum info DOES come up in the string. Its the+ellpsand the+towgs84parameters. The NAD83 datum is defined here: epsg-registry.org/export.htm?wkt=urn:ogc:def:crs:EPSG::4269.
– Spacedman
Aug 14 '18 at 14:40
|
show 2 more comments
GeoTIFF files, which is what you get if youwriteRaster(foo, "foo.tif")do store projection info,
– Spacedman
Aug 14 '18 at 13:40
@Spacedman- the written rasters in tif format does not have the datum information i.e +datum=NAD83 when read back into R or when viewed in QGIS or Arc (comes up as D_unknown)
– tg110
Aug 14 '18 at 13:49
The information about the datum is written to the TIFF, and read back in, its just the name of the datum that isn't recognised. That doesn't matter much.
– Spacedman
Aug 14 '18 at 14:06
That is hard to believe! And very misdirecting since there is no mention of the datum in the projection string. So if I were to pass this product on to somebody else, they would think it is wrong because the datum info does not come up in the string when read into R or QGIS and comes up as unknown in Arc. Also as mentioned in the post linked in the question, including +datum and writing out the shps works, so why cannot it work with rasters?
– tg110
Aug 14 '18 at 14:32
The datum info DOES come up in the string. Its the+ellpsand the+towgs84parameters. The NAD83 datum is defined here: epsg-registry.org/export.htm?wkt=urn:ogc:def:crs:EPSG::4269.
– Spacedman
Aug 14 '18 at 14:40
GeoTIFF files, which is what you get if you
writeRaster(foo, "foo.tif") do store projection info,– Spacedman
Aug 14 '18 at 13:40
GeoTIFF files, which is what you get if you
writeRaster(foo, "foo.tif") do store projection info,– Spacedman
Aug 14 '18 at 13:40
@Spacedman- the written rasters in tif format does not have the datum information i.e +datum=NAD83 when read back into R or when viewed in QGIS or Arc (comes up as D_unknown)
– tg110
Aug 14 '18 at 13:49
@Spacedman- the written rasters in tif format does not have the datum information i.e +datum=NAD83 when read back into R or when viewed in QGIS or Arc (comes up as D_unknown)
– tg110
Aug 14 '18 at 13:49
The information about the datum is written to the TIFF, and read back in, its just the name of the datum that isn't recognised. That doesn't matter much.
– Spacedman
Aug 14 '18 at 14:06
The information about the datum is written to the TIFF, and read back in, its just the name of the datum that isn't recognised. That doesn't matter much.
– Spacedman
Aug 14 '18 at 14:06
That is hard to believe! And very misdirecting since there is no mention of the datum in the projection string. So if I were to pass this product on to somebody else, they would think it is wrong because the datum info does not come up in the string when read into R or QGIS and comes up as unknown in Arc. Also as mentioned in the post linked in the question, including +datum and writing out the shps works, so why cannot it work with rasters?
– tg110
Aug 14 '18 at 14:32
That is hard to believe! And very misdirecting since there is no mention of the datum in the projection string. So if I were to pass this product on to somebody else, they would think it is wrong because the datum info does not come up in the string when read into R or QGIS and comes up as unknown in Arc. Also as mentioned in the post linked in the question, including +datum and writing out the shps works, so why cannot it work with rasters?
– tg110
Aug 14 '18 at 14:32
The datum info DOES come up in the string. Its the
+ellps and the +towgs84 parameters. The NAD83 datum is defined here: epsg-registry.org/export.htm?wkt=urn:ogc:def:crs:EPSG::4269.– Spacedman
Aug 14 '18 at 14:40
The datum info DOES come up in the string. Its the
+ellps and the +towgs84 parameters. The NAD83 datum is defined here: epsg-registry.org/export.htm?wkt=urn:ogc:def:crs:EPSG::4269.– Spacedman
Aug 14 '18 at 14:40
|
show 2 more comments
1 Answer
1
active
oldest
votes
I have been able to reproduce this on my machine and have found a solution. The "data" file is quite large so I don't post it here but as an example, see below. There is some raster file data which is loaded into the workspace. I perform some calculations, and save a copy. "data" has the crs given below.
> writeRaster(data, "~/R_work/Mackenzie/2015_06_binary.tif",
+ "GTiff", datatype = "INT1U", overwrite = T, options = c("COMPRESS=LZW", "TFW=YES"))
> data
class : RasterLayer
dimensions : 24099, 13793, 332397507 (nrow, ncol, ncell)
resolution : 30, 30 (x, y)
extent : -15267810, -14854020, 10270650, 10993620 (xmin, xmax, ymin, ymax)
coord. ref. : +proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +no_defs
names : layer
values : 0, 1 (min, max)
After reading the dataset back in and looking at the crs, it appears different. This difference doesn't allow it to be read into ArcGIS or Python.
> data <- raster("~/R_work/Mackenzie/2015_06_binary.tif")
> crs(data)
CRS arguments:
+proj=merc +lon_0=0 +lat_ts=0 +x_0=0 +y_0=0 +a=6378137 +b=6378137 +units=m +no_defs
However, if we use the CRS function from sp (not crs from raster) this seems to be fixed. Note that the crs of data3 is missing the EPSG - this is fine, as the other properties are preserved. Observe:
data2 <- data
crs(data2) <- CRS('+init=EPSG:3857')
> crs(data2)
CRS arguments:
+init=EPSG:3857 +proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0
+units=m +nadgrids=@null +no_defs
writeRaster(data2, "C:/Users/lvulis/Documents/deltas/R_work/Mackenzie/2015_06_binary2.tif",
"GTiff", datatype = "INT1U", overwrite = T, options = c("COMPRESS=LZW", "TFW=YES"))
data3 <- raster("C:/Users/lvulis/Documents/deltas/R_work/Mackenzie/2015_06_binary2.tif")
> crs(data3)
CRS arguments:
+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m
+nadgrids=@null +no_defs
answered Jan 28 at 23:19
HeymansHeymans
186
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
});
}
});
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%2f292718%2fwriteraster-not-writing-datum-information%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
I have been able to reproduce this on my machine and have found a solution. The "data" file is quite large so I don't post it here but as an example, see below. There is some raster file data which is loaded into the workspace. I perform some calculations, and save a copy. "data" has the crs given below.
> writeRaster(data, "~/R_work/Mackenzie/2015_06_binary.tif",
+ "GTiff", datatype = "INT1U", overwrite = T, options = c("COMPRESS=LZW", "TFW=YES"))
> data
class : RasterLayer
dimensions : 24099, 13793, 332397507 (nrow, ncol, ncell)
resolution : 30, 30 (x, y)
extent : -15267810, -14854020, 10270650, 10993620 (xmin, xmax, ymin, ymax)
coord. ref. : +proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +no_defs
names : layer
values : 0, 1 (min, max)
After reading the dataset back in and looking at the crs, it appears different. This difference doesn't allow it to be read into ArcGIS or Python.
> data <- raster("~/R_work/Mackenzie/2015_06_binary.tif")
> crs(data)
CRS arguments:
+proj=merc +lon_0=0 +lat_ts=0 +x_0=0 +y_0=0 +a=6378137 +b=6378137 +units=m +no_defs
However, if we use the CRS function from sp (not crs from raster) this seems to be fixed. Note that the crs of data3 is missing the EPSG - this is fine, as the other properties are preserved. Observe:
data2 <- data
crs(data2) <- CRS('+init=EPSG:3857')
> crs(data2)
CRS arguments:
+init=EPSG:3857 +proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0
+units=m +nadgrids=@null +no_defs
writeRaster(data2, "C:/Users/lvulis/Documents/deltas/R_work/Mackenzie/2015_06_binary2.tif",
"GTiff", datatype = "INT1U", overwrite = T, options = c("COMPRESS=LZW", "TFW=YES"))
data3 <- raster("C:/Users/lvulis/Documents/deltas/R_work/Mackenzie/2015_06_binary2.tif")
> crs(data3)
CRS arguments:
+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m
+nadgrids=@null +no_defs
answered Jan 28 at 23:19
HeymansHeymans
186
add a comment |
I have been able to reproduce this on my machine and have found a solution. The "data" file is quite large so I don't post it here but as an example, see below. There is some raster file data which is loaded into the workspace. I perform some calculations, and save a copy. "data" has the crs given below.
> writeRaster(data, "~/R_work/Mackenzie/2015_06_binary.tif",
+ "GTiff", datatype = "INT1U", overwrite = T, options = c("COMPRESS=LZW", "TFW=YES"))
> data
class : RasterLayer
dimensions : 24099, 13793, 332397507 (nrow, ncol, ncell)
resolution : 30, 30 (x, y)
extent : -15267810, -14854020, 10270650, 10993620 (xmin, xmax, ymin, ymax)
coord. ref. : +proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +no_defs
names : layer
values : 0, 1 (min, max)
After reading the dataset back in and looking at the crs, it appears different. This difference doesn't allow it to be read into ArcGIS or Python.
> data <- raster("~/R_work/Mackenzie/2015_06_binary.tif")
> crs(data)
CRS arguments:
+proj=merc +lon_0=0 +lat_ts=0 +x_0=0 +y_0=0 +a=6378137 +b=6378137 +units=m +no_defs
However, if we use the CRS function from sp (not crs from raster) this seems to be fixed. Note that the crs of data3 is missing the EPSG - this is fine, as the other properties are preserved. Observe:
data2 <- data
crs(data2) <- CRS('+init=EPSG:3857')
> crs(data2)
CRS arguments:
+init=EPSG:3857 +proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0
+units=m +nadgrids=@null +no_defs
writeRaster(data2, "C:/Users/lvulis/Documents/deltas/R_work/Mackenzie/2015_06_binary2.tif",
"GTiff", datatype = "INT1U", overwrite = T, options = c("COMPRESS=LZW", "TFW=YES"))
data3 <- raster("C:/Users/lvulis/Documents/deltas/R_work/Mackenzie/2015_06_binary2.tif")
> crs(data3)
CRS arguments:
+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m
+nadgrids=@null +no_defs
answered Jan 28 at 23:19
HeymansHeymans
186
add a comment |
I have been able to reproduce this on my machine and have found a solution. The "data" file is quite large so I don't post it here but as an example, see below. There is some raster file data which is loaded into the workspace. I perform some calculations, and save a copy. "data" has the crs given below.
> writeRaster(data, "~/R_work/Mackenzie/2015_06_binary.tif",
+ "GTiff", datatype = "INT1U", overwrite = T, options = c("COMPRESS=LZW", "TFW=YES"))
> data
class : RasterLayer
dimensions : 24099, 13793, 332397507 (nrow, ncol, ncell)
resolution : 30, 30 (x, y)
extent : -15267810, -14854020, 10270650, 10993620 (xmin, xmax, ymin, ymax)
coord. ref. : +proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +no_defs
names : layer
values : 0, 1 (min, max)
After reading the dataset back in and looking at the crs, it appears different. This difference doesn't allow it to be read into ArcGIS or Python.
> data <- raster("~/R_work/Mackenzie/2015_06_binary.tif")
> crs(data)
CRS arguments:
+proj=merc +lon_0=0 +lat_ts=0 +x_0=0 +y_0=0 +a=6378137 +b=6378137 +units=m +no_defs
However, if we use the CRS function from sp (not crs from raster) this seems to be fixed. Note that the crs of data3 is missing the EPSG - this is fine, as the other properties are preserved. Observe:
data2 <- data
crs(data2) <- CRS('+init=EPSG:3857')
> crs(data2)
CRS arguments:
+init=EPSG:3857 +proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0
+units=m +nadgrids=@null +no_defs
writeRaster(data2, "C:/Users/lvulis/Documents/deltas/R_work/Mackenzie/2015_06_binary2.tif",
"GTiff", datatype = "INT1U", overwrite = T, options = c("COMPRESS=LZW", "TFW=YES"))
data3 <- raster("C:/Users/lvulis/Documents/deltas/R_work/Mackenzie/2015_06_binary2.tif")
> crs(data3)
CRS arguments:
+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m
+nadgrids=@null +no_defs
answered Jan 28 at 23:19
HeymansHeymans
186
I have been able to reproduce this on my machine and have found a solution. The "data" file is quite large so I don't post it here but as an example, see below. There is some raster file data which is loaded into the workspace. I perform some calculations, and save a copy. "data" has the crs given below.
> writeRaster(data, "~/R_work/Mackenzie/2015_06_binary.tif",
+ "GTiff", datatype = "INT1U", overwrite = T, options = c("COMPRESS=LZW", "TFW=YES"))
> data
class : RasterLayer
dimensions : 24099, 13793, 332397507 (nrow, ncol, ncell)
resolution : 30, 30 (x, y)
extent : -15267810, -14854020, 10270650, 10993620 (xmin, xmax, ymin, ymax)
coord. ref. : +proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +no_defs
names : layer
values : 0, 1 (min, max)
After reading the dataset back in and looking at the crs, it appears different. This difference doesn't allow it to be read into ArcGIS or Python.
> data <- raster("~/R_work/Mackenzie/2015_06_binary.tif")
> crs(data)
CRS arguments:
+proj=merc +lon_0=0 +lat_ts=0 +x_0=0 +y_0=0 +a=6378137 +b=6378137 +units=m +no_defs
However, if we use the CRS function from sp (not crs from raster) this seems to be fixed. Note that the crs of data3 is missing the EPSG - this is fine, as the other properties are preserved. Observe:
data2 <- data
crs(data2) <- CRS('+init=EPSG:3857')
> crs(data2)
CRS arguments:
+init=EPSG:3857 +proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0
+units=m +nadgrids=@null +no_defs
writeRaster(data2, "C:/Users/lvulis/Documents/deltas/R_work/Mackenzie/2015_06_binary2.tif",
"GTiff", datatype = "INT1U", overwrite = T, options = c("COMPRESS=LZW", "TFW=YES"))
data3 <- raster("C:/Users/lvulis/Documents/deltas/R_work/Mackenzie/2015_06_binary2.tif")
> crs(data3)
CRS arguments:
+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m
+nadgrids=@null +no_defs
answered Jan 28 at 23:19
HeymansHeymans
186
answered Jan 28 at 23:19
HeymansHeymans
186
answered Jan 28 at 23:19
HeymansHeymans
186
answered Jan 28 at 23:19
HeymansHeymans
186
186
add a comment |
add a comment |
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%2f292718%2fwriteraster-not-writing-datum-information%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
GeoTIFF files, which is what you get if you
writeRaster(foo, "foo.tif")do store projection info,– Spacedman
Aug 14 '18 at 13:40
@Spacedman- the written rasters in tif format does not have the datum information i.e +datum=NAD83 when read back into R or when viewed in QGIS or Arc (comes up as D_unknown)
– tg110
Aug 14 '18 at 13:49
The information about the datum is written to the TIFF, and read back in, its just the name of the datum that isn't recognised. That doesn't matter much.
– Spacedman
Aug 14 '18 at 14:06
That is hard to believe! And very misdirecting since there is no mention of the datum in the projection string. So if I were to pass this product on to somebody else, they would think it is wrong because the datum info does not come up in the string when read into R or QGIS and comes up as unknown in Arc. Also as mentioned in the post linked in the question, including +datum and writing out the shps works, so why cannot it work with rasters?
– tg110
Aug 14 '18 at 14:32
The datum info DOES come up in the string. Its the
+ellpsand the+towgs84parameters. The NAD83 datum is defined here: epsg-registry.org/export.htm?wkt=urn:ogc:def:crs:EPSG::4269.– Spacedman
Aug 14 '18 at 14:40