Giter Site home page Giter Site logo

arcrasterrescue's People

Contributors

gparadis avatar josephko91 avatar r-barnes avatar ratnanil avatar tomalrussell avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

arcrasterrescue's Issues

zlib -3 runtime error

Hi - thank you for making this tool available and open, it's super useful.

I'm able to run it most of the time, but I have a particular FileGDB which throws this error for each layer:

terminate called after throwing an instance of 'std::runtime_error'
  what():  zlib error: -3
Aborted (core dumped)

I'm afraid I'm not sure how to provide a reproducible example, the data I'm working with is proprietary.

This SO answer talks about the same error code. Could it be that the FileGDB is using another compression method (e.g. GZIP instead of ZLIB)? Would ArcRasterRescue handle this case by default?

Another quirk (possible red herring) is that the system I'm working on only has cmake at 3.5, so I downgraded cmake_minimum_required to VERSION 3.5 and replaced the cxx_std_11 argument in calls to target_compile_features with cxx_constexpr (which needs c++ 11 anyway, I understand) to get it to build. This may have been a horrible hack, I'm not very familiar with cmake.

Incomplete/Errant Export of Raster Data

I have a large raster layer in a File Geodatabase that I wish to export for use with non-ESRI products on a non-Windows system.

The export runs and creates a GeoTIFF of the expected size, but the pixel values appear to not be set correctly and there are no minimum or maximum values set.

The source data is available at: [https://www.ewgateway.org/wp-content/uploads/2019/06/UrbanLandCover_1m.zip] (1.2 GB)

Layer in Question: LULC_Urban2017
Compression: LZ77
Uncompressed Layer Size: just under 15 GB

The raster layer includes an attribute table, but that can be dropped from the export; I'm only interested in the raster data.

Running gdalinfo on the output file results in an error.
gdalinfo -mm LULC_Urban2017.tif
ERROR 1: LULC_Urban2017.tif, band 1: Failed to compute min/max, no valid pixels found in sampling.

I then looked at the project fork [https://github.com/justinfisk/ArcRasterRescue] and compiled that version since there was an update to the geo transform code. Using the executable compiled from that source, I was able to successfully export the raster layer.

Issue rescuing PRISM data

Hello,
Thank you so much for this program, I really appreciate your time and efforts.

I am trying to rescue PRISM data downloaded from Geospatial Data Gateway. I am able to run the executable successfully and produce a Tiff file, however, it seems that I am not able to read this file in either R or visualize in QGIS or visualize at GeoTIFF.io.

The source data are in decimal degrees with a cell resolution of 0.000000001 decimal degrees; could the cell resolution be too small and some weird rounding errors are happening?

The error from RGDAL:

> tst = readGDAL(fname = "precipann_r_mn.tif")
precipann_r_mn.tif has GDAL driver GTiff 
and has 768 rows and 1024 columns
Error in validObject(.Object) : 
  invalid classGridTopologyobject: cellsize has incorrect dimension

And from the web console from GeoTIFF.io I get the following error messages:

ERROR initializing GeoTIFFLayer ReferenceError: proj4 is not defined
Uncaught (in promise) TypeError: this._bounds is undefined

QGIS doesn't show any image, but it does show a histogram that I would expect for annual precipitation in Minnesota:
image

Running gdalinfo (results below) show a pixel resolution of 0, 0.

I can't seem to understand why I can't open it and yet there is a reasonable histogram of the data, the data is there.
Could this be an issue of just updating the metadata with something like exiftool?

Thanks for any and all help toward resolution or just clarification,
Dave

I have uploaded the zip file containing the gdb and I ran the following to run the program
./arc_raster.exe ./mn_prism_climate_1981_2010.gdb/ 0 ./precipann_r_mn.tif

The results of gdalinfo are below:

gdalinfo precipann_r_mn.tif 
Driver: GTiff/GeoTIFF
Files: precipann_r_mn.tif
Size is 1024, 768
Coordinate System is:
GEOGCS["GCS_WGS_1984",
    DATUM["D_WGS_1984",
        SPHEROID["WGS_1984",6378137,298.257223563]],
    PRIMEM["Greenwich",0],
    UNIT["degree",0.0174532925199433]]
Origin = (-97.306988166333326,49.448243586642462)
Pixel Size = (0.000000000000000,-0.000000000000000)
Metadata:
  AREA_OR_POINT=Area
  PROCESSING_HISTORY=2020-10-24 21:03:28 UTC | Arc Raster Rescue (url=github.com/r-barnes/ArcRasterRescue, hash=2f4140e9d209355e, compiled=2020-10-22 19:44:46 UTC) | ./arc_raster.exe ../mn_prism_climate_1981_2010.gdb/ 0 ../precipann_r_mn.tif And thanks again for this tool
  TIFFTAG_DATETIME=2020-10-24 21:03:28 UTC
  TIFFTAG_SOFTWARE=Arc Raster Rescue (url=github.com/r-barnes/ArcRasterRescue, hash=2f4140e9d209355e, compiled=2020-10-22 19:44:46 UTC)
Image Structure Metadata:
  INTERLEAVE=BAND
Corner Coordinates:
Upper Left  ( -97.3069882,  49.4482436) ( 97d18'25.16"W, 49d26'53.68"N)
Lower Left  ( -97.3069882,  49.4482436) ( 97d18'25.16"W, 49d26'53.68"N)
Upper Right ( -97.3069882,  49.4482436) ( 97d18'25.16"W, 49d26'53.68"N)
Lower Right ( -97.3069882,  49.4482436) ( 97d18'25.16"W, 49d26'53.68"N)
Center      ( -97.3069882,  49.4482436) ( 97d18'25.16"W, 49d26'53.68"N)

prism1981_2010_mn.zip

Char issues with no_data

Extracted from #17 by @joeperdefloep

I don't think it is related to the issue, but I also had some overflow warnings when building the program related to the nodata value.

Details

Scanning dependencies of target arc_raster_rescue
make[2]: Warning: File 'CMakeFiles/arc_raster_rescue.dir/depend.make' has modification time 0.71 s in the future
[ 25%] Building CXX object CMakeFiles/arc_raster_rescue.dir/src/arr.cpp.o
/mnt/c/Users/Joep/Documents/ArcRasterRescue/src/arr.cpp: In instantiation of ‘RasterData::RasterData(std::string, const RasterBase&) [with T = unsigned char; std::string = std::__cxx11::basic_string]’:
/mnt/c/Users/Joep/Documents/ArcRasterRescue/src/arr.cpp:1246:20: required from ‘void ExportTypedRasterToGeoTIFF(std::string, std::string, int, std::string) [with T = unsigned char; std::string = std::__cxx11::basic_string]’
/mnt/c/Users/Joep/Documents/ArcRasterRescue/src/arr.cpp:1278:84: required from here
/mnt/c/Users/Joep/Documents/ArcRasterRescue/src/arr.cpp:958:36: warning: unsigned conversion from ‘int’ to ‘unsigned char’ changes value from ‘-9999’ to ‘241’ [-Woverflow]
958 | resize(maxpx-minpx, maxpy-minpy, -9999);
| ^~~~~
/mnt/c/Users/Joep/Documents/ArcRasterRescue/src/arr.cpp:1132:13: warning: unsigned conversion from ‘int’ to ‘unsigned char’ changes value from ‘-9999’ to ‘241’ [-Woverflow]
1132 | no_data = -9999; //TODO: This cannot always be NoData.
| ^~~~~
/mnt/c/Users/Joep/Documents/ArcRasterRescue/src/arr.cpp: In instantiation of ‘RasterData::RasterData(std::string, const RasterBase&) [with T = signed char; std::string = std::__cxx11::basic_string]’:
/mnt/c/Users/Joep/Documents/ArcRasterRescue/src/arr.cpp:1246:20: required from ‘void ExportTypedRasterToGeoTIFF(std::string, std::string, int, std::string) [with T = signed char; std::string = std::__cxx11::basic_string]’
/mnt/c/Users/Joep/Documents/ArcRasterRescue/src/arr.cpp:1284:83: required from here
/mnt/c/Users/Joep/Documents/ArcRasterRescue/src/arr.cpp:958:36: warning: overflow in conversion from ‘int’ to ‘signed char’ changes value from ‘-9999’ to ‘-15’ [-Woverflow]
958 | resize(maxpx-minpx, maxpy-minpy, -9999);
| ^~~~~
/mnt/c/Users/Joep/Documents/ArcRasterRescue/src/arr.cpp:1132:13: warning: overflow in conversion from ‘int’ to ‘signed char’ changes value from ‘-9999’ to ‘-15’ [-Woverflow]
1132 | no_data = -9999; //TODO: This cannot always be NoData.
| ^~~~~
[ 50%] Linking CXX static library libarc_raster_rescue.a
make[2]: warning: Clock skew detected. Your build may be incomplete.
[ 50%] Built target arc_raster_rescue
Scanning dependencies of target arc_raster_rescue.exe
make[2]: Warning: File 'CMakeFiles/arc_raster_rescue.exe.dir/depend.make' has modification time 0.7 s in the future
[ 75%] Building CXX object CMakeFiles/arc_raster_rescue.exe.dir/evaluation/main.cpp.o
[100%] Linking CXX executable arc_raster_rescue.exe
make[2]: warning: Clock skew detected. Your build may be incomplete.
[100%] Built target arc_raster_rescue.exe

How to use the *.exe on Ubuntu

Apologies for what might be a Ubuntu noob question, but how to use the arc_raster_rescue.exe on Ubuntu? Or does it run on some other system?

Invalid Position in Large Rasters

We're running into an issue where with some of our larger rasters (around 4 GB) where reading the file goes wrong around the 2 GB mark.

We tracked down what is happening to this bit of logic:

    GotoPosition(geoDatabaseIndex, 16 + m_featureIndex*featureTableOffsets);
    int32_t featureOffset = ReadInt32(geoDatabaseIndex);

where featureOffset is returned as a negative value. After that, everything goes wrong and it eventually ends up stuck in an endless loop trying to read from an invalid stream position.

DOI not working

Thanks so much for this great tool! It really saved my day today.

I am currently writing an essay, and wanted to insert a reference. However the DOI provided ( doi: 10.5281/zenodo.4128479.) does not return anything when entered in my search bar (firefox).

Kind regards,
Joep

std::length_error exception when running on 9GB DEM raster dataset

I'm trying to extract a statewide DEM from here: ftp://ftp.gis.oregon.gov/elevation/DEM/Statewide_Filegeodatabase/OR_DEM_10M.gdb/

I've attached the full log but the relevant part is here:

Opening BaseTable as 'OR_DEM_10M.gdb/a00000027.gdbtable'...
Opening RasterProjection as 'OR_DEM_10M.gdb/a00000027.gdbtable'
Opening BaseTable as 'OR_DEM_10M.gdb/a00000029.gdbtable'...
Allocating 4x65408x48640 = 12725780480
terminate called after throwing an instance of 'std::length_error'
what(): vector::_M_default_append
Aborted

I realize that that's a nearly 13GB allocation and would likely have failed with a bad_alloc like #6 but it seems odd to me that it would throw a length_error before that? Given that this software is for the GIS discipline it should be able to handle any size of data thrown at it unless the physical limits of the machine are incapable of processing it.

Might also be unrelated but I had to add a #include <array> in arc_raster_rescue.hpp to get this to compile as there were two uses of std::array without ever actually defining it.

ARR_failure_log.txt

"Could not map native type 'a' to GDAL type!"

Hello,
I was eager to try out v1.0.0, but after successfully compiling I ran into an issue that I don't know how to troubleshoot.

OS: Ubuntu 18.04 (in WSL)
Source gdb file: https://coast.noaa.gov/htdata/Inundation/SLR/FloodFreqData/Flood_Frequency_data_dist.zip
Desired layer number: 22
Error as follows:

Projection: GEOGCS["GCS_North_American_1983",DATUM["D_North_American_1983",SPHEROID["GRS_1980",6378137.0,298.257222101]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]]
Could not map native type 'a' to GDAL type! (Use `c++filt -t` to decode.)
terminate called after throwing an instance of 'std::runtime_error'
  what():  Could not map native data type to GDAL type!
Aborted

nodata region affecting georegistration

I'm looking at this raster GDB: http://frap.fire.ca.gov/data/frapgisdata-sw-fveg_download

In correct alignment it looks like this

image

with

PROJCS["NAD_1983_California_Teale_Albers",
    GEOGCS["NAD83",
        DATUM["North_American_Datum_1983",
            SPHEROID["GRS 1980",6378137,298.2572221010042,
                AUTHORITY["EPSG","7019"]],
            AUTHORITY["EPSG","6269"]],
        PRIMEM["Greenwich",0],
        UNIT["degree",0.0174532925199433],
        AUTHORITY["EPSG","4269"]],
    PROJECTION["Albers_Conic_Equal_Area"],
    PARAMETER["standard_parallel_1",34],
    PARAMETER["standard_parallel_2",40.5],
    PARAMETER["latitude_of_center",0],
    PARAMETER["longitude_of_center",-120],
    PARAMETER["false_easting",0],
    PARAMETER["false_northing",-4000000],
    UNIT["metre",1,
        AUTHORITY["EPSG","9001"]]]
Origin = (-636269.999999998137355,530310.000000000000000)
Pixel Size = (30.000000000000000,-30.000000000000000)

Size is 39623, 38094
Upper Left  ( -636270.000,  530310.000) (127d44' 2.84"W, 42d33'31.44"N)
Lower Left  ( -636270.000, -612510.000) (126d44'50.64"W, 32d17'39.60"N)
Upper Right (  552420.000,  530310.000) (113d16'53.19"W, 42d36'58.97"N)
Lower Right (  552420.000, -612510.000) (114d 8'21.71"W, 32d20'40.82"N)
Center      (  -41925.000,  -41100.000) (120d28'32.91"W, 37d38'44.53"N)

The box on the plot shows the extent of the raster itself, so there's a region 9031 pixels wide before any valid data is present, at easting = -365340 (which is -636270 + 9031 * 30).
When I convert with ArcRasterRescue I get the following, and the western edge of valid data is right at the left extent, at -636270 - so the region of missing data has not been accounted for. There's a smaller gap at the top causing a shift north as well.

Driver: GTiff/GeoTIFF
Files: fveg15.tif
Size is 30592, 35456
Coordinate System is:
PROJCS["NAD_1983_California_Teale_Albers",
    GEOGCS["GCS_North_American_1983",
        DATUM["D_North_American_1983",
            SPHEROID["GRS_1980",6378137.0,298.257222101]],
        PRIMEM["Greenwich",0.0],
        UNIT["Degree",0.017453292519943295]],
    PROJECTION["Albers"],
    PARAMETER["False_Easting",0.0],
    PARAMETER["False_Northing",-4000000.0],
    PARAMETER["Central_Meridian",-120.0],
    PARAMETER["Standard_Parallel_1",34.0],
    PARAMETER["Standard_Parallel_2",40.5],
    PARAMETER["Latitude_Of_Origin",0.0],
    UNIT["Meter",1.0]]
Origin = (-636254.999999998137355,530295.000000000000000)
Pixel Size = (30.000000000000000,-30.000000000000000)
Metadata:
  AREA_OR_POINT=Area
  PROCESSING_HISTORY=2018-05-08 03:48:17 UTC | Arc Raster Rescue (url=github.com/r-barnes/ArcRasterRescue, hash=b60ea39fcf11666d, compiled=2018-05-08 03:43:04 UTC) | ./ArcRasterRescue/arc_raster.exe fveg15_1.gdb/ 0 fveg15.tif
  TIFFTAG_DATETIME=2018-05-08 03:48:17 UTC
  TIFFTAG_SOFTWARE=Arc Raster Rescue (url=github.com/r-barnes/ArcRasterRescue, hash=b60ea39fcf11666d, compiled=2018-05-08 03:43:04 UTC)
Image Structure Metadata:
  INTERLEAVE=BAND
Corner Coordinates:
Upper Left  ( -636255.000,  530295.000)
Lower Left  ( -636255.000, -533385.000)
Upper Right (  281505.000,  530295.000)
Lower Right (  281505.000, -533385.000)
Center      ( -177375.000,   -1545.000)
Band 1 Block=30592x1 Type=Int32, ColorInterp=Gray
  NoData Value=-9999

I've seen this problem with another example, but I didn't understand it at the time and I can't share that file. I hope my explanation is clear.

This second plot shows the output of ArcRasterRescue plotted in the same context as the plot above, and with the states overlaid. The frame and map context is correct, but the raster is shifted to the west, and north.

image

Thanks!

read/save projection?

Hi Richard

Thanks a lot for this utility, awesome!!! I was wondering what happens with the projection of the raster? Is this kept as the original in the gdb? I am unfamiliar with the gdb as well as gtiff format, but was wondering whether it would be possible that ArcRasterRescue returns the info on the projection in the gtiff?

Thanks!!

Job "killed" for test runs

Hello! This is my first attempt trying to use this tool, however I am not having any success with my particular input .gdb files. I have tried compiling and running on my local machine following the instructions in the readme, and I have also tried using the docker container.

Source of .gdb files used in tests:
https://geoplatform.maps.arcgis.com/home/item.html?id=9203dd8971b0489ea17a89b41d6acab2
https://geoplatform.maps.arcgis.com/home/item.html?id=82b2b023bdd740cea55ca29ad78c7eec

  1. Using instructions in readme:
  • The program runs and a TIFF is generated, however upon opening it in QGIS, it doesn't look like it was converted correctly. The range of values is completely changed and no image actually shows up when imported as a layer.
  1. Using docker container:
  • When I run the executable with the docker image mounted, it starts to run and then it fails with the message "Killed"
  • no TIFF is generated at all in this case, not even a corrupted one

I was very excited to try this tool since there seems to be no open-source (i.e., non-ESRI) solution to converting .gdb files to geotiff, but I just can't seem to get it working with my files! Any help with be greatly appreciated!

4 bit data warps raster file

I have a classified raster with 4 bit data stored in a geodatabase. When converting with ARR, the output was a weird striped output. I have included the .gdb, database with a single raster. The converted file with ArcRasterRescue is lu_arr.tif, and the rest is the converted file using ArcGIS.
lu.zip
The (verbose) output is given below:


/ArcRasterRescue/build/arc_raster_rescue.exe ./lu.gdb/ 0 ./lu_arr.tif
Arc Raster Rescue (url=github.com/r-barnes/ArcRasterRescue, hash=482eb367ba86b43c, compiled=2021-05-06 20:37:05)
Opening BaseTable as './lu.gdb/a00000001.gdbtable'...
gdbtables found:
        GDB_SystemCatalog - a00000001.gdbtable
        GDB_DBTune - a00000002.gdbtable
        GDB_SpatialRefs - a00000003.gdbtable
        GDB_Items - a00000004.gdbtable
        GDB_ItemTypes - a00000005.gdbtable
        GDB_ItemRelationships - a00000006.gdbtable
        GDB_ItemRelationshipTypes - a00000007.gdbtable
        GDB_ReplicaLog - a00000008.gdbtable
        lu_prado_20m - a00000009.gdbtable
        fras_ras_lu_prado_20m - a0000000a.gdbtable
        fras_aux_lu_prado_20m - a0000000b.gdbtable
        fras_blk_lu_prado_20m - a0000000c.gdbtable
        fras_bnd_lu_prado_20m - a0000000d.gdbtable
        VAT_lu_prado_20m - a0000000e.gdbtable
Opening BaseTable as './lu.gdb/a0000000d.gdbtable'...
Opening RasterBase as './lu.gdb/a0000000d.gdbtable'
Field name (type=1): sequence_nbr
Skipping field 'sequence_nbr'
Field value: 1
Field name (type=1): raster_id
Skipping field 'raster_id'
Field value: 1
Field name (type=4): name
Field value: ''
Field name (type=1): band_flags
Skipping field 'band_flags'
Field value: 67340801
Field name (type=1): band_width
Field value: 380
Field name (type=1): band_height
Field value: 583
Field name (type=1): band_types
band_types = 0 4 20 0 00000000 00000100 00100000 00000000
Detected band data type =
Field name (type=1): block_width
Field value: 128
Field name (type=1): block_height
Field value: 128
Field name (type=3): block_origin_x
Field value: 614456
Field name (type=3): block_origin_y
Field value: 4.18933e+06
Field name (type=3): eminx
Field value: 614456
Field name (type=3): eminy
Field value: 4.17769e+06
Field name (type=3): emaxx
Field value: 622036
Field name (type=3): emaxy
Field value: 4.18933e+06
Field name (type=1): cdate
Field value: 1620332591
Field name (type=1): mdate
Field value: 1620332591
Field name (type=1): srid
Skipping field 'srid'
Field value: 2
Using geotransform (this is experimental): 614456.00000000093132257462 19.94736842105263008307 0.00000000000000000000 4189334.00000000372529029846 0.00000000000000000000 -19.96569468267581370924
Using internal datatype 'h'. Use 'c++filt -t' to decode.
Opening BaseTable as './lu.gdb/a00000009.gdbtable'...
field.raster.wkt: PROJCS["ED_1950_UTM_Zone_30N",GEOGCS["GCS_European_1950",DATUM["D_European_1950",SPHEROID["International_1924",6378388.0,297.0]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]],PROJECTION["Transverse_Mercator"],PARAMETER["False_Easting",500000.0],PARAMETER["False_Northing",0.0],PARAMETER["Central_Meridian",-3.0],PARAMETER["Scale_Factor",0.9996],PARAMETER["Latitude_Of_Origin",0.0],UNIT["Meter",1.0]]
field.shape.wkt: PROJCS["ED_1950_UTM_Zone_30N",GEOGCS["GCS_European_1950",DATUM["D_European_1950",SPHEROID["International_1924",6378388.0,297.0]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]],PROJECTION["Transverse_Mercator"],PARAMETER["False_Easting",500000.0],PARAMETER["False_Northing",0.0],PARAMETER["Central_Meridian",-3.0],PARAMETER["Scale_Factor",0.9996],PARAMETER["Latitude_Of_Origin",0.0],UNIT["Meter",1.0]]
Opening BaseTable as './lu.gdb/a0000000d.gdbtable'...
Opening RasterBase as './lu.gdb/a0000000d.gdbtable'
Field name (type=1): sequence_nbr
Skipping field 'sequence_nbr'
Field value: 1
Field name (type=1): raster_id
Skipping field 'raster_id'
Field value: 1
Field name (type=4): name
Field value: ''
Field name (type=1): band_flags
Skipping field 'band_flags'
Field value: 67340801
Field name (type=1): band_width
Field value: 380
Field name (type=1): band_height
Field value: 583
Field name (type=1): band_types
band_types = 0 4 20 0 00000000 00000100 00100000 00000000
Detected band data type =
Field name (type=1): block_width
Field value: 128
Field name (type=1): block_height
Field value: 128
Field name (type=3): block_origin_x
Field value: 614456.00000000093132257462
Field name (type=3): block_origin_y
Field value: 4189334.00000000372529029846
Field name (type=3): eminx
Field value: 614456.00000000093132257462
Field name (type=3): eminy
Field value: 4177694.00000000372529029846
Field name (type=3): emaxx
Field value: 622036.00000000093132257462
Field name (type=3): emaxy
Field value: 4189334.00000000372529029846
Field name (type=1): cdate
Field value: 1620332591
Field name (type=1): mdate
Field value: 1620332591
Field name (type=1): srid
Skipping field 'srid'
Field value: 2
Using geotransform (this is experimental): 614456.00000000093132257462 19.94736842105263008307 0.00000000000000000000 4189334.00000000372529029846 0.00000000000000000000 -19.96569468267581370924
Opening BaseTable as './lu.gdb/a0000000a.gdbtable'...
Opening RasterProjection as './lu.gdb/a0000000a.gdbtable'
Opening BaseTable as './lu.gdb/a0000000c.gdbtable'...
Allocating 1x384x640 = 245760
Opening Raster Data as ./lu.gdb/a0000000c.gdbtable
Skipped points: 0
Projection: PROJCS["ED_1950_UTM_Zone_30N",GEOGCS["GCS_European_1950",DATUM["D_European_1950",SPHEROID["International_1924",6378388.0,297.0]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]],PROJECTION["Transverse_Mercator"],PARAMETER["False_Easting",500000.0],PARAMETER["False_Northing",0.0],PARAMETER["Central_Meridian",-3.0],PARAMETER["Scale_Factor",0.9996],PARAMETER["Latitude_Of_Origin",0.0],UNIT["Meter",1.0]]

I don't think it is related to the issue, but I also had some overflow warnings when building the program related to the nodata value.

```

Scanning dependencies of target arc_raster_rescue
make[2]: Warning: File 'CMakeFiles/arc_raster_rescue.dir/depend.make' has modification time 0.71 s in the future
[ 25%] Building CXX object CMakeFiles/arc_raster_rescue.dir/src/arr.cpp.o
/mnt/c/Users/Joep/Documents/ArcRasterRescue/src/arr.cpp: In instantiation of ‘RasterData::RasterData(std::string, const RasterBase&) [with T = unsigned char; std::string = std::__cxx11::basic_string]’:
/mnt/c/Users/Joep/Documents/ArcRasterRescue/src/arr.cpp:1246:20: required from ‘void ExportTypedRasterToGeoTIFF(std::string, std::string, int, std::string) [with T = unsigned char; std::string = std::__cxx11::basic_string]’
/mnt/c/Users/Joep/Documents/ArcRasterRescue/src/arr.cpp:1278:84: required from here
/mnt/c/Users/Joep/Documents/ArcRasterRescue/src/arr.cpp:958:36: warning: unsigned conversion from ‘int’ to ‘unsigned char’ changes value from ‘-9999’ to ‘241’ [-Woverflow]
958 | resize(maxpx-minpx, maxpy-minpy, -9999);
| ^~~~~
/mnt/c/Users/Joep/Documents/ArcRasterRescue/src/arr.cpp:1132:13: warning: unsigned conversion from ‘int’ to ‘unsigned char’ changes value from ‘-9999’ to ‘241’ [-Woverflow]
1132 | no_data = -9999; //TODO: This cannot always be NoData.
| ^~~~~
/mnt/c/Users/Joep/Documents/ArcRasterRescue/src/arr.cpp: In instantiation of ‘RasterData::RasterData(std::string, const RasterBase&) [with T = signed char; std::string = std::__cxx11::basic_string]’:
/mnt/c/Users/Joep/Documents/ArcRasterRescue/src/arr.cpp:1246:20: required from ‘void ExportTypedRasterToGeoTIFF(std::string, std::string, int, std::string) [with T = signed char; std::string = std::__cxx11::basic_string]’
/mnt/c/Users/Joep/Documents/ArcRasterRescue/src/arr.cpp:1284:83: required from here
/mnt/c/Users/Joep/Documents/ArcRasterRescue/src/arr.cpp:958:36: warning: overflow in conversion from ‘int’ to ‘signed char’ changes value from ‘-9999’ to ‘-15’ [-Woverflow]
958 | resize(maxpx-minpx, maxpy-minpy, -9999);
| ^~~~~
/mnt/c/Users/Joep/Documents/ArcRasterRescue/src/arr.cpp:1132:13: warning: overflow in conversion from ‘int’ to ‘signed char’ changes value from ‘-9999’ to ‘-15’ [-Woverflow]
1132 | no_data = -9999; //TODO: This cannot always be NoData.
| ^~~~~
[ 50%] Linking CXX static library libarc_raster_rescue.a
make[2]: warning: Clock skew detected. Your build may be incomplete.
[ 50%] Built target arc_raster_rescue
Scanning dependencies of target arc_raster_rescue.exe
make[2]: Warning: File 'CMakeFiles/arc_raster_rescue.exe.dir/depend.make' has modification time 0.7 s in the future
[ 75%] Building CXX object CMakeFiles/arc_raster_rescue.exe.dir/evaluation/main.cpp.o
[100%] Linking CXX executable arc_raster_rescue.exe
make[2]: warning: Clock skew detected. Your build may be incomplete.
[100%] Built target arc_raster_rescue.exe

</details>

I hope this helps!

(Larger?) Rasters are offset when exported

Hey there,

I really appreciate the work you're doing to open up raster FileGDB's to the open source community - but I am seeing an issue when trying to use this program.

I am working remotely and not on my main desktop workstation, and I don't have a linux system on this laptop. I used WSL debian to build the program and then attempted to rescue some rasters! Unfortunately, none of the rasters were working properly - All of them show no data when loaded, but they are the appropriate file size.

I then tried to use the docker method to extract the rasters, and this succeeded - however some of them (I believe it was larger ones,) were offset by hundreds of meters. Some lined up fine but others were very noticeably offset - I was unable to figure out why

Unfortunately the data is private and not free to distribute so I cannot supply a sample of it. I can try to provide any additional information that I am able but I will be limited with what I can provide

std::bad_alloc core dump example

I'm trying to extract a raster from the gdb located at:

https://gisdata.mn.gov/dataset/water-lake-bathymetry

  • ftp://ftp.gisdata.mn.gov/pub/gdrs/data/pub/us_mn_state_dnr/water_lake_bathymetry/fgdb_water_lake_bathymetry.zip

Running into an error (copied below) that I thought I'd share:

arc_raster.exe data/mn_bathy/water_lake_bathymetry.gdb/ 0 lake_bathymetric_elevation_model

arc_raster.exe data/mn_bathy/water_lake_bathymetry.gdb/ 0 lake_bathymetric_elevation_model
Arc Raster Rescue (url=github.com/r-barnes/ArcRasterRescue, hash=2f4140e9d209355e, compiled=2019-08-23 12:48:01 UTC)
Allocating 4x104576x117376 = 49098850304
terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc
Aborted (core dumped)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.