ICU4J Support

[Werner Keil]

Dear All,

After JSR 363 has gone Final, it seems best to keep all communication here since the EG strictly speaking no longer exists under the current JCP terms. And java.net is going away rather soon, so the old EG mailing list may be gone soon.

With unit systems like ISO 80000 not available without a commercial agreement and license based on ISO requirements, Unicode CLDR (https://github.com/unitsofmeasurement/uom-systems/tree/master/unicode) became a rather flexible replacement especially for non-SI units like BIT or BYTE.

ICU4J 58 recently added additional units to http://icu-project.org/apiref/icu4j/com/ibm/icu/util/MeasureUnit.html
Namely NORTH, WEST, EAST and SOUTH. with "coordinate" as a quantity.

How do you feel about those?
They are pretty much enum based and unless you combine them with another unit (e.g. "Go 400 miles North", which is probably the driving use case given Android also added full ICU support in 7.x) usually have no numeric relevance either.
So per definition in the Spec we would not see them as a quantity and you may not find a use case for getQuantity(200, NORTH) by ifself either unless you combine it with something else, e.g. Length.

Please also discuss or add tickets to https://github.com/unitsofmeasurement/uom-systems/issues.

Thanks and Regards,
Werner

[Martin Desruisseaux]

Hello Werner

Le 24/10/16 à 10:29, Werner Keil a écrit :

> ICU4J 58 recently added additional units to
> http://icu-project.org/apiref/icu4j/com/ibm/icu/util/MeasureUnit.html
> Namely NORTH, WEST, EAST and SOUTH. with "coordinate" as a quantity.

I do not think that those directions should be part of a Unit of
Measurement package. The geospatial international standards (ISO/OGC)
consider units and directions as two separated properties.

Martin

[Jean-Marie Dautelle]

+1

--
You received this message because you are subscribed to the Google Groups "Units Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to units-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

It is not the strongest of the species that survives, nor the most intelligent. It is the one that is most adaptable to change. - Darwin's Origin of Species (digest)

[Werner Keil]

Martin/Jean-Marie,

Thanks for the quick reply. As there are other entries in ICU4J, especially MILLILITER or DECIMETER, we don't support for a good reason, we can also safely ignore them in the Unicode system.

I spoke to members of Eclipse Science WG (upcoming TLD) in a F2F like the one Jean-Marie and I participated in Toulouse a while ago.
Especially around potential compile-time safety for operations like divide() and multiply() of either Unit or Quantity implementations or both.

I shared some thoughts on increased support (primarily JUnit tests for the API based on earlier work at uom.org or Eclipse UOMo) on the Science WG mailing list. I may also mirror or forward this in our own list. Either in a new thread or one that exists on the subject.

I asked Linux/Apache organizers again about Apache Europe and it looks more like they have problems with their CMS and cloned entries of last year. I spoke at both Apache Big Data and "Core" last year so my speaker entry was duplicated in both, but it may only be an option to join Anatole as co-speaker on Tamaya it seems. Which I probably won't take the trouble, since it is quite hard to reach from Central or Eastern Europe compared to e.g. Budapest or Sofia (where I have 3-4 talks at Java2Days as invited speaker;-)

Luckily from Paris there are plenty of cheap direct flights, so Martin seems fine to reach Apache Big Data:-)

Regards,
Werner

[Werner Keil]

After some uncertainty about which proposals were accepted and which speakers got to the list by mistake, it turned out, my Monitoring/Health proposal was accepted by Apache Big Data Europe ;-)
And was scheduled Monday 3:30pm, so I'd be able to attend Martin's and also meet him there e.g. to discuss GeoAPI starting to use JSR 363.

My presentation is centered around PCP among other similar solutions (like Apache Sirona) http://sched.co/8m2w
So when I look at Java and Parfait, JSR 363 will certainly be mentioned, though only as a minor aspect or the way Parfait supports units of measurement.
That PCP does will be highlighted compared to some of its competitors;-)

Regards,
Werner