Hey Joe, I think that #2 below (org.unitsofmeasurement) would be a good package for this.
Thoughts? Cheers, Chris On 12/4/12 4:00 PM, "Joe White" <[email protected]> wrote: >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/measu >>>re/Units.html >>>> >>> >>> >
