Re: [emergency] Re: Circle and Polygon

[Art Botterell <acb@incident.com>]

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
>>
>
>
>
>