[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. Thanks! - 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]