Support Arc/Curve Geometries

[thorsten-reitz]

PostGIS supports several types of arc and curve geometries, which the JDBC driver apparently does not support. A simple fallback might be to invoke ST_CurveToLine if any circular string (Arc) or Curve is encountered.

[sebasbaumh]

You could try postgis-java-ng. I created this project to add handling for curve geometries and to simplify the existing API while incorporating new features of Java 8+.

@phillipross maybe you could also have a look 😄
I created a separate project instead of a fork as some of the changes regarding the class hierarchy are clearly breaking changes (but necessary to support curves and align with the PostGIS geometries).
And I already use it for myself, but it still needs to be published to Maven.
My main goal also was to clean up the implementation and make it more lightweight by dropping support for too old PostGIS or Java versions.

[phillipross]

Yes, very interesting @sebasbaumh

If you'd like to incorporate your changes into postgis-java, i'm sure we can work through compatibility issues. Semantic versioning, git branches, maven classifiers... there are many methods, tools, and utilities to help with compatibility 😉

[sebasbaumh]

@phillipross That would be really great 😄
So how do we go on here? Maybe you had a look at the project I created.

That is the current class hierarchy for the Geometry class:

Compared to the original one:

Where possible the Geometry classes use newer Java features like generics.

I also added some tests for geometries with curves and the other new geometry types.
They are plain JUnit tests that connect to a database if some VM arguments are set while running the test: testJdbcUrl, testJdbcUsername and testJdbcPassword.
If not set, they are just omitted (e.g. for automatic building without a database).

Basically the parser only runs on WKB/EWKB geometries, just as newer PostGIS versions return them to the client. It still supports big endian encoding, though I saw no PostGIS version return this - but it only writes little endian encoding, as PostGIS returns it. The DriverWrapper has been cleaned up to support that approach (basically using only the one instance former named LW/light weight).

After all as the class hierarchy changed to a large extend and as the geometry classes have been adapted, it could not be considered as a drop-in-replacement - but rather an evolution, which is the reason I called it -ng/Next Generation 😉

Basically I would see it like that: the original project is suitable for anyone stuck with old PostGIS/PostgreSQL versions/old Java versions and the new code allows more geometry types and easier handling if you are already on current versions of the environment.
So maybe this could be an additional module under the hood of postgis?
Or maybe change the old one to "legacy"?

What do you think? 😄

[phillipross]

This all sounds like promising work. I'll take a look at your project when I get a chance. Specifically I'll take a look at how drastically changed your code is, but whatever the case, massive changes are not necessarily problematic as long as we follow a few guiding principals. One of the most important of these is to document where compatibility has been broken, and in what versions. It's not a problem to break compatibility across major versions, and we maintain git branches corresponding to major/minor releases to make it possible to maintain multiple versions at the same time for the sake of compatibility.

And one thing I like to remind people is that the versions of the postgis-java project do NOT correspond to versions of postgis itself, just as the postgresql jdbc driver versions no longer correspond to the postgresql db version.

If jdbc driver wrapper changes break compatibility, and a new class hierarchy for geometries clashes heavily with the existing version, we simply need to identify those issues and make sure they're valuable changes and then merge them in with version increments. I'll have to look closer at your project though to see how you've changed things.

[phillipross]

@sebasbaumh I've created a gitter channel for postgis-java (https://gitter.im/postgis/postgis-java)

We can discuss things further there instead of filling this specific issue with discussion that is not particularly relevant to the issue.

[sebasbaumh]

@phillipross I pushed a version to Maven central, which is syncing right now:

<dependency>
	<groupId>io.github.sebasbaumh</groupId>
	<artifactId>postgis-java-ng</artifactId>
	<version>1.0.5</version>
</dependency>

So if anyone wants to test or use it, that is a quick start.
Just come back to me if you think, it could go under the hood of postgis - which I would appreciate.