search

ewestern / geos

This is a Haskell binding to Geos, the open-source geometry library
MIT License
13 stars 9 forks source link

Geography support #31

Open tysonzero opened 5 years ago

tysonzero commented 5 years ago

I noticed distance is documented to not support geographic coordinate systems, so my followup question is what level of support this library has for geographic coordinate systems, and if any of the currently missing support is planned/desired.

ewestern commented 5 years ago

Interesting, I had thought that postgis mostly directly used geos under the hood, but it looks like they have a lot of their own logic for doing some of the geometrical operations on spheroids. At the moment, I think it's probably best to keep this limited to the functionality present in the underlying geos library. Unless I'm missing something, I don't thing geos exports a function that makes a distance calculation on a spheroid.

tysonzero commented 5 years ago

Hmm I assumed that Geos did provide this functionality. So does it basically just not handle SRID 4326 correctly?

ewestern commented 5 years ago

My understanding is that geos does not use SRID in any of its calculations. The reason it is included in the types is to maintain consistency for other applications, especially wrt serialization/deserialization.

tysonzero commented 5 years ago

Hmm ok interesting. So is the geography type which correctly handles 4326 a PostGIS specific thing based on how 4326 should be handled but isn't by Geos itself?

ewestern commented 5 years ago

A geography type is definitely a PostGIS-specific thing. That said, many of the functions exported by geos don't depend on a spheroid projection.

You can tell which functions existing in PostGIS use spheroid calculations (and will therefore have different results than the 2D calculations performed by GEOS) by looking at the types here: https://postgis.net/docs/manual-2.5/reference.html

For example ST_Union uses geos' union. As such, its argument type is geometry, and it automatically casts geography to geometry and performs the same calculation as geos.

ST_Distance, on the other hand, has specialized geography implementation, so that will use Postgis native code when called on a geography and GEOS code when called on a geometry.

Does that make sense?

tysonzero commented 5 years ago

Yeah that makes sense.

Although it looks like looking at the types is not a universal rule for things being SRID agnostic. For example it looks like ST_Union can be problematic when operating on Geographies in some cases.