Subject: [Geopriv] "House Number" misnamed?

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 26 Oct 2009 12:00:28 -0400

In the original PIDF-LO definition in RFC4119, we have a field called "House
Number" (and a "House Number Suffix").  Is this field misnamed?

Suppose you had a "milepost" on a road, or on a railroad, or even a hiking
trail.  Would you expect the marker number (which is usually miles or
kilometers as measured from an end of the road/railroad/trail) to appear in
the "HNO" field?

I think yes, which means that the field is misnamed.  I would suspect that
the appetite of the work group to actually change the name of the field
would be low, although I would probably like to do something that would
generalize the use of the field.

A more subtle question.  In 4119, under HNO, it says "numeric part only".
If the post marker was "125.5" is that numeric enough, or would we have to
use the suffix?

Brian

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 26 Oct 2009 12:52:59 -0500

>If the post marker was "125.5" is that numeric enough, or would we have to

you're differentiating this sufficiently from apartment number, right?

because I see a street address belonging to an apartment complex, 
then an apartment number belonging to an individual apartment.

If you are saying the HNO is the street address "number" (and not 
confused by the apartment number) - then this generalization is agreeable.

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

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 26 Oct 2009 14:05:41 -0400

Yes, Apartment number currently goes in ³UNIT², but my ³INT² proposal would
change that.  It does NOT go in ³HNO².

Brian

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 26 Oct 2009 13:27:12 -0500

At 01:05 PM 10/26/2009, Rosen, Brian wrote:
>change that.

exactly how many _existing_ CAtypes are you 
planning on obsoleting within your INT proposal?

FWIW - Apartments can be external just as easily 
as internal (and they're fairly uniform in 
numbering) so this one, for now, shouldn't be removed

>It does NOT go in ³HNO².

what does not go in HNO? Apartment or post marker?

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 26 Oct 2009 14:37:57 -0400

BLD, FLR, UNIT, ROOM, SEAT would be "obsoleted", in the same sense A6 was
obsoleted by RD.

Apartment number doesn't go in HNO. Milepost number would,  I propose.

Can you cite an example where an apartment number is not a subset of a
street address (that is, you have a RoaD name, what we now call a "House
Number", and then there is some kind of subdivision?

"INT" would define everything that is a subdivision of from the entity
addressed by RD (and it's parts) and what is now called HNO.

You would encode something as simple as a house with an apartment as
<RD>Main</RD>
<HNO>123</HNO>; with the current name
<INT N="Apartment">B</INT>

We would encode I85N Milepost 123 as
<STP>Interstate</STP>
<RD>85</RD>
<POD>N</POD>
<HNP>Milepost</HNP>
<HNO>123</HNO>

Brian

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 26 Oct 2009 14:33:15 -0500

>BLD, FLR, UNIT, ROOM, SEAT would be "obsoleted", in the same sense A6 was

I have a big problem with taking these out and 
leaving them with no IANA registration, as they 
are unique features IMO, and they exist, therefore they should remain.

>Apartment number doesn't go in HNO. Milepost number would,  I propose.

I'm good with this

>Number", and then there is some kind of subdivision?

I have no issues with apartment number being 
UNIT, which is a subset of HNO. We agree here.

><INT N="Apartment">B</INT>

I'm not seeing what you gain by removing <UNIT> B</UNIT> from the above

>We would encode I85N Milepost 123 as

this example seems fine

James

---

From: Brian Rosen <[email-masked]>
Date: Mon, 26 Oct 2009 16:24:30 -0400

We wouldn't take them out in the same sense that A6 is not taken out.  It is
suggested that A6 not be used, and RD and the associated CA types be used
instead.

The problem is that UNIT is NOT a unique feature, and you get confusion on
what it means in some circumstances.  It's not good to have two ways to do
things.  BLD/FLR/UNIT/ROOM doesn't always work.  INT always works.  The
proposal is to use INT, but not actually deprecate BLD/FLR/UNIT/ROOM.

Be strict in what you send (INT) be liberal in what you accept (UNIT).

UNIT usually works with Apartment, but the variations on naming get you in
trouble.  For example, is the value of UNIT "B", "Apt. B", or "Apartment B"?
That is often not specified in a national addressing standard, yet to be
useful, we need things to at least be consistent.  What do you do with
"Penthouse", which might be considered a UNIT or a FLR.

What happens when you have a designator between "BLD" and "APT" that isn't
"FLR".  Suppose your address was Building 1, West Tower, Apartment 6.   What
do you do with Tower?  Is it a UNIT?  How about Floor?  If Apartment 6 has
two floors, with the front door at Floor 7, but you have an upper and a
lower level, what do you do with FLR?

INT Always works
<INT N="Building">1</INT>
<INT N="Tower">West</INT>
<INT N="Floor">7</INT>
<INT N="Apartment">6</INT>
<INT N="Level">Upper</INT>

Brian

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 27 Oct 2009 07:44:31 +0800

Misnamed as it may be, the actual label does not need to change if we want to extend its semantics.  The only problem comes about when you attempt to constrain semantics.  I see no problem with what you propose.

It's a simple enough change to note that HNO can refer to milestones or whatever.  The only question that arises is whether this is the right thing to do.  There was that proposal to add support for a separate "post number", which seemed to indicate that such things were commonplace, but orthogonal to house numbering.

I've always thought that all the suffix fields were largely redundant and just a source of extra complexity.  As it stands, any document author can choose to use the suffix, or just roll the two identifiers into the base element.  The Austrian mappings in the RFC-to-be use the latter approach consistently.

--Martin

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Rosen, Brian
> Sent: Tuesday, 27 October 2009 3:00 AM
> To: [email-masked]
> Subject: [Geopriv] "House Number" misnamed?
>

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 26 Oct 2009 20:32:14 -0500

At 03:24 PM 10/26/2009, Brian Rosen wrote:
>things.

then why was civic created after geo existed?

;-)

>  BLD/FLR/UNIT/ROOM doesn't always work.  INT always works.

INT was just proposed - and it's yet a WG item, 
and you're claiming "it always works"?

interesting...

>The proposal is to use INT, but not actually deprecate BLD/FLR/UNIT/ROOM.
>

it;s Unit B. If the units are apartments, then the conversion is obvious.

>"Penthouse", which might be considered a UNIT or a FLR.

well - Penthouse is the name of a certain floor. 
This means you fill in both fields.

>do you do with Tower?

West Tower is a <NAM> additionally in the civic address.

Does the PISD-LO schema limit the number of <NAM> elements to 1 or less?
If not, then you supply all you need to that makes this address more unique.

>Is it a UNIT?  How about Floor?  If Apartment 6 has

you always go with which floor the front door is 
on, because that's also how the "suite" number is determined.

><INT N="Level">Upper</INT>

this is blowing up the idea of structure in 
PIDF-LO by having a free flowing wildcard element 
possible with an unlimited number of permutations 
of "" quoted text strings -- which, you're 
arguing, shouldn't ever be IANA registered.

I don't like it. It's making what we're defining 
more chaotic and not more structured.

James

---

From: Brian Rosen <[email-masked]>
Date: Tue, 27 Oct 2009 10:36:49 -0400

While I think a separate field is acceptable, and we had one actual use case
raised for it (a highway that has both mileposts and assigned house
numbers), I think we don't need a separate field.

We can straightforwardly go down to one element: a big long text field
filled with nation-specific rules and delimiters.  If that is the way you
want to make civics work, please write a draft.  If you think that parsing
addresses into multiple fields makes sense, then it's pretty hard to draw
lines, especially on prefix/suffix on the street name and the address
number, because that is so common in many nations.

Brian

On 10/26/09 7:44 PM, "Thomson, Martin" <[email-masked]> wrote:

> Misnamed as it may be, the actual label does not need to change if we want to
> extend its semantics.  The only problem comes about when you attempt to
> constrain semantics.  I see no problem with what you propose.
> 
> It's a simple enough change to note that HNO can refer to milestones or
> whatever.  The only question that arises is whether this is the right thing to
> do.  There was that proposal to add support for a separate "post number",
> which seemed to indicate that such things were commonplace, but orthogonal to
> house numbering.
> 
> I've always thought that all the suffix fields were largely redundant and just
> a source of extra complexity.  As it stands, any document author can choose to
> use the suffix, or just roll the two identifiers into the base element.  The
> Austrian mappings in the RFC-to-be use the latter approach consistently.
> 
> --Martin
>