See upstream issue at yeesian/ArchGDAL.jl#177

Now it gives the following error

MethodError: Cannot `convert` an object of type Type{Missing} to an object of type ArchGDAL.OGRFieldType

This issue is used to trigger TagBot; feel free to unsubscribe.

If you haven't already, you should update your TagBot.yml to include issue comment triggers.
Please see this post on Discourse for instructions and more details.

If you'd like for me to do this for you, comment TagBot fix on this issue.
I'll open a PR within a few hours, please be patient!

if add a new layer to the existing geopackage, it will replace the current geopackage

ERROR: GDALError (CE_Failure, code 10):
        Pointer 'hDS' is NULL in 'GDALDatasetH'.

actually means that the file is not found, but we could be nicer about this.

Hi @evetion:
I have run the example commands in the README file from a Jupyter notebook that accepts Julia.
When I run:
df = GDF.read("test_points.shp")
I obtain a similar table to the one in the example but with the following differences:
The geometry is in the first column and the points do not appear explicitly but only says:
Geometry: wkbPoint

What can be the cause of the difference ?

The other questions is if I can use GeoDataFrames to merge a shapefile with a data frame when both
objects have a column in common. I want to preserve all the shapefile geometric structure.

Thank you very much,
Martín

Wondering if it might make it easier on the user to have some of the arguments to write be keywords?

Then the user wouldn't have to specify every argument if they only want to change, e.g., crs or driver.

As reported by https://discourse.julialang.org/t/what-is-the-state-of-rasterization-and-rasterstats-in-julia/72366/25.

Should probably be nothing instead of WGS 84 as it is now.

I noticed that this package re-exports isempty from ArchGDAL. In ArchGDAL it is not exported.

It is unfortunate however to export something that is also exported from Base, leading to

WARNING: both GeoDataFrames and Base export "isempty"; uses of it in module Main must be qualified
ERROR: UndefVarError: isempty not defined

Or document them. As reported by https://discourse.julialang.org/t/what-is-the-state-of-rasterization-and-rasterstats-in-julia/72366/25.

Looks like the GeoDataFrames.write function can probably be simplified a lot now that yeesian/ArchGDAL.jl#315 is merged. (Still needs to be tagged)

https://github.com/evetion/GeoDataFrames.jl/blob/v0.3.0/src/io.jl#L59-L155

The title says all, basically. You can use the identifydriver function to discover the driver for a file extension and then use that, instead of curating your own list.

This error gets thrown when I try to use GeoDataFrames.write() with the .gpkg or .shp file formats. I am certain that it is not a problem with the data, as this error occurs even when trying to write a dataframe that has just been read unmodified from a working .gpkg file. Function was previously working, but has broken after I tried to install the Turf.jl package

now that DataFrames supports it

This is an upstream problem in ArchGDAL but I'm opening it here (since this package seems to be aimed at making ArchGDAL's weird pointer-based types friendlier to work with). Here's the problem in a nutshell:

julia> gdf = GDF.read("doesnt_exist.gpkg")
ERROR: GDALError (CE_Failure, code 10):
        Pointer 'hDS' is NULL in 'GDALDatasetH'.

Could we have read() check if a file exists before passing it on to ArchGDAL, and throw a friendlier error message if it doesn't exist?

Is there any interest in an extension package to support plotting GeoDataFrames with GeoMakie?

Not being able to nicely plot GeoDataFrames directly with GeoMakie has been a small pain point of mine.

Below is a tentative working example implementation.
It was written quickly for a specific purpose but could be generalised.

import ArchGDAL as AG
import Dataframes, GeoDataFrames
using GeoMakie

function plot_map(gdf::DataFrame; geom_col=:geometry)
    f = Figure(; size=(600, 900))
    ga = GeoAxis(
        f[1,1];
        dest="+proj=latlong +datum=WGS84",
        xlabel="Longitude",
        ylabel="Latitude",
        xticklabelpad=15,
        yticklabelpad=40,
        xticklabelsize=10,
        yticklabelsize=10,
        aspect=AxisAspect(0.75)
    )

    plottable = GeoMakie.geo2basic(AG.forceto.(gdf[!, geom_col], AG.wkbPolygon))
    poly!(ga, plottable)

    # Need to auto-set limits explicitly, otherwise tick labels don't appear properly (?)
    autolimits!(ga)
    xlims!(ga)
    ylims!(ga)

    display(f)

    return f
end

Right now GeoDataFrames.read by default returns the first layer. Since many datasets have only one layer, that is very convenient. But perhaps we should not automatically do this if there are more than 1 layers? Otherwise it is very easy for users to miss the fact that they are only seeing part of the data.

https://github.com/yeesian/ArchGDAL.jl

Hi I tried to write a .geojson file from a GeoDataFrame and I get a GDAL error.

import GeoDataFrames as GDF
using DataFrames

coords = zip(rand(10), rand(10))
df = DataFrame(geometry=createpoint.(coords), name="test");

GDF.write("test_points.geojson", df)

yields the following error message when trying to write the geojson

ERROR: GDALError (CE_Failure, code 10):
        Pointer 'hDefn' is NULL in 'OGR_F_Create'.

These are the versions I have

⌅ [c9ce4bd3] ArchGDAL v0.9.3
⌃ [62cb38b5] GeoDataFrames v0.3.1

Reading point data from columns in a csv file is a very common task, and it would be nice to have a shortcut here, something like
GeoDataFrames.open(fn, crs="espg:3006", geom_columns=(...))

Since GeoDataFrames.read calls ArchGDAL.read, it'd be nice to forward, or otherwise make accesible, the keyword arguments to that function: https://yeesian.com/ArchGDAL.jl/dev/reference/#ArchGDAL.read-Tuple{AbstractString}.

#sdsl23

A colleague trying the package was most stuck by the column name having to be specified manually (e.g. :Shape)

If we have the names available in gdal it would be good to propagate them to dataframe metadata so we can retrieve them automatically.

When exporting a GeoDataFrame that has 3D point geometries using GeoDataFrame.write(), the exported 3D geometries get flattened to 2D. This appears to be a geometry typing issue.

It can be corrected by altering the "lookup_type" dictionary in io.jl to associate PointTraits with wkbPoint25D geometries instead of wkbPoint geometries like the following:

const lookup_type = Dict{DataType,AG.OGRwkbGeometryType}(
    AG.GeoInterface.PointTrait => AG.wkbPoint25D,
    AG.GeoInterface.MultiPointTrait => AG.wkbMultiPoint,
    AG.GeoInterface.LineStringTrait => AG.wkbLineString,
    AG.GeoInterface.LinearRingTrait => AG.wkbMultiLineString,
    AG.GeoInterface.MultiLineStringTrait => AG.wkbMultiLineString,
    AG.GeoInterface.PolygonTrait => AG.wkbPolygon,
    AG.GeoInterface.MultiPolygonTrait => AG.wkbMultiPolygon,
)

There's probably a more elegant solution using GeoInterface, but this hack is useful if you only ever work in 3D points.