Subject: [Geopriv] problems with civil location in PIDF-LO

From: Rohan Mahy <[email-masked]>
Date: Wed, 17 Nov 2004 11:57:26 -0800

Hi,

I think I have discovered some problems with the civil location format 
in PIDF-LO that should probably be fixed before the document becomes an 
RFC.  I would like to sincerely apologize to the working group that I 
didn't provide this feedback earlier. At least I think the format can 
be fixed with a minimum of delay and reworking.

1) The tags in the "A" series (A1 through A6) appear to be a hierarchy, 
but they don't have an important property of a hierarchy.  For example 
A4 is not necessarily a strict subset of A3.  I think this series 
actually conflates 3 separate things which can be geographically 
orthogonal:  administrative divisions, habitated area divisions, and 
streets.  For example, New York City is listed as A3, but it actually 
encompasses several counties (A2).  Also, many cities (A3 in the 
current hierarchy) are located in a township (also A3).  Finally, many 
streets (A6) cross neighborhoods (A5), cities (A3), and even counties 
or districts (A2).

I propose that the document instead reflect one hierarchy for 
administrative division (A<n>) and a separate hierarchy for habitated 
areas H<n>.  An item in the H-series can be located uniquely in the 
context of some element in the A-series. Streets would be dealt with 
separately as described in the next point, but likewise can be located 
uniquely in the context of an element in the A-series or H-series.

Label	Description
A0		ISO 2-letter country code
A1		ISO 2nd level country subdivision
		(province, state, prefecture, ken, departamento)
A2		county, parish, gun, district
A3		township, sub-district (typically rural)

H0		metropolitan area, to, fu
H1		city, town, locality, shi, ku
H2		city district, borough, ward, cho, machi, village, mura
H3		neighborhood, chome

ST		street name

Also, several of the existing elements are really subparts without a 
container element. For organizational purposes, it is probably useful 
for all of these tags to have containers:

lot		a container which describes a named or numbered building, house, 
lot, or plot
road		a container which describes a street, road, track, path, trail, 
or way
division	a container for elements in the A-series which describe 
land-divisions
locality	a container for elements in the H-series which describe 
city/town/village

2) the location information provided by the current PIDF-LO document 
format does not fully describe the semantics of the location with 
respect to the presentity. It implicitly assumes some semantics in a 
sloppy manner.  The semantics of indicating location needs to include 
some kind of preposition in the assertion.  We usually indicate that a 
presentity is "within" a city, neighborhood, country, or province; when 
driving we can be "in" a certain street but "adjacent" to a building or 
lot number (numeric address); when inside a building we can be "within" 
a numbered lot, but "addressed by" a nearby street.  In many rural 
areas, the best way to describe part of your location is to say you are 
"near" a small town or larger village.

Also, as soon as streets, localities, and land-divisions are no longer 
smushed together into one hierarchy, we need to describe the scope that 
makes each element unique.
lot 110  is unique with respect to road Main St which is unique with 
respect to locality Springfield which is unique with respect to 
division us-tn (tennessee).  This relationship is complicated by the 
fact that names and numbers (if they exist at all) for streets and lots 
are very different from region to region. For example, a lot or house 
number is described in terms of a street in some regions (ex: the US), 
and in terms of a neighborhood in others (ex: in Japan).

My proposal is to modify the schema to incorporate the notion of these 
types of semantics and to allow other assertions in the future.  Each 
container element can have a position attribute which specifies the 
position semantics (ex: in, adjacent, near--the default position 
semantics is "in"), and a unique-within attribute which provides the 
context in which to interpret the element.  The "unique-within" 
attribute points to a XPath expression which describes this 
relationship explicitly.  In most simple descriptions, the XPath 
expression is just the element name (road, locality, division) 
prepended with "//".  If you have more than one top level element, you 
need to add an "id" attribute with a unique value to distinguish among 
them. The division expression is always rooted in global country-code 
hierarchy, so it must not have a unique-within attribute.

3) There is no way to describe alternate versions of the same name 
(sometimes these are even in different languages or script systems). To 
accommodate this, you should be able to include multiple sub-elements 
of the same type within a container element. Each of these sub-elements 
would be an alternate identifier for the same thing. The first in the 
list would be the most preferred.

<road>
   <st id="1">6th</st><sts id="1">avenue</sts>
   <st id="2">avenue of the americas</st>
</road>

Below are several examples. I hope this proposal is a productive way 
forward.  If this is seen as useful, I can write up the corresponding 
XML schema and additional descriptive text.
many thanks,
-rohan

-------
Examples:

<lot unique-within='//road'>
   <hno>675</hno>
   <hns>1/2</hns>
   <nam>foobar apartments</nam>
</lot>
<road position="near" unique-within='//locality/h1'>
   <prd>west</prd>
   <st>114th</st>
   <sts>street</sts>
</road>
<locality unique-within='//division/a1'>
   <h3>morningside heights</h3>
   <h2>manhattan</h2>
   <h1>new york city</h1>
   <h0 unique-within='//division/a0'>greater new york city area</h0>
</locality>
<division>
   <a2>king's county</a2>
   <a1>ny</a1>
   <a0>us</a0>
</division>
<flr unique-within='//lot'>5</flr>
<loc unique-witihn='//flr'>room 543</loc>
<pc unique-within='//division/a0'>10027</pc>

<lot context='//locality[@id="1"]/h2>
   <nam>the gibsons</nam>
</lot>
<locality id="1" unique-within='//division/a1'>
   <h2>barmby-on-the-marsh</h2>
</locality>
<locality id="2" position=near unique-within='//division/a1'>
   <h2>goul</h2>
</locality>
<division>
   <a1>north humberside</a1>
   <a0>uk</a0>
</division>

<lot unique-within='//locality/h3'>
   <hno>9-11</hno>
</lot>
<locality unique-within='//division/a1'>
   <h3>3-chome</h3>
   <h2>midori-cho</h2>
   <h1>musashino-shi</h1>
   <h0 context="a0">tokyo</h0>
</locality>
<division>
   <a1>tokyo-ko</a>
   <a0>jp</a0>
</division

<lot unique-within='//road[@id="1"]'>
   <hno>110</hno>
   <nam>airespace</nam>
</lot>
<crossing position="near" unique-within='//locality/h1'>
   <cross-street path='//road[@id="1"'/>
   <cross-street path='//road[@id="2"'/>
</crossing>
<road id="1" unique-within='//locality/h1'>
   <st>nortech</st>
   <sts>parkway</sts>
</road>
<road id="2" unique-within='//locality/h1'>
   <st>disk</st>
   <sts>drive</sts>
</road>
<locality unique-within='//division/a1'>
   <h2>alviso</h2>
   <h1>san jose</h1>
   <h0 context="a1">san francisco bay area</h0>
</locality>
<division>
   <a2>santa clara county</a2>
   <a1>ca</a1>
   <a0>us</a0>
</division>
<loc unique-within='//lot'>northeast corner</loc>

<lot position="near" unique-within='//road'>
   <hno>21-43</hns>
   <hns>1/2</hns>
   <nam>cervezaria gallos</nam>
</lot>
<road position="in" unique-within='//locality/h2'>
   <st id="1">calle roberto robles</st>
   <st id="2">4a</st><sts id="2">calle</sts>
   <!-- there are two alternate versions of street name -->
</road>
<locality unique-within='//division/a1'>
   <h2>zona 1</h2>
   <h1>xela</h1>
</locality>
<division>
   <a1>qz</a1>
   <a0>gt</a0>
</division>

<loc unique-within='//road'>3rd slip up, 2nd boat rafted over on the 
right</loc>
<road position="adjacent" unique-within='//locality/h2'>
   <st>g</st>
   <sts>dock</sts>
</road>
<nam unique-within='//locality[@id="1"]'>maple bay marina</nam>
<locality id="1" unique-within='//division/a2'>
   <h2>maple bay</h1>
</locality>
<locality id="2" unique-within='//division/a1'>
   <h2 position="near">duncan</h1>
</locality>
<division>
   <a2>vancouver island</a2>
   <a1>bc</a1>
   <a0>ca</a0>
</division>

<lot unique-within='//locality[@id="1"]/h3'>
   <nam>carpenter's</nam>
</lot>
<locality id="1" unique-within='//division/a2'>
   <h3>hayes maze</h3>
   <h2>last chance</h2>
</locality>
<road position="near" unique-within='//division/a2'>
   <st>last chance</st>
   <sts>road</sts>
</road>
</locality id="2" position="near">
   <h1>davenport</h1>
</locality>
<division>
   <a2>santa cruz county</a2>
   <a1>ca</a1>
   <a0>us</a0>
</division>

<lot unique-within='//road'>
   <nam>lough house</nam>
</lot>
<road position="near" unique-within='//locality/h2'>
   <st>lough</st>
   <sts>road</sts>
</road>
<locality unique-within='//division/a1'>
   <h2>the lough</h2>
   <h1 unique-within='//division/a0'>cork</h1>
</locality>
<division>
   <a1>cork</a1>
   <a0>ie</a0>
</division>

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

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 18 Nov 2004 16:47:04 -0600

Rohan

You make a compelling argument to change the text with some well thought 
out examples given.  I'm not sure how others feel, but this is worth 
discussion and deciding if it should be accounted for, or is considered too 
late in the process.

This also directly affects the civic-address ID from Henning (obviously) 
that is in WGLC now.

At 11:57 AM 11/17/2004 -0800, Rohan Mahy wrote:
>Hi,
>
>I think I have discovered some problems with the civil location format in 
>PIDF-LO that should probably be fixed before the document becomes an 
>didn't provide this feedback earlier. At least I think the format can be 
>fixed with a minimum of delay and reworking.
>
>but they don't have an important property of a hierarchy.  For example A4 
>is not necessarily a strict subset of A3.  I think this series actually 
>conflates 3 separate things which can be geographically 
>encompasses several counties (A2).  Also, many cities (A3 in the current 
>hierarchy) are located in a township (also A3).  Finally, many streets 
>(A6) cross neighborhoods (A5), cities (A3), and even counties or districts 
>(A2).
>
>container element. For organizational purposes, it is probably useful for 
>all of these tags to have containers:
>
>lot             a container which describes a named or numbered building, 
>house, lot, or plot
>road            a container which describes a street, road, track, path, 
>trail, or way
>format does not fully describe the semantics of the location with respect 
>to the presentity. It implicitly assumes some semantics in a sloppy 
>manner.  The semantics of indicating location needs to include some kind 
>of preposition in the assertion.  We usually indicate that a presentity is 
>"within" a city, neighborhood, country, or province; when driving we can 
>be "in" a certain street but "adjacent" to a building or lot number 
>(numeric address); when inside a building we can be "within" a numbered 
>lot, but "addressed by" a nearby street.  In many rural areas, the best 
>way to describe part of your location is to say you are "near" a small 
>town or larger village.
>
>respect to locality Springfield which is unique with respect to division 
>us-tn (tennessee).  This relationship is complicated by the fact that 
>names and numbers (if they exist at all) for streets and lots are very 
>different from region to region. For example, a lot or house number is 
>described in terms of a street in some regions (ex: the US), and in terms 
>of a neighborhood in others (ex: in Japan).
>
>position semantics (ex: in, adjacent, near--the default position semantics 
>is "in"), and a unique-within attribute which provides the context in 
>which to interpret the element.  The "unique-within" attribute points to a 
>XPath expression which describes this relationship explicitly.  In most 
>simple descriptions, the XPath expression is just the element name (road, 
>locality, division) prepended with "//".  If you have more than one top 
>level element, you need to add an "id" attribute with a unique value to 
>distinguish among them. The division expression is always rooted in global 
>country-code hierarchy, so it must not have a unique-within attribute.
>
>
>accommodate this, you should be able to include multiple sub-elements of 
>the same type within a container element. Each of these sub-elements would 
>be an alternate identifier for the same thing. The first in the list would 
>be the most preferred.
>
><road>
>forward.  If this is seen as useful, I can write up the corresponding XML 
>schema and additional descriptive text.
>many thanks,
>-rohan
>
>
>-------
>Examples:
>

cheers,
James

                                *******************
                 Truth is not to be argued... it is to be presented

---

From: Andrew Newton <[email-masked]>
Date: Thu, 18 Nov 2004 18:08:12 -0500

On Nov 18, 2004, at 5:47 PM, James M. Polk wrote:

> Rohan
>
> You make a compelling argument to change the text with some well 
> thought out examples given.  I'm not sure how others feel, but this is 
> worth discussion and deciding if it should be accounted for, or is 
> considered too late in the process.

I think the differentiation between A-space and H-space is interesting. 
  But I think it is too late in the process to stop the PDIF-LO v1 from 
going to RFC.  This is certainly a substantive change request that 
can't simply be done at AUTH48.

At IETF 61, Jon admitted that it shouldn't be surprising that there 
will be needed changes to PIDF-LO.  This should be put in the list of 
changes for urn:ietf:params:xml:ns:pidf:geopriv20.

> This also directly affects the civic-address ID from Henning 
> (obviously) that is in WGLC now.

Not exactly correct, but we still have time to change things here.  But 
if the dhcp-civil draft is changed what do we do about the mismatch 
between it and PIDF-LO?  Given that there are likely to be more changes 
lined for urn:params:xml:ns:pidf:geopriv20 than just this one, my 
suggestion is to address all of these issues at a later time with 
GEOCONF_CIVIC2 (if we deem it necessary).

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 18 Nov 2004 23:00:01 -0500

> (A6) cross neighborhoods (A5), cities (A3), and even counties or 
> districts (A2).

I believe this description is misguided, as it misses the central 
objective of a location identification - unique and reproducible 
identification of a target.

This is indeed meant as an administrative hierarchy to the extent that 
it matters for identification and is likely to be done consistently 
within a country. Indeed, streets do span cities, but the important 
aspect is that a street is guaranteed to be only unique within a city. 
The opposite property is not relevant for the purposes of location 
identification.

We are not trying to do a taxonomy of place names here, but rather 
reflect unique hierarchies, so that each location can be located in one 
sequence of A1 through A6, without ambiguity.

In particular, it does not matter if in some cases, there is no strict 
hierarchy, as long as there is no confusion for one country what each 
label means. Nothing in the usage of the civic address format depends on 
the fact that a county is always bigger than a city, for example.

A township is just another name for a city/town-like entity. I'm not 
aware that, at least in the US, there can ever be a city in a township 
or vice versa. (For example, the US only has four levels of elections: 
local, county/parish, state, national.)

> uniquely in the context of an element in the A-series or H-series.

I do not believe that this is necessary for unique identification of a 
place.

Given the complexity incurred, I'm opposed to making the change, even 
ignoring the lateness of the proposal. No existing classification 
systems follows this logic, as far as I've been able to tell, making 
mapping of the "real world" (e.g., NENA coordinates) unnecessarily 
difficult. The problems stated are due to trying to use an 
identification system as something which it isn't designed for, namely 
as an ontology of place names.

Henning

> described in terms of a street in some regions (ex: the US), and in 
> terms of a neighborhood in others (ex: in Japan).
> 
> attribute points to a XPath expression which describes this relationship 
> explicitly.  In most simple descriptions, the XPath expression is just 
> the element name (road, locality, division) prepended with "//".  If you 
> have more than one top level element, you need to add an "id" attribute 
> with a unique value to distinguish among them. The division expression 
> is always rooted in global country-code hierarchy, so it must not have a 
> unique-within attribute.
> 
> 
> the same type within a container element. Each of these sub-elements

---

From: Rohan Mahy <[email-masked]>
Date: Fri, 19 Nov 2004 13:53:55 -0800

On Nov 18, 2004, at 20:00, Henning Schulzrinne wrote:

> Rohan Mahy wrote:
>> Hi,
>
>> 1) The tags in the "A" series (A1 through A6) appear to be a 
>> hierarchy, but they don't have an important property of a hierarchy.  
>> For example A4 is not necessarily a strict subset of A3.  I think 
>> this series actually conflates 3 separate things which can be 
>> geographically orthogonal:  administrative divisions, habitated area 
>> divisions, and streets.  For example, New York City is listed as A3, 
>> but it actually encompasses several counties (A2).  Also, many cities 
>> (A3 in the current hierarchy) are located in a township (also A3).  
>> Finally, many streets (A6) cross neighborhoods (A5), cities (A3), and 
>> even counties or districts (A2).
>

One of the primary design goals of PIDF-LO (indeed for the entire 
geopriv working group) is to provide partial disclosure of location due 
to privacy concerns. Reproducible identification is necessary at 
several levels, not just at the granularity used by emergency services 
in the United States.

> aspect is that a street is guaranteed to be only unique within a city.

No. Even in the US, a street is not always unique within a city.  I'm 
sure you've heard the story of towns with multiple Elm Streets. Outside 
the States I even provided a concrete example where this is not the 
case.  In large cities in Guatemala (and apparently some other Central 
American cities) streets and avenues are numbered within a Zone of the 
city.  (There is a 2nd Street in Zone 1, a 2nd Street in Zone 2, 
etc..).

The person providing location information may not be in a city at all.  
In rural areas, the street could be unique within a small jurisdiction 
like a county, or based on proximity to a nearby town.

Finally, some regions don't use street names at all.

> reflect unique hierarchies, so that each location can be located in 
> one sequence of A1 through A6, without ambiguity.

I provided several concrete example where I think there is ambiguity.

> label means. Nothing in the usage of the civic address format depends 
> on the fact that a county is always bigger than a city, for example.
>

I may be wrong, but I believe that Boston contains townships.  However, 
rather than making these types of assumptions for the world based on 
one country, we'd better be more sure.

>> separately as described in the next point, but likewise can be 
>> located uniquely in the context of an element in the A-series or 
>> H-series.
>
> difficult.

The "real world" is a complex place, and it extends beyond the borders 
of the United States.  I provided some concrete examples in the format 
I proposed. I used these examples because I believe they would be 
difficult to express in the format in the draft.  Rather than blindly 
assert that the current format is fine, I would much prefer if you try 
to demonstrate some way to make the current format express the 
locations I provided.

Please note, that all of the examples I provided are based on real 
place names and that I have been to most of them.

> The problems stated are due to trying to use an identification system 
> as something which it isn't designed for, namely as an ontology of 
> place names.

If you are right then you should have no problem addressing my concerns 
constructively.  In a phrase:  "Show me"

thanks,
-rohan

>> some kind of preposition in the assertion.  We usually indicate that 
>> a presentity is "within" a city, neighborhood, country, or province; 
>> when driving we can be "in" a certain street but "adjacent" to a 
>> building or lot number (numeric address); when inside a building we 
>> can be "within" a numbered lot, but "addressed by" a nearby street.  
>> In many rural areas, the best way to describe part of your location 
>> is to say you are "near" a small town or larger village.
>> Also, as soon as streets, localities, and land-divisions are no 
>> longer smushed together into one hierarchy, we need to describe the 
>> scope that makes each element unique.
>> fact that names and numbers (if they exist at all) for streets and 
>> lots are very different from region to region. For example, a lot or 
>> house number is described in terms of a street in some regions (ex: 
>> the US), and in terms of a neighborhood in others (ex: in Japan).
>> My proposal is to modify the schema to incorporate the notion of 
>> these types of semantics and to allow other assertions in the future. 
>>  Each container element can have a position attribute which specifies 
>> the position semantics (ex: in, adjacent, near--the default position 
>> prepended with "//".  If you have more than one top level element, 
>> you need to add an "id" attribute with a unique value to distinguish 
>> among them. The division expression is always rooted in global 
>> (sometimes these are even in different languages or script systems). 
>> To accommodate this, you should be able to include multiple 
>> sub-elements of the same type within a container element. Each of 
>> these sub-elements would be an alternate identifier for the same 
>> thing. The first in the list would be the most preferred.
>> <road>

---

From: Ted Hardie <[email-masked]>
Date: Fri, 19 Nov 2004 14:38:39 -0800

At 1:53 PM -0800 11/19/04, Rohan Mahy wrote:
>The "real world" is a complex place, and it extends beyond the 
>borders of the United States.  I provided some concrete examples in 
>the format I proposed. I used these examples because I believe they 
>would be difficult to express in the format in the draft.  Rather 
>than blindly assert that the current format is fine, I would much 
>prefer if you try to demonstrate some way to make the current format 
>express the locations I provided.

Howdy Rohan,
	I think the key point in response to this is the one Jon made:  we
know it's complex, but we had to start somewhere.  We're not saying we
need to stop there.  I am concerned, though, that if we don't start somewhere
soon, the process of adding new functionality may drag on past the point
at which people will care about the work.  As a result, I'd rather 
see us get out a
v1, then move on to a v2, than revisit this question before getting 
anything out
at all.
	And I have to echo Jon's other point--I would dearly love to
steal something good here.  Even if we do a good job at getting something
put together, this group lacks enough expertise in this area that we're
bound to be slow.
			regards,
				Ted Hardie

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 19 Nov 2004 16:59:12 -0600

Ted

My concern overall with your answer - which I would otherwise agree with - 
is the agenda item discussing the shut down of the WG next March. Andy 
phrased it more of a SHOULD tone than a MAY tone when discussing it. 
SHOULDs mean there really better be a good reason not to do a thing. If v2 
of PIDF-LO were a serious consideration, shouldn't the chairs have worded 
shutting down the group a little differently last week?

At 02:38 PM 11/19/2004 -0800, Ted Hardie wrote:
>>The "real world" is a complex place, and it extends beyond the borders of 
>>the United States.  I provided some concrete examples in the format I 
>>proposed. I used these examples because I believe they would be difficult 
>>to express in the format in the draft.  Rather than blindly assert that 
>>the current format is fine, I would much prefer if you try to demonstrate 
>>some way to make the current format express the locations I provided.
>
>Howdy Rohan,
>at which people will care about the work.  As a result, I'd rather see us 
>get out a

cheers,
James

                                *******************

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 21 Nov 2004 21:01:44 -0500

Rather than nesting >> a few more levels, let me try to distill the 
issues Rohan identifies and see if we at least agree at that level.

(1) Preposition ("near", "in")

(2) Alternate location designations (lot number and the like)

(3) Alternate renderings in different languages

As to (1): The current description only allows to describe locations to 
the level specified, i.e., no "near", just in. I happen to think that 
this is a reasonable approximation for a first version, particularly 
since proximity indications are likely to get complicated quickly. For 
example, proximity may require indications of distance.

(2): While there are alternate designations, they are of far more 
restricted use than street addresses, at least as to the examples given 
(lot numbers). These elements can, if there is a true needed, easily be 
added later.

(3): I agree that alternate language renderings would be nice and very 
useful. That's why the DHCP version for civic addresses goes to some 
length to accommodate these. However, for XML, there may alternate ways 
to handle this, by labeling whole <person> tuples by language in 
presence, as there may well be other presence information that should be 
rendered in multiple languages.

Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 21 Nov 2004 21:28:48 -0500

Rohan Mahy wrote:

> to privacy concerns. Reproducible identification is necessary at several 
> levels, not just at the granularity used by emergency services in the 
> United States.

Clearly, there is a range of functionality. We intentionally 
concentrated on "civic addresses", which are commonly understood to be 
designations of (mostly inhabited) places described by street addresses.

I would certainly like to hear about other real-time, presence-like 
applications that need information about other types of information.

The information in the civic address format is not limited to emergency 
services. It seems to correspond quite nicely to what routing services 
(Yahoo directions and the like), postal and courier delivery and most 
humans visiting people use. I'm not sure I can say that about lot numbers.

> sure you've heard the story of towns with multiple Elm Streets. Outside 

Actually, I discussed this at length within NENA. While this is 
theoretically possible, this is by now mostly an urban legend. Any 
region that has address delivery for emergency services (which is close 
to 100% by now) has unique street names within a single locality 
(community) designation. Otherwise, the chance for confusion would be 
far too high, for both postal delivery and emergency services.

It does happen that there is both an Elm Street and Elm Avenue or that a 
single street is discontinuous (true in Ottawa, for example), but it's 
considered the same street, with disjoint number ranges.

Please provide a real, verified and recent example of this case.

> city.  (There is a 2nd Street in Zone 1, a 2nd Street in Zone 2, etc..).

This is why we have sub-city hierarchies (A4 and A5). The current model 
does not require that streets are unique within a city level if there is 
a designation below that.

> like a county, or based on proximity to a nearby town.

Nothing breaks if a street is unique across larger areas, e.g, in an 
unincorporated area. I don't see why this is a problem in theory or 
practice.

Clearly, it's a bad idea to provide location information as

A1=NY
A6=Elm Street

but things are ok as long as you truncate from the bottom of the 
hierarchy, as the geopriv-privacy draft does.

Please provide a real-life example where this fails to uniquely identify 
a civic (street address) location.

> Finally, some regions don't use street names at all.

True, but nobody forces you to include this information. Thus, I'm not 
sure what your point is here.

> I provided several concrete example where I think there is ambiguity.

I didn't find a real-life example, ignoring the proximity case.

> rather than making these types of assumptions for the world based on one 
> country, we'd better be more sure.

In the US, the census bureau designates civic entities by one name. 
Sub-classification is not necessary. In other words, for the US, it is 
sufficient to designate the street, community and state for unique 
identification. There can never be two towns/cities/boroughs with the 
same name within the same state or two streets with the same name within 
the same locality. (These did exist in early American history, but no more.)

Thus, whether Boston is divided, for whatever reason, into wards, 
boroughs or other units is immaterial for the problem of location 
identification.

Other countries may well require more levels, but that's why we have 6 
levels that need to be populated in a country-specific way.

> of the United States.  I provided some concrete examples in the format I 
> proposed. I used these examples because I believe they would be 
> to demonstrate some way to make the current format express the locations 
> I provided.

Ignoring proximity, which I believe to be a separate problem, please 
demonstrate a concrete example that would fail. I'm afraid I didn't see 
anything along those lines in your earlier message. I believe your 
misunderstanding is that you imply that there needs to be strict 
hierarchy for this to work. This is not true. There only needs to be a 
unique mapping from relevant locally well-understood civic address 
components to Ax levels and other labels. No more, no less.

> 
> Please note, that all of the examples I provided are based on real place 
> names and that I have been to most of them.

It is unclear what exactly would fail in those cases.

> constructively.  In a phrase:  "Show me"

I'm afraid I don't know what precisely you want shown. That every place 
you mention is uniquely identified by the existing labels?

Henning

---

From: Rohan Mahy <[email-masked]>
Date: Mon, 22 Nov 2004 11:27:32 -0800

On Nov 21, 2004, at 18:01, Henning Schulzrinne wrote:

> As to (1): The current description only allows to describe locations 
> to the level specified, i.e., no "near", just in. I happen to think 
> that this is a reasonable approximation for a first version, 
> particularly since proximity indications are likely to get complicated 
> quickly. For example, proximity may require indications of distance.

The current description describes streets which you are "near", house 
numbers that you are either near (in the US) or in (in Japan), and 
cities and jurisdictions that you are "in".  At the very least, the 
format needs to be explicit about what the semantics actually are.

> restricted use than street addresses, at least as to the examples 
> given (lot numbers). These elements can, if there is a true needed, 
> easily be added later.

I don't understand what you are referring to.  Do you mean that I can 
refer to one house by street number or name, or that some locations 
only have identification by house number while others only have 
identification by name?

I agree that the former is only a "nice to have".  I was concerned 
about the later (for example, my "Lough House" example.)  In these 
cases, there is no house number, and sometimes no street name.

> length to accommodate these. However, for XML, there may alternate 
> ways to handle this, by labeling whole <person> tuples by language in 
> presence, as there may well be other presence information that should 
> be rendered in multiple languages.

This seems like a reasonable approach. presumably one could label an 
entire civicAddress element with a language.

thanks,
-rohan

---

From: Rohan Mahy <[email-masked]>
Date: Mon, 22 Nov 2004 12:21:16 -0800

On Nov 21, 2004, at 18:28, Henning Schulzrinne wrote:

>> geopriv working group) is to provide partial disclosure of location 
>> due to privacy concerns. Reproducible identification is necessary at 
>> several levels, not just at the granularity used by emergency 
>> services in the United States.
>

I don't agree that this is "commonly understood".  In any case, this is 
not mentioned anywhere in the document, and the term civil location is 
used instead of civic address.  The closest thing I could find is the 
following one-liner:

>    The following schema is a trivial representation of civil location
>    that MAY be implemented by entities compliant with this
>    specification.

If this is how we are limiting scope, then lets put it in the document:

"The following schema is a trivial representation of civil addresses.  
Civil addresses designate generally inhabited areas with street, city, 
or jurisdictional identifiers." etc...

A number of my comments about proximity are related to the notion that 
this work is described as civil location instead of civic addresses.  
The difference for me is that I can describe my position in words 
instead of coordinates when I am in the street or on the side of the 
highway.  If we are declaring this out of scope for now and we only 
deal with "in-building" or "in the property" locations, that's fine, 
but we need to declare what the scope is.

> The information in the civic address format is not limited to 
> emergency services. It seems to correspond quite nicely to what 
> routing services (Yahoo directions and the like), postal and courier 
> delivery and most humans visiting people use. I'm not sure I can say 
> that about lot numbers.

A "lot" is an abstraction that allows you to express "this building" or 
"this house" inclusive of the several different ways that people 
identify them (ex: by street number, by building number, by name).

> region that has address delivery for emergency services (which is 
> close to 100% by now) has unique street names within a single locality 
> It does happen that there is both an Elm Street and Elm Avenue or that 
> a single street is discontinuous (true in Ottawa, for example), but 
> it's considered the same street, with disjoint number ranges.
>

Sure.  I live at 121 Ladera Drive.  There is a house 2 blocks away at 
121 Ladera Court.  I get their mail all the time.  While there may be 
some unique name in the MSAG which is used only for emergency services, 
the only name known by the residents and the address used for postal 
purposes is "Ladera".  As a result <A6>Ladera<A6> is NOT unique within 
any of the previous items in the A-series.

Sure you can say that A6 is made unique by STS or some other element, 
but then how does an implementor know what HNO refers to?  Sometimes it 
refers to STS, sometimes to A6, sometimes to A4.

The semantics and the definitions in the document need to be crisp and 
clear to an implementor. I don't think the current format is there, and 
I am concerned that we have a tablecloth which is slightly too small 
for the table.  You can keep moving the tablecloth around by redefining 
the semantics, but once you nail down one definition the tablecloth 
still needs to cover the table.

>> case.  In large cities in Guatemala (and apparently some other 
>> Central American cities) streets and avenues are numbered within a 
>> Zone of the city.  (There is a 2nd Street in Zone 1, a 2nd Street in 
>> Zone 2, etc..).
>
> This is why we have sub-city hierarchies (A4 and A5). The current 
> model does not require that streets are unique within a city level if 
> there is a designation below that.

I'm glad to hear that.  Maybe I missed it, but I did not notice a clear 
description of this in the document.  This and my comment below were in 
reaction to your statement that "streets are always unique within a 
city".  I don't think the document says that today, but many 
implementors will make similar assumptions unless clear guidelines and 
semantics are described.

>> The person providing location information may not be in a city at 
>> all.  In rural areas, the street could be unique within a small 
>> jurisdiction like a county, or based on proximity to a nearby town.
>

thanks,
-rohan

---

From: Andrew Newton <[email-masked]>
Date: Tue, 23 Nov 2004 09:16:38 -0500

On Nov 19, 2004, at 5:59 PM, James M. Polk wrote:

> My concern overall with your answer - which I would otherwise agree 
> with - is the agenda item discussing the shut down of the WG next 
> March. Andy phrased it more of a SHOULD tone than a MAY tone when 
> discussing it. SHOULDs mean there really better be a good reason not 
> to do a thing. If v2 of PIDF-LO were a serious consideration, 
> shouldn't the chairs have worded shutting down the group a little 
> differently last week?

It was my observation at IETF 61 that there was not support for 
shutting down this working group in March.  Now, I don't know if that's 
because people prefer it to happen in June or July or not at all.  You 
should view my suggestion in the milestone discussion as a proposal and 
not a fact.

Quite simply, I think as long as GEOPRIV is attempting to meet its 
milestones and the participants are not issuing death threats to each 
other, then the working group will not be shut down (and GEOPRIV is a 
very well behaved working group).  However, that doesn't mean we should 
go looking for busy work.

I would ask that people interested in PIDF-LO v2 start to put together 
a document of their requirements.

Does this address your concern, James?

-andy

---

From: Rohan Mahy <[email-masked]>
Date: Tue, 23 Nov 2004 11:53:40 -0800

Hi Ted,

I am OK with limiting our scope, but I want to make sure we are 
explicit about it.  You can't look at the current document to find that 
out.

thanks,
-rohan

On Nov 19, 2004, at 14:38, Ted Hardie wrote:
> at which people will care about the work.  As a result, I'd rather see 
> us get out a

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 27 Nov 2004 11:36:27 -0500

Rohan Mahy wrote:

> used instead of civic address.  The closest thing I could find is the 

I agree that this should be better defined. The DHCP-civic document does 
try:

"Geospatial coordinates indicate longitude, latitude and altitude, while
civic addresses indicate a street address."

I'll expand this to

Geospatial coordinates indicate longitude, latitude and altitude, while
civic addresses indicate locations, generally in inhabited areas, that
can be uniquely identified by a hierarchy of jurisdictions, postal codes
and street addressess.

> highway.  If we are declaring this out of scope for now and we only deal 
> with "in-building" or "in the property" locations, that's fine, but we 
> need to declare what the scope is.

I agree that precision of scope would help. I've added some words to 
that effect in the DHCP draft, considering them implicit last-call 
coments :-)

There is a whole set of complicated location descriptions that we cannot 
represent except as descriptive text, such as "at the fire hydrant on 
the northeast corner of the intersection of Broad Avenue and Ft. Lee 
Road." Directions such as "take a left onto the first unmarked path 
after you get to the Deep Valley trail head" are even more difficult to 
cast into structured information - and it is not clear to me that this 
gains much, given that these addresses are likely only meaningful to 
humans, not GIS systems.

Since PIDF-LO (and the DHCP version) are most likely to be used for 
automatically generated addresses, I see this as a reasonable 80% solution.

> any of the previous items in the A-series.

This is the example I mentioned, namely that the same name is used with 
two different suffixes. The precise and more correct statement is that 
the combination of A6, PRD, POD, STS, colloquially known as a street 
name, is unique within a community. This is the MSAG and postal usage.

> refers to STS, sometimes to A6, sometimes to A4.

The combination of A6, PRD, POD and STS.

> implementors will make similar assumptions unless clear guidelines and 

While added precision is clearly helpful, I don't see this as a 
particular practical problem. People and automata have gotten reasonably 
good at providing a set of address components that uniquely identify a 
building or other civic address. Our job is to provide space to encode 
this available information.

All we could usefully say in the document is that, depending on the 
country and region, that an instance of A6+PRD+POD+STS is unique within 
A1 through A5, but possibly A1 through A4 or A1-A3 or even A1-A2.

Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 27 Nov 2004 10:56:04 -0500

Rohan Mahy wrote:

> format needs to be explicit about what the semantics actually are.

I agree that there is an implied semantics here that it wouldn't hurt to 
spell out.

Street and house numbers (as well as things like room numbers) don't 
cover 2D space completely, so these could denote both "in/on" or 
"nearest".  I agree with Rohan that distinguishing the two ("I'm in the 
building designated as 123 Main Street" vs. "123 Main Street is the 
closest building, but I'm actually standing in front of it") is useful 
and relatively simple, e.g., by adding an attribute.

I believe this attribute is inherited, i.e., it makes little sense to say

"I'm in 123 Main Street, but only near Main Street".

Most of the higher administrative domains are covering, although there 
are clearly areas, such as the high seas, that are outside any national 
boundary.

> refer to one house by street number or name, or that some locations only 
> have identification by house number while others only have 
> identification by name?

I meant alternate designations such as property tax lot numbers.

> 
> I agree that the former is only a "nice to have".  I was concerned about 
> the later (for example, my "Lough House" example.)  In these cases, 
> there is no house number, and sometimes no street name.

The current scheme does support such designations and does not force :

<country>IE</country>
<a0>Cork</a0>
<a3>The lough</a3>
<lmk>Lough House</lmk>

It is up to the originator of the address to make sure that, for the 
purposes of the application, the designation is unique. If somebody 
wants to play a treasure hunt game where the only location hint is

<country>US</country>
<lmk>The Acme Building</lmk>

without a hint as to which city, this is permissible, albeit of rather 
limited use. I don't see that uniqueness indications are particularly 
helpful here, particularly since these are often guesses. (For example, 
just because somebody believes Kurfuerstenstrasse to be unique within 
Berlin and sets the appropriate attribute doesn't make it so.)

My hunch is that, outside of treasure hunts and geocaching, deliberate 
non-unique addresses are of little practical value and most likely to be 
mistakes.

> entire civicAddress element with a language.

Since xml:lang is a well-defined type, I would hope that we can quickly, 
in 48h or by a simple extension, add 'language' attributes to the civic 
address elements or at least to <civilAddress>. The former will also 
make it much easier to directly copy the DHCP data into XML without loss 
of language information. This is not currently possible, unfortunately.

I noticed what I believe to be a bug in the PIDF-LO schema:

<civilAddress> is defined as a ComplexType, but not as an element. Thus, 
I don't think

<cl:civilAddress>
              <cl:country>US</cl:country>
              <cl:A1>New York</cl:A1>
              <cl:A3>New York</cl:A3>
              <cl:A6>Broadway</cl:A6>
              <cl:HNO>123</cl:HNO>
              <cl:LOC>Suite 75</cl:LOC>
              <cl:PC>10027-0401</cl:PC>
            </cl:civilAddress>

actually can be verified against the schema. Did somebody verify the 
example against the schema?