using https://pcjericks.github.io/py-gdalogr-cookbook/projection.html#reproject-a-layer as an example. e.g. pull out geometries from a shapefile in ArchGDAL using http://gisdata-piercecowa.opendata.arcgis.com/datasets/nonmotorized-transportation-plan

shapes = AG.registerdrivers() do
    AG.read("Nonmotorized_Transportation_Plan.shp") do dataset
        [
            AG.getgeom(feature) for feature in AG.getlayer(dataset, 0)
            if GDAL.getgeometryref(feature.ptr) != C_NULL
        ]
    end
end

from there, to project them, the following should work:

AG.createcoordtrans(AG.importEPSG(2927), AG.importEPSG(4326)) do coordtrans
    AG.transform!.(shapes, coordtrans)
end

alternatively:

AG.transform!.(shapes, AG.importEPSG(4326))

Great to have the extensive testing, but 200MB of data is quite a lot for a Julia package. Perhaps it'd be good to put the data in a separate repository (ArchGDALData), that is in the test/REQUIRE only?

The bulk comes from 2 83MB rasters.
test/ospy/data4/aster.img
test/ospy/data5/aster.img

https://docs.julialang.org/en/v1/base/base/index.html#Base.getproperty

Taken from and closes #50:

Maybe we should replace the isfile with a checksum in case there are corrupted files. In julia 0.7 SHA is in the stdlib.

Thanks for putting this package together.

I have a simple need of import tiff rasters with something better than imagemagic. It seems I can do that with this package but I'm not sure of the simplest way to just get a tiff into some kind of Julia Array. My GDAL experience is limited.

Trying to get the band of single band datasets with ArchGDAL.getband(dataset, 1) is giving me a ReadOnlyMemoryError()` (is that expected?)

Without the band object there are no methods like getnodatavalue, how else can I get that information? (as separate values, not gdalinfo text)

The module fails to load with Julia 1.0, some of the reasons are that Base.Dates was replaced with just Dates or that Void was replaced with missing.

Would you like to support 0.4? I'd like to know before I get rid of some deprecation warnings. (For me it's not necessary.)

See if there's anything we can learn from

• https://gist.github.com/geowurster/99283743379436a0abc464f7cdd9acca
• rasterio/rasterio#665
• rasterio/rasterio#684
• rasterio/rasterio#969
• rasterio/rasterio#993
• rasterio/rasterio#997

see shapely/shapely#553

Some references

• https://gdal.org/doxygen/classGDALDataset.html
• https://gdal.org/doxygen/classOGRGeometry.html
• https://gdal.org/api/index.html
• https://gdal.org/python/osgeo.ogr.Geometry-class.html

I get this when running `Pkg.test("ArchGDAL") on Julia 0.7

curl: (22) The requested URL returned error: 503 first byte timeout ERROR: LoadError: failed process: Process(curl -g -L -f -o /home/js/.julia/dev/ArchGDAL/test/ospy/data4/aster.img 'https://github.com/yeesian/ArchGDALDatasets/blob/master/ospy/data4/aster.img?raw=true'`, ProcessExited(22)) [22]
Stacktrace:
[1] error(::String, ::Base.Process, ::String, ::Int64, ::String) at ./error.jl:42
[2] pipeline_error at ./process.jl:712 [inlined]
[3] #run#509(::Bool, ::Function, ::Cmd) at ./process.jl:670
[4] run at ./process.jl:668 [inlined]
[5] download(::String, ::String) at ./download.jl:48
[6] top-level scope at /home/js/.julia/dev/ArchGDAL/test/runtests.jl:62 [inlined]
[7] top-level scope at ./none:0
[8] include at ./boot.jl:317 [inlined]
[9] include_relative(::Module, ::String) at ./loading.jl:1034
[10] include(::Module, ::String) at ./sysimg.jl:29
[11] include(::String) at ./client.jl:398
[12] top-level scope at none:0
in expression starting at /home/js/.julia/dev/ArchGDAL/test/runtests.jl:56
ERROR: Package ArchGDAL errored during testing
Stacktrace:
[1] cmderror(::String, ::Vararg{String,N} where N) at /home/js/github/julia07/usr/share/julia/stdlib/v0.7/Pkg/src/Types.jl:120
[2] macro expansion at ./logging.jl:313 [inlined]
[3] #test#59(::Bool, ::Function, ::Pkg.Types.Context, ::Array{Pkg.Types.PackageSpec,1}) at /home/js/github/julia07/usr/share/julia/stdlib/v0.7/Pkg/src/Operations.jl:1273
[4] #test at ./none:0 [inlined]
[5] #test#44(::Bool, ::Base.Iterators.Pairs{Union{},Union{},Tuple{},NamedTuple{(),Tuple{}}}, ::Function, ::Pkg.Types.Context, ::Array{Pkg.Types.PackageSpec,1}) at /home/js/github/julia07/usr/share/julia/stdlib/v0.7/Pkg/src/API.jl:239
[6] test at /home/js/github/julia07/usr/share/julia/stdlib/v0.7/Pkg/src/API.jl:225 [inlined]
[7] #test#43 at /home/js/github/julia07/usr/share/julia/stdlib/v0.7/Pkg/src/API.jl:222 [inlined]
[8] test at /home/js/github/julia07/usr/share/julia/stdlib/v0.7/Pkg/src/API.jl:222 [inlined]
[9] #test#42 at /home/js/github/julia07/usr/share/julia/stdlib/v0.7/Pkg/src/API.jl:221 [inlined]
[10] test at /home/js/github/julia07/usr/share/julia/stdlib/v0.7/Pkg/src/API.jl:221 [inlined]
[11] #test#41 at /home/js/github/julia07/usr/share/julia/stdlib/v0.7/Pkg/src/API.jl:220 [inlined]
[12] test(::String) at /home/js/github/julia07/usr/share/julia/stdlib/v0.7/Pkg/src/API.jl:220
[13] top-level scope at none:0
`

And this on 0.6.4:
> Pkg.test("ArchGDAL") INFO: Testing ArchGDAL % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 141 0 141 0 0 151 0 --:--:-- --:--:-- --:--:-- 151 100 152 100 152 0 0 125 0 0:00:01 0:00:01 --:--:-- 125 0 0 0 0 0 0 0 0 --:--:-- 0:01:01 --:--:-- 0 curl: (22) The requested URL returned error: 503 first byte timeout ERROR: LoadError: failed process: Process(curl -L -f -o /home/js/.julia/v0.6/ArchGDAL/test/ospy/data4/aster.img 'https://github.com/yeesian/ArchGDALDatasets/blob/master/ospy/data4/aster.img?raw=true'`, ProcessExited(22)) [22]
Stacktrace:
[1] pipeline_error(::Base.Process) at ./process.jl:682
[2] run(::Cmd) at ./process.jl:651
[3] download(::String, ::String) at ./interactiveutil.jl:640
[4] macro expansion at /home/js/.julia/v0.6/ArchGDAL/test/runtests.jl:62 [inlined]
[5] anonymous at ./:?
[6] include_from_node1(::String) at ./loading.jl:576
[7] include(::String) at ./sysimg.jl:14
[8] process_options(::Base.JLOptions) at ./client.jl:305
[9] _start() at ./client.jl:371
while loading /home/js/.julia/v0.6/ArchGDAL/test/runtests.jl, in expression starting on line 56
================================================================[ ERROR: ArchGDAL ]================================================================

failed process: Process(/usr/bin/julia -Cx86-64 -J/usr/lib/x86_64-linux-gnu/julia/sys.so --compile=yes --depwarn=yes --check-bounds=yes --code-coverage=none --color=yes --compilecache=yes /home/js/.julia/v0.6/ArchGDAL/test/runtests.jl, ProcessExited(1)) [1]

===================================================================================================================================================
ERROR: ArchGDAL had test errors
`

Cannot tag a new version "v0.0.0" preceding all existing versions.
cc: @yeesian

For reference: https://gdal.org/user/ogr_feature_style.html. Some other links

• https://docs.qgis.org/3.16/en/docs/user_manual/style_library/style_manager.html
• https://github.com/OSGeo/gdal/blob/master/autotest/kml_generate_test_files.py

It doesn't seem well-supported or popular though, so I haven't been able to find good examples to work with. Keeping this ticket open in case I've been looking in the wrong places and someone else is able to point me in the right direction.

┌ Warning: 437 docstrings potentially missing:
│
│     ArchGDAL.indexof :: Tuple{ArchGDAL.AbstractRasterBand}
│     ArchGDAL.unsafe_nextfeature :: Tuple{ArchGDAL.AbstractFeatureLayer}
│     ArchGDAL.convexhull :: Tuple{ArchGDAL.AbstractGeometry}
│     ArchGDAL.setcoorddim! :: Tuple{ArchGDAL.AbstractGeometry,Integer}
│     ArchGDAL.getgeomdefn :: Union{Tuple{ArchGDAL.FeatureDefn}, Tuple{ArchGDAL.FeatureDefn,Integer}}
│     ArchGDAL.getgeomdefn :: Tuple{ArchGDAL.Feature,Integer}
│     ArchGDAL.wkbsize :: Tuple{ArchGDAL.AbstractGeometry}

To take the first example, indexof has a fine docstring:

"""
Fetch the band number (1+) within its dataset, or 0 if unknown.

This method may return a value of 0 to indicate overviews, or free-standing
`GDALRasterBand` objects without a relationship to a dataset.
"""
indexof(band::AbstractRasterBand) = GDAL.gdalgetbandnumber(band.ptr)

But since this function is not included in the docs anywhere with an @docs tag, this docstring doesn't end up in the docs. In fact @docs is used nowhere in the docs.

indexof is listed twice in two different pages, with a description based on the docstring:

• i = ArchGDAL.indexof(band): the index of the raster band.
• ArchGDAL.indexof(band): the index of the band (1+) within its dataset, or 0 if unknown. (1)

But it's better to put the @docs in one location, and then use cross referencing from other parts.

Here is the code that should reproduce the error.

ArchGDAL.registerdrivers() do
    drv = ArchGDAL.getdriver("ESRI Shapefile")
    ArchGDAL.create("test",drv) do ds

        layer = ArchGDAL.createlayer(ds,"test") # UndefVarError: wkbUnknown not defined
        # layer = ArchGDAL.createlayer(ds,"test", geom=ArchGDAL.GDAL.wkbUnknown) # This seems to  work
        ...
    end
end

the problem seems to be at dataset.jl line 315

https://docs.julialang.org/en/latest/manual/interfaces.html#Interfaces-1
https://docs.julialang.org/en/latest/base/collections.html#lib-collections-iteration-1

Currently this package does not provide any data abstractions for handles to GDAL objects, and makes it the responsibility of the user.

It uses the unsafe prefix for methods that returns objects that needs to be destroyed:

julia> AG.unsafe_
unsafe_boundary                   unsafe_createmultipoint            unsafe_fromWKB
unsafe_buffer                     unsafe_createmultipolygon          unsafe_fromWKT
unsafe_centroid                   unsafe_createmultipolygon_noholes  unsafe_fromXML
unsafe_clone                      unsafe_createpoint                 unsafe_getcurvegeom
unsafe_convexhull                 unsafe_createpolygon               unsafe_getfeature
unsafe_create                     unsafe_createstylemanager          unsafe_getlineargeom
unsafe_createRAT                  unsafe_createstyletable            unsafe_intersection
unsafe_createcolortable           unsafe_createstyletool             unsafe_loadstringlist
unsafe_createcoordtrans           unsafe_delaunaytriangulation       unsafe_newspatialref
unsafe_createcopy                 unsafe_difference                  unsafe_nextfeature
unsafe_createfeature              unsafe_executesql                  unsafe_pointalongline
unsafe_createfeaturedefn          unsafe_forceto                     unsafe_pointonsurface
unsafe_createfielddefn            unsafe_fromEPSG                    unsafe_polygonfromedges
unsafe_creategeom                 unsafe_fromEPSGA                   unsafe_polygonize
unsafe_creategeomcollection       unsafe_fromESRI                    unsafe_read
unsafe_creategeomfielddefn        unsafe_fromGML                     unsafe_symdifference
unsafe_createlinearring           unsafe_fromJSON                    unsafe_union
unsafe_createlinestring           unsafe_fromPROJ4                   unsafe_update
unsafe_createmultilinestring      unsafe_fromURL

and do-blocks as context managers.

I have also committed to the (questionable) decision of overloading the display methods for a nicer user-experience (like in the README).

Unfortunately, that means that user code which "leaks" the handles outside the do-block managers will likely result in a segfault:

  | | |_| | | | (_| |  |  Version 0.4.6 (2016-06-19 17:16 UTC)
 _/ |\__'_|_|_|\__'_|  |  Official http://julialang.org/ release
|__/                   |  x86_64-apple-darwin13.4.0

julia> import ArchGDAL; const AG = ArchGDAL
ArchGDAL

julia> AG.registerdrivers() do
       AG.read("data/point.geojson") do dataset
       dataset
       end
       end
Segmentation fault: 11

Since the display methods will call GDAL methods on an object that has been destroyed.

Some Possible Resolutions

1. make the do-block context managers return true/false to indicate success/failure.
2. provide corresponding data-types in this package, e.g.

type FeatureLayer
    ptr::Ptr{GDAL.OGRLayerH}
    ...
end

that will provide methods that set obj.ptr to C_NULL after destroying the GDAL object corresponding to obj::FeatureLayer.

ping @visr @meggart

Miscellaneous Remarks

To anticipate some suggestion(s): this package will not be providing finalizers that calls GDAL's destroy on the objects, as it does not mix well with a style of programming that makes it the responsibility of the user to manage memory, and users expecting it should look for other packages (e.g. GeoDataFrames).

What do you think of a utility function to read bands from geo tiff files?

using ArchGDAL

function readgeotiff(fname, bands=1)
    ArchGDAL.registerdrivers() do
        ArchGDAL.read(fname) do dataset
            ArchGDAL.read(dataset, bands)
        end
    end
end

I am using it all the time, maybe it could be part of ArchGDAL.jl?

in the methods for gdaldatasets

Could you put a tag on bbe15b6, maybe v0.0.0, as that this the last commit which works with Julia 0.6. For me there is no need to register it with METADATA (although attobot might do it anyway).

I believe things are stable enough that documentation for this package should be a priority after #19

If a complete band is read into an array, the x and y dimensions are flipped:

using ArchGDAL

filepath = "dem.tif"

arr = ArchGDAL.registerdrivers() do
    ArchGDAL.read(filepath) do dataset
        ArchGDAL.read(dataset, 1)
    end
end
summary(arr) # => 97×33 Array{UInt8,2}

run(`gdalinfo $filepath`)
⋮
Size is 97, 33 # this is ncol, nrow
Band 1 Block=97x1 Type=Byte, ColorInterp=Undefined # blocks are single rows
⋮

This is because GDAL is row-based and Julia column-based.
Some options regarding this:

• Keep as is, warn in the docs that users must take this into account
• Call permutedims (docs) before returning the array. Makes a copy of the whole dataset.
• Return a PermutedDimsArray (docs). This does not create a copy, but a permuted view.

I haven't really worked with PermutedDimsArray yet, but to me it seems like the best choice right now. Thoughts?

Hello,

First of all, thank you developers for all the hard work!

I have an image of a traffic density heat map that I have georeferenced and exported as a geoTIFF. I am now trying to extract the longitude and latitude values from that georeferenced image using Julia. I am reasonably new to Julia programming and geodata, so a lot of the documentation is going over my head.

Is this something that ArchGDAL can be used for? If so, how? The documentation available does provide some hints on how to do it but there are no easy to follow examples.

My apologies for the beginner questions.

Cheers!

following the discussion in https://discourse.julialang.org/t/how-can-i-rasterize-the-polygons-of-a-shapefile-in-julia/15089/2 and incorporating the GDAL/OGR cookbook example.

• documentation

Will make it easier to port online examples/tutorials for GDAL when working on things like #40 (comment)

It would be good to have a getindex method for Dataset as a wrapper to read that accepted Integer and Colon indexes, instead of only UnitRange. It would also be great for standardisation if it used the same indices as the array returned by read(ds), but less critical.

I've written a wrapper for ArchGDAL that is aiming to present a standard interface shared with other data sources like NCDatasets: https://github.com/rafaqz/GeoData.jl/blob/master/src/sources/gdal.jl

It works fine for whole arrays and (kind of) for unitranges, but it's going to need a lot of special casing and a rewrite/wrapper of the rasterio() methods for these things to work as users will expect. Maybe that would be more useful here? I'm not sure.

I was following the test/test_gdal_tutorials.jl script, the tutorial lead to shapefiles without any data.

AG.create("$pointshapefile.shp", "ESRI Shapefile") do dataset
            ...
            featuredefn = AG.getlayerdefn(layer)
            @test AG.getname(featuredefn) == "point_out"
            AG.createfeature(featuredefn) do feature # This doesn't write any data out
            #AG.createfeature(layer) do feature # I ended with this, which works
                AG.setfield!(feature, AG.getfieldindex(feature, "Name"), "myname")
            ...
end

It doesn't error out because it is defined in context.jl line 52. So I am not sure if this is a bug or user error.

References:

• http://juliaimages.github.io/TestImages.jl/
• http://dl.maptools.org/dl/geotiff/samples/

It would be great to do transformations between projections for points and geometries with one method, wrapping all the underlying calls. This would be fairly easy to do if crs were wrapped in types like in CoordinateReferenceSystemsBase.jl.

Something like this could just work without knowing what happens underneath because we would have all the information required to dispatch to the correct methods:

transform(sourceproj::WellKnownText, targetproj::EPSGcode, val::Geometry)

Julia methods with a ! bang normally write to the first argument. It would be easier to understand if they did here too. Its hard to tell when the buffer or Dataset etc is being written to.

Hi, I have installed ArchGdal and Gdal.jl successfully and all tests pass.

I started with

using ArchGDAL

const AG = ArchGDAL

import base.read

function read(f, filename)
                  return AG.registerdrivers() do
                      AG.read(filename) do dataset
                          f(dataset)
              end end end

I then have a file directory file and do:

read(file*"/interim_vswl1_12_N80.grib") do dataset
                  print(dataset)
              end;
CPLDestroyMutex: Error = 16 (Resource busy)
CPLDestroyMutex: Error = 16 (Resource busy)
ERROR: GDALError (Failure, code 4):
    /Users/jonnorberg/Documents/ecmwf/rawData/interim_vswl1_12_N80.grib is a grib file, but no raster dataset was successfully identified.

This is probably due to me not having used gdal at all before so I would just like to ask if there is anything obvious I can do to extract the data.

Any hints is appreciated!

An example in http://geoexamples.blogspot.com/2012/01/creating-files-in-ogr-and-gdal-with.html.

I'm also starting to feel that we should support a more REPL friendly version of ArchGDAL.read(filename) that just reads and copies the original dataset into an in-memory dataset for exploration. Expert users can still use the do-block version for out-of-core processing.

As shown in the title, give some examples，thanks!

In several test files, before and after statements are printed. These files often contain no functional tests and are thus only partly finished:

AG.importEPSG(26912) do spatialref
        println("before (Proj4): $(AG.toPROJ4(spatialref))")
        println("before (WKT): $(AG.toWKT(spatialref))")
        AG.morphtoESRI!(spatialref)
        println("after (Proj4): $(AG.toPROJ4(spatialref))")
        println("after: $(AG.toWKT(spatialref))")
end

We should finish these tests, they can be used at the least for regression testing.

gathering links for now;

• http://osgeo-org.1560.x6.nabble.com/GTiff-gdal-translate-CMYK-problem-td3758190.html
• https://github.com/wkearn/RasterIO.jl/blob/master/doc/devdocs/DataModel.md
• https://lists.osgeo.org/pipermail/gdal-dev/2014-October/040318.html

Hi there,

First of all, thanks for this library!

I'm trying to use Proj4 together with ArchGDAL. I have a GeoTIFF with elevation data and I would like to read it in and then get the elevation for each x,y location (in albers projection).

So I do this:

elevation_data = ArchGDAL.registerdrivers() do
           ArchGDAL.read("uk_elevation.tif") do dataset
               ArchGDAL.read(dataset, 1)
           end
       end

7714×13698 Array{UInt8,2}

to import the data but now I have a matrix which is unscaled. Is there a way to convert the matrix indices into the x and y coordinates that are compatible with Proj4 projected coordinates that are also in the same Albers projection? And is there a way to scale the elevation data too? I only have values between 0 and 255... hmm

The elevation file looks like this:

> gdalinfo uk.tif 
Driver: GTiff/GeoTIFF
Files: uk_elevation.tif
Size is 7714, 13698
Coordinate System is:
PROJCS["unnamed",
    GEOGCS["WGS 84",
        DATUM["unknown",
            SPHEROID["WGS84",6378137,298.257223563]],
        PRIMEM["Greenwich",0],
        UNIT["degree",0.0174532925199433]],
    PROJECTION["Albers_Conic_Equal_Area"],
    PARAMETER["standard_parallel_1",51.29427447728234],
    PARAMETER["standard_parallel_2",58.02853263411481],
    PARAMETER["latitude_of_center",0],
    PARAMETER["longitude_of_center",-4.482421875],
    PARAMETER["false_easting",0],
    PARAMETER["false_northing",0],
    UNIT["metre",1,
        AUTHORITY["EPSG","9001"]]]
Origin = (-260204.431288259220310,6254165.336497165262699)
Pixel Size = (90.011859131968379,-90.011859131968379)
Metadata:
  AREA_OR_POINT=Area
Image Structure Metadata:
  INTERLEAVE=BAND
Corner Coordinates:
Upper Left  ( -260204.431, 6254165.336) (  9d15' 7.20"W, 60d52'11.04"N)
Lower Left  ( -260204.431, 5021182.890) (  8d 5'36.26"W, 49d48'51.47"N)
Upper Right (  434147.050, 6254165.336) (  3d27'14.14"E, 60d43'41.74"N)
Lower Right (  434147.050, 5021182.890) (  1d31'58.96"E, 49d42'25.89"N)
Center      (   86971.309, 5637674.113) (  3d 6'25.92"W, 55d24'10.38"N)
Band 1 Block=7714x1 Type=Byte, ColorInterp=Gray
  NoData Value=255

If I want to access data, I can use this function:

upper_left = ( -260204.431, 6254165.336)
pixel_size = 90.011859131968379

get_elevation(elevation_data, x, y) = elevation_data[Int(round((x - upper_left[1])/pixel_size)), Int(round(-(y - upper_left[2])/pixel_size))]

but these x & y values are completely different to what I get with Proj4... (Perhaps I should be posting this in Proj4's issues instead.)

Sorry if this is a silly question but I'm unfamiliar with geodata :(

Thanks in advance!

In particular, for

• src/base/display.jl (test/test_display.jl)
• src/ogr/featurelayer.jl (test/test_featurelayer.jl)
• src/ogr/geometry.jl (test/test_geometry.jl)
• src/raster/rasterio.jl (test/test_rasterio.jl)
• src/spatialref.jl (test/test_spatialref.jl) # to be added to test/runtests.jl

Importing a raster (tiff) to an array using read() gives an array that is 90 degrees rotated from what image magic would import.

I guess this would be something a wrapper package would deal with, but is this the intended behaviour?

on:
Reproject a Geometry: Error During Test Got an exception of type GDAL.GDALError outside of a @test GDALError (Failure, code 4): Unable to open EPSG support file gcs.csv. Try setting the GDAL_DATA environment variable to point to the directory containing EPSG csv files.
(source)
So this one isn't related to JuliaGeo/GDAL.jl#42, as the x64 build works over there.

I was trying to work through your tutorial, and the way the install commands are written with GDAL first, ArchGDAL won't install.

Not sure if this is something that's easily fixed, just wanted to highlight it.

julia> Pkg.add("ArchGDAL")
 Resolving package versions...
ERROR: Unsatisfiable requirements detected for package GDAL [add2ef01]:
 GDAL [add2ef01] log:
 ├─possible versions are: [0.1.0-0.1.2, 0.2.0, 1.0.0-1.0.1] or uninstalled
 ├─restricted to versions 1.0.1 by an explicit requirement, leaving only versions 1.0.1
 └─restricted by compatibility requirements with ArchGDAL [c9ce4bd3] to versions: 0.2.0 — no versions left
   └─ArchGDAL [c9ce4bd3] log:
     ├─possible versions are: [0.1.0, 0.2.0-0.2.1] or uninstalled
     └─restricted to versions * by an explicit requirement, leaving only versions [0.1.0, 0.2.0-0.2.1]
Stacktrace:
 [1] #propagate_constraints!#61(::Bool, ::typeof(Pkg.GraphType.propagate_constraints!), ::Pkg.GraphType.Graph, ::Set{Int64}) at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.2/Pkg/src/GraphType.jl:1007
 [2] propagate_constraints! at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.2/Pkg/src/GraphType.jl:948 [inlined]
 [3] #simplify_graph!#121(::Bool, ::typeof(Pkg.GraphType.simplify_graph!), ::Pkg.GraphType.Graph, ::Set{Int64}) at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.2/Pkg/src/GraphType.jl:1462
 [4] simplify_graph! at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.2/Pkg/src/GraphType.jl:1462 [inlined]
 [5] resolve_versions!(::Pkg.Types.Context, ::Array{Pkg.Types.PackageSpec,1}) at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.2/Pkg/src/Operations.jl:317
 [6] #add#100(::Bool, ::typeof(Pkg.Operations.add), ::Pkg.Types.Context, ::Array{Pkg.Types.PackageSpec,1}, ::Array{Base.UUID,1}) at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.2/Pkg/src/Operations.jl:962
 [7] #add at ./none:0 [inlined]
 [8] #add#25(::Bool, ::Base.Iterators.Pairs{Union{},Union{},Tuple{},NamedTuple{(),Tuple{}}}, ::typeof(Pkg.API.add), ::Pkg.Types.Context, ::Array{Pkg.Types.PackageSpec,1}) at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.2/Pkg/src/API.jl:99
 [9] add at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.2/Pkg/src/API.jl:69 [inlined]
 [10] #add#24 at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.2/Pkg/src/API.jl:67 [inlined]
 [11] add at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.2/Pkg/src/API.jl:67 [inlined]
 [12] #add#21 at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.2/Pkg/src/API.jl:65 [inlined]
 [13] add at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.2/Pkg/src/API.jl:65 [inlined]
 [14] #add#20(::Base.Iterators.Pairs{Union{},Union{},Tuple{},NamedTuple{(),Tuple{}}}, ::typeof(Pkg.API.add), ::String) at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.2/Pkg/src/API.jl:64
 [15] add(::String) at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.2/Pkg/src/API.jl:64
 [16] top-level scope at REPL[40]:1

julia> Pkg.rm("GDAL")
  Updating `~/.julia/environments/v1.2/Project.toml`
  [add2ef01] - GDAL v1.0.1
  Updating `~/.julia/environments/v1.2/Manifest.toml`
  [fa961155] - CEnum v0.2.0
  [add2ef01] - GDAL v1.0.1

julia> Pkg.add("ArchGDAL")
 Resolving package versions...
 Installed ArchGDAL ──── v0.2.1
 Installed GDAL ──────── v0.2.0
 Installed DataStreams ─ v0.4.2
  Updating `~/.julia/environments/v1.2/Project.toml`
  [c9ce4bd3] + ArchGDAL v0.2.1
  Updating `~/.julia/environments/v1.2/Manifest.toml`
  [c9ce4bd3] + ArchGDAL v0.2.1
  [9a8bc11e] + DataStreams v0.4.2
  [add2ef01] + GDAL v0.2.0
  [cf35fbd7] + GeoInterface v0.4.1
  [3cdcf5f2] + RecipesBase v0.7.0
  [ea10d353] + WeakRefStrings v0.6.1
  Building GDAL → `~/.julia/packages/GDAL/vec6Y/deps/build.log`

prompted by #39

can follow the example in

• https://github.com/wkearn/RasterIO.jl/blob/master/doc/RasterioGuide.ipynb

and possibly others, e.g.

• https://www.geos.ed.ac.uk/~smudd/TopoTutorials/html/tutorial_raster_conversion.html
• http://invisibleroads.com/tutorials/gdal-raster-extract.html

I managed to install, build and test GDAL without errors. However Pkg.test("ArchGDAL") fails with the following error:

Test Summary:                 |
Force polygon to multipolygon | No tests
Method 1
Reproject a Geometry: Error During Test
  Got an exception of type GDAL.GDALError outside of a @test
  GDALError (Failure, code 6):
        Unable to load PROJ.4 library (libproj-9.dll), creation of OGRCoordinateTransformation failed.

Earlier during testing I got another error that gcs.csv couldn't be found, but I fixed that by setting the GDAL_DATA environment variable to C:\Users\niclas\.julia\v0.6\WinRPM\deps\usr\x86_64-w64-mingw32\sys-root\mingw\share. Not very obvious, thank goodness for search. :) But the library libproj-9.dll appears to be nowhere on my system. Do I need to do a manual install of GDAL?

Hi,
Thanks for the nice work with this package!

Just getting started and can't seem to fully understand the API.
I'm trying to do the equivalent of this RasterIO.jl example:

image = fill(UInt8(127), (150, 250))

raster = RasterIO.createraster("pyrasterio/example.tif",
                                500, # width
                                300, # height
                                1, # number of bands
                                UInt8, # DataType
                                "GTiff") # Drivername

RasterIO.update!(raster,
                 image, # image to "burn" into the raster
                 1, # update band 1
                 30:180, # along (window) xcoords 30 to 180
                 50:300) # along (window) ycoords 30 to 180

RasterIO.closeraster(raster)

From https://github.com/wkearn/RasterIO.jl/blob/master/doc/RasterioGuide.ipynb

Since RasterIO.jl is deprecated in favour is ArchGDAL, I'm trying to follow the new write API.

Sorry for opening an issue - I'd be happy to help with documentation when I get a better grasp of the API.

Thanks

I've tried to read a subset but with several bands at once from a VRT. The documentation says this can be done using ArchGDAL.read(dataset, indices, rows, cols)
But when I do so:

    ArchGDAL.registerdrivers() do
        ArchGDAL.read(path_vrt) do dataset
             arr = ArchGDAL.read(dataset, Int32[1,2,3,4], 1:100, 1:100)
        end
    end

all columns and rows (~12000x12000) will be loaded.
What have I done wrong?

I would really like for this package to be registered. What do you think that needs to be done for this? I've created the same issue for JuliaGeo/GDAL.jl#44 as this package depends heavily on it.

• #19 Finish tests
• #10 Move large test data
• ...?