Re: [emergency-if] Meeting Notes from last weeks IF meeting

Interesting. This discussion parallels many of the discussions in the IETF 
on location, confidence of location elements, dereferencing, QoS and so forth. 
Might not simply adding a measure of quality to each element be a more general 
mechanism for expressing the accuracy/quality of any geo element? This is the 
approach the IETF is taking. There is also a defacto standard titled UnCertML 
for expressing uncertainty. This is being used in a variety of OGC standards as 
well as standards being developed in other communities. If each element has an 
expression of uncertainty, then the consuming application can them determine 
which representation it wishes to use. Assuming some apriori ordering will cause 
confusion and may be self-defeating.

 

Cheers

Carl

 

  
----- Original Message ----- 

  
From: 
  Hans Jespersen 

  
To:  
  

  
Sent: Monday, September 27, 2010 11:45 
  PM

  
Subject: [emergency-if] Meeting Notes 
  from last weeks IF meeting

  

  

  
Attendance: 
  Hans Jespersen, Gary Ham, Rex 
  Brooks

  
 

  
Since we had light 
  attendance and Gary had to leave the meeting early, we 
  focused on exploring and enumerating all the potential options for item #15 on 
  the Issues List.

  
 

  
Item #15 is the 
  requirement to allow multiple representations of a Target Area (for example 
  both Polygon and LocCode) and to be able to specify precedence (an ordering) 
  which indicates which representation is most 
  accurate.

  
 

  
Ways to do this 
  include:

  
1) Specify that the 
  precedence be the “document order” in the XML text. – We would have to 
  redefine the schema to remove the current sequence order restriction - 
  [Gary] 
  expressed concern that certain parsers reply on sequence order for efficiency 
  (i.e SAX vs DOM parsers)

  
 

  
2) Use an attribute 
  directly in the tags (i.e. <polygon precedence=”true”> - This would 
  require parsing all elements to find which are set to “true” which could 
  confusingly be set twice or more.

  
 

  
3) Use an attribute in 
  <target area> (i.e. <targetArea most_accurate=”polygon”> - This 
  would at least always be in same place and if it where not present, or 
  ignored, it would match today’s behavior.

  
 

  
4) Add a 
  <MostAccurate> tag: ie:

  
 

  
      
  <TargetArea>

  
            
  <Polygon>

  
                  
  <MostAccurate>

  
                  
  ...

  
            
  </Polygon>

  
            
  <Circle>

  
                  
  ...

  
            
  </Circle>

  
      
  </TargetArea>

  
      
  

  
 

  
      
  

  
5) Add explicit 
  <primary> and <secondary> container 
  elements

  
 

  
      
  <TargetArea>

  
            
  <PrimaryRepresentation>

  
<Polygon>

  
                  
  ...

  
            
        </Polygon>

  
            
  </PrimaryRepresentation>

  
            
  <SecondaryRepresentation>

  
            
        <Circle>

  
            
        ...

  
            
        </Circle>

  
<SecondaryRepresentation>           
  

  
      
  </TargetArea>

  
      
        

  
 

  
 

  
6) Specify a set universal 
  order of accuracy: i.e. <Polygon> is always the best representation, 
  then <LocCode>, then <Circle>, then <BoundingBox>, 
  etc.

  
 

  
      
  [Hans] expressed problems with any universal ordering because there are clear 
  cases where the order would be different. For example when the target area is 
  a state then the locCode is exact and the polygon is an approximation. When 
  the target area is a plume, then the polygon is a best estimate and the 
  locCodes are a poor approximation.

  
 

  
 

  
Additional discussion 
  points:

  
[Gary] Expressed a need to 
  continue to support unions of multiple target 
  areas.

  
[Gary] Thought that 
  unions of different representation types should be supported, i.e. the target 
  area is a <LocCode> plus a <Polygon>. 

  
 

  
 

  
 

  
-- 

  
Hans 
  Jespersen

  
Principal Systems 
Engineer

  
Solace Systems Inc.

  
2051 Landings Drive, 
  Mountain View, CA 94043

  
Phone: (650) 
  924-2670

  


  
http://www.solacesystems.com