GeoInterface.jl icon indicating copy to clipboard operation
GeoInterface.jl copied to clipboard

Add WellKnownGeometry as a package extension.

Open evetion opened this issue 2 years ago • 6 comments

So there's a fallback for asbinary and astext once WellKnownGeometry is loaded.

evetion avatar Jul 23 '23 19:07 evetion

Don't we get a circular dependency problem when GeoInterface depends on WellKnownGeometry and vice versa?

felixcremer avatar Jul 24 '23 07:07 felixcremer

Don't we get a circular dependency problem when GeoInterface depends on WellKnownGeometry and vice versa?

If we add it directly yes. Indirectly as package extensions as I've done now, I'm not sure (could explain the errors/warnings), but it does work. Would be neat to use this pattern for future package extensions, for example LibGEOS, providing a fallback things like intersection(geomA, geomB).

evetion avatar Jul 24 '23 12:07 evetion

The circular dependency sounds like a problem, what happens when you need to bump the version?

With the LibGEOS idea, you can already do LibGEOS.intersection(anygeom, anygeom) and it works on any GeoInterface compatible geometries.

I've been thinking it makes more sense to just align all the function names in LibGEOS and other packages to the names used here, rather than having a fallback like that here... Then users are explicitly choosing the backend.

rafaqz avatar Jul 25 '23 19:07 rafaqz

Well apart from circularity (we control both compats, so shouldn't be a big issue), this is about a design to handle (multiple) backends.

ArchGDAL, LibGEOS and WellKnownGeometry all could be the backend here, but implementing GeoInterface.asbinary(:Any) in a package is piracy and loading multiple packages at the same time will clash.

Instead of saying X is the blessed package by only implementing it there, I rather be explicit in GeoInterface, having all blessed fallbacks defined here. Package extensions seemed to fit the bill, but maybe not.

evetion avatar Jul 25 '23 20:07 evetion

Could we move this extension to live in WellKnownGeometry? That way we would get the same behaviour of loading this code when both GeoInterface and WellKnownText are specifically loaded, but without the circular dependency because WellKnownText depends on GeoInterface anyways. And we could do the same for the other backends, the only problem is, that we would get clashes, when we load two backends, but this is something that would also happen when we put the extensions here.

felixcremer avatar Jul 25 '23 20:07 felixcremer

Yeah isnt the circular thing a problem for CI? Like how can tests pass for one without the other when you bump compat?

rafaqz avatar Jul 25 '23 23:07 rafaqz