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

["Thomson, Martin" <[e-mail]>]

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

Without the need for interoperable exchange formats, an implementation of a LoST server could have additional information that says that one civic address is entirely contained within another.  This information would not necessarily be able to be represented in the synchronization protocol.  

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

Yes, I would imagine that this location is considered to be "within" the specified boundary "address".  The boundary effectively states that any location with the same country and postal code is within the boundary.

The consumer of a LoST boundary (client, or caching server) has a very simple algorithm to follow.  For each specified element in the boundary "address", compare for equality.  If a boundary-specified element is either not equal or absent in the request address, the address is outside the boundary.  Additional elements in the request address that were not specified in the boundary address can only be considered to be unimportant.

Worst case, which is always available, is that the LoST server maintains an exhaustive list of civic addresses that are within the boundary.  Obviously, there might be certain simplifications that could be made (such as ignoring interior elements).

These things will vary, depending on the needs of the specific LoST application.  In Australia and many other countries emergency services are centralized.  Therefore, a LoST server that serves those countries is able to correctly determine a route for emergency services based on the <country> tag alone.  In the US, things are much more complicated and the LoST server therefore needs much more extensive information.

Two important considerations:

 1)  It is not possible to indicate that a certain element MUST be absent when expressing a boundary.  This is a failing of the system, and one that might need to be addressed.  

   Deployment experience might show that this is not necessary, but I've seen evidence enough that civic addresses are capable of producing just about any corner case imaginable.

 2)  Any single boundary "address" is not necessarily complete on its own.  A complete boundary specification might require the union of multiple such boundaries.  In some cases, this can get extremely complicated.

  To give an example of this, imagine the case where a road is used as a dividing line.  If, as is common in many places, odd numbered houses are on one side of the road and even on the other, the boundary specification for either region cannot simply indicate the road, it must specify each house number individually.  That's quite costly, but the only choice available, given the specification (or, as I noted previously, absence thereof).

Cheers,
Martin


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