Submit as an OSGeo project?

[desruisseaux]

Do we want to submit those JNI bindings as an OSGeo project? If yes, what would be the steps for that?

[kbevers]

Becoming an OSGeo project is quite an elaborate process: https://www.osgeo.org/about/committees/incubation/incubation-process/. Currently it would be impossible. Becoming an OSGeo community project is probably possible but there is also some way to go for that to happen: https://wiki.osgeo.org/wiki/OSGeo_Community_Projects

[desruisseaux]

Community project is fine. Or alternatively is there a process or repository for extensions or plugins to an OSGeo project? Is it a question that could be asked on the PROJ mailing list?

[kbevers]

Formally I don't think it would be a problem to keep PROJ-JNI under the wings of the PROJ project. That would just be another product maintained by the project, similarly to PROJ-data. The main issue is whether the PROJ project is willing to take responsibility for this code or not. None of the current PROJ core committers are interested in (or able to) maintain Java code so a couple of committed volunteers taking on that job is definitely required. The fear is of course that we end up with more or less abandoned code as happened with the JNI bindings that was bundled in the PROJ repo.

Discussing this on the PROJ mailing list is a good start. At some point a formal RFC would have to be written detailing how PROJ-JNI would be handled by the project. But start by raising the topic and get a feel for the interest of the community.

[desruisseaux]

I can volunteer for maintaining the JNI-binding. I didn't before because the fact that it didn't implemented GeoAPI made it less usable to me, to the point that I was maintaining another binding of Proj.4. With this binding under PROJ wing I would delete the other binding, so my focus would be on the PROJ one only.

[kbevers]

That sounds good. Ideally we would have a couple of people involved with PROJ-JNI so that it isn't too dependant on you. Do you know anyone that would be interested in pitching in from time to time?

[desruisseaux]

It is a little bit hard to said. The very first JNI bindings were done by Andrea Antonello from Grass community, but it was many years ago. Even Rouault has already provided a patch for a bug in the C part; while he obviously has much other work to do, he may be able to provide at least some guidance. FilipGh has provided good patches for current bindings. I do not know at which extent those peoples who be interrested to help, but my hope is that with the visibility gained under PROJ wing more volunteers would appear.

[kbevers]

but my hope is that with the visibility gained under PROJ wing more volunteers would appear.

I agree with this last part. Hopefully it is possible to gain a bit of traction with more exposure. Let's see what the rest of the PROJ folks think about this.

[desruisseaux]

It seems that the only possible approach is OSGeo community project. Do we have a volunteer for doing a submission? I would stay around as a volunteer for development work.

[willcohen]

I'm interested in being helpful here as well however is useful, especially since the process of keeping proj4j up-to-date with upstream seems increasingly difficult given the rapid pace of change happening within PROJ itself. The major benefit to proj4j's approach is that it never needs native code and allows for much more flexibility, but now that proj requires the use of sqlite which isn't available as a pure java implementation, to stay current, proj4j would need to reimplement the entire database in a pure-java db type on top of also reimplementing all of proj's reworked internals. It seems that rather than requiring all of that work, a JNI approach might be a nice complementary effort that's a little less portable but much easier to keep current.

I do have one additional question, however, which might want to be solved before this gets submitted as a formal project under any umbrella: it seems increasingly common (and useful!) for jvm libraries embedding native code to include cross-platform compiled libraries inside (a la sqlite). The downside would be a larger jar, but the upside would be the ability for users to just include this as a dependency and not need anything beyond the JVM to do projections, which makes this dramatically more streamlined for users. Would a similar path be useful here? If size is a concern, there might be a way of splitting out the native library loader into a different dependency and keeping the overall bindings here, though I've never seen that done in practice. Having something released and available on Maven which embeds native PROJ would be a dramatic development!

[kbevers]

I'm interested in being helpful here as well however is useful

Any help is welcome! I'd be extremely happy if more people from the Java geospatial world would rally behind this library so it can gain some traction.

Would a similar path be useful here?

To me it sounds like a good approach. Mind you, I am not a Java expert in any way so my word doesn't carry much weight here. @desruisseaux probably have a better feeling for this. Regarding the size of the jar, I don't think that is going to be a problem. PROJ itself isn't that big, even including the dependencies (libtiff, sqlite). And compared to the ~1GB of grid files users are likely to install as well it is negligible.

[desruisseaux]

Hello @willcohen and thanks! Indeed help would be very welcome. We need a volunteer for all the "administrative" parts with OSGeo. If you can help in getting in touch with the right persons at OSGeo, setting up a project of the right category (it seems it would be a "community project") and transferring the GitHub repository, that would be very welcome! I can volunteer for maintenance of Java and C++ code, but would like the "project management" parts to be done by someone else. I don't know if OSGeo community projects have a chair, but if so and if you can volunteer for being that chair, that would be great!

About inclusion of native libraries in the JAR file, I do not have a strong opinion. I guess we would need to do more experiments. Current version already embeds native code, but only the JNI bindings (not the PROJ library itself) and only for the platform on which PROJ-JNI has been built.The difficulties that I see are:

• We need to provide binary for all platforms: Windows, MacOS, Linux, potentially with 32 bits versus 64 bits variants, ARM, etc. It may be the PROJ size multiplied by 4 or more.
• Embedding native library for all platforms can not be done on a single developer machine (as far as I know, unless creating many virtual machines). We may need to setup some process like Travis, for which I'm not familiar. We would need someone help for that part.
• Native libraries can not be executed directly from JAR files; they need to be copied as an ordinary file on the file system first. In the worst case, it may imply copying the whole PROJ library in a temporary file every time the java command is executed.

Some of above-cited problems can be mitigated: we can try to copy PROJ in a more permanent location than temporary files (but where?) We can avoid providing native library for all platforms and instead creates a separated JAR file for each platform. JavaFX does that, but it requires non-trivial Maven configuration if we want it to download the right JAR file automatically (JavaFX does that with a Maven plugin that they developed themselves).

A possible approach could be to migrate the project to OSGeo first, then create a few branches for experimenting different ways of linking to PROJ library.

[willcohen]

Great. Happy to get started on this. I'd like to take a little time first to get a little more familiar with the internals of the code base first. A first prerequisite would be double-checking source code headers, contributing guidelines, code of conduct, but also to make sure I can more easily answer the basic questions about how this specifically fits into the ecosystem versus competing efforts, to make the application as streamlined as possible.

[desruisseaux]

For the internal, I recommend to read the following document first. This is basically the same document as ISO 19111 standard, which was developed conjointly by OGC and ISO:

OGC Abstract Specification Topic 2: Referencing by coordinates

The huge improvement of PROJ 6 compared to PROJ 4 is its alignment on that OGC/ISO standard. PROJ 4 (and consequently Proj4J) have limitations inherited from initial PROJ design as a map projection library, not a generic "referencing by coordinates" library. I described some problems here. Those problems are fixed in PROJ 6, but requires major changes in the way of thinking the library. The above OGC/ISO standard can be seen as a blueprint describing what should be the library objects and their relationship. It is much more powerful than PROJ 4 model.

I suggest to forget PROJ 4 API. If looking at PROJ 6 C++ API, we can see a close to one-to-one mapping between PROJ C++ objects and ISO 19111 objects. Peoples familiar with ISO 19111 should understand PROJ C++ API easily. Likewise the same ISO 19111 objects have been translated to Java interfaces in the GeoAPI project. We can also see a close to one-to-one mapping between GeoAPI and PROJ 6 C++ API, which is a natural consequence of the fact that both APIs are derived from the same ISO standard. So again, peoples familiar with ISO 19111 should understand GeoAPI (and consequently this PROJ-JNI project) easily.

[willcohen]

Hi there, I've had a little more time to try using this as a prototype in a few projects and I think I have a better handle on the codebase.

In terms of getting this submitted, based off of their community projects page:

OSGeo Community Projects

• Be geospatial
  • Confirm by checking README or project description
  • project page on the osgeo website
  • We ask projects have some user documentation, for example an OSGeo Live quickstart
• Have a free license or an open source license.
  • The license must be OSI approved
  • We ask that the project team check the file headers and double check the license has been appropriately applied
• Welcome participation and new contributors
  • We look for a clear contribution policy
  • We ask that the project demonstrate collaboration, perhaps with a history of bug report or pull requests
  • Projects are required to have a code of conduct

Once all these boxes are checked, I think it's as simple as me sending an email to the incubation list, and there's lots of examples from previous months.

If you'd all like, I can go ahead and start a pull request over the next few days for a CONTRIBUTIONS.md and code of conduct (many projects pick the Contributor Covenant, does that one look good to you both?). After that I can double check the headers and I think that's that!

Only last question is if you all want to pick another name or stick with org.kortforsynigen/proj as the project coordinates! The most ideal candidate for maven central, I suppose, would be org.proj/proj, but I'm not sure who controls that domain (whether that's the PROJ project or OSGeo itself).

[kbevers]

I think it's as simple as me sending an email to the incubation list,

Yep, it's as easy as that!

If you'd all like, I can go ahead and start a pull request over the next few days for a CONTRIBUTIONS.md and code of conduct (many projects pick the Contributor Covenant, does that one look good to you both?)

No objection from me, your effort is much appreciated! The Contributor Covenant is fine and is usually the recommended CoC by OSGeo. The PROJ project uses it as well.

Only last question is if you all want to pick another name or stick with org.kortforsynigen/proj as the project coordinates! The most ideal candidate for maven central, I suppose, would be org.proj/proj, but I'm not sure who controls that domain (whether that's the PROJ project or OSGeo itself).

Another name would be ideal. That's one of the reasons behind becomming an OSGeo community project, as that would allow os to use org.osgeo/proj, although org.proj/proj would be fine as well I think. proj.org is owned by OSGeo and managed by the OSGeo system administrators team, but the PROJ project of course can use it however it likes.