Subject: [Ecrit] [issue2] Is it allowed to specify civic and geospatial info into the query?

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 07 Jun 2006 11:30:23 +0000

Hannes Tschofenig <[email-masked]> added the comment:

TENTATIVE SUMMARY:

Here is the update: 

* Either civic OR geospatial in a LoST query 

Marc, Henning, Shida, Richard, Brian, John Schnizlein, Byron Smith,

* Both civic AND geospatial possible in a LoST query 

Roger, Martin, Andy, James W.

These folks don't seem to take a clear position:

John Hearty, Jean-Francois, Clive D.W. Feather

__________________________________________________
LoST Issue Tracker <[email-masked]>
<http://www.tschofenig.priv.at:8080/lost/issue2>
__________________________________________________

_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Wed, 7 Jun 2006 12:43:39 +0100

> * Either civic OR geospatial in a LoST query 
[but not both] camp.

-- 
Clive D.W. Feather  | Work:  <[email-masked]>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <[email-masked]>  | Fax:    +44 870 051 9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
THUS plc            |                            |

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 7 Jun 2006 09:04:12 -0400

I'll add one additional consideration. Somewhere along the way, I  
heard the bonmot that computer science only knows three numbers: 0, 1  
and infinity. This is generally taken to mean that systems should  
support none, one or an (essentially) infinite number of objects, for  
example, but not some arbitrary limit. (Many buffer overflows can be  
taken as an illustration of what happens when people assume  
otherwise.) This would mean that if we were to support both geo and  
civic, we'd also have to support any number of location objects, in  
any geo/civic combination. After all, an end system could easily get  
geo or civic information from multiple sources. Since, according to  
the arguments put forth, the LoST server is in the best position to  
sort this out, all location objects, of whatever kind, would have to  
be presented at the same time, whether 1, 2 or a dozen.

This probably means that the real alternative to the first option is  
"an unlimited combination of geo and civic".

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Wed, 07 Jun 2006 15:51:35 -0400

Add my voice for one only. Keep the protocol simple.

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 7 Jun 2006 17:42:24 -0500

I'd like to clarify my position, because I think that this discussion has headed off course a little.

Firstly, I'd recommend that people read the PDIF-LO [sic] profile draft.  That draft talks about cardinality and I think that it is extremely important to this discussion.

http://tools.ietf.org/html/draft-ietf-geopriv-pdif-lo-profile-04.txt

This document notes that it is possible to have civic and geodetic that together form a complex to describe a single location.  The example used is a set of 2-dimensional coordinates with an altitude expressed in building floors.  This is the reason that I support both, not because I see that the LoST server being able to make intelligent decisions about multiple conflicting pieces of information.

Here's how I see this working.  The seeker has a PIDF-LO.  They apply the selection methods described in the above document to select a single tuple that contains location information.
(XPath="/presence/tuple[status/geopriv][1]")

Whatever location information that tuple contains, be it geodetic or civic, the seeker lifts the contents of the location-info element and puts it in an appropriate LoST query.

Here are the applicable rules:

   Rule #1: A geopriv element MUST describe a discrete location.
   Rule #4: Providing more than one location in a single <location-info>
      element SHOULD be avoided where possible.
   Rule #5: When providing more than one location in a single <location-
      info> element the locations MUST be provided by a common source.
   Rule #6: Providing more than one location in a single <location-info>
      element SHOULD only be done if they form a complex to describe the
      same location.  For example, a geodetic location describing a
      point, and a civic location indicating the floor in a building.
   Rule #8: Where a PIDF document contains more than one tuple
      containing a status element with a geopriv location element , the
      priority of tuples SHOULD be based on tuple position within the
      PIDF document.  That is to say, the tuple with the highest
      priority location occurs earliest in the PIDF document.  Initial
      priority SHOULD be determined by the originating UA, the final
      priority MAY be determined by a proxy along the way, or the UAS.

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]]
> Sent: Wednesday, 7 June 2006 9:30 PM
> To: [email-masked]
> Subject: [Ecrit] [issue2] Is it allowed to specify civic and geospatial
> infointo the query?
> 
> 
> <http://www.tschofenig.com:8080/lost/issue2>

------------------------------------------------------------------------------------------------
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]

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Wed, 07 Jun 2006 20:56:01 -0400

OK, I've looked over the draft, and the rules make sense. I would still, 
as the "call server" programmer, choose the first location-info element 
and send only it. There's no way we should expect the mapping server to 
wade through potentially many objects when (within our charter) it makes 
sense to reply to only one of them.

Thomson, Martin [Business:EXTRNL:ANDREW] wrote:
> Firstly, I'd recommend that people read the PDIF-LO [sic] profile
> draft.  That draft talks about cardinality and I think that it is
> extremely important to this discussion.
> 
> This document notes that it is possible to have civic and geodetic
> that together form a complex to describe a single location.  The
> example used is a set of 2-dimensional coordinates with an altitude
> expressed in building floors.  This is the reason that I support
> both, not because I see that the LoST server being able to make
> intelligent decisions about multiple conflicting pieces of
> information.
> 
> Here's how I see this working.  The seeker has a PIDF-LO.  They apply
> the selection methods described in the above document to select a
> single tuple that contains location information. 
> Whatever location information that tuple contains, be it geodetic or
> civic, the seeker lifts the contents of the location-info element and
> puts it in an appropriate LoST query.
> 
> Rule #1: A geopriv element MUST describe a discrete location. Rule
> #4: Providing more than one location in a single <location-info> 
> element SHOULD be avoided where possible. Rule #5: When providing
> more than one location in a single <location- info> element the
> locations MUST be provided by a common source. Rule #6: Providing
> more than one location in a single <location-info> element SHOULD
> only be done if they form a complex to describe the same location.
> For example, a geodetic location describing a point, and a civic
> location indicating the floor in a building. Rule #8: Where a PIDF
> document contains more than one tuple containing a status element
> with a geopriv location element , the priority of tuples SHOULD be
> based on tuple position within the PIDF document.  That is to say,
> the tuple with the highest priority location occurs earliest in the
> PIDF document.  Initial priority SHOULD be determined by the
> originating UA, the final priority MAY be determined by a proxy along
> the way, or the UAS.
> 
> 
>> -----Original Message----- From: Hannes Tschofenig
>> [mailto:[email-masked]] Sent: Wednesday, 7 June 2006
>> 9:30 PM To: [email-masked] Subject: [Ecrit] [issue2] Is it allowed
>> to specify civic and geospatial infointo the query?
>> 
>> 
>> __________________________________________________ LoST Issue
>> Tracker <[email-masked]> 
>> _______________________________________________ Ecrit mailing list 
>> [email-masked] https://www1.ietf.org/mailman/listinfo/ecrit
> 
>  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. 
> ------------------------------------------------------------------------
> 
> 
> _______________________________________________ Ecrit mailing list 
> [email-masked] https://www1.ietf.org/mailman/listinfo/ecrit

---

From: Shida Schubert <[email-masked]>
Date: Wed, 07 Jun 2006 18:57:16 -0700

Hi Tom;

According to what I understand the issue still remains because
Rule#5 and Rule#6 allows a compound location information composed of
both geo and civic in single <location-info> element.

Two of which location type is a supplementary location info(floor or
altitude)
that can be dropped from the LoST query is probably not easy to find out.
I guess we can't expect all the intermediary that supports LoST client
functionality,
the ability to compute the two location inside one <location-info>
element to
seek out the proper location information to submit with the LoST query.

I think I understand the problem, but I still feel very uncomfortable to
send
more than one location to LoST server in a single query. I'd rather
loose the
ability to express the flexibility the pidf-lo-profile has about
including more
than one location.

If more than one location needs to be included in single location-info
element,
may be we can define a new element or an attribute to an "tuple" element
to express that a location information A adds additional info to location
information B?

Thanks & Regards
Shida

Tom-PT Taylor wrote:
> OK, I've looked over the draft, and the rules make sense. I would
> still, as the "call server" programmer, choose the first location-info
> element and send only it. There's no way we should expect the mapping
> server to wade through potentially many objects when (within our
> charter) it makes sense to reply to only one of them.
>

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 7 Jun 2006 22:35:29 -0500

It is better to think of anything that appears within a single <location-info> element as a single location.  You aren't sending more than one location to the LoST server.  If you think about it as a single "location" with multiple parts (elements), the fears about multiple responses disappear.

The only valid concern that remains is LoST server complexity.  But when you scratch beneath the surface a little, this begins to be less of a source of intestinal torment.  If we consider the occasions where this composite location is possible, it quickly resolves down to the floors altitude case, and not a whole lot more.  In other words, I can't think of a good alternative example.  That means that the LoST server can safely ignore the "<civicAddress><FLR>2</FLR></civicAddress>" that goes along with the geodetic information, except where you have the weird case where the bottom-floor cinema is served by a different PSAP to the upper-floors (not my example).

> From: Shida Schubert [mailto:[email-masked]]
> Sent: Thursday, 8 June 2006 11:57 AM
> To: Tom-PT Taylor
> Cc: Thomson, Martin; [email-masked]
> Subject: Re: [Ecrit] [issue2] Is it allowed to specify civic and
> geospatialinfointo the query?
> 
> 
> Hi Tom;
>

---

From: Shida Schubert <[email-masked]>
Date: Wed, 07 Jun 2006 23:20:20 -0700

Hi Tom;

I agree with you to some extent but I am still not comfortable.

As long as the two information really supplement each other, and one of
the information is sufficient to find the proper PSAP URI and both
information only resolves to one PSAP URI if both were queried, I might
be able to live with that.

Just out of curiosity. Assuming LoST supports query with location
information with two location type as long as it is a compound location
information where two information supplement each other, what would
happen if LoST server that was queried did not support geo and it
happend to have the supplementary information in geo(latitude)?

If it does not understand civic location format, it is unable to identify
the information to be used to find the proper PSAP and might proceed to
query the database using the location info provided in geo format(only
latitude info.

I guess it could return an error stating that it's an invalid location
as well as default uri for the service requested(e.g. Default PSAP URI
for the
region LoST server is responsible)...

Regards
Shida

Thomson, Martin wrote:
>>>> -----------------------------------------------------------------------
>>>>         
>> -------------------------
>>     
>>>> -----------------------------------------------------------------------
>>>>         
>> -------------------------
>>     
>>>> [mf2]
>>>>
>>>>
>>>> -----------------------------------------------------------------------
>>>>         
>> -
>>

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 8 Jun 2006 02:17:27 -0500

I think that you meant to ask me, so I'll answer.  I'm not sure if that's a good thing or not to be mistaken for Tom ;)

I'm not sure if I understand your scenario.  Do you have a server that doesn't support geo, but has extra information that it can use?

The only scenarios that I can see arising from this are those where one piece is not understood (either the geo, or civic part).  Two things can happen

  - the other pieces are sufficient to get a result (I don't understand civic, but I don't care about altitude), or

  - the other pieces are pretty ambiguous (I don't understand geo, and the second floor anywhere on the planet isn't specific enough for me).

> Sent: Thursday, 8 June 2006 4:20 PM
> To: Thomson, Martin
> Cc: [email-masked]
> Subject: Re: [Ecrit] [issue2] Is it allowed to specify civicand
> > It is better to think of anything that appears within a single
> <location-info> element as a single location.  You aren't sending more
> than one location to the LoST server.  If you think about it as a single
> "location" with multiple parts (elements), the fears about multiple
> responses disappear.
> >
> > The only valid concern that remains is LoST server complexity.  But when
> you scratch beneath the surface a little, this begins to be less of a
> source of intestinal torment.  If we consider the occasions where this
> composite location is possible, it quickly resolves down to the floors
> altitude case, and not a whole lot more.  In other words, I can't think of
> a good alternative example.  That means that the LoST server can safely
> ignore the "<civicAddress><FLR>2</FLR></civicAddress>" that goes along
> with the geodetic information, except where you have the weird case where
> the bottom-floor cinema is served by a different PSAP to the upper-floors
> (not my example).
> >
> >
> >
> ------------------------
> ------------------------

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 08 Jun 2006 10:08:06 +0200

Hi Martin,

Thomson, Martin wrote:
~snip~

> The only valid concern that remains is LoST server complexity.  But
> when you scratch beneath the surface a little, this begins to be less
> of a source of intestinal torment.  If we consider the occasions
> where this composite location is possible, it quickly resolves down
> to the floors altitude case, and not a whole lot more.  In other
> words, I can't think of a good alternative example.  That means that
> the LoST server can safely ignore the
> "<civicAddress><FLR>2</FLR></civicAddress>" that goes along with the
> geodetic information, except where you have the weird case where the
> bottom-floor cinema is served by a different PSAP to the upper-floors
> (not my example).

It seems that there is no real use case here where composite location is 
useful.

Ciao
Hannes

---

From: "Winterbottom, James" <[email-masked]>
Date: Thu, 8 Jun 2006 05:31:36 -0500

This is not quite true.
There is a case where a composite value is very useful for the purposes
of services dispatch. The problem is that the end-point may well not be
able to make a discernable difference for the purposes of what is
required for route determination.

Are we now suggesting that a location should consist of 2 different
geopriv objects, one for route determination and one for dispatch?

> From: Hannes Tschofenig [mailto:[email-masked]]
> Sent: Thursday, 8 June 2006 6:08 PM
> To: Thomson, Martin
> Cc: [email-masked]
> Subject: Re: [Ecrit] [issue2] Is it allowed to specifycivic and

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 08 Jun 2006 12:34:23 +0200

Hi James,

> geopriv objects, one for route determination and one for dispatch?

No. We are just trying to figure out what info we need to dump into the 
LoST query.

Ciao
Hannes

>>>when you scratch beneath the surface a little, this begins to be
> 
> less
> 
>>>bottom-floor cinema is served by a different PSAP to the
> 
> upper-floors
> 
>>>(not my example).
>>
>>It seems that there is no real use case here where composite location
> 
> is
> 
>>useful.
>>
>>Ciao
>>Hannes
>>

---

From: "Winterbottom, James" <[email-masked]>
Date: Thu, 8 Jun 2006 05:54:18 -0500

Hi Hannes,

The more specific you make the requirements on what can be passed to the
LoST server, the more intelligent and aware of the local policies you
need to make the end-point. This is a bad idea, and something that
policies in the LoST server should resolve.

Either the routing and dispatch information is the same, or it is not.
And if it is not then the end-point should be able to retrieve them or
otherwise determine them independently and they should be flagged as
such. To date, while it has not been categorically stated, I have had
the assumption that what I route on is what I deliver to the PSAP.

Cheers
James

> Sent: Thursday, 8 June 2006 8:34 PM
> To: Winterbottom, James

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 08 Jun 2006 13:59:50 +0200

Hi James,

> policies in the LoST server should resolve.

If I look at the list of people that support the idea of passing either 
geo OR civic (but not both) then I recognize that it is quite long in 
the meanwhile.

> the assumption that what I route on is what I deliver to the PSAP.

I think we have two different cases here:

(a) composite location info (mixed civic and geo)
(b) multiple different location infos (possibly from different sources)

Most of the responses to the mailing list thread referred to (b) where 
you obtain location info using different protocols, potentially at 
different points in time and also via different (virtual) interfaces. It 
is quite reasonable to have multiple geo location objects that may be 
available to the LoST client. I had the impression that people argued 
that you should send a separate query for each location object. This 
makes sense to me.

These scenario for (a) is a bit different:

We can obviously construct scenarios where the composite location info 
makes sense. The question, however, is whether these scenarios are 
important for us. We add more complexity with increased functionality.

Ciao
Hannes

>>>There is a case where a composite value is very useful for the
> 
> purposes
> 
>>>of services dispatch. The problem is that the end-point may well not
> 
> be
> 
>>No. We are just trying to figure out what info we need to dump into
> 
> the
> 
>>LoST query.
>>
>>Ciao
>>Hannes
>>
>>
>>
>>>
>>>>>words, I can't think of a good alternative example.  That means
> 
> that
> 
>>>>>"<civicAddress><FLR>2</FLR></civicAddress>" that goes along with
> 
> the
> 
>>>>>geodetic information, except where you have the weird case where
> 
> the
> 
>>>>It seems that there is no real use case here where composite
> 
> location
> 
>>>is
>>>
>>>
>>>>useful.
>>>>
>>>>Ciao
>>>>Hannes
>>>>

---

From: "Marc Linsner" <[email-masked]>
Date: Thu, 8 Jun 2006 08:53:58 -0400

The issue of a having a complex location, geo for horizontal and civic for
vertical, IMO, is an IETF/GeoPriv self-inflicted problem.  Discussions
pre-RFC3825 concluded the vertical component of 3-dimensional geo
coordinates, in their native form (feet/meters), were not very helpful for
the emergency services call routing and dispatching use cases.  Hence, the
measurement unit concept within the RFC3825 location information that allows
expressing the vertical information in units other than normal feet/meters
associated with geo representations.  When GeoPriv created RFC4119, this
concept of expressing the vertical component of a geo representation in
units other than the geo-normal feet/meters did not carry forward from
RFC3825 into RFC4119.  IMO, admittedly biased, this was a mistake.

So, here we are trying to deal with:

1) Accept emergency call routing on 2-dimensional info only because we
believe LoST is too stupid to deal with complex location representations.

2) Create the LoST query that mandates a single location, but can include
both geo and civic field(s).  (I believe that we can give guidance to make
this workable.)

3) Change RFC4119 to allow the vertical measurement unit concept within a
geo representation.

If anyone can think of other cases where we will have complex
representations, we need to discuss them now.

-Marc-

> 
> It is better to think of anything that appears within a 
> single <location-info> element as a single location.  You 
> aren't sending more than one location to the LoST server.  If 
> you think about it as a single "location" with multiple parts 
> (elements), the fears about multiple responses disappear.
> 
> The only valid concern that remains is LoST server 
> complexity.  But when you scratch beneath the surface a 
> little, this begins to be less of a source of intestinal 
> torment.  If we consider the occasions where this composite 
> location is possible, it quickly resolves down to the floors 
> altitude case, and not a whole lot more.  In other words, I 
> can't think of a good alternative example.  That means that 
> "<civicAddress><FLR>2</FLR></civicAddress>" that goes along 
> with the geodetic information, except where you have the 
> weird case where the bottom-floor cinema is served by a 
> different PSAP to the upper-floors (not my example).
> 
> 
> > functionality, the ability to compute the two location inside one 
> > <location-info> element to seek out the proper location 
> information to 
> > submit with the LoST query.
> > 
> > I think I understand the problem, but I still feel very 
> uncomfortable 
> > to send more than one location to LoST server in a single 
> query. I'd 
> > rather loose the ability to express the flexibility the 
> > pidf-lo-profile has about including more than one location.
> > 
> > element, may be we can define a new element or an attribute to an 
> > "tuple" element to express that a location information A adds 
> > additional info to location information B?
> > 
> > Thanks & Regards
> > Shida
> > 
> > Tom-PT Taylor wrote:
> > > still, as the "call server" programmer, choose the first 
> > > location-info element and send only it. There's no way we should 
> > > expect the mapping server to wade through potentially 
> many objects 
> > > when (within our
> > >> I'd like to clarify my position, because I think that this 
> > >> discussion has headed off course a little.
> > >>
> > >> Whatever location information that tuple contains, be it 
> geodetic 
> > >> or civic, the seeker lifts the contents of the location-info 
> > >> element and puts it in an appropriate LoST query.
> > >>
> > >> originating UA, the final priority MAY be determined by a proxy 
> > >> along the way, or the UAS.
> > >>
> > >>
> > >>> [mailto:[email-masked]] Sent: Wednesday, 7 June 
> > >>> 2006 9:30 PM To: [email-masked] Subject: [Ecrit] [issue2] Is it 
> > >>> allowed to specify civic and geospatial infointo the query?
> > >>>
> > >>>

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 8 Jun 2006 09:39:02 -0400

I have no objection to having a "hybrid" address if it is indeed  
logically a single address which can never, ever lead to two  
different PSAPs. As Marc notes, one has to ask if this is really the  
best way to organize location information since we are now  
commingling two very different cases:

(1) a (purportedly) single location determined by two different  
mechanisms, i.e., with the potential that civic and geo are actually  
not referring to the same point or building due to measurement errors  
of various sorts;

(2) a hybrid location, where x and y coordinates are specified in geo  
and z coordinates in "civic" (floors)

Plus, there are then the various civic "enhancements" such as  
building names, suite number or tenant name that are useful in  
practice, so they might also get thrown in for model (2).

Maybe this is a geopriv topic, but this strikes me as a recipe for  
confusion. Having to pick apart the various cases of

- geo has altitude, civic has (only) a floor, but maybe also a  
building name -> could be (1) or (2)

- geo has no altitude, civic has only floor (but maybe also building  
name and tenant or house number) -> (2)

- geo has no altitude, but civic has street-level addressing -> (1)

- and plenty more

seems to lead to lots of special cases that are likely to increase as  
we add more elements to either civic or geo.

Henning

On Jun 7, 2006, at 11:35 PM, Thomson, Martin wrote:

> <location-info> element as a single location.  You aren't sending  
> more than one location to the LoST server.  If you think about it  
> as a single "location" with multiple parts (elements), the fears  
> about multiple responses disappear.
>
> less of a source of intestinal torment.  If we consider the  
> occasions where this composite location is possible, it quickly  
> resolves down to the floors altitude case, and not a whole lot  
> more.  In other words, I can't think of a good alternative  
> example.  That means that the LoST server can safely ignore the  
> the geodetic information, except where you have the weird case  
> where the bottom-floor cinema is served by a different PSAP to the  
> upper-floors (not my example).
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 8 Jun 2006 09:39:02 -0400

- and plenty more

Henning

---

From: Andrew Newton <[email-masked]>
Date: Thu, 8 Jun 2006 12:27:56 -0400

On Jun 8, 2006, at 9:39 AM, Henning Schulzrinne wrote:

> different PSAPs.

That works for me.

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 08 Jun 2006 12:40:19 -0400

Now that we seem to be approaching a common understanding of the problem 
space, based on Hannes' observation, we should probably step back and 
ask if LoST needs to solve this. (I think hybrid addresses are quite 
useful for dispatch.)

Thus, maybe the question can be re-stated: Do we need to support the 
case that the location is specified primarily in geo coordinates, but 
PSAP resolution depends on the floor or suite number (specified in the 
civic part)?

I suspect none of the existing MSAG/ALI databases support this, but if 
this is a feature that 911 operators have asked for for years, it might 
be worth the extra specification complexity and additional error cases 
("You have specified a street name together with a geo address. Only a 
floor number is allowed.")

Are there any other practically-relevant cases of hybrid addresses?

Andrew Newton wrote:
>> logically a single address which can never, ever lead to two different 
>> PSAPs.
>>
> 
> That works for me.
> 
> -andy

---

From: Shida Schubert <[email-masked]>
Date: Thu, 08 Jun 2006 11:39:11 -0700

As I noted on my e-mail I sent yesterday, as long as
two information really supplement each other and
lead to only one PSAP URI, I am okay with this too.

Regards
Shida

---

From: Shida Schubert <[email-masked]>
Date: Thu, 08 Jun 2006 11:42:10 -0700

Hi Martin;

I looked at the requirement again and saw that it's mandatory to
understand both Civic and Geo for the mapping protocol so the
concern I had would not arise.

Regards
Shida

Thomson, Martin wrote:
>>>> that can be dropped from the LoST query is probably not easy to find
>>>>         
>> out.
>>     
>>>> I think I understand the problem, but I still feel very uncomfortable
>>>>         
>> to
>>     
>>>> send
>>>> may be we can define a new element or an attribute to an "tuple"
>>>>         
>> element
>>     
>>>> to express that a location information A adds additional info to
>>>>         
>> location
>>     
>>>> information B?
>>>>
>>>> Thanks & Regards
>>>> Shida
>>>>
>>>> Tom-PT Taylor wrote:
>>>>
>>>>         
>>>>>> ---------------------------------------------------------------------
>>>>>>             
>> --
>>     
>>>>>> ---------------------------------------------------------------------
>>>>>>             
>> --
>>     
>>>>>> ---------------------------------------------------------------------
>>>>>>             
>> --
>>     
>>>> -
>>>>
>>>>

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 8 Jun 2006 20:46:00 -0400

I just supplied one: country with a geo.  Used in disputed territory.  Works
really well in nearly every case (doesn't work with GPS and no assist).

-----Original Message-----
From: Marc Linsner [mailto:[email-masked]] 
Sent: Thursday, June 08, 2006 8:54 AM
To: 'Thomson, Martin'; [email-masked]; 'Tom-PT Taylor'
Cc: [email-masked]
Subject: RE: [Ecrit] [issue2] Is it allowed to specifycivicand

-Marc-