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


Help: OASIS Mailing Lists Help | MarkMail Help

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

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 
>Pages Newslink about an 
>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
Video lesson:    http://www.youtube.com/watch?v=PrNjJCh7Ppg&fmt=18
Video overview:  http://www.youtube.com/watch?v=VTiodiij6gE&fmt=18
G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
Male Cancer Awareness Nov'07  http://www.CraneSoftwrights.com/m/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal

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