DotSpatial: Open large geotiff raster failed due to file pointer math overflow, and also very slow opening large grid

Yes. Using the GdalImageProvider of the older commit of @jany-tenaj is far more performant, GDAL is a lot faster indeed. @TongZhai do try to use this different version to compare for speed, using the simple code excerpt I posted above.

The only problem to pay attention to is that the unsuspecting user will see an increase in their file because GDAL overviews are built internally. At the moment, I do not have enough information on how to control this, therefore, @TongZhai, be warned, when testing for this, you may want to use a copy.

I assume GDAL will have accounted for the case of very large files… maybe overviews for very large files are built externally, but I will have to double-check that.

Regarding the existing MapRasterLayer implementation, it is slightly off in terms of performance for large rasters. A faster method will definitely have to be implemented if a more “standalone” DotSpatial behavior is needed, which can probably do something along the lines of what I wrote earlier, i.e. what the GdalImageProvider currently does.

OK, it seems that what I am thinking of doing (switching the raster rendering with a simple raw-data write and down-sampling) is already implemented in the GdalImageProvider. Therefore, there is what I have been missing all along.

GdalImageProvider gip = new GdalImageProvider();

var imageData = gip.Open(filename);

MapImageLayer imgLayer = new MapImageLayer(imageData);

map.Layers.Add(imgLayer);

Overviews are built externally as .mwi and .mwh files.

This should be faster for now. @TongZhai do give this a shot to see if the raster loads faster. You may have to adjust your int values to long once again because of the overflow problem, but thereafter, it should work out of the box. I am not entirely sure that the bug fixes I proposed earlier (#1326 and #1332) will also cover this case. If the raster does not appear immediately, you may need to zoom in a bit and let me know so that I can also look into this. However, I think these fixes should have this case covered as well.

I will try the older commit of @jany-tenaj now to see how this compares in terms of performance.

@jany-tenaj Not really, I am only trying to document what is currently going on inside the core library and experiment with the various tools already available. I have stumbled upon various bugs, mostly minor, but which are enough to break various tools. I will try to document those soon as well.

I clearly prefer a GDAL-supported implementation, however most DotSpatial classes appear to have been created with an intent to work on their own as an alternative. For example MapRasterLayer can also create pyramids “by itself”, in the absence of GDAL support. I don’t know your thoughts on whether we should also attempt to provide an improved built-in managed implementation as an alternative. In that case, I assume building overviews automagically when loading a MapRasterLayer should not create internal overviews, thus altering the file, rather probably external overviews. What do you think?

For now, I am trying to experiment with whatever is already available, including your old commit, in order to work out a simple demo workflow of loading a large image and getting it running.