Most of the use cases I know involve a floor plan.
You send a firefighter to a fire, and he has a set of floorplans, either flat 2D pictures, an Architectural CAD database, or something like a Building Information Model for the building.
You show a map of "you are here" overlaying a red X on a floorplan picture
You perform some kind of routing, like mail drop routing where you minimize the route of the mail cart
You track the location of equipment in a hospital and answer the question: where is the closest EKG monitor not currently in use?
All of these use the existing floor plan, and the existing signage in the building.
If your floor plan actually labels rooms as rooms and floors as floors, and has some simple notion of "Suites" or some such thing as a "UNIT", then it's possible to write code that examines the floor plan and forces the PIDF fields into the labels on the floor plan.
However, I've supplied many examples where you can't do that.
Some of the above examples could be implemented because the local knowledge of how the actual labels and space use were mapped into the fixed field names could be given to the implementer or put in some configuration file. Others (like the "you are here" if implemented on your iPhone) couldn't be done because there is no way the implementation can be told the mapping.
Please also note that it's a force fit: the space being named may not be a "ROOM", but since the fields are fixed, we have to force the actual space, say an elevator, into the fixed field. No other systems would claim an elevator is a room, and no other systems would attempt to label an elevator as a room. INT wouldn't. It would call an elevator an Elevator, and be able to locate Lobby Elevator 1 or Tower A Elevator 2. That would precisely map to what was on the floorplan, CAD database or BIM.
Brian
> -----Original Message-----
> From: Thomson, Martin [mailto:Martin.Thomson@andrew.com]
> Sent: Wednesday, July 15, 2009 11:58 PM
> To: Brian Rosen; Marc Linsner; geopriv@ietf.org
> Subject: RE: [Geopriv] draft-rosen-geopriv-pidf-interior
>
> You've made a fairly strong case for the inclusion of some additional
> information.
>
> In order to resolve our current conflict, I think that we actually need
> use cases. To what purpose do you intend to put this information?
>
> It's unclear how arbitrary labels could be used to establish any sort
> of common meaning. It appears that the intent is not to establish any
> such meaning, and rely on the ability of humans to make sense of the
> localized labels.
>
> There's a distinct difference between information that has some common
> semantic (as the current fields do) and what it is that (I think) you
> are proposing. We have common semantics for street addressing for at
> least one good reason: automated processing for emergency services.
>
> Within buildings there is certainly still some benefit to retaining
> this sort of common semantic. Firefighters can still benefit from
> knowing what floor something is on, and still benefit from being able
> to know where to look for this information. I'm sure that there are
> other use cases that can still equally benefit.
>
> To the extent that use cases are applicable regardless of building type
> (emergency services, pizza delivery, etc), common semantics are useful.
> More specific applications with particular needs and environments
> (warehouses) might need their own conventions...and additions.
>
> I don't agree with Richard that adding new definitions is especially
> onerous, but I can understand that a lowest common denominator system
> of labels with loose constraints such as you propose could be turned to
> any purpose.
>
> So, when it comes to establishing this system of labels, is the intent
> just to communicate with humans? It that is the case, then Richard's
> suggestion might be a good one - and I could justify it as a more
> verbose LOC element.
>
> --Martin
>
> > -----Original Message-----
> > From: Brian Rosen [mailto:br@brianrosen.net]
> > Sent: Thursday, 16 July 2009 12:20 PM
> > To: Thomson, Martin; 'Marc Linsner'; geopriv@ietf.org
> > Subject: RE: [Geopriv] draft-rosen-geopriv-pidf-interior
> >
> > No, specifically, INT is always interoperable and the fixed tags
> > aren't.
> >
> > I can build any number of applications that can use INT exactly the
> way
> > the
> > building documentation names spaces. I can't build any interoperable
> > implementations where the interior spaces are not completely
> obviously
> > mapped into the fixed tags.
> >
> > The point of INT is that the way the spaces are named is self defined
> > in the
> > structure. All applications can understand the naming conventions,
> and
> > they
> > can relate those conventions to the PIDF as well as the other
> available
> > documentation.
> >
> > With fixed tags, there is no way to do that. Unless you create the
> > documentation to show the mapping, or create a document that maps
> what
> > is
> > essentially the INT representation into fixed tags, you can't create
> > interoperable implementations of anything.
> >
> > Lots and lots of examples
> >
> > A lawyers office is Suite 202, but has two floors, they are called
> > "Upper"
> > and "Lower". If you looked outside, these are actually floors 2 and
> 3,
> > but
> > you can't get to room 27 on the upper floor by getting off the
> elevator
> > at
> > floor 3. You have to go to Suite 202 on floor 2 and go to the Upper
> > floor
> > using an interior staircase.
> >
> > What is the content of "FLR"? "3" or "upper"?
> >
> > Both might be appropriate. The fundamental problem is that in this
> > particular space, there are actually two things that equate to "FLR":
> > the
> > floor the Suite is on, and the interior floor. You want to say
> > "Building 2,
> > Suite 202, Upper Floor, Room 27" You may even want to say "Building
> 2,
> > Floor 2, Suite 202, Upper Floor, Room 27.
> >
> > The warehouse examples: Aisles, Racks, shelves. Are they
> UNIT/ROOM/FLR
> > or
> > UNIT/ROOM/SEAT or FLOOR/UNIT/ROOM or BLD/ROOM/UNIT?
> >
> > The fundamental problem with the fixed tags is that no other
> > documentation
> > uses them in many buildings. You have to map the existing naming
> > convention
> > into the tags. There is no way to document how you do that, no way
> to
> > pretty print or parse unambiguously into them.
> >
> > INTs use the conventions of the existing documentation, and trivially
> > extend
> > to any convention.
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
> > > Behalf Of Thomson, Martin
> > > Sent: Wednesday, July 15, 2009 9:43 PM
> > > To: Marc Linsner; geopriv@ietf.org
> > > Subject: Re: [Geopriv] draft-rosen-geopriv-pidf-interior
> > >
> > > The point that has been made is that INT would not be
> interoperable.
> > > Interoperability requires a shared understanding of semantics.
> > >
> > > I have no objection to providing better localization support, but
> > let's
> > > not destroy what is there to create something that is not usable by
> > > automated systems.
> > >
> > > --Martin
> > >
> > > > -----Original Message-----
> > > > From: Marc Linsner [mailto:mlinsner@cisco.com]
> > > > Sent: Wednesday, 15 July 2009 11:15 PM
> > > > To: Thomson, Martin; geopriv@ietf.org
> > > > Subject: Re: [Geopriv] draft-rosen-geopriv-pidf-interior
> > > >
> > > > Martin,
> > > >
> > > > So you are suggesting to utilize "LOC" vs. "INT"?
> > > >
> > > > We must remember that PIDF-LO is used by many to fulfill many
> > > different
> > > > use
> > > > cases. I would guess the opponents of expanding PIDF-LO find it
> > > > complete
> > > > for their use case(s). The proponents of expanding PIDF-LO would
> > > like
> > > > to
> > > > create an interoperable mechanism for expanded use cases.
> > > >
> > > > Afterall, "LO" means "Location Object" not "Location Outdoors".
> > ;^)
> > > >
> > > > We need an standard mechanism to express various location
> > attributes
> > > > used
> > > > inside a building/campus. The use cases include both physical
> and
> > > > 'cyber'
> > > > locations.
> > > >
> > > > -Marc-
> > > >
> > > >
> > > >
> > > > On 7/14/09 7:51 PM, "Thomson, Martin" <Martin.Thomson@andrew.com>
> > > > wrote:
> > > >
> > > > > a) no
> > > > > b) mu, but mostly no
> > > > > c) no
> > > > >
> > > > > This document is symptomatic of an inclination to solve any
> > > > addressing problem
> > > > > by adding elements, without regard to cost and complexity.
> > > > >
> > > > > There are already 30+ elements; and we're experiencing
> difficulty
> > > > selling
> > > > > folks on the need for numbers larger than 5. By adding
> > complexity,
> > > > we only
> > > > > continue to alienate those people and decrease the relevance of
> > the
> > > > existing
> > > > > product.
> > > > >
> > > > > The civic address considerations document describes a number of
> > > > techniques
> > > > > that can be used to deal with each of the specific problems
> that
> > > > you've
> > > > > raised. The semantics of the existing types are flexible
> enough
> > to
> > > > > accommodate most, if not all of your use cases.
> > > > >
> > > > > The document does not adequately describe how this might be
> > > conveyed
> > > > in DHCP.
> > > > >
> > > > > --Martin
> > > > >
> > > > >> -----Original Message-----
> > > > >> From: geopriv-bounces@ietf.org [mailto:geopriv-
> bounces@ietf.org]
> > > On
> > > > >> Behalf Of Rosen, Brian
> > > > >> Sent: Wednesday, 15 July 2009 7:07 AM
> > > > >> To: geopriv@ietf.org
> > > > >> Subject: [Geopriv] draft-rosen-geopriv-pidf-interior
> > > > >>
> > > > >> I would appreciate some comments on this draft:
> > > > >> a) Does it makes sense to you to do it this way instead of how
> > we
> > > > >> currently support "interior" location?
> > > > >> b) Do the specifics look right (basically, it's an ordered
> list
> > of
> > > > >> name/value pairs with no registry and a flag that suggests how
> > to
> > > > >> pretty
> > > > >> print the result)
> > > > >> c) Should we deprecate the existing mechanism in favor of
> this,
> > or
> > > > just
> > > > >> let the old one lie there?
> > > > >>
> > > > >> Several groups that tried to do interior addressing ran into
> the
> > > > kind
> > > > >> of
> > > > >> problems the existing mechanism couldn't handle and went for
> the
> > > > open
> > > > >> ended name/value pair idea.
> > > > >>
> > > > >> Brian
> > > > >> _______________________________________________
> > > > >> Geopriv mailing list
> > > > >> Geopriv@ietf.org
> > > > >> https://www.ietf.org/mailman/listinfo/geopriv
> > > > >
> > > > > ---------------------------------------------------------------
> --
> > --
> > > --
> > > > ---------
> > > > > ------------------
> > > > > 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]
> > > > > _______________________________________________
> > > > > Geopriv mailing list
> > > > > Geopriv@ietf.org
> > > > > https://www.ietf.org/mailman/listinfo/geopriv
> > > >
> > > >
> > >
> > > -------------------------------------------------------------------
> --
> > --
> > > -------------------------
> > > 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]
> > > _______________________________________________
> > > Geopriv mailing list
> > > Geopriv@ietf.org
> > > https://www.ietf.org/mailman/listinfo/geopriv
> >
>
> -----------------------------------------------------------------------
> -------------------------
> 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]
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
