Re: [Ecrit] LoST Questions/Comments - civic hierarchy

["Avery Penniston" <[e-mail]>]

James, thanks for the info on the work going on in Geopriv.  I'm interested to see how that discussion shakes out.  Specifically on how abbreviations/alternate spellings should be handled, how elements other than A elements get defined for super/sub sets,  and how to compare optional elements when left blank in one location, but supplied in another.  Perhaps the questions I have about civic location comparison belong in the Geopriv WG.

Martin, I think what you are saying is that if two civic locations do not match exactly (both the elements provided, and the blank elements) then, currently, LoST should consider them not equal.  But should LoST try to determine if one location 'fits' inside another?  For example a resolver wants to check if a location is found within one of its cached mapping service boundaries. 

 If the request location is something like:
          <country>DE</country>
          <A1>Bavaria</A1>
          <A3>Munich</A3>
          <A6>Otto-Hahn-Ring</A6>
          <HNO>6</HNO>
          <PC>81675</PC>

Should it attempt to match it with a cached mapping that has a boundary like this?:
          <country>DE</country>
          <PC>81675</PC>

Without having some type of definition that describes how the different CAType elements relate to one another spatially, location matching could be quite an expensive task on the server. 

Avery


> -----Original Message-----
> From: Thomson, Martin [mailto:[e-mail]]
> Sent: Wednesday, August 12, 2009 6:16 PM
> To: Avery Penniston; Brian Rosen; Tschofenig, Hannes (NSN - FI/Espoo);
> [e-mail]
> Subject: RE: [Ecrit] LoST Questions/Comments - civic hierarchy
> 
> Hi Avery,
> 
> When you request a hierarchy, or ordering, of civic addresses, this is
> OK for the top-level A* parameters, but it quickly fails at other
> levels.  It is even not possible when comparing A* parameters with non-
> A* parameters.
> 
> For instance, postal codes often cover an area equivalent to a suburb
> in scale, which is A4.  Thoroughfares frequently pass through multiple
> suburbs (A4), sometimes even states (A1).
> 
> While it's nice in theory, you can't rely on ordering outside of A*.
> As a hint, the civic address "boundary" can only be interpreted in a
> very narrow way:
> 
>   If any of the provided elements change from that specified, the
> provided service URI no longer applies and a new LoST request is
> needed.
> 
> It's a shame that LoST doesn't actually say this.  It should.
> 
> --Martin
> 
> -----Original Message-----
> From: Winterbottom, James [mailto:[e-mail]]
> Sent: Wednesday, August 12, 2009 4:32 PM
> To: Avery Penniston; Brian Rosen; Tschofenig, Hannes (NSN - FI/Espoo);
> [e-mail]
> Subject: RE: [Ecrit] LoST Questions/Comments
> 
> Hi Avery,
> 
> There are quite strong recommendations being made in Geopriv about
> countries profiling civic addresses for their jurisdictions.
> http://www.ietf.org/id/draft-ietf-geopriv-civic-address-
> recommendations-03.txt
> 
> Doing this ensures that civic addresses have specific forms for
> specific countries and the comparison issues you describe below become
> unnecessary, because you don't conform to the normalized form for the
> jurisdiction then your location is invalid.
> 
> Cheers
> James
>
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On
> Behalf
> > Of Avery Penniston
> > Sent: Thursday, 13 August 2009 6:51 AM
> > To: Brian Rosen; Tschofenig, Hannes (NSN - FI/Espoo); [e-mail]
> > Subject: Re: [Ecrit] LoST Questions/Comments
> >
> > Hi Hannes, Brian, et al.,
> >
> >
> > I think a hierarchy for PIDF-LO is essential for comparing civic
> > locations in order to mitigate relational ambiguity of locations.
> Brian
> > mentioned that the A elements already provide a level of hierarchy,
> and
> > it makes sense, for example, to include the country code to
> > disambiguate
> > Munich, DE from any Munich.  But what about cases where the A1
> element
> > is provided as well,(i.e. Munich, Bavaria, DE), and a comparison
> > location does not include that element (i.e. Munich, DE).  Should
> these
> > locations not be equal because one contains additional information?
> > The
> > answer might be that, no, they are equivalent because there is only 1
> > Munich in Germany, and the A1 element becomes irrelevant.  But this
> > forces another burden on the LoST Server to verify, if any elements
> in
> > the A levels (above the lowest one provided) are missing, that a
> child
> > element's value is only found only once in the higher A element that
> it
> > is aware of in order to be valid.  So for example, if a location had
> a
> > fictitious PIDF-LO of <country>de</country><A5>Zeppelin Square</A5>,
> > then the LoST server would have to check all of Germany to make sure
> > there is only 1 neighborhood of that name.  This becomes more tedious
> > the bigger the 'gap' between the highest and lowest A element
> provided.
> >
> <snip>
> 
> -----------------------------------------------------------------------
> -------------------------
> 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]