>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@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@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@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@ietf.org
> >>>>>> https://www.ietf.org/mailman/listinfo/geopriv
> >>>>>
> >>>>>
> >>>
> >>>
> >
> > _______________________________________________
> > Geopriv mailing list
> > Geopriv@ietf.org
> > https://www.ietf.org/mailman/listinfo/geopriv
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
