OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

# ubl-tsc message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [ubl-tsc] RE: GoToMeeting Invitation - Go to meeting for todays UBL Telecon

• From: "G. Ken Holman" <gkholman@CraneSoftwrights.com>
• To: Hendry <ahendry@pacbell.net>,Andrew Schoka <AMSchoka@comcast.net>
• Date: Sat, 12 Sep 2009 09:03:36 -0700

```At 2009-09-11 21:45 -0700, Hendry wrote:
>Following on to the last conversation we had regarding location
>coordinates and altitude I thought the last article in this
><http://xml.coverpages.org/draft-ietf-geopriv-geo-uri-02.txt>IETF
>Draft for geographic locations was interesting since it includes
>altitude.  The modeling concepts might be useful.

Reviewing that specification I note that signed decimal values for
latitude and longitude are used rather than degrees/minutes/direction
used in UBL (I was not involved in the original design so I've
included Tim in the discussion who was involved).  So I'm unsure it
can be regarded as a precedent we need to follow.  But it certainly
gives us direction (pun intended).

For terminology, I see that "altitude" is used rather than
"elevation", so I'll stop using "elevation" in my discussions,
assuming that "altitude" is more widely accepted for the term.

My first inkling was to model altitude as two components of value and
direction, so as to be consistent with the separation of direction
from value in latitude and longitude.  But then I realized the
separation is probably there because it is a multi-component value
rather than a singleton value.  And wouldn't it be confusing if you
had -37 degrees and +15 minutes in a single direction?  So the values
(I'm assuming) are meant to be positive and the direction code is definitive.

Altitude is certainly a singleton value as a measurement, and
measurement is a signed value with a unit of measure, so users would
have the flexibility of specifying feet, meters, or whatever they want.

So, I think what UBL 2.1 needs in cac:LocationCoordinate is simply
the optional cbc:AltitudeMeasure.

Can anyone think of an argument for an alternative approach?

. . . . . . . . . . . . Ken

p.s. should this discussion have been posted to the TSC mail list
rather than an email chain?  Should the summary be posted by someone
to the TSC mail list?

--
Interested in these classes?  http://www.CraneSoftwrights.com/m/i/
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/m/
Training tools: Comprehensive interactive XSLT/XPath 1.0/2.0 video