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: RE: [ubl-tsc] FW: [ubl-psc] Status of issues raised in November 2010


Hi Andrew,

I did not asserted thet GPS Area circular, it was just a question I put to
myself, but now I have a more clear idea.

First I provide a good definition for understanding GPS measures and how
they are used as locations or other uses on GIS or other applications.

"GIS (Geographic Information Systems) is tool to display and analyze
information geographically. GPS (Global Positioning Systems) is a
technology that uses satellites to give one its position on the Earth with
the aid of a GPS device or unit. GPS can be incorporated into GIS by using
a GPS device to collect points, lines, or polygons, which can be imported
into a GIS application for future analysis and interpretation."

So I note GPS instruments can just provide single location (I verified
this with an expert), then lines and polygons are used as a collection of
points to describe something relevant for a GIS system.

Cities are usually indicated with their centre (location), but a location
could be even more precise (e.g. a building).

Lines are used for distances.

Polygons are usually used to associate other information (e.g. population
density), but "Area" I think is a better term.

The circular area is more related to the precision of a GPS that could be
some meters.

Finally I would see something like this for an Area:

    AreaCoordinate   0..1      (new ABIE)
    - AreaName   0..1
    - AreaDescription  0..1
    - LocationCoordinate  0..n     (ASBIE)


Cheers,

Roberto


> Roberto,
>
> Thanks for your comment. The original thought was that the area could be
> some kind of polygon so maybe GPS Area might not work so well since it
> might
> imply a circular region with a center point and radius as BBIEs. Maybe
> that
> is what a GPS Area is, can you get us a definition from a GPS source?
>
> Regards,
>
> Andy
>
>
>
>
>
>   _____
>
> From: Roberto Cisternino [mailto:roberto@javest.com]
> Sent: Monday, February 14, 2011 2:10 PM
> To: Andrew Schoka
> Cc: ubl-tsc@lists.oasis-open.org; 'Audun Vennesland'; 'Tim McGrath';
> michael.onder@dot.gov; 'Jan Tore Pedersen'; 'Veile, Alan';
> ken.holman@documentengineeringservices.com
> Subject: Re: [ubl-tsc] FW: [ubl-psc] Status of issues raised in November
> 2010
>
>
>
> Hello Andrew and TSC,
>
> I agree we should avoid changing the meaning of information items.
>
> About Locations expressed as a polygon I found that the "Google Earth"
> tool has a similar concept but it is not strictly a way to express a
> location, instead seems to be just a tool to highlight an area of
> interest.
>
> According to the GPS world there is an alternate location called "GPS
> Area".
>
> So "GPS Area" can be an alternate name for the new LocationRegion ABIE.
>
> At this point I ask you if circular areas have to be considered as well
> (this question is for who has raised the original issue)
>
> Cheers,
>
> Roberto
>
>> TSCers,
>>
>> Most recently Audun raised this as an update that didn't make it into
>> prd01.
>> Now Ken has offered a different option from just changing the
>> cardinality
>> of
>> LocationCoordinate to 0..n, He is asking for the opinion of others
>> regarding
>> the two options. Our last discussion on this concluded that changing the
>> cardinality would be sufficient but we hadn't considered this other
>> option.
>> Would others care to comment?
>>
>> Regards,
>>
>> Andy
>>
>>   _____
>>
>> From: G. Ken Holman [mailto:gkholman@CraneSoftwrights.com]
>> Sent: Monday, February 14, 2011 11:11 AM
>> To: 'ubl-psc@lists.oasis-open.org'
>> Subject: Re: [ubl-psc] Status of issues raised in November 2010
>>
>>
>>
>> At 2011-02-14 16:41 +0100, Arianna Brutti wrote:
>>>Hi Ken,
>>>
>>>--> about item (2), currently we have:
>>>
>>>ASBIE from Location to LocationCoordinate cardinality 0..1
>>>
>>>and LocationCoordinate is as follows:
>>>
>>>CoordinateSystemCode                  0..1
>>>LatitudeDegreesMeasure                 0..1
>>>LatitudeMinutesMeasure                  0..1
>>>LatitudeDirectionCode                     0..1
>>>LongitudeDegreesMeasure              0..1
>>>LongitudeMinutesMeasure               0..1
>>>LongitudeDirectionCode                  0..1
>>>AltitudeMeasure                              0..1
>>>
>>>Please, let me know if the final decision was to update the
>>> cardinalities.
>>
>> The decision is up to PSC, not to me.  Someone identified the need to
>> express an address as an arbitrary area and could not do so using a
>> single location coordinate.  I am not questioning the definition of a
>> single location coordinate, I'm questioning its use in the address
>> and other locations in the model.
>>
>> In my argument I presented two possible ways of doing this:  simply
>> changing the cardinality to "0..n" or by introducing a new ABIE for a
>> LocationRegion (or LocationArea?) that represents a different
>> semantic (area instead of point).  Then LocationCoordinate stays as
>> "0..1" in address and the new LocationRegion is added to address as
>> "0..1".  The other LocationCoordinate uses might also be other
>> candidates for adding a LocationRegion.  Then the definition of
>> LocationRegion has LocationCoordinate with "0..n" so that one then
>> describes the region as a set of points.
>>
>> But it is up to PSC to decide to change LocationCoordinate or
>> introduce LocationRegion.  It is not up to me.
>>
>> Looking at the LocationCoordinate ABIE here:
>>
>>
> http://docs.oasis-open.org/ubl/prd1-UBL-2.1/mod/summary/reports/UBL-AllDocum
>> ents-2.1.html#Table_LocationCoordinate.Details
>>
>> ... I see by the carets below the UBL name that there are three
>> ASBIEs that reference this ABIE:
>>
>>
> http://docs.oasis-open.org/ubl/prd1-UBL-2.1/mod/summary/reports/UBL-AllDocum
>> ents-2.1.html#t-CommonLibrary-41
>>
> http://docs.oasis-open.org/ubl/prd1-UBL-2.1/mod/summary/reports/UBL-AllDocum
>> ents-2.1.html#t-CommonLibrary-1083
>>
> http://docs.oasis-open.org/ubl/prd1-UBL-2.1/mod/summary/reports/UBL-AllDocum
>> ents-2.1.html#t-CommonLibrary-1689
>>
>> By clicking on the caret below the row number at the left, these are
>> the ABIEs where we would consider adding the new LocationRegion if we
>> go that way; Address, Location and SubsidiaryLocation:
>>
>>
> http://docs.oasis-open.org/ubl/prd1-UBL-2.1/mod/summary/reports/UBL-AllDocum
>> ents-2.1.html#Table_Address.Details
>>
> http://docs.oasis-open.org/ubl/prd1-UBL-2.1/mod/summary/reports/UBL-AllDocum
>> ents-2.1.html#Table_Location.Details
>>
> http://docs.oasis-open.org/ubl/prd1-UBL-2.1/mod/summary/reports/UBL-AllDocum
>> ents-2.1.html#Table_SubsidiaryLocation.Details
>>
>> It is my opinion that we add LocationRegion rather than increasing
>> the cardinality of LocationCoordinate because the two concepts are
>> different, but they only need to be made different if this makes
>> business sense.  No need making it unnecessarily complex if it is
>> sufficient to simply increase the cardinality of
>> LocationCoordinate.  You know I have a bad habit of making things
>> more complex than necessary when I don't understand the business
>> requirement.
>>
>> I hope TSC will have an opinion about this, and so I will post to TSC
>> a link to this discussion today.  I would think that in
>> transportation this question of locations and regions is important.
>>
>>>--> About point (3): could you provide me a list of "bad" descriptions?
>>
>> Yes, I will.  I was unsure if this was as important to PSC as it is
>> to me.  I would like to see all of the descriptions use only ASCII
>> characters (Unicode characters from "~" and below).  This will help
>> anyone who is working with the spreadsheets and schemas.
>>
>> This report will be included in my SGTG analysis of the next export
>> from eDoCreator.  If I get the time before the calls this week, I
>> will try to run the report on PRD1.
>>
>> Oh, I failed to mention that prohibiting "--" in definitions will
>> also be helpful so that downstream XML processing tools don't have to
>> change the definition when putting the definition into an XML comment.
>>
>>>--> About point (4) I agree with you. During the 2nd public review,
>>>we could make a list of tautological definitions and update them.
>>
>> I'm glad both PSC and TSC will take on this task.  I think it is
>> incredibly important in order to convey the meaning of what PSC/TSC
>> has meant for each of the constructs.  This will reduce the number of
>> support questions sent to the TC or to UBL-Dev as more and more
>> people embrace UBL.
>>
>> Thank you, Arianna.
>>
>> . . . . . . . . . Ken
>>
>>
>> --
>> Contact us for world-wide XML consulting & instructor-led training
>> Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/o/
>> G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
>> Legal business disclaimers:  http://www.CraneSoftwrights.com/legal
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this mail list, you must leave the OASIS TC that
>> generates this mail.  Follow this link to all your TCs in OASIS at:
>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>>
>>   _____
>>
>> No virus found in this message.
>> Checked by AVG - www.avg.com
>> Version: 10.0.1204 / Virus Database: 1435/3441 - Release Date: 02/13/11
>>
>>
>
>
> --
> * JAVEST by Roberto Cisternino
> *
> * Document Engineering Services Ltd. - Alliance Member
> * UBL Italian Localization SubCommittee (ITLSC), co-Chair
> * UBL Online Community editorial board member (ubl.xml.org)
> * Italian UBL Advisor
>
>   Roberto Cisternino
>
>   mobile: +39 328 2148123
>   skype:  roberto.cisternino.ubl-itlsc
>
> [UBL Technical Committee]
>     http://www.oasis-open.org/committees/ubl
>
> [UBL Online Community]
>     http://ubl.xml.org
>
> [UBL International Conferences]
>     http://www.ublconference.org
>
> [UBL Italian Localization Subcommittee]
>     http://www.oasis-open.org/committees/ubl-itlsc
>
> [Iniziativa divulgativa UBL Italia]
>     http://www.ubl-italia.org
>
>   _____
>
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 10.0.1204 / Virus Database: 1435/3443 - Release Date: 02/14/11
>
>


-- 
* JAVEST by Roberto Cisternino
*
* Document Engineering Services Ltd. - Alliance Member
* UBL Italian Localization SubCommittee (ITLSC), co-Chair
* UBL Online Community editorial board member (ubl.xml.org)
* Italian UBL Advisor

  Roberto Cisternino

  mobile: +39 328 2148123
  skype:  roberto.cisternino.ubl-itlsc

[UBL Technical Committee]
    http://www.oasis-open.org/committees/ubl

[UBL Online Community]
    http://ubl.xml.org

[UBL International Conferences]
    http://www.ublconference.org

[UBL Italian Localization Subcommittee]
    http://www.oasis-open.org/committees/ubl-itlsc

[Iniziativa divulgativa UBL Italia]
    http://www.ubl-italia.org




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