Timeline for Georeferencing metadata in GeoTIFF files
Current License: CC BY-SA 4.0
21 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 21, 2021 at 8:07 | history | bumped | CommunityBot | This question has answers that may be good or bad; the system has marked it active so that they can be reviewed. | |
| Mar 16, 2021 at 12:03 | history | bumped | CommunityBot | This question has answers that may be good or bad; the system has marked it active so that they can be reviewed. | |
| Nov 15, 2020 at 20:01 | history | bumped | CommunityBot | This question has answers that may be good or bad; the system has marked it active so that they can be reviewed. | |
| Jul 14, 2020 at 22:04 | history | bumped | CommunityBot | This question has answers that may be good or bad; the system has marked it active so that they can be reviewed. | |
| Mar 9, 2020 at 16:02 | history | bumped | CommunityBot | This question has answers that may be good or bad; the system has marked it active so that they can be reviewed. | |
| Nov 10, 2019 at 2:01 | history | bumped | CommunityBot | This question has answers that may be good or bad; the system has marked it active so that they can be reviewed. | |
| Jul 12, 2019 at 20:01 | history | bumped | CommunityBot | This question has answers that may be good or bad; the system has marked it active so that they can be reviewed. | |
| Mar 14, 2019 at 18:03 | history | bumped | CommunityBot | This question has answers that may be good or bad; the system has marked it active so that they can be reviewed. | |
| Nov 14, 2018 at 16:01 | history | bumped | CommunityBot | This question has answers that may be good or bad; the system has marked it active so that they can be reviewed. | |
| Oct 13, 2018 at 2:00 | history | bumped | CommunityBot | This question has answers that may be good or bad; the system has marked it active so that they can be reviewed. | |
| Sep 12, 2018 at 22:00 | history | bumped | CommunityBot | This question has answers that may be good or bad; the system has marked it active so that they can be reviewed. | |
| Aug 8, 2018 at 18:05 | comment | added | nivek | Thanks @MichaelStimson. Was sending via Dropbox. I forgot to update so I will do so now for others' benefit. I ultimately resampled using the gdalwarp tool (EPSG 32759 per your suggestion) and it worked fine. Got confirmation from colleague that he was able to use the new file once received via Dropbox. Thanks again for all of your help. Definitely something to keep in mind in the future when sending, receiving, manipulating GeoTIFF files. | |
| Aug 7, 2018 at 6:33 | answer | added | user30184 | timeline score: 1 | |
| Jul 31, 2018 at 23:14 | comment | added | Michael Stimson | Just a thought, how are you sending the file? Is it by Dropbox, google drive etc.. by FTP or as an attachment in an email? If you are emailing the image your ever helpful system may be resampling/compressing the raster to help keep your email small, if this is happening your GeoTags most likely are being voided.. I know from experience editing GeoTIFF files in GIMP or Photoshop (or even paint) destroy the tags they don't recognize which renders the file unreferenced. Check the size of the sent file, if it has been reduced find a different way to transport the file. | |
| Jul 31, 2018 at 6:14 | history | edited | nmtoken | CC BY-SA 4.0 | spelling, removed thanks |
| Jul 31, 2018 at 4:32 | comment | added | nivek | Forgot to mention, there are no *.tfw files generated by writeRaster or gdal_merge.py - only the TIFs themselves! So yes I have been operating on the assumption that the image cannot "lose" the info - and presumably the problem is more on ArcMap rather than on my end. (We're engineers and fairly ignorant of GIS conventions, so apologies for whatever aspects of this weren't obvious from the start!) I will ask my colleague to send a screenshot as well. Thanks. I'm planning to publish the maps soon with a DOI, so I do very much want everything to be "just right." | |
| Jul 31, 2018 at 4:07 | comment | added | nivek | Thanks. Hoping not to deal with it in R primarily because it's processor-intensive. I just discovered GDALWARP does the job pretty quick (somehow I thought it was slower). | |
| Jul 31, 2018 at 3:57 | comment | added | Michael Stimson | I mean before exporting with writeraster in R compile your map in WGS84 UTM Zone 59 (north or south); a standard coordinate system is less likely to cause problems. Can you get a screen shot of the catalog properties in ArcGIS from your colleague? Did you send the .tfw file with it? The GDALInfo isn't clear if it's a world TIFF or GeoTIFF (same driver) but GDAL_merge should produce GeoTIFF which embeds geolocation so (theoretically) the image can't loose geolocation - at the very worst it should fail to co-align, which is easier to fix than no geolocation at all. | |
| Jul 31, 2018 at 3:32 | comment | added | nivek | @MichaelStimson thanks. It wasn't entirely clear but I inferred the latter from their reply (i.e. no geolocation at all); I am waiting for clarification from them. It would be ideal if I can rewrite the metadata but leave the actual TIF as-is, since it's quite large. Is that what you meant by export? Or did you mean apply a coordinate tranformation/warp step? (Can give that a try but hoping to avoid as in my experience it's somewhat time-consuming). Thanks for your help. | |
| Jul 31, 2018 at 2:14 | comment | added | Michael Stimson | When they say not georeferenced do they mean not where they expect it or located at Null Island (with no geolocation at all).. your projection is "unnamed" but looks like it should be "custom" with the nonstandard false easting and central meridian but that shouldn't be a problem for ArcMap - is there a possibility that you could export this map in a more standard coordinate system like WGS84 UTM (EPSG:32759 (south) or EPSG:32659 (north))? That might make it a bit easier to transform or redefine properly. | |
| Jul 30, 2018 at 23:02 | history | asked | nivek | CC BY-SA 4.0 |