EE Limit hit... Is there a workaround?

[lukezirngibl]

I am trying to generate a fairly heavy STL set. This is my following config:

{
"CPU_cores_to_use": 4,
"DEM_name": "JAXA/ALOS/AW3D30/V2_2",
"basethick": 5,
"bottom_image": null,
"fileformat": "STLb",
"ignore_leq": null,
"importedDEM": null,
"lower_leq": null,
"max_cells_for_memory_only": 25000000,
"no_bottom": false,
"ntilesx": 6,
"ntilesy": 3,
"only": null,
"printres": 0.2,
"tile_centered": false,
"tilewidth": 200,
"unprojected": false,
"zip_file_name": "terrain",
"zscale": 1.0,
"trlat": 47.81622262056006,
"trlon": 10.519218241500798,
"bllat": 45.805185338248926,
"bllon": 5.926325117874116
}

Now the web version says this is too big to process. So I tried doing it locally via python (made an EE account and everything). Using the local python version I get:

lon/lat size in degrees: [4.592893123626682, 2.011037282311136]
INFO:root:lon/lat size in degrees: [4.592893123626682, 2.011037282311136]
requesting 58.42479269311229 m resolution from EarthEngine
Earth Engine raster: JAXA/ALOS/AW3D30/V2_2
INFO:root:Earth Engine raster: JAXA/ALOS/AW3D30/V2_2
 ALOS DSM: Global 30m
INFO:root: ALOS DSM: Global 30m
Traceback (most recent call last):
  File "/usr/local/anaconda3/lib/python3.8/site-packages/ee/data.py", line 330, in _execute_cloud_call
    return call.execute(num_retries=num_retries)
  File "/usr/local/anaconda3/lib/python3.8/site-packages/googleapiclient/_helpers.py", line 134, in positional_wrapper
    return wrapped(*args, **kwargs)
  File "/usr/local/anaconda3/lib/python3.8/site-packages/googleapiclient/http.py", line 915, in execute
    raise HttpError(resp, content, uri=self.uri)
googleapiclient.errors.HttpError: <HttpError 400 when requesting https://earthengine.googleapis.com/v1alpha/projects/earthengine-legacy/thumbnails?fields=name&alt=json returned "Total request size (95398144 bytes) must be less than or equal to 33554432 bytes.">

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "TouchTerrain_standalone.py", line 253, in <module>
    main()
  File "TouchTerrain_standalone.py", line 208, in main
    totalsize, full_zip_file_name = TouchTerrain.get_zipped_tiles(**args) # all args are in a dict
  File "/Users/lukaszirngibl/Desktop/TouchTerrain_for_CAGEO/touchterrain/common/TouchTerrainEarthEngine.py", line 692, in get_zipped_tiles
    request = image1.getDownloadUrl(request_dict)
  File "/usr/local/anaconda3/lib/python3.8/site-packages/ee/deprecation.py", line 32, in Wrapper
    return func(*args, **kwargs)
  File "/usr/local/anaconda3/lib/python3.8/site-packages/ee/image.py", line 435, in getDownloadURL
    return data.makeDownloadUrl(data.getDownloadId(request))
  File "/usr/local/anaconda3/lib/python3.8/site-packages/ee/data.py", line 888, in getDownloadId
    result = _execute_cloud_call(
  File "/usr/local/anaconda3/lib/python3.8/site-packages/ee/data.py", line 332, in _execute_cloud_call
    raise _translate_cloud_exception(e)
ee.ee_exception.EEException: Total request size (95398144 bytes) must be less than or equal to 33554432 bytes.

So this seems to be some sort of limit EE..

Then I tried to doing the tiles individually but that is causing all sorts of headaches because the tiles don’t quite line up (even though I’m computing all the correct lat/lon coordinates for each tile).

Any ideas on how I can fix this? Thank you so much for you time. Any help at all would be greatly appreciated :)

[ChHarding]

Luke,

a) you could work around the EE limit by figuring out how to export the huge geotiff you want to google drive, which it how Google wants us to deal with large data transfer now. Problem is I‘ve not ever done this, but I’d be happy to help figuring it out.

b) for your manually dimensioned tiles, you’re getting warped geotiffs/stls b/c your input coordinates have to be in lat/long but the geotiff EE returns will be automatically be reprojected to the closest UTM zone. So either you’re getting different UTM zones or maybe a bit of warp will happen even if they all share the same UTM zone. A possible way around this may be to first set the projection with "projection”:12345 and figure out the EPSG code for the best UTM zone for your extent: https://spatialreference.org/ https://spatialreference.org/

Or, you could use "unprojected": true but then your x-y-dimension will be in degrees and you z will be in meters so you’ll have to rescale your STL along z and you’ll have to eyeball that. Also, you won’t know what the exact exaggeration factor is (x1.2? x2.3?) but maybe you don’t care.

c) do you really need a printers of 0.2 mm? Would going to 0.4 mm solve all of this for you?

d) you could try SRTM instead of AW3D30, which (I think) is in 16 bit ints (i.e. elevations are only at meter resolution, which my be OK for you) instead of 32 bit floats

Finally: what are you trying to do with this monster model ? :)

Cheers

Chris

On Nov 17, 2020, at 04:02, Luke Zirngibl notifications@github.com wrote:

I am trying to generate a fairly heavy STL set. This is my following config:

{ "CPU_cores_to_use": 4, "DEM_name": "JAXA/ALOS/AW3D30/V2_2", "basethick": 5, "bottom_image": null, "fileformat": "STLb", "ignore_leq": null, "importedDEM": null, "lower_leq": null, "max_cells_for_memory_only": 25000000, "no_bottom": false, "ntilesx": 6, "ntilesy": 3, "only": null, "printres": 0.2, "tile_centered": false, "tilewidth": 200, "unprojected": false, "zip_file_name": "terrain", "zscale": 1.0, "trlat": 47.81622262056006, "trlon": 10.519218241500798, "bllat": 45.805185338248926, "bllon": 5.926325117874116 } Now the web version says this is too big to process. So I tried doing it locally via python (made an EE account and everything). Using the local python version I get:

lon/lat size in degrees: [4.592893123626682, 2.011037282311136] INFO:root:lon/lat size in degrees: [4.592893123626682, 2.011037282311136] requesting 58.42479269311229 m resolution from EarthEngine Earth Engine raster: JAXA/ALOS/AW3D30/V2_2 INFO:root:Earth Engine raster: JAXA/ALOS/AW3D30/V2_2 ALOS DSM: Global 30m INFO:root: ALOS DSM: Global 30m Traceback (most recent call last): File "/usr/local/anaconda3/lib/python3.8/site-packages/ee/data.py", line 330, in _execute_cloud_call return call.execute(num_retries=num_retries) File "/usr/local/anaconda3/lib/python3.8/site-packages/googleapiclient/_helpers.py", line 134, in positional_wrapper return wrapped(*args, **kwargs) File "/usr/local/anaconda3/lib/python3.8/site-packages/googleapiclient/http.py", line 915, in execute raise HttpError(resp, content, uri=self.uri) googleapiclient.errors.HttpError: <HttpError 400 when requesting https://earthengine.googleapis.com/v1alpha/projects/earthengine-legacy/thumbnails?fields=name&alt=json returned "Total request size (95398144 bytes) must be less than or equal to 33554432 bytes."> During handling of the above exception, another exception occurred:

Traceback (most recent call last): File "TouchTerrain_standalone.py", line 253, in main() File "TouchTerrain_standalone.py", line 208, in main totalsize, full_zip_file_name = TouchTerrain.get_zipped_tiles(*args) # all args are in a dict File "/Users/lukaszirngibl/Desktop/TouchTerrain_for_CAGEO/touchterrain/common/TouchTerrainEarthEngine.py", line 692, in get_zipped_tiles request = image1.getDownloadUrl(request_dict) File "/usr/local/anaconda3/lib/python3.8/site-packages/ee/deprecation.py", line 32, in Wrapper return func(args, **kwargs) File "/usr/local/anaconda3/lib/python3.8/site-packages/ee/image.py", line 435, in getDownloadURL return data.makeDownloadUrl(data.getDownloadId(request)) File "/usr/local/anaconda3/lib/python3.8/site-packages/ee/data.py", line 888, in getDownloadId result = _execute_cloud_call( File "/usr/local/anaconda3/lib/python3.8/site-packages/ee/data.py", line 332, in _execute_cloud_call raise _translate_cloud_exception(e) ee.ee_exception.EEException: Total request size (95398144 bytes) must be less than or equal to 33554432 bytes. So this seems to be some sort of limit EE..

Then I tried to doing the tiles individually but that is causing all sorts of headaches because the tiles don’t quite line up (even though I’m computing all the correct lat/lon coordinates for each tile).

Any ideas on how I can fix this? Thank you so much for you time. Any help at all would be greatly appreciated :)

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/ChHarding/TouchTerrain_for_CAGEO/issues/34, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEYDF5OPPN2HVXTGHOILHHTSQJC3JANCNFSM4TYK6DCQ.

Chris Harding Associate Professor Department of Geological & Atmospheric Sciences

TouchTerrain.geol.iastate.edu

[lukezirngibl]

Hey Chris,

Thanks for the speedy reply! I have gone with your (d) approach of using "USGS/SRTMGL1_003" as the DEM along with a 0.25mm resolution. This seems to have brought me under the EE limit.

I will print two of these tiles (using the Ultimaker 2+) to see how they look and fit. I will report back. I suspect if the resolution isn't good enough, I'll need to try and figure out how to do approach (a).

I'm printing a massive raised-relief map of Switzerland :)

Thanks for your help!

[ChHarding]

Luke,

You are printing with a standard 0.4 mm nozzle, right? If so I think you’re kidding yourself if you think that slicing a STL made from a 0.25 mm equivalent raster is better than one made from 0.4 mm raster. I realize that even with a 0.4 nozzle it is theoretically possible to print thinner (what Cura calls thin walls) but that’s a very special case where it squeezes a thinner wall between existing walls that leave a < 0.4 mm gap. 99.9% of all “tracks” printed with a 0.4 mm nozzle will be very close to 0.4 mm wide in reality. If you now take a say 0.2 mm raster and made a STL from it, it will have more details but then the slicer has to cram those 0.4 mm tracks over those small details and so it needs to “average” out your fine details.
I’ve actually never tried this until now and I could see that some aspects, like sharp corners, could potentially come out better with the 0.2 mm model. But I’m very convinced that even those would make a visual difference, especially on naturalistic shapes like terrain. So dealing with those much larger models really don’t buy you much at all.

Also, I have started to export a large DEM from Earth Engine and got pretty far. But, now I’m being told that I can’t save 16 bit signed data into a Geotiff, which seems bonkers.

Here’s the script:

// https://developers.google.com/earth-engine/guides/exporting

var trlat = -110 var trlon = 36 var bllat = -111 var bllon = 35

var dataset = ee.Image('JAXA/ALOS/AW3D30/V2_2'); var elevation = dataset.select('AVE_DSM'); print(elevation) var elevationVis = { min: 0, max: 2000, palette: ['0000ff', '00ffff', 'ffff00', 'ff0000', 'ffffff'], opacity: 0.5, }; Map.addLayer(elevation, elevationVis, 'Elevation');

var geometry = ee.Geometry.Rectangle([trlat, trlon, bllat, bllon]); Map.addLayer(geometry, {'opacity': 0.5}, 'box');

Map.setCenter(-110.5, 35.5, 8);

// Export the image, specifying scale and region. Export.image.toDrive({ image: dataset, description: 'DEM_large', fileFormat: 'GeoTIFF', scale: 1000, // in meters region: geometry, crs: "EPSG:32612" /// EPSG for UTM 12N with WGS84(!) });

// When this code is run, an export task will be created in the Code Editor Tasks tab. // Click the Run button next to the task to start it. // The image will be created in your Drive account with the specified fileFormat.

but this is the error:

I’m going to ask the earth engine google group for help.

BTW are you from Switzerland? Are you working for a university?

Cheers

Chris

On Nov 17, 2020, at 10:06, Luke Zirngibl notifications@github.com wrote:

Hey Chris,

Thanks for the speedy reply! I have gone with your (d) approach of using "USGS/SRTMGL1_003" as the DEM along with a 0.25mm resolution. This seems brought me under the EE limit.

I will print two of these tiles (using the Ultimaker 2+) to see how they look and fit. I will report back. I suspect if the resolution isn't good enough, I'll need to try and figure out how to do approach (a).

I'm printing a massive raised-relief map of Switzerland :)

Thanks for your help!

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ChHarding/TouchTerrain_for_CAGEO/issues/34#issuecomment-729029381, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEYDF5J7DOADWNRLKD7OAM3SQKNPXANCNFSM4TYK6DCQ.

Chris Harding Associate Professor Department of Geological & Atmospheric Sciences

TouchTerrain.geol.iastate.edu

[ChHarding]

I figured out what the problem was with my script so this does now work in principle:

———————— // https://developers.google.com/earth-engine/guides/exporting

var trlat = -110 var trlon = 36 var bllat = -111 var bllon = 35

var dataset = ee.Image('JAXA/ALOS/AW3D30/V2_2'); var elevation = dataset.select('AVE_DSM'); print(elevation) var elevationVis = { min: 0, max: 4000, palette: ['0000ff', '00ffff', 'ffff00', 'ff0000', 'ffffff'], opacity: 0.5, }; Map.addLayer(elevation, elevationVis, 'Elevation');

var geometry = ee.Geometry.Rectangle([trlat, trlon, bllat, bllon]); Map.addLayer(geometry, {'opacity': 0.5}, 'box');

Map.setCenter(-110.5, 35.5, 8);

// Export the image, specifying scale and region. Export.image.toDrive({ image: elevation, description: 'DEM_large', fileFormat: 'GeoTIFF', scale: 1000, // in meters region: geometry, crs: "EPSG:32612" /// EPSG for UTM 12N with WGS84(!) });

// When this code is run, an export task will be created in the Code Editor Tasks tab. // Click the Run button next to the task to start it. // The image will be created in your Drive account with the specified fileFormat. ————————

On Nov 17, 2020, at 10:53, Chris Harding charding@iastate.edu wrote:

Luke,

You are printing with a standard 0.4 mm nozzle, right? If so I think you’re kidding yourself if you think that slicing a STL made from a 0.25 mm equivalent raster is better than one made from 0.4 mm raster. I realize that even with a 0.4 nozzle it is theoretically possible to print thinner (what Cura calls thin walls) but that’s a very special case where it squeezes a thinner wall between existing walls that leave a < 0.4 mm gap. 99.9% of all “tracks” printed with a 0.4 mm nozzle will be very close to 0.4 mm wide in reality. If you now take a say 0.2 mm raster and made a STL from it, it will have more details but then the slicer has to cram those 0.4 mm tracks over those small details and so it needs to “average” out your fine details.
I’ve actually never tried this until now and I could see that some aspects, like sharp corners, could potentially come out better with the 0.2 mm model. But I’m very convinced that even those would make a visual difference, especially on naturalistic shapes like terrain. So dealing with those much larger models really don’t buy you much at all.

Also, I have started to export a large DEM from Earth Engine and got pretty far. But, now I’m being told that I can’t save 16 bit signed data into a Geotiff, which seems bonkers.

Here’s the script:

// https://developers.google.com/earth-engine/guides/exporting https://developers.google.com/earth-engine/guides/exporting

var trlat = -110 var trlon = 36 var bllat = -111 var bllon = 35

var dataset = ee.Image('JAXA/ALOS/AW3D30/V2_2'); var elevation = dataset.select('AVE_DSM'); print(elevation) var elevationVis = { min: 0, max: 2000, palette: ['0000ff', '00ffff', 'ffff00', 'ff0000', 'ffffff'], opacity: 0.5, }; Map.addLayer(elevation, elevationVis, 'Elevation');

var geometry = ee.Geometry.Rectangle([trlat, trlon, bllat, bllon]); Map.addLayer(geometry, {'opacity': 0.5}, 'box');

Map.setCenter(-110.5, 35.5, 8);

// Export the image, specifying scale and region. Export.image.toDrive({ image: dataset, description: 'DEM_large', fileFormat: 'GeoTIFF', scale: 1000, // in meters region: geometry, crs: "EPSG:32612" /// EPSG for UTM 12N with WGS84(!) });

// When this code is run, an export task will be created in the Code Editor Tasks tab. // Click the Run button next to the task to start it. // The image will be created in your Drive account with the specified fileFormat.

but this is the error:

I’m going to ask the earth engine google group for help. BTW are you from Switzerland? Are you working for a university? Cheers Chris > On Nov 17, 2020, at 10:06, Luke Zirngibl > wrote: > > > Hey Chris, > > Thanks for the speedy reply! I have gone with your (d) approach of using "USGS/SRTMGL1_003" as the DEM along with a 0.25mm resolution. This seems brought me under the EE limit. > > I will print two of these tiles (using the Ultimaker 2+) to see how they look and fit. I will report back. I suspect if the resolution isn't good enough, I'll need to try and figure out how to do approach (a). > > I'm printing a massive raised-relief map of Switzerland :) > > Thanks for your help! > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub , or unsubscribe . > Chris Harding Associate Professor Department of Geological & Atmospheric Sciences TouchTerrain.geol.iastate.edu

Chris Harding Associate Professor Department of Geological & Atmospheric Sciences

TouchTerrain.geol.iastate.edu

[lukezirngibl]

Hey Chris,

nice!! I'll give the export script a shot tomorrow.

Re: 0.4mm resolution.

-- Yeah, I think you're right. My friend had showed me one she printed at 0.4mm (right one in below pic), but I think she didn't set the tile width properly and scaled it up. Therefore the resolution on that is probably closer to ~1mm..

Re: BTW are you from Switzerland? Are you working for a university?

-- Yeah, I live in Zurich. Nope, no more school for me. Just doing this as a hobby.

[ChHarding]

On Nov 17, 2020, at 14:20, Luke Zirngibl notifications@github.com wrote:

Hey Chris,

nice!! I'll give the export script a shot tomorrow.

Re: 0.4mm resolution.

-- Yeah, I think you're right. My friend had showed me one she printed at 0.4mm (right one in below pic), but I think she didn't set the tile width properly and scaled it up. Therefore the resolution on that is probably closer to ~1mm..

https://user-images.githubusercontent.com/8725920/99442274-72178f80-2919-11eb-8e65-d6bd941e8bf9.jpgShe also seems to have printed it “upright” rather than “flat” on the bed which would explain the up-down stripes. If you print it flat, you get “natural” contours:

(This is not mine, somebody switched filament every x layers)

Cheers

Chris

Chris Harding Associate Professor Department of Geological & Atmospheric Sciences

TouchTerrain.geol.iastate.edu

[lukezirngibl]

So i printed a tile using the SRTMGL data set (@ 0.25mm resolution). And getting slight imperfections (e.g holes) in the model. I will try to print a AW3D30 @ 0.4mm resolution to see how that looks.

Btw, I tried the following code:

var trlat = 47.81622262056006
var trlon = 10.519218241500798
var bllat = 45.805185338248926
var bllon = 5.926325117874116

var dataset = ee.Image('JAXA/ALOS/AW3D30/V2_2');
var elevation = dataset.select('AVE_DSM');
print(elevation)
var elevationVis = {
  min: 0,
  max: 4000,
  palette: ['0000ff', '00ffff', 'ffff00', 'ff0000', 'ffffff'],
  opacity: 0.5,
};
Map.addLayer(elevation, elevationVis, 'Elevation');

var geometry = ee.Geometry.Rectangle([ trlon, trlat, bllon, bllat ]);
Map.addLayer(geometry, {'opacity': 0.5}, 'box');

Map.setCenter(
  trlon - ((trlon - bllon) / 2), 
  trlat - ((trlat - bllat) / 2), 
  8
);

// Export the image, specifying scale and region.
Export.image.toDrive({
  image: elevation,
  description: 'v3',
  fileFormat: 'GeoTIFF',
  scale: 30, // in meters
  maxPixels: 1e12,
  region: geometry,
  crs: "EPSG:32612"   /// EPSG for UTM 12N with WGS84(!)
});

Everything looked correct.. (btw, i think your lat/lons may have been swapped), but after running the script, the generated tiff files seemed totally unusable. I tried running your script with this new importedDEM, but it just generated a bunch of flat tiles.

[ChHarding]

So i printed a tile using the SRTMGL data set (@ 0.25mm resolution). And getting slight imperfections (e.g holes) in the model.

Totally possible. Shuttle-sensed data is from 2000? and had technical imitations on e.g. high angle slopes. I will try to print a AW3D30 @ 0.4mm resolution to see how that looks.

Btw, I tried the following code:

var trlat = 47.81622262056006 var trlon = 10.519218241500798 var bllat = 45.805185338248926 var bllon = 5.926325117874116

var dataset = ee.Image('JAXA/ALOS/AW3D30/V2_2'); var elevation = dataset.select('AVE_DSM'); print(elevation) var elevationVis = { min: 0, max: 4000, palette: ['0000ff', '00ffff', 'ffff00', 'ff0000', 'ffffff'], opacity: 0.5, }; Map.addLayer(elevation, elevationVis, 'Elevation');

var geometry = ee.Geometry.Rectangle([ trlon, trlat, bllon, bllat ]); Map.addLayer(geometry, {'opacity': 0.5}, 'box');

Map.setCenter( trlon - ((trlon - bllon) / 2), trlat - ((trlat - bllat) / 2), 8 );

// Export the image, specifying scale and region. Export.image.toDrive({ image: elevation, description: 'v3', fileFormat: 'GeoTIFF', scale: 30, // in meters maxPixels: 1e12, region: geometry, crs: "EPSG:32612" /// EPSG for UTM 12N with WGS84(!)

Everything looked correct.. (btw, i think your lat/lons may have been swapped), but after running the script, the generated tiff files seemed totally unusable.

You need to set the EPSG to UTM zone 32N, try “EPSG:32632”. I’m not surprised that the geotiff is bogus, you told it to project to a UTM zone half around the globe :)

I tried running your script with this new importedDEM, but it just generated a bunch of flat tiles.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ChHarding/TouchTerrain_for_CAGEO/issues/34#issuecomment-731080301, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEYDF5KNTUEKMSCM266JYBLSQY673ANCNFSM4TYK6DCQ.

Chris Harding Associate Professor Department of Geological & Atmospheric Sciences

TouchTerrain.geol.iastate.edu

[lukezirngibl]

:) nice catch. will try this soon. thanks!

[ChHarding]

Luke,

I cleaned up and tested the script and can now verify that it does work to export geotiffs at source resolution. I did use a smaller extend b/c I didn’t want to wait a couple of hours :) If its OK with you I’ll put this script in the Readme on GitHub.

Cheers

Chris

Pixel size is 30 x 30 m

——————— // Example of exporting a raster from EE to Google Drive // you will need the corner coords, which you can get from the Area Selection Box display // on the web app and the EPSG code for whatever projection you want to use. If you want // to use a UTM zon, look at the log file from the web app. // You also should know the source resolution of your DEM so you can set the scale parameter // of the export to it.

// Set DEm source
var dataset = ee.Image('JAXA/ALOS/AW3D30/V2_2'); var elevation = dataset.select('AVE_DSM'); print(elevation); // print some metadata into console

// make a spectral color scheme for elevation data layer var elevationVis = { min: 0, max: 4000, palette: ['0000ff', '00ffff', 'ffff00', 'ff0000', 'ffffff'], opacity: 0.5, }; Map.addLayer(elevation, elevationVis, 'Elevation');

// define area to export and show as box layer var trlat = 46.78374215384358 var trlon = 8.071201291153262 var bllat = 46.63448889213306 var bllon = 7.574375128591488 var geometry = ee.Geometry.Rectangle([ trlon, trlat, bllon, bllat ]); Map.addLayer(geometry, {'opacity': 0.5}, 'box');

// Fly to center of Box Map.setCenter( trlon - ((trlon - bllon) / 2), trlat - ((trlat - bllat) / 2), 8 // zoomlevel );

// Export the image, specifying scale and region. // https://developers.google.com/earth-engine/guides/exporting Export.image.toDrive({ image: elevation, description: 'EE_to_Google_Drive_example', // name of geotiff (.tif will be added) fileFormat: 'GeoTIFF', scale: 30, // resolution in meters maxPixels: 1e12, // overwrites the default of 1e08 region: geometry, crs: "EPSG:32632" // EPSG for the proper UTM zone with WGS84(!) });

// When this code is run, an export task will be created in the Code Editor Tasks tab. // Click the Run button next to the task to start it. // The image will be created in your Drive account with the specified fileFormat.

On Nov 20, 2020, at 04:18, Luke Zirngibl notifications@github.com wrote:

So i printed a tile using the SRTMGL data set (@ 0.25mm resolution). And getting slight imperfections (e.g holes) in the model. I will try to print a AW3D30 @ 0.4mm resolution to see how that looks.

Btw, I tried the following code:

var trlat = 47.81622262056006 var trlon = 10.519218241500798 var bllat = 45.805185338248926 var bllon = 5.926325117874116

var dataset = ee.Image('JAXA/ALOS/AW3D30/V2_2'); var elevation = dataset.select('AVE_DSM'); print(elevation) var elevationVis = { min: 0, max: 4000, palette: ['0000ff', '00ffff', 'ffff00', 'ff0000', 'ffffff'], opacity: 0.5, }; Map.addLayer(elevation, elevationVis, 'Elevation');

var geometry = ee.Geometry.Rectangle([ trlon, trlat, bllon, bllat ]); Map.addLayer(geometry, {'opacity': 0.5}, 'box');

Map.setCenter( trlon - ((trlon - bllon) / 2), trlat - ((trlat - bllat) / 2), 8 );

// Export the image, specifying scale and region. Export.image.toDrive({ image: elevation, description: 'v3', fileFormat: 'GeoTIFF', scale: 30, // in meters maxPixels: 1e12, region: geometry, crs: "EPSG:32612" /// EPSG for UTM 12N with WGS84(!) }); Everything looked correct.. (btw, i think your lat/lons may have been swapped), but after running the script, the generated tiff files seemed totally unusable. I tried running your script with this new importedDEM, but it just generated a bunch of flat tiles.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ChHarding/TouchTerrain_for_CAGEO/issues/34#issuecomment-731080301, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEYDF5KNTUEKMSCM266JYBLSQY673ANCNFSM4TYK6DCQ.

Chris Harding Associate Professor Department of Geological & Atmospheric Sciences