Subject: Re: [Geopriv] loc-filters additional requirements

From: "James M. Polk" <[email-masked]>
Date: Thu, 02 Jul 2009 00:38:00 -0500

Martin

Given you points, which at the moment I have no issues with - I'd 
like to still be able to specify that Alice wants Bob's civic 
location to the office or cube or building, and not just the city - 
which might be the default value Bob may choose to return.

If this takes two steps (#1 as Bob and see what he gives you, then 
ask again when his response wasn't to Alice's preferable level of 
detail) - this seems inefficient, but doable.

What I'm not see below, though you may have left it out because that 
will make the message longer, is this 'asking for specific elements 
of civic' level of detail.

Perhaps Alice wants to know Bob's

- altitude or
- cube he's in or
- the building name he's in or
- the street or
- county

all of which he wouldn't *or*didn't* return in his response as his default.

I keep going back to the only piece of location-info that's mandatory 
to be in a PIDF-LO is the ISO country code; everything else is 
assumed, and should be able to be asked for.

I don't read 4660/4661/4662 or Brian's filters ID to have this level 
of requestability (hey - new word), but I believe this has usefulness.

James

At 07:22 PM 6/30/2009, Thomson, Martin wrote:
>I'll note that 4661 isn't totally clear on these points, so there 
>are some assumptions in how this fits together.
>
>For geo/civic, <include/exclude> is a little clumsy in one direction 
>and possibly impossible in the other.  Even assuming that we have 
>only RFC 5491 shapes to contend with it's a bit fuzzy.
>
>Requesting geodetic you can't specify ALL shapes because the PA must 
>include these elements.  You only want one, but this would result in 
>getting every shape:
>
>         <include type="xpath">//gml:Point</include>
>         <include type="xpath">//gml:Polygon</include>
>         <include type="xpath">//gs:Circle</include>
>         <include type="xpath">//gs:Ellipsoid</include>
>         ...
>         <exclude type="xpath">//ca:CivicAddress</exclude>
>
>Even using an include type of "namespace" wouldn't be advisable, 
>there are two of those.  And without doing a lot more reading, I'm 
>not certain that this wouldn't include the entire namespace, which 
>for GML would be ridiculous.
>
>The same argument applies to shape conversion.  In my experience, 
>applications tend only support a limited number of shapes by 
>choice.  Therefore, it's likely that they will indicate the set of 
>shapes that they support and would prefer.  Again, using include 
>would probably result in multiple values.
>
>To that end, I propose two very simple filters:
>
>    <locationType>geodetic/civic/any</locationType>
>
>Which is clearly defined to mean that location information is 
>requested in this form; if necessary the PA should convert the 
>information it has into this form.
>
>And:
>
>   <geodeticShape>gml:Point</geodeticShape>
>
>Which has similar meaning: provide
>
>I also considered combining the two - to some extent this makes 
>sense if you consider these to have a sort of information hierarchy:
>
>   Location - Civic
>            - Geodetic - Point
>                       - Polygon
>                       - Circle
>                       - ....
>
>That does mess with the syntax a little though.
>
>With respect to location quality, I have a concrete proposal in the 
>draft I referenced (draft-thomson-geopriv-location-quality-04).
>
>      <quality xmlns="urn:ietf:params:xml:ns:geopriv:lq">
>        <maxUncertainty confidence="95">
>          <horizontal>150</horizontal>
>          <vertical>1000</vertical>
>        </maxUncertainty>
>        <maxAge>2008-05-27T05:47:55Z</maxAge>
>      </quality>
>
>To some extent I'm reluctant to request these additions.  There are 
>things here that are more generally applicable to continuous-valued 
>presence data (c.f. draft-thomson-simple-cont-presence-val-req).  My 
>gut feel is that these sort of additions would greatly increase the 
>complexity of what you are doing.  It might be better to leave these 
>out for now and concentrate on the easy ones.
>
>--Martin
>
> > -----Original Message-----
> > From: Brian Rosen [mailto:[email-masked]]
> > Sent: Wednesday, 1 July 2009 1:01 AM
> > To: Thomson, Martin; [email-masked]
> > Subject: RE: [Geopriv] loc-filters additional requirements
> >
> > Can you not use filter <include> and <exclude> from RFC4661 to
> > accomplish
> > the geo/civic and shape filters?
> >
> > That was how I thought we would do it.
> >
> > I don't have a problem with expanding to cover quality.
> >
> > A specific proposal might be nice.
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]] On
> > > Behalf Of Thomson, Martin
> > > Sent: Tuesday, June 30, 2009 2:37 AM
> > > To: [email-masked]
> > > Subject: [Geopriv] loc-filters additional requirements
> > >
> > > I apologise for not getting these in earlier, but this came out of a
> > > discussion that James Polk and I had over his filters draft.  We
> > > concluded that the draft would become informational and would provide
> > a
> > > "cookbook" type of assistance to implementers rather than defining
> > new
> > > filters.
> > >
> > > To that end, there were a few fairly basic filters that could not be
> > > accommodated by the current loc-filters document.  We decided to
> > raise
> > > these in the GEOPRIV WG:
> > >
> > >   1. location type:  A requirement to specify the desired location
> > > type: geodetic or civic.  This would be a simple addition and would
> > > either filter out the undesired type, or - if the PA supported it -
> > > allow for the application of (reverse) geo-coding.
> > >
> > >   2. location shape: For geodetic locations, it might be desirable to
> > > have the server perform shape conversion.  For instance, on a serving
> > > node it's possible to make certain assumptions about shapes that
> > result
> > > in a smaller shape when converting.  This could be significantly
> > better
> > > than leaving a client to perform any conversions (perhaps based on
> > > draft-thomson-geopriv-uncertainty) without that additional
> > information.
> > >
> > > I also have some more general requirements on quality that I would
> > like
> > > to see included (see draft-thomson-geopriv-location-quality).  These
> > > might require a somewhat different approach, as they regard the
> > > continuous nature of location information.  I would have liked for
> > > these to be considered, but am pragmatic enough to accept dealing
> > with
> > > these at a later date.
> > >
> > > In casting unsubstantiated dispersions about the maturity of this
> > > document, these are the issues that I believe were not covered.
> > ...and
> > > need to be.  I hope that this is adequate substantiation.
> > >
> > > --Martin
> > >
> > > p.s. We probably also need to go to SIMPLE to discuss the addition of
> > a
> > > != operator in 4661.  There was a good use case for that included in
> > > James' document, but my notes don't elaborate on it.
> > >
>
>------------------------------------------------------------------------------------------------
>This message is for the designated recipient only and may
>contain privileged, proprietary, or otherwise private information.
>If you have received it in error, please notify the sender
>immediately and delete the original.  Any unauthorized use of
>this email is prohibited.
>------------------------------------------------------------------------------------------------
>[mf2]
>_______________________________________________
>Geopriv mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/geopriv

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 2 Jul 2009 01:27:41 -0500

That's certainly a worthwhile goal.  It's somewhat equivalent in geodetic terms to requesting a certain uncertainty.

You're right, I was being economical - all that falls into the location quality bucket and is subject to my reservations on the topic.

> From: James M. Polk [mailto:[email-masked]]
> Sent: Thursday, 2 July 2009 3:38 PM
> To: Thomson, Martin; Brian Rosen; [email-masked]
> Subject: Re: [Geopriv] loc-filters additional requirements
> 
> Martin
>

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Tue, 14 Jul 2009 23:31:51 +0300

Hi Martin, 

This functionality is not directly related to the original goal of the
filters document that tried to limit the amount of notifications that are
being sent to the watcher. 

Anyway, functionality (1) is already in the HELD specification and has also
been re-used in the HTTP dereference document (that was actually the reason
for having more functionality than just an HTTP lookup). Also providing the
functionality in this document would be very much inline with the Deref
document. This, I believe, is a good idea. 

Regarding functionality (2): This is neither in HELD nor in Deref. If you
believe it is useful then we should add it to the Deref document as well. In
general, we should think about how to keep this type of functionality (from
a semantic point of view) roughly aligned and separated from the actual
transport. 

You mentioned the quality aspects: As a brief note I wanted to mention that
some basic functionality (in the form of the 'responseTime' attribute) is
already in the HELD base specification and is therefore inherited by the
Deref document. As such, I believe it should be provided also in this
document. 

Ciao
Hannes

>I apologise for not getting these in earlier, but this came 
>out of a discussion that James Polk and I had over his filters 
>draft.  We concluded that the draft would become informational 
>and would provide a "cookbook" type of assistance to 
>implementers rather than defining new filters.
>
>To that end, there were a few fairly basic filters that could 
>not be accommodated by the current loc-filters document.  We 
>decided to raise these in the GEOPRIV WG:
>
>  1. location type:  A requirement to specify the desired 
>location type: geodetic or civic.  This would be a simple 
>addition and would either filter out the undesired type, or - 
>if the PA supported it - allow for the application of 
>(reverse) geo-coding.
>
>  2. location shape: For geodetic locations, it might be 
>desirable to have the server perform shape conversion.  For 
>instance, on a serving node it's possible to make certain 
>assumptions about shapes that result in a smaller shape when 
>converting.  This could be significantly better than leaving a 
>client to perform any conversions (perhaps based on 
>draft-thomson-geopriv-uncertainty) without that additional information.
>
>I also have some more general requirements on quality that I 
>would like to see included (see 
>draft-thomson-geopriv-location-quality).  These might require 
>a somewhat different approach, as they regard the continuous 
>nature of location information.  I would have liked for these 
>to be considered, but am pragmatic enough to accept dealing 
>with these at a later date.
>
>In casting unsubstantiated dispersions about the maturity of 
>this document, these are the issues that I believe were not 
>covered.  ...and need to be.  I hope that this is adequate 
>substantiation.
>
>--Martin
>
>p.s. We probably also need to go to SIMPLE to discuss the 
>addition of a != operator in 4661.  There was a good use case 
>for that included in James' document, but my notes don't 
>elaborate on it.
>

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 14 Jul 2009 18:34:50 -0500

If I get you right, you want to be able to just use the information that is directly expressed in the PIDF to do everything.  Then you don't need a loc-filters document.  What you need is a much (much) smarter implementation of RFC 4661 - a specification that is already difficult to implement.

I know how to force inclusion of geodetic in the fashion you suggest, but it's cumbersome, indirect and brittle:

 <what>
   <include type="xpath">
     //gp:location-info/*[@srsName="urn:ogc:def:crs:EPSG::4326" or @srsName="urn:ogc:def:crs:EPSG::4979"]
   </include>
 </what>

How a PA is expected to see this and infer that it needs to perform geocoding, is probably beyond the ken of many.  The PA could just recognize the string and infer from that, but that's massively brittle.

I sat down and figured out how something like this might be implemented by a generic(-ish) PA.  You need to know that only GML geometries have an srsName attribute (which is actually not true: srsName cannot be namespace qualified, so this relies on an assumption).  Then the solution requires that the PA have further specialized knowledge.  Once you get to that sort of complexity, it's not that hard to just do something simple:

   <what><lf:locationType>geodetic</lf:locationType></what>

At some point, you need to know about the content in order to do the geocoding.  Why overcomplicate matters trying to avoid putting this knowledge in the filter?

Someone once submitted a centroid draft.  Derived properties in the PIDF could lead to some confusion.  Again, the same argument applies.

Quality filters need proper feedback to be properly useful [1].  Even with the proposed filters, this is necessary.  It's very easy to implement filters that don't actually achieve the intended goal.

--Martin

[1] http://tools.ietf.org/html/draft-thomson-simple-cont-presence-val-req

> Sent: Wednesday, 15 July 2009 7:14 AM
> To: 'Hannes Tschofenig'; Thomson, Martin; [email-masked]
> I'm particularly interested in keeping the same functionality for
> filtering
> for SIP and HELD, so I don't want to see HELD-specific solutions.
> 
> I think you could easily force a civic by requiring country code field,
> with
> something similar for the geo.
> 
> I suspect, but haven't thought out how to do something similar to force
> a
> particular shape
> 
> I'd probably go along with adding quality filters, but I'd prefer we
> first
> make the quality parameters actual elements in a PIDF instead of
> implicitly
> using something like the circle radius.  We could then ask for a
> specific
> value or range of those elements of the PIDF.
> 
> Brian
> 
> > Behalf Of Hannes Tschofenig
> > Sent: Tuesday, July 14, 2009 4:32 PM
> > To: 'Thomson, Martin'; [email-masked]
> > Anyway, functionality (1) is already in the HELD specification and
> has
> > also
> > for having more functionality than just an HTTP lookup). Also
> providing
> > the
> > You mentioned the quality aspects: As a brief note I wanted to
> mention
> > that
> > some basic functionality (in the form of the 'responseTime'
> attribute)
> > is

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Wed, 15 Jul 2009 10:02:01 +0300

Hi Brian, 

>I'm particularly interested in keeping the same functionality 
>for filtering for SIP and HELD, so I don't want to see 
>HELD-specific solutions.

Good to hear that. 
(A small correction: It is more about SIP loc filters and HTTP deref as
mechanisms to retrieve location rather than SIP and HELD.)

>
>I think you could easily force a civic by requiring country 
>code field, with something similar for the geo.

I don't think that this would work. Maybe I misunderstand the functionality
of RFC 4661 but you cannot require certain fields to be present. 

>
>I suspect, but haven't thought out how to do something similar 
>to force a particular shape

I also see challenges here. 

>
>I'd probably go along with adding quality filters, but I'd 
>prefer we first make the quality parameters actual elements in 
>a PIDF instead of implicitly using something like the circle 
>radius.  We could then ask for a specific value or range of 
>those elements of the PIDF.

The quality parameters that are described in HELD do not require any
extensions to PIDF. 
The quality parameters Martin has been working on provide more functionality
and I would not want to include them into this document to keep it simpler. 

I will try to compile a version to give folks a chance to see how it looks
like. 

Ciao
Hannes

>> filters document that tried to limit the amount of 
>notifications that 
>> are being sent to the watcher.
>> 
>> Anyway, functionality (1) is already in the HELD 
>specification and has 
>> also been re-used in the HTTP dereference document (that was 
>actually 
>> the reason for having more functionality than just an HTTP lookup). 
>> Also providing the functionality in this document would be very much 
>> inline with the Deref document. This, I believe, is a good idea.
>> 
>> Regarding functionality (2): This is neither in HELD nor in 
>Deref. If 
>> you believe it is useful then we should add it to the Deref document 
>> as well. In general, we should think about how to keep this type of 
>> functionality (from a semantic point of view) roughly aligned and 
>> separated from the actual transport.
>> 
>> You mentioned the quality aspects: As a brief note I wanted 
>to mention 
>> that some basic functionality (in the form of the 'responseTime' 
>> attribute) is already in the HELD base specification and is 
>therefore 
>> inherited by the Deref document. As such, I believe it should be 
>> provided also in this document.
>> 
>> Ciao
>> Hannes
>> 
>> 
>out of a 
>> >a "cookbook" type of assistance to implementers rather than 
>defining 
>> >new filters.
>> >
>> >raise these in the GEOPRIV WG:
>> >
>desirable to 
>> >result in a smaller shape when converting.  This could be 
>> >significantly better than leaving a client to perform any 
>conversions 
>> >(perhaps based on
>> >like to see included (see draft-thomson-geopriv-location-quality).  
>> >These might require a somewhat different approach, as they 
>regard the 
>> >...and need to be.  I hope that this is adequate substantiation.
>> >
>> >--Martin
>> >
>addition of 
>> >a != operator in 4661.  There was a good use case for that included 
>> >in James' document, but my notes don't elaborate on it.
>> >
>> >This message is for the designated recipient only and may contain 
>> >privileged, proprietary, or otherwise private information.
>> >immediately and delete the original.  Any unauthorized use of this 
>> >email is prohibited.

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Wed, 15 Jul 2009 10:02:30 +0300

We could use RFC 4661 for some things quite nicely. There are, however,
limits. 
Here I agree with Martin that we create funny constructs RFC 4661 and might
still not quite get what we are looking for. At this point we should just
define extensions that are easier to understand and to implement. 

Ciao
Hannes

>From: Thomson, Martin [mailto:[email-masked]] 
>Sent: 15 July, 2009 02:35
>To: Brian Rosen; Hannes Tschofenig; [email-masked]
>If I get you right, you want to be able to just use the 
>information that is directly expressed in the PIDF to do 
>everything.  Then you don't need a loc-filters document.  What 
>you need is a much (much) smarter implementation of RFC 4661 - 
>a specification that is already difficult to implement.
>
>I know how to force inclusion of geodetic in the fashion you 
>suggest, but it's cumbersome, indirect and brittle:
>
> <what>
>   <include type="xpath">
>     
>How a PA is expected to see this and infer that it needs to 
>perform geocoding, is probably beyond the ken of many.  The PA 
>could just recognize the string and infer from that, but 
>that's massively brittle.
>
>I sat down and figured out how something like this might be 
>implemented by a generic(-ish) PA.  You need to know that only 
>GML geometries have an srsName attribute (which is actually 
>not true: srsName cannot be namespace qualified, so this 
>relies on an assumption).  Then the solution requires that the 
>PA have further specialized knowledge.  Once you get to that 
>sort of complexity, it's not that hard to just do something simple:
>
>At some point, you need to know about the content in order to 
>do the geocoding.  Why overcomplicate matters trying to avoid 
>putting this knowledge in the filter?
>
>Someone once submitted a centroid draft.  Derived properties 
>in the PIDF could lead to some confusion.  Again, the same 
>argument applies.
>
>Quality filters need proper feedback to be properly useful 
>[1].  Even with the proposed filters, this is necessary.  It's 
>very easy to implement filters that don't actually achieve the 
>intended goal.
>
>--Martin
>
>[1] 
>http://tools.ietf.org/html/draft-thomson-simple-cont-presence-val-req
>
>> filtering for SIP and HELD, so I don't want to see HELD-specific 
>> solutions.
>> 
>> I think you could easily force a civic by requiring country code 
>> field, with something similar for the geo.
>> 
>> I suspect, but haven't thought out how to do something similar to 
>> force a particular shape
>> 
>> first make the quality parameters actual elements in a PIDF 
>instead of 
>> implicitly using something like the circle radius.  We could 
>then ask 
>> for a specific value or range of those elements of the PIDF.
>> 
>> Brian
>> 
>> > filters document that tried to limit the amount of notifications 
>> > that are being sent to the watcher.
>> >
>> > been re-used in the HTTP dereference document (that was 
>actually the 
>> > reason for having more functionality than just an HTTP 
>lookup). Also
>> providing
>> > the
>> > Regarding functionality (2): This is neither in HELD nor in Deref. 
>> > If you believe it is useful then we should add it to the Deref 
>> > document as well. In general, we should think about how to 
>keep this 
>> > type of functionality (from a semantic point of view) roughly 
>> > aligned and separated from the
>> actual
>> > transport.
>> >
>> > already in the HELD base specification and is therefore 
>inherited by 
>> > the Deref document. As such, I believe it should be 
>provided also in 
>> > this document.
>> >
>> > Ciao
>> > Hannes
>> >
>> >
>> > >I apologise for not getting these in earlier, but this 
>came out of 
>> > >a discussion that James Polk and I had over his filters 
>draft.  We 
>> > >concluded that the draft would become informational and would 
>> > >provide a "cookbook" type of assistance to implementers 
>rather than 
>> > >defining new filters.
>> > >
>> > >To that end, there were a few fairly basic filters that could not 
>> > >be accommodated by the current loc-filters document.  We 
>decided to 
>location 
>desirable 
>> > >to have the server perform shape conversion.  For instance, on a 
>> > >serving node it's possible to make certain assumptions 
>about shapes 
>> > >that result in a smaller shape when converting.  This could be 
>> > >conversions (perhaps based on
>> > >These might require a somewhat different approach, as they regard 
>> > >the continuous nature of location information.  I would 
>have liked 
>> > >for these to be considered, but am pragmatic enough to accept 
>> > >dealing with these at a later date.
>> > >
>addition 
>> > >of a != operator in 4661.  There was a good use case for that 
>> > >included in James' document, but my notes don't elaborate on it.
>> > >

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 14 Jul 2009 17:13:55 -0400

I'm particularly interested in keeping the same functionality for filtering
for SIP and HELD, so I don't want to see HELD-specific solutions.

I think you could easily force a civic by requiring country code field, with
something similar for the geo.

I suspect, but haven't thought out how to do something similar to force a
particular shape

I'd probably go along with adding quality filters, but I'd prefer we first
make the quality parameters actual elements in a PIDF instead of implicitly
using something like the circle radius.  We could then ask for a specific
value or range of those elements of the PIDF.

Brian

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 15 Jul 2009 09:38:11 -0400

How about:
<include type="xpath">/tuple/status/gp:geopriv/gp:location-info/gml:location </include>
and
<include type="xpath">/tuple/status/gp:geopriv/gp:location-info/cl:civicAddress</include>

That is neither brittle nor cumbersome.

Brian

> Sent: Tuesday, July 14, 2009 7:35 PM
> If I get you right, you want to be able to just use the information
> that is directly expressed in the PIDF to do everything.  Then you
> don't need a loc-filters document.  What you need is a much (much)
> smarter implementation of RFC 4661 - a specification that is already
> difficult to implement.
> 
> I know how to force inclusion of geodetic in the fashion you suggest,
> but it's cumbersome, indirect and brittle:
> 
>  <what>
>    <include type="xpath">
> How a PA is expected to see this and infer that it needs to perform
> geocoding, is probably beyond the ken of many.  The PA could just
> recognize the string and infer from that, but that's massively brittle.
> 
> I sat down and figured out how something like this might be implemented
> by a generic(-ish) PA.  You need to know that only GML geometries have
> an srsName attribute (which is actually not true: srsName cannot be
> namespace qualified, so this relies on an assumption).  Then the
> solution requires that the PA have further specialized knowledge.  Once
> you get to that sort of complexity, it's not that hard to just do
> something simple:
> 
> At some point, you need to know about the content in order to do the
> geocoding.  Why overcomplicate matters trying to avoid putting this
> knowledge in the filter?
> 
> Someone once submitted a centroid draft.  Derived properties in the
> PIDF could lead to some confusion.  Again, the same argument applies.
> 
> Quality filters need proper feedback to be properly useful [1].  Even
> with the proposed filters, this is necessary.  It's very easy to
> implement filters that don't actually achieve the intended goal.
> 
> --Martin
> 
> field,
> force
> > > been re-used in the HTTP dereference document (that was actually
> the
> > > reason
> If
> > > you
> > > general, we should think about how to keep this type of
> functionality
> > > (from
> > > already in the HELD base specification and is therefore inherited
> by
> > > the

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 15 Jul 2009 18:41:56 -0500

The second is OK, the first doesn't work.

> Sent: Wednesday, 15 July 2009 11:38 PM
> To: Thomson, Martin; 'Hannes Tschofenig'; [email-masked]
> implemented
> > [1] http://tools.ietf.org/html/draft-thomson-simple-cont-presence-
> val-
> > req
> >
> > > > This functionality is not directly related to the original goal
> of
> > > the
> Deref.
> > > > believe it is useful then we should add it to the Deref document
> as
> > > > well. In
> > ---------------------------------------------------------------------
> --
> > -------------------------
> > ---------------------------------------------------------------------
> --
> > -------------------------
> > [mf2]
>

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 15 Jul 2009 20:09:01 -0400

Why?

> Sent: Wednesday, July 15, 2009 7:42 PM
> suggest,
> > > > > From: [email-masked] [mailto:geopriv-
> [email-masked]]
> > On
> notifications
> > > > > functionality in this document would be very much inline with
> the
> > > > Deref
> > > > > a semantic point of view) roughly aligned and separated from
> the
> > > > actual
> > > > > transport.
> > > > >
> inherited
> > > > > Deref document. As such, I believe it should be provided also
> in
> > > this
> > > > > document.
> > > > >
> > > > > Ciao
> > > > > Hannes
> > > > >
> > > > >
> > > > > >--------------------------------------------------------------
> -
> > > > > >---------------------------------
> > > > > >--------------------------------------------------------------
> -
> > > > > >---------------------------------
> > > > > >[mf2]

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 15 Jul 2009 19:41:30 -0500

Let's assume that the PA is intelligent enough to identify an element in an <include> that doesn't exist, link that to a particular presence source and populate that data.  Let's assume that the PA has presence sources that are able to source location of either type, or presence sources that are able to acquire the alternative location type and perform (reverse-)geocoding.

There isn't one single form for geodetic data.  You need to select one of a set.  RFC 4661 doesn't offer any option to say "include one of these elements".  What you propose depends on one of two things: location conversion, or a new form of geodetic location, such as you seem to want to include.  Neither of those work especially well - one degrades location, the other doesn't exist yet.

--Martin

p.s. gml:location is deprecated.

> Sent: Thursday, 16 July 2009 10:09 AM
> information
> > > >      //gp:location-info/*[@srsName="urn:ogc:def:crs:EPSG::4326"
> or
> > > > @srsName="urn:ogc:def:crs:EPSG::4979"]
> > > >    </include>
> > > >  </what>
> > > >
> perform
> for
> code
> to
> prefer
> > > we
> specification
> to
> > > > -----------------------------------------------------------------
> --
> > --
> > > --
> > > > -----------------------------------------------------------------
> --
> > --
> > > --