How to incorporate proj 5.0 changes?

[willcohen]

What should the process be for starting to think about incorporating proj’s 5.0 overall API changes (in addition to the testing changes being addressed by #9)?

It seems like proj4j is going to eventually need to incorporate proj’s new pipeline and some port of the changed API’s functionality to be able to keep up with upstream’s changes, especially as projections start to be redefined with this new process. Is a good starting point to add time in as a fourth variable to projected coordinates and start implementing the various pipeline operations accordingly? Would it be better to make a new object like ProjCoordinate4D for this (replicating proj’s model of new things living in the “PJ_” api), or would it be better to add “t” into the existing ProjCoordinate and feather in that functionality as is?

[dr-jts]

In general, yes, it does seem like proj4J will have to track PROJ.4 at some point. This seems like an ideal thing for LocationTech to find funding for.

[dr-jts]

Does incorporating the pipeline pattern require adding 4D support?

[willcohen]

It does appear that pipeline is implemented separately for 2D, 3D, and 4D.

[dr-jts]

Being a fan of simplicity, my first inclination would be to simple add a t ordinate to the existing ProjCoordinate. Presence of a time component would be indicated by a non-null value. But would need to understand more about the use of time in the API to know if this is sufficient.

[willcohen]

Now that proj4 has stopped using source data files compatible with the existing epsg plain text file, does it make sense for proj4j to start generating/ingesting the upstream sql database instead? It seems like the simplest way to try to track those changes to existing projections (even before things like 4d coordinates and pipeline are implemented here), but would require adding a dependency like https://github.com/xerial/sqlite-jdbc. On the one hand, this might create potential problems for full cross-platform compatibility since proj4j would be dropping to native sqlite binaries now, but on the other hand, this is now a hard dependency for proj4 in general.

[dr-jts]

(This might be better opened as a separate issue BTW)

Now that proj4 has stopped using source data files compatible with the existing epsg plain text file, does it make sense for proj4j to start generating/ingesting the upstream sql database instead?

I have a strong personal dislike to the use of SQLite, since it is (a) complex and heavyweight and (b) native code. So -1 on adopting it from me. That said, I realize that this will make tracking PROJ harder.

I do wonder why SQLite has been deemed necessary for PROJ. Is it because that's what EPSG uses? To avoid the chore of writing some query/join code?