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


Help: OASIS Mailing Lists Help | MarkMail Help

emergency message

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

Subject: Re: [emergency] Re: Circle and Polygon

Carl, if you don't mind I'd like to keep this on the issue list for  
the time being... as you point out, it has a political aspect, so I'm  
thinking it'll be especially important that we've made sure  
everyone's had a chance to weigh it carefully and that we've come  
away with a quorum decision.


- Art

On Jun 15, 2005, at 6/15/05 11:48 AM, Carl Reed wrote:

> Well stated.
> Thanks Art -
> I stand corrected. I also spoke with another implementor of CAP on the
> same issue of the CRS and withdraw any suggestions of not having  
> WGS as
> mandatory.
> Cheers
> Carl
>> Carl -
>> If the primary purpose of the circles and polygons in CAP was to
>> provide data for GIS display I'd have an easier time with your
>> suggestion.  But that's not really the case.
>> The primary purpose of the geospatial elements in CAP is to enable
>> location-aware receivers to identify those messages that are relevant
>> at their locations or at other locations of interest... or, depending
>> on network architecture, to enable routing mechanisms to make those
>> determinations on the end-receivers' behalf.  So we're talking about
>> devices that don't need to, and in many cases can't, support
>> conversions among multiple reference systems.
>> As you point out, the geospatial systems that need transformations
>> from WGS-84 to other CRSs are generally able to do them themselves,
>> as well as being able to take advantage of even more detailed GML
>> data that might be included as a resource.  But there's a larger
>> universe of devices out there, at both the input and output ends and
>> even in the middle, for which cost, weight, power, traffic volume and
>> other constraints suggest a simpler approach.
>> So... again, speaking as just one of the TC membership... I hesitate
>> to complicate the CAP format, which has been used successfully even
>> in Australia, unless we're shown an absolute technical need to  
>> do   so.
>>  Right now the issue seems to be one of local preferences, and    
>> we're
>> never going to be able to please everyone.
>> - Art
>> On Jun 15, 2005, at 6/15/05 11:04 AM, Carl Reed wrote:
>>> Art -
>>> Thanks for the quick response.
>>> Just to clarify so that there is no misunderstanding:
>>> 1. I agree that specifying WGS 84 as the default CRS and best
>>> practice is
>>> a good thing. There is no disagreement here.2. The current CAP 1.0
>>> spec references the EPSG definition of WGS 84. This
>>> is a good thing.3. The current approach works within the contextual
>>> framework of those who
>>> have implemented CAP to date. Fine
>>> That said, please consider:
>>> 4. I am not asking to change this position.
>>> 5. I am asking for the ability to specify another CRS.
>>> 6. This does not add complexity - nor does it break  
>>> interoperability.
>>> 7. It actually enhances interoperability as ALL
>>> communities/nations/jurisdictions are accommodated.8. It does not
>>> break interoperability because the optional element
>>> provides the EPSG code for the CRS being used. The majority of
>>> geospatial
>>> technology providers know of and use these codes.9. Most systems
>>> ingesting a WGS 84 based CAP payload will have to
>>> transform any coordinates contained in the CAP message into some  
>>> other
>>> projected system, such as State Plane. This is necessary to
>>> display/portray the location of an alert in the context of a common
>>> operational picture.
>>> I am looking toward future usage and flexibility.
>>> If my position falls short and is unacceptable, I will give up  
>>> pushing
>>> this position WRT CRS extensibility for CAP and move to other EM TC
>>> actions and work.
>>>> [Oops, our notes passed each other in the mail.]
>>>> On Jun 15, 2005, at 6/15/05 9:42 AM, Carl Reed wrote:
>>>>> You still appear to be missing the point. We can leave CAP and  
>>>>> EDXL
>>>>> with
>>>>> WGS 84 as the default (but not mandatory!) so that all existing
>>>>> implementations work and the level of "simplicity" being sought is
>>>>> maintained. We are suggesting optional elements that would allow
>>>>> folks to
>>>>> use other than WGS 84 as the only CRS.
>>>> OK, my mistake... guess we *aren't* all agreed on the need to  
>>>> fix on
>>>> a single standard reference system.  Personally, I think we do, if
>>>> only in order to keep  things simple for implementers.  Otherwise
>>>> we're going to have only local rather than global  
>>>> interoperability of
>>>> CAP messages.
>>>> What we're not getting here is a sense of proportion.  Is this a
>>>> serious and widespread problem or just a few folks' personal
>>>> theoretical axe?  I really can't tell... although I'll note again
>>>> that none of these complaints seem to come from folks who've  
>>>> actually
>>>> deployed implementations.
>>>> - Art
>>>> ------------------------------------------------------------------- 
>>>> --
>>>> To unsubscribe from this mail list, you must leave the OASIS TC  
>>>> that
>>>> generates this mail.  You may a link to this group and all  
>>>> your   TCs
>>>> in
>>>> OASIS at:
>>>> https://www.oasis-open.org/apps/org/workgroup/portal/
>>>> my_workgroups.php
>> ---------------------------------------------------------------------
>> To unsubscribe from this mail list, you must leave the OASIS TC that
>> generates this mail.  You may a link to this group and all your  
>> TCs in
>> OASIS at:
>> https://www.oasis-open.org/apps/org/workgroup/portal/ 
>> my_workgroups.php

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