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: Sample email to interested parties WRTgeoenhancements to CAP


Hi,

If CAP uses GML geometries than the potential support for multiple CRS
is already addressed.  CAP or CAP deployments can then easily restrict
this by simply stating (listing) the CRS that are supported.  In a
community that wishes to support multiple CRS then the community
services must provide for coordinate translation - this can be achieved
using coordinate transformation services, or can be accomplished by WFS
or similar data provision services.  I would suggest that the client
view applications be restricted to a single CRS for simplicity.

R

-----Original Message-----
From: Alessandro Triglia [mailto:sandro@oss.com] 
Sent: November 26, 2007 4:05 PM
To: 'Art Botterell'; emergency@lists.oasis-open.org
Subject: RE: [emergency] RE: Sample email to interested parties
WRTgeoenhancements to CAP

 

> -----Original Message-----
> From: Art Botterell [mailto:ABott@so.cccounty.us]
> Sent: Monday, November 26, 2007 23:26
> To: emergency@lists.oasis-open.org; creed@opengeospatial.org
> Subject: Re: [emergency] RE: Sample email to interested parties 
> WRTgeoenhancements to CAP
> 
> Guess I'm not clear on how we could support multiple CRSs without 
> creating a burden on consuming devices, some of them potentially quite

> thin.  Do you see a way, Carl (or anyone)?
> 
> As for local mandates, in China or wherever: Participation in global 
> standards is always voluntary.  If we start trying to be all things to

> everyone, seem like we risk winding up with specs so broad and floppy 
> that they cease to be effective as standards at all.
> 
> This work involves more than just aggregating everyone's desires, I 
> think.  Sometimes choices must be made.  We certainly want to solicit 
> and respect everybody's input, but I'm not sure we can or should try 
> to satisfy everyone in every regard.


I think that, in general, it is better to produce a flexible standard
and then profile it locally according to local requirements (as
necessary) than to produce an inflexible standard that can only be used
in a smaller subset of use cases or within a smaller community.

If we can make CAP support multiple CRSes with little additional effort
and little additional complexity, its adoption can be much broader, even
if some local implementations will be unable to fully communicate with
other local implementations.  In my view, this is a much better
situation than having a smaller number of implementations that
understand each other perfectly, and the rest of the world developing
and using different and totally incompatible standards.

If WGS 84 is considered the best option throughout the US, for example,
it is certainly possible for US government agencies to require the use
of CAP with WGS 84 whenever they issue an RFP, but the standard itself
should not have that limitation if it prevents broad adoption in other
countries and communities.

Alessandro



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