add coordtype

[rafaqz]

Closes #128

Currently on a GI.MultiPolygon this takes 4ns. Its not a compile time operation. We could put this in the type parameters of the wrapper geometries at construction so its instant.

A lot of packages will be able to set this absolutely to a single type, e.g. Shapefile.jl, GeoJSON.jl and LibGEOS.jl can return Float64.

[asinghvi17]

Should we remove the Point from here, so that the dispatch with parent(p) for Point feeds into these?

[rafaqz]

I think that will hit the fallback method in fallbacks.jl. It just get the X coord type

[asinghvi17]

should we also add some @test_inferred? Or is it too early for that?

[rafaqz]

Yes, good idea

[asinghvi17]

GeoInterface implementations:

We have recently added a coordtype::Type{<: Number} function to the GeoInterface API. This needs to be implemented in all the GeoInterface packages and made fast so other people can use it.

Packages to update

• yeesian/ArchGDAL.jl (always Float64)
• JuliaGeo/LibGEOS.jl (always Float64)
• JuliaGeo/GeoParquet.jl
• JuliaGeo/GeoArrow.jl
• JuliaGeo/GeoJSON.jl (always Float64)
• JuliaGeo/Shapefile.jl (can have f32 or f64)
• evetion/FlatGeobuf.jl
• evetion/WellKnownGeometry.jl (at least for well known binary, probably also for text if we parse to float64)
• JuliaGeo/GeometryBasics.jl (encoded in eltype)

The way you implement this is that you define the two-argument coordtype(trait, obj) function.
You should do this specifically for at least FeatureTrait, FeatureCollectionTrait (if such objects exist in the package) and AbstractGeometryTrait.

GeoInterface.coordtype(::GeoInterface.FeatureCollectionTrait, featurecollection::YourAbstractFeatureCollection) = ...
GeoInterface.coordtype(::GeoInterface.FeatureTrait, feature::YourAbstractFeature) = ...
GeoInterface.coordtype(::GeoInterface.AbstractGeometryTrait, geom::YourAbstractGeometrySupertype) = ...

Only implement the feature and feature collection trait methods if those are types in the repo. For example, WellKnownGeometry, LibGEOS and GeometryBasics have no feature collection or feature types.

Clone each repo and make the change, then make a PR. For some you may have to fork.

[evetion]

I'm fine with this, but might be good to give a concrete example of what this improves. Do we also want to give some hints using coordtype for let's say GI.coordinates? That's the most type unstable thing I can think of in here.

[rafaqz]

Yeah, we could use it for coordinates in some cases

(Answered the rest in the issue thread)

[asinghvi17]

https://gdal.org/en/stable/doxygen/classOGRPoint.html#a5170ea70ce7458059e4395f852fce687 indicates that ArchGDAL must also set this to Float64, so it's just Julia types that need to have the type statically encoded somehow.

[asinghvi17]

bump @evetion @visr - can we get this in? I do have quite a few uses for it in GeometryOps now...

[evetion]

bump @evetion @visr - can we get this in? I do have quite a few uses for it in GeometryOps now...

Let's get it in.

[rafaqz]

Is there anything required or can we just merge?

[asinghvi17]

Merged. Id like to wait for extent computation and then get a minor release out.