Re: [Geopriv] "House Number" misnamed?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Geopriv] "House Number" misnamed?

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

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.


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.

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"?


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


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.
well - Penthouse is the name of a certain floor. This means you fill in both fields. 



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?


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
two floors, with the front door at Floor 7, but you have an upper and a
lower level, what do you do with FLR?
you always go with which floor the front door is on, because that's also how the "suite" number is determined. 



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



Brian


On 10/26/09 3:33 PM, "James Polk" <jmpolk at cisco.com> wrote:

> At 01:37 PM 10/26/2009, Rosen, Brian wrote:
>> BLD, FLR, UNIT, ROOM, SEAT would be "obsoleted", in the same sense A6 was
>> obsoleted by RD.
>
> 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
>
>
>> 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?
>
> I have no issues with apartment number being
> UNIT, which is a subset of HNO. We agree here.
>
>> "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>
>
> I'm not seeing what you gain by removing <UNIT> B</UNIT> from the above
>
>
>> We would encode I85N Milepost 123 as
>> <STP>Interstate</STP>
>> <RD>85</RD>
>> <POD>N</POD>
>> <HNP>Milepost</HNP>
>> <HNO>123</HNO>
>
> this example seems fine
>
> James
>
>
>
>> Brian
>>
>>
>> On 10/26/09 2:27 PM, "James Polk" <jmpolk at cisco.com> wrote:
>>
>>> At 01:05 PM 10/26/2009, Rosen, Brian wrote:
>>>> Yes, Apartment number currently goes in
>> ³UNIT², but my ³INT² proposal would
>>>> 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?
>>>
>>>
>>>> Brian
>>>>
>>>>
>>>> On 10/26/09 1:52 PM, "James Polk" <jmpolk at cisco.com> wrote:
>>>>
>>>>> At 11:00 AM 10/26/2009, Rosen, Brian wrote:
>>>>>> 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?
>>>>>
>>>>> 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
>>>>>> Geopriv at ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/geopriv
>>>>>
>>>>>
>>>
>>>
>
> _______________________________________________
> Geopriv mailing list
> Geopriv at ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.