Provide best-in-class WKT -> Proj4 conversion routines about proj4j HOT 9 OPEN

I wrote a Coordinate Reference Systems library to parse CRS WKT 1 and 2. Recently added a CRS to PROJ / PROJ.4 parser as well.

Example to use with this library:

// String wkt = ...
CoordinateReferenceSystem crs = null;
CRS crsObject = CRSReader.read(wkt);
if (crsObject != null) {
    String params = ProjParser.paramsText(crsObject);
    if (params != null) {
        crs = CRSParser.getCRSFactory().createFromParameters(crsObject.getName(), params);
    }
}

from proj4j.

I think the use of native code in sqlite-jdbc is a main concern here, since proj4j is a pure java reimplementation of proj.

It does lead to a thought experiment -- if we're going to the trouble to embed native code for JDBC for this library, why don't we just build a native version of proj for as many platforms as possible, just like sqlite-jdbc, and embed that into a java library using JNI as a wrapper? On the other hand, if proj4j is the pure-java version of proj, we need to be reimplementing everything piece by piece, which might mean something like h2 or derby.

from proj4j.

Obviously GDAL does this somehow. But besides that I would love to identify a couple of reference resources that look like they can be used to do this in a principled way.

Potentially this is an good opportunity for GSoC project.

from proj4j.

It's my understanding that recent versions of GDAL now have a binary dependency on PROJ version 6. Which seems to answer the question of how GDAL does it...

This announcement describes some high level things about PROJ 6. There is an ISO spec and OGC spec that PROJ 6 implements. Of interest also, there is a sqlite database defining the projections. That database is installed with PROJ binaries.

from proj4j.

I don't know how much of an issue it is any more with caching, but the text file parsing that used to happen for constructing the lookup tables was quite slow. A SQLlite approach would be much faster, and allow us to keep up with the official database more easily.

from proj4j.

More discussion on this in #53. There are some concerns with sqlite and its not being pure java. On my own I've started trying out an approach to this but it's not nearly put together enough for a pull request -- it's fairly straightforward to copy the .sql files from upstream on some kind of version release cadence, and then have maven's build for proj4j just build its own version of the database first. From there, it seems like all of the SQL queries proj implements are located in one place, though modeling that OGC spec mentioned above would be a fair bit of work. It might make sense to wait until EPSG changes to model v10, though that seems to be on a delayed timeline.

from proj4j.

@willcohen Is this not sufficient? Or does it require a native sqlite installation (I couldn't tell from the README)?

https://github.com/xerial/sqlite-jdbc

The .jar file contains some native libraries:

from proj4j.

@willcohen very interesting

from proj4j.

When proj appears on the classpath, it looks like this project implements a JNI approach. For this reason, it may be that that library is better suited to handle this native case.

from proj4j.