I will agree with Mattmann about the license compatibility issues. As for GeoAPI, why has nothing been done with that project in so long? Don't want to hijack this thread but it seems like the projects could benefit each other nicely. Why is that not happening? For the time-being I believe we should set the stage for a "next generation" geospatial framework in SIS.
On Tue, Dec 4, 2012 at 12:41 AM, Mattmann, Chris A (388J) < [email protected]> wrote: > Hi Martin, > > If it's not too much trouble, 2, then 2b seem to be the best choices IMHO. > We take something with a friendly academic, permissive > license now, compatible with Apache SIS and ALv2, and then as we need, we > provide our own implementation as we evolve. Seems > small, and incremental enough for consensus :) > > Cheers, > Chris > > On Dec 1, 2012, at 8:33 AM, Martin Desruisseaux wrote: > > > Hello all > > > > There is a technical problem for which the current situation is not > satisfying, and for which I have trouble to find the best action... > > > > We needs a "Unit of measurement" framework. Because this is important to > so many domains (even the JDK has a TimeUnit class), we made a > standardisation attempts 12 years ago (JSR-108), which failed [1]. We made > a second attempt (JSR-275), which failed again [2]. GeoAPI - and > consequently current Apache SIS - currently have a dependency toward this > failed JSR-275 attempt. This obviously brings two problems: > > > > 1) JSR-275 namespace (javax.measure.unit) is not supposed to exist. > > 2) JSR-275 bugs will never be fixed. > > > > After JSR-275 rejection, the main JSR-275 authors moved their API as > interfaces in the "org.unitsofmeasurement.unit" package under a BSD-like > license [3]. Those interfaces are implemented by the Eclipse UOMo project > among others [4], and his maintainer told me that they are gaining > acceptance in the Eclipse community. > > > > However the maintainer told me that a sensor-related JSR have good > chances to start in 2013, could include units of measurement, and that they > want to go fast. This would bring yet another package name in the mix (or > maybe they would reuse the javax.measure.unit one - we don't know). So the > alternatives at this time are: > > > > 1) Keep JSR-275 for now, wait and see. > > 2) Adopt org.unitsofmeasurement interfaces, then: > > 2a) Adopt UOMo implementation > > 2b) Provide our own implementation > > 3) Define our own interfaces > > > > On 1), we are already waiting for two years and I still have trouble to > figure out if yes or no a third JSR attempt will happen... On 2), the > problem is that the decision does not involve only SIS, but also GeoAPI, > and as a standardisation attempt we are better to be as sure as possible > that we will not change again if, for example, Oracle starts a new JSR. On > 2a), I have not tried this UOMo implementation. But I had some trouble with > the JSR-275 implementation. Many statics methods in the Units class that I > just committed today [5] are workarounds for JSR-275 bugs or limitations. > Some methods like "valueOfEPSG" (scroll down until the bottom of the page) > are very specific to the geospatial domain and unlikely to be supported > natively by an external unit framework. The NetCDF unit names > ("degrees_east", "degrees_north") are also quite specific, so maybe having > our own implementation is not completely non-sense. On 2b) actually we > already have an implementation from old JSR-108 days, so it could be easily > refactored to "org.unitsofmeasurement" interfaces. On 3), it would need to > be done in GeoAPI I don't think it would have a lot of support... > > > > The GeoAPI working group is not active at this time, so I suspect that > we may have more discussion on this SIS list, then brings a proposal to the > GeoAPI list. This proposal (about interfaces only - the implementation > decision stay on the SIS side only) would need to be written as a change > request and posted before December 27 if we want it to be considered at the > next OGC meeting. > > > > Any though, opinion, proposal would be highly appreciated... > > > > Regards, > > > > Martin > > > > > > [1] http://jcp.org/en/jsr/detail?id=108 > > [2] http://jcp.org/en/jsr/detail?id=275 > > [3] http://www.unitsofmeasurement.org/ > > [4] http://www.eclipse.org/uomo/ > > [5] > https://builds.apache.org/job/sis-jdk7/site/apidocs/org/apache/sis/measure/Units.html > > > >
