<div dir="ltr"><div dir="ltr">Okay I was able to configure wcohen with Project Author permission, please have a go at creating the project page. The instructions we have for "<a href="https://www.osgeo.org/community/getting-started-osgeo/add-service-provider/">adding a service provider</a>" are the best note for how to fill in content on the osgeo website (lots of tabs).</div><div dir="ltr"><br></div><div>Thanks for the background on the project, good stuff.</div><div dir="ltr"><div><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>--</div><div>Jody Garnett</div></div></div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 28 May 2021 at 17:26, Will Cohen <<a href="mailto:wwcohen@gmail.com">wwcohen@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hello and thanks for the reply!</div><div><br></div><div>My osgeo id is wcohen.</div><div><br></div><div>Re proj4j -- very much, I've made a few small contributions to it, and it serves the JVM community well. However, in the last few years, a few issues have come up with proj4j that make an alternative (and complementary) project make sense, from my perspective:</div><div><br></div><div>1. First, the changes to PROJ from version 5 and above (the pipeline operator, and so on) require a pretty fundamental change to how proj4j's object model is structured (<a href="https://github.com/locationtech/proj4j/issues/12" target="_blank">https://github.com/locationtech/proj4j/issues/12</a>). This would be a pretty heavy lift to rewrite entirely in Java, and has largely kept proj4j based on version 4. It is a goal of proj4j to stay purely written in Java, which would generally require that keeping up with upstream continue to be a full port to Java. <br></div><div>2. Related to the first point, the fact that PROJ has adopted SQLite means that the only way to use it on the JVM would be either to use sqlite-jdbc (which requires native bindings, since the pure Java implementation is no longer maintained), or to fully port the SQLite database to h2, derby, or hsqldb (<a href="https://github.com/locationtech/proj4j/issues/53" target="_blank">https://github.com/locationtech/proj4j/issues/53</a>), which do have pure Java implementations. Since proj4j is not interested in using sqlite-jdbc, and maintaining an accurate parallel database file is a significant maintenance burden, it seems like PROJ-JNI would provide a useful alternative to proj4j for users who don't mind jumping to some native code.</div><div><br></div><div>Most fundamentally, to be able to handle the full range of projections via shapefiles or other data sources that extend beyond what proj4j can handle, the only current option for JVM users is GeoTools. It seems logical to provide some level of project handling that's a little more lightweight for simpler use cases, so it seems reasonable to have a library that binds right to PROJ and piggybacks off of that project's hard work without reinventing all those particular wheels!</div><div><br></div><div>Work that's still a little to-be-determined is how best to simplify this process for the end user, and create .jars for PROJ-JNI that include enough native versions of PROJ (plus the grid files etc), that using PROJ-JNI should be as seamless as proj4j for the majority of platforms that support SQLite (and, by extension, modern versions of PROJ).</div><div><br></div><div>And finally, no logo yet, but we can work on that!<br></div><div><br></div><div>Will<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, May 28, 2021 at 8:03 PM Jody Garnett <<a href="mailto:jody.garnett@gmail.com" target="_blank">jody.garnett@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">Will:<div><br></div><div>Thanks for contacting osgeo, and the clear presentation of your project.</div><div><br></div><div>Let's see if we can work on the website page - what is your osgeo userid? And do you have a logo :)</div><div><br></div><div>Aside: Are you aware of proj4j ?<br clear="all"><div><div dir="ltr"><div dir="ltr"><div><div dir="ltr"><div>--</div><div>Jody Garnett</div></div></div></div></div></div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 27 May 2021 at 06:12, Will Cohen <<a href="mailto:wwcohen@gmail.com" target="_blank">wwcohen@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hello,<br><br>I'm writing to request that the incubation committee consider PROJ-JNI (<a href="https://github.com/Kortforsyningen/PROJ-JNI" target="_blank">https://github.com/Kortforsyningen/PROJ-JNI</a>) for inclusion as an OSGeo Community Project. This project's goal is to provide a JVM ecosystem set of native bindings to upstream PROJ, an increasingly important task given the increased development speed of PROJ in recent years, starting with the changes post PROJ 6. In particular, PROJ's shift to SQLite requires that JVM users of PROJ eventually interoperate with native libraries, making native bindings to PROJ itself a logical next step.<br><br>One very tangible benefit of inclusion, in addition to helping build community support for the project, would be the potential use of the org.osgeo/proj or org.proj/proj Maven coordinates as a home for project releases. The project has an initial 1.0 functional release tagged on GitHub, but artifacts haven’t yet been released to Maven Central given the placeholder group ID so far.<br><br>Please let me know if you have any questions!<br><br>Will<br><br>- [X] Be geospatial<br> - [X] Confirm by checking README or project description (<a href="https://github.com/Kortforsyningen/PROJ-JNI/blob/master/README.md" target="_blank">https://github.com/Kortforsyningen/PROJ-JNI/blob/master/README.md</a>)<br> - [ ] project page on the osgeo website (this we do not yet have)<br> - [x] We ask projects have some user documentation, for example an OSGeo Live quickstart (linked from the README)<br>- [X] Have a free license or an open source license. (MIT, <a href="https://github.com/Kortforsyningen/PROJ-JNI/blob/master/LICENSE" target="_blank">https://github.com/Kortforsyningen/PROJ-JNI/blob/master/LICENSE</a>)<br> - [X] The license must be OSI approved (MIT)<br> - [X] We ask that the project team check the file headers and double check the license has been appropriately applied (it appears on all code files)<br>- [X] Welcome participation and new contributors (certainly looking for contributors and participation, which is part of why we seek to be a community project!)<br> - [X] We look for a clear contribution policy (see README, we will work through github)<br> - [X] We ask that the project demonstrate collaboration, perhaps with a history of bug report or pull requests (github)<br> - [X] Projects are required to have a code of conduct (contributor covenant, <a href="https://github.com/Kortforsyningen/PROJ-JNI/blob/master/CODE_OF_CONDUCT.md" target="_blank">https://github.com/Kortforsyningen/PROJ-JNI/blob/master/CODE_OF_CONDUCT.md</a>)</div>
_______________________________________________<br>
Incubator mailing list<br>
<a href="mailto:Incubator@lists.osgeo.org" target="_blank">Incubator@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/incubator" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/incubator</a><br>
</blockquote></div>
</blockquote></div>
</blockquote></div>