I'm also with Chris on this. If we can find a package to handle the dirty bits and wrap it with the correct interfaces to get us through, then move to a "better" implementation as we go, I think we should. Does anyone have any suggestions for a library that is nicely licensed that has this functionality?
Joe On Dec 4, 2012, at 5:14 PM, Adam Estrada <[email protected]> wrote: > 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 >>> >> >>
