Re: [emergency] Re: Circle and Polygon

["Carl Reed" <creed@opengeospatial.org>]

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