Hi

I downloaded a large quantity of data (6Gb) from this source : https://ghsl.jrc.ec.europa.eu/download/projectionR2020/BUILT-POP_PROJ_GLOBE_SSP_R2020.zip

This data should show geographical projection of population by 2100 for the whole world, I am only interested in the data of Mauritania which you can access here : https://ied-sa.box.com/s/8d40fhq5g0hffdxtdvxxuxkuhputfksx

(I only unzipped the data I wanted, then zipped it again) to share it here (5Mo)

it is under gdb format and I cannot open it with M9.

I tried File/Import (both selecting "all file *.*" or "gdb Files") nothing appears in the project pane

I tried to create a new datasource, same, not working

the journal windows only says :

"2023-03-20 10:18:53 -- Manifold System 9.0.180.0

2023-03-20 10:18:53 -- Starting up

2023-03-20 10:18:53 Log file: C:\Users\xefi\AppData\Local\Manifold\v9.0\20230320.log

2023-03-20 10:18:54 -- Startup complete (1.126 sec)

2023-03-20 10:18:54 -- Create: (New Project) (0.013 sec)

2023-03-20 10:29:26 *** Failed to load library: nvcuda.dll

2023-03-20 10:29:26 *** Failed to load library: cuda.dll

2023-03-20 10:34:02 -- Import: D:\2 - Affaires\50 mauritanie\BUILT-POP_PROJ_GLOBE_SSP_R2020 - 1\Pop_builtup_projections_SSP2_2015_2100\WestAfrica\MRT\MRT_BUProject_2015_2100.gdb\gdb (0.313 sec)

"

Any clue how I can import these data in Manifold?

I think Manifold uses the FileGBD SDK, which cannot open raster datasets within GDBs.

You probably need to follow the instructions to install GDAL and use the OpenFileGDB extension (not sure if it's possible to specify through Manifold as GDAL also has its own version of the FileGDB SDK). The current master (which will eventually become GDAL 3.7) should be able to open raster datasets, but the necessary libraries to enable Manifold compatibility may not have been built yet.

The GDAL/OGR section of the docs could do with some updating as GDAL 2.x is now very old.

The GDAL/OGR section of the docs could do with some updating as GDAL 2.x is now very old.

It's not the doc or that 2.x is old, but which versions of GDAL are supported.

The operative commentary on 2.0.x is in the second paragraph of the topic, where it mentions "The Manifold GDAL dataport allows working with versions from GDAL 2.0.x onward, and automatically selects the latest version available with automatic adjustments for the call interface. See the Third Party Release Levels topic for the latest GDAL / OGR version supported."

The third party release levels topic says GDAL up to GDAL 3.3.x is supported. So that's what you have to install, as installing 3.6.x won't work (Manifold only tracks GDAL after a few builds, as for the great majority of Manifold users there's no need to use GDAL, and those who do use GDAL occasionally don't seem to be updating it with every build).

The GISInternals.com site only provides up to 3.6.2 as a stable build. According to the GDAL doc, 3.6.2 doesn't support rasters in file GDB either using Esri's File GDB SDK or the OpenFileGDB GDAL module.

An option would be to use development builds of GDAL 3.7 and do a conversion from a raster in the file GDB to GeoTIFF.

OK apologies, it is clear there. Maybe what I should have said is it would be good for Manifold to support more recent versions of GDAL, there are all sorts of sometimes quite important enhancements in each minor release. 3.3 is now a couple of years old, and will be 4 minor versions out of date come May.

Whether users of Manifold use them is another matter of course, but I would have thought the 3.7 one is important enough to definitely warrant inclusion, given it enables a whole category of data, rasters in file geodatabases, to be used by Manifold. Providing of course that the OpenFileGDB driver is the default, or there is a way to choose.

Thinking it would make a good video tutorial!

3.7 is not out yet, at least not as a regular build provided by sites like GISInternals.com. If people want to experiment with other packages that are still in flux, they can do that: just use a GDAL command line to do whatever experimental conversions you want. If it comes out and is stable and works reasonably well, I'd guess that's the sort of thing that might prompt an update. Or maybe not if the community doesn't care about it.

What drives priorities for what gets built into Manifold is what users want for priorities. There's no guesswork about it. What people ask for gets prioritized. What people don't ask for, doesn't. There's a well-known guide to sending in Suggestions that covers how all that works. If nobody expresses interest in GDAL or more frequent updates of GDAL minor builds that's an indication that as far as the Manifold community is concerned, that's not a priority.

But if for your work there's something in one of the GDAL minor builds you need that you can't get using one of Manifold's own built-in dataports, don't hesitate to send in a suggestion for supporting that build.

Hi,

thank you for your answers.

I didn't understand well what you debated, I never used GDAL before... but I gave it a try : I downloaded GDAL but it is still not working...

1. went to GISInternals.com
2. downloaded gdal-3.6.2-1930-x64-core.msi
3. run it
4. reboot
5. added both path to the system PATH environment variable (GDAL & GDAL/Plugins)
6. try to import with *.* GDAL/OGR => fail
7. reboot
8. try to import with *.* GDAL/OGR=> fail

The log journal says :

code 

2023-03-23 07:26:01 *** Failed to load library: gdal303.dll

2023-03-23 07:26:01 *** Failed to load library: gdal302.dll

2023-03-23 07:26:01 *** Failed to load library: gdal301.dll

2023-03-23 07:26:01 *** Failed to load library: gdal300.dll

2023-03-23 07:26:01 *** Failed to load library: gdal204.dll

2023-03-23 07:26:01 *** Failed to load library: gdal203.dll

2023-03-23 07:26:01 *** Failed to load library: gdal202.dll

2023-03-23 07:26:01 *** Failed to load library: gdal201.dll

2023-03-23 07:26:01 *** Failed to load library: gdal200.dll

2023-03-23 07:26:01 *** (import) Cannot open file.

2023-03-23 07:26:01  -- Import: C:\MRT\MRT_POPProject_2015_2100.gdb\gdb (0.017 sec)

Have you any ideas why does manifold fail to import the gdal library ?

Because the latest gdal version that Manifold supports is 3.3.x (gdal303.dll)

https://www.gisinternals.com/query2.html?content=filelist&file=release-1916-gdal-3-3-2-mapserver-7-6-4.zip

Later versions are not supported. Send in a suggestion, if you'd like.

Thank you,

I succeed in installing GDAL & using manifold with it (no more "failed to load library...)

(the link you gave me was for 32bit download, while I am working on a 64computer)

but it is still not working nothing appears in the project pane.

2023-03-23 10:51:09  -- Create: (New Project) (0.007 sec)

2023-03-23 10:51:23  -- Load library: C:\Program Files\GDAL\gdal303.dll

2023-03-23 10:51:24  -- (import) Driver: OpenFileGDB (ESRI FileGDB)

2023-03-23 10:51:24  -- Import: C:\MRT\MRT_BUProject_2015_2100.gdb\gdb (0.498 sec)

2023-03-23 10:51:41  -- Import: C:\MRT\MRT_POPProject_2015_2100.gdb\gdb (0.038 sec)

Can someone try to import my data in manifold? It is only 5Mo

https://ied-sa.box.com/s/8d40fhq5g0hffdxtdvxxuxkuhputfksx

Oh, sorry. For future visitors the 64bit downloads link:

https://www.gisinternals.com/query2.html?content=filelist&file=release-1928-x64-gdal-3-3-2-mapserver-7-6-4.zip

You cannot yet open raster data from GDB.

ESRI File Geodatabase raster (OpenFileGDB) will be available in gdal 3.7

https://github.com/OSGeo/gdal/blob/master/doc/source/drivers/raster/openfilegdb.rst

So do you mean that for now Manifold cannot open this file? (Since manifold works only with gdal 3.3 and gdal 3.7 is needed to open gdb raster?)

Correct. And 3.7 isn't released yet.

the open source driver for raster GDB has only just been *written* - there's still a month at least until GDAL 3.7 is released - if you're keen check the osgeo/gdal/docker dir on github and run the bleeding edge GDAL so you can test it, and report via GDAL forums - any feedback will be helpful

https://github.com/mdsumner

We don't yet support GDAL 3.7, so, no.

When GDAL 3.7 is released though, being able to access raster data in GDB files (which they seem to be doing by reading the files directly rather than going through ESRI's SDK) will be reason enough for us to support it.