Gdal 3.4.0 Load Geotiff Not Show

Question

Gdal 3.4.0 Load Geotiff Not Show

tangxiaodao opened this issue 3 years ago · 29 comments

Describe the bug
Compiled with Gdal 3.4.0 and loaded the Geotiff file, it can not display normally (or does not display). When the function "ReadProjection" is commented out, it can be displayed normally, but I don't know if there will be other problems. The reason why it cannot be displayed by debugging is the "DrawImage" function in" ImageDrawing.cpp". Code as below:

if (!WithinVisibleExtents(specs.xllCorner, specs.GetXtrCorner(), specs.yllCorner, specs.GetYtrCorner()))
{
     return NULL;
}

This always return NULL.
Check it, please.
Best wishes to you.

Expected behavior
Can not show geotiff nomally.

Screenshots
None.

Desktop

OS: Windows 10,64 bit.
Version [latest from github]

Answer 1 · 2022-01-24T10:45:46.000Z

Thanks for reporting this.
Currently we are working on upgrading MapWinGIS to GDAL3 and VS2019 and VC++17 and we already solved some issues with the projection.
You can have a look at the feature branch: https://github.com/MapWindow/MapWinGIS/tree/feature/MWGIS-244-VS2019-GDAL3-Proj8
Because we are working in the branch with several persons it is not guaranteed to compile all the time.

Answer 2 · 2022-01-24T11:02:25.000Z

@pmeems ,thanks for your reply.
Does VC++17 mean VS2017 or c++20? Or continue to use the standard C++11 or C++14. In addition, it is recommended that third-party libraries, such as Gdal, GeoTiff, Tiff, SpatialIndex, ShapeLib, DbgHelp, Cryptopp, Curl, etc., be compiled and installed directly with vcpkg, and then spend more time focusing on the update of the mapwingis framework.If possible, use CMakeList to manage projects.
Best wishes to you. @

Answer 3 · 2022-01-24T12:23:04.000Z

I mean ISO C++17 Standard (/std:c++17)
We still have some issues due to the byte type. We did solve it in our code, but it seems some Microsoft header files are causing problems now. So it might we need to fall back to C++14.

I'm not familiar with vcpkg but recently another used suggested as well.
Do you have MapWinGIS running with the GDAL packages? I'm mostly interested in if all file formats are supported.
Could you check if MapWinGIS can open an ECW-file? Currently, GDAL2 doesn't support it. GDAL3 from GisInternals does support it again.
If the package support ECW we can try to switch to using vcpkg.

I'm also trying to automate the build/release steps using Azure Pipeline. Using vcpkg and perhaps CMakeList might simplify that process. But I'm not a C++ developer, so I probably need your help with this if we continue that road. ;)

Answer 4 · 2022-01-24T12:43:06.000Z

It is recommended to use C++11 or C++14. After all, C++20 may not be stable yet. If it is possible, upload an ECW file and I will test it with GDAL3. In addition, BYTE is indeed a problem. When I use it, I usually define a macro : typedef unsigned char BYTE, or use unsigned char directly.

Answer 5 · 2022-01-24T12:48:16.000Z

You can use the GDAL test files: http://download.osgeo.org/gdal/data/

Answer 6 · 2022-01-24T12:51:44.000Z

And vcpkg is very very very simple and easy to use, easy to install , easy to use. Similar to command "apt-install" under linux. If you need which package is installed directly using the command "vcpkg.exe install gdal", vcpkg auto compiled, the vcpkg result include the folders include(.h), lib(.lib), bin(*.dll), the work that needs to be done It is to add these references and libraries to the VC project, and copy the dlls to the application directory.

Answer 7 · 2022-01-24T12:53:19.000Z

ok,l'll test it.

Answer 8 · 2022-01-24T13:01:39.000Z

Are you not the original author of MapWinGis? Or are you maintaining the DotSpatial library? I have also test the DotSpatial library. I don't think its original architecture is very good. I tested Gdal with C# to open a large image, about 4GB, which is completely fine, but DotSpatial uses its own to create a pyramid, and it is very slow to open a large image. And there are still problems. I originally wanted to refactor his code, but found that the workload is relatively large, and many modules need to be rewritten.
ps : I am good at C++, C# ,QT, Pascal,Gis etc.

Answer 9 · 2022-01-24T13:10:20.000Z

I'm not the original author of MapWinGIS. I did do a lot of development using C# with MapWinGIS (testing) and MapWindow5.
I've never been involved with DotSpatial. We continued with MapWinGIS because of the slowness of DotSpatial ;)

Good to hear you are good in C++ en C#. We have a lot of plans to improve both MapWinGIS and MW5, after we migrate to GDAL3 and Proj6+.

Answer 10 · 2022-01-24T14:09:41.000Z

ECW is not a standard format of GDAL, neither GDAL2 nor GDAL3 support ECW, ECW is a commercial third-party library from Hexagon Geospatial, they provide a free read-only version, and writing is chargeable. So ECW has nothing to do with GDAL, both GDAL2 or GDAL3 support ECW extension, here are the screenshots of GDAL2 and GDAL3:
GDAL2:

GDAL3:

Answer 11 · 2022-01-24T14:49:37.000Z

You're right about the ECW-support.
But in the binaries from gisinternals.com ECW-support is enabled.
Making it the main reason why we use those files.

Answer 12 · 2022-01-25T10:58:27.000Z

I have read the code from https://github.com/MapWindow/MapWinGIS/tree/feature/MWGIS-244-VS2019-GDAL3-Proj8 , found tha,the gdal-data of GDAL3 not exsits pcs.csv, so the function LoadProjectionStrings from Utils_Projections.cpp ,code csvPath = thisOcxPath() + "gdal-data\\pcs.csv" not need to be modified?

Answer 13 · 2022-01-25T11:05:03.000Z

In addition, in the related functions of CGeoProjection::SetWellKnownGeogCS(...), do you need to add _projection->OSRSetAxisMappingStrategy(...),maybe gdal3 need it?

Answer 14 · 2022-01-25T15:35:32.000Z

Thanks @tangxiaodao for looking into this.

Currently I'm trying to get the whole build process working on my new VM and then I'll try to automate this using Azure Pipelines or GitHub Actions. Currently I can compile all 4 versions but can only register Release|x64 and Debug|Win32.
Not sure why yet.

Jerry Faust Is very busy with upgrading ShapeLib, so we haven't yet had the chance to look into the changes that are needed due to upgrading from Proj4 to Proj7.

But feel free to find these issues and suggest a fix. We will merge them later.
Perhaps you can also create a PR on the branch, making it easier to merge.

Answer 15 · 2022-01-26T13:18:18.000Z

I had huge issues with the new branch so I needed to create a new branch which is now compiling fine using VS2019 and GDAL3.
@tangxiaodao I hope you don't have too much changes on the old gdal branch, because it will be deleted soon.
The new branch is https://github.com/MapWindow/MapWinGIS/tree/feature/GDAL3-VS2019

And it might be easier to communicate via email: bontepaarden[at]gmail[dot]com ;)

Answer 16 · 2022-01-26T14:10:11.000Z

@pmeems Okay.I'll follow with u.And communicate with email.

Answer 17 · 2022-02-02T10:54:41.000Z

@tangxiaodao It seems you know C++. Are you interested in helping fix the issue we have with upgrading LibSpatial?
It is explained at libspatialindex/libspatialindex#224 (comment)

Answer 18 · 2022-02-08T14:30:34.000Z

Can you share your GeoTiff or try using the latest binaries?
You can get them from the latest finished Github Action at https://github.com/MapWindow/MapWinGIS/actions
For example https://github.com/MapWindow/MapWinGIS/actions/runs/1812739847. At the bottom, you have the artifacts.
Download one of them and copy them over your existing binaries.
Most likely you need to run regsvr32 to register the ocx and set PROJ_LIB as an environment variable pointing to the location of proj.db ([ocx location]\proj7\share).
If your GeoTiff is still not showing I need (a piece of) the file for debugging.

Answer 19 · 2022-02-09T05:28:48.000Z

OK, I'll try it. If possible, it is recommended to set proj.db to a dynamic path.

Answer 20 · 2022-02-09T05:35:42.000Z

@tangxiaodao It seems you know C++. Are you interested in helping fix the issue we have with upgrading LibSpatial? It is explained at libspatialindex/libspatialindex#224 (comment)

I'm sorry, I just see your this reply. I was busy with other work recently, so I didn't have noticed your reply.

Answer 21 · 2022-02-09T07:52:38.000Z

If possible, it is recommended to set proj.db to a dynamic path.

The location of the proj.db is set by PROJ_LIB, so it is more or less dynamic.

Answer 22 · 2022-02-09T08:04:46.000Z

Will u try use CPLSetConfigOption("PROJ_LIB","\proj.db")?

Answer 23 · 2022-02-09T08:08:04.000Z

I am using vcpkg to configure the environment of MW for GDAL3 + proj 8 and rebuild the binary to try to reproduce your problem. It may take some time.

Answer 24 · 2022-02-09T08:08:25.000Z

I've added your suggestion to MWGIS-278: Check for PROJ_LIB and set if missing
This issue is still open.

Answer 25 · 2022-02-09T08:12:18.000Z

Can I set up a separate branch for environmental testing of vcpkg configuration?

Answer 26 · 2022-02-09T08:14:14.000Z

Can I set up a separate branch for environmental testing of vcpkg configuration?

Yes you can.

This issue is getting really cluttered. Perhaps it is best to move the conversation to the forum: https://mapwindow.discourse.group/c/mapwingis/8 or contact me via email.

Answer 27 · 2022-02-09T08:19:04.000Z

Ok, I'll test it locally first, email you when needed, and push a branch for vcpkg.

Answer 28 · 2022-02-09T08:28:48.000Z

u can get geotiff files from opentopography website.

Answer 29 · 2022-02-09T09:25:07.000Z

I've downloaded the tiff from https://portal.opentopography.org/dataspace/dataset?opentopoID=OTDS.022020.32616.2
And opened it:

Seems to me that it is working.

I'm closing this issue now. Please, create a new issue when you have a specific GeoTiff which is not working.