Subject: [Geopriv] draft-rosen-geopriv-pidf-interior

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 14 Jul 2009 17:06:49 -0400

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

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 14 Jul 2009 18:51:11 -0500

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: [email-masked] [mailto:[email-masked]] On
> Behalf Of Rosen, Brian
> Sent: Wednesday, 15 July 2009 7:07 AM
> To: [email-masked]
> Subject: [Geopriv] draft-rosen-geopriv-pidf-interior
> 
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> 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]

---

From: Marc Linsner <[email-masked]>
Date: Wed, 15 Jul 2009 09:14:33 -0400

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" <[email-masked]> 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.
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 15 Jul 2009 09:06:50 -0400

I am trying to remove 5 tags (BLD, FLR, UNIT, ROOM, SEAT) and replace them with one (INT).
That's a simplification, not a complication.

I am trying to achieve a couple of reasonable goals:
  a) Given a PIDF, pretty print the location matching the local signage and plans
  b) Given a pretty printed location, create a valid PIDF

The address considerations document only works where there is an established pattern, and a document that describes how to encode a location using the pattern.  The example of Austrian addresses is certainly a good example.

Interior location doesn't have a pattern (it has many, many patterns), and there isn't, and couldn't reasonably be, a document for each pattern.  Address considerations also relies on the fact that the value of the country code element tells you which pattern (and document), and there is no corresponding way to know which pattern goes with which address.

The DHCP encoding comment is apt, and I'll cover it in the next version.

Brian

> From: Thomson, Martin [mailto:[email-masked]]
> Sent: Tuesday, July 14, 2009 7:51 PM
> To: Rosen, Brian; [email-masked]
> Subject: RE: [Geopriv] draft-rosen-geopriv-pidf-interior
> 
> 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.
>

---

From: <[email-masked]>
Date: Wed, 15 Jul 2009 23:24:32 +0200

>From my perspective: 

a)  yes
b)  yes
c) don't care

It is true that there are too many elements already, yet not enough to cover all use cases. If you do not want to increase the number of elements, just deprecate the ones which will not be necessary once this new 'INT' element gets defined (FLR, UNIT, ROOM, SEAT).

- Gabor

  >From: [email-masked] 
  >[mailto:[email-masked]] On Behalf Of ext Thomson, Martin
  >Sent: Tuesday, July 14, 2009 4:51 PM
  >Subject: Re: [Geopriv] draft-rosen-geopriv-pidf-interior
  >
  >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.
  >
  >> 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
  >immediately and delete the original.  Any unauthorized use 
  >of this email is prohibited.

---

From: [email-masked]
Date: Wed, 15 Jul 2009 17:34:16 -0400 (EDT)

I should perhaps know this, but is there an extension mechanism for PIDF?

When KML was being processed to become an OGC standard, one issue was how
any developer or organization could add extensions to core KML without
breaking any applications. After considered thought, we defined the KML
extension mechanism.. Works very well and allows for not just extensions
but also alpha development and testing of new KML functions without having
to wait for the next release of KML and have the advantage of market and
development testing.

Cheers

Carl
>> problem
>> selling
>> techniques
>>> pretty

---

From: "Allan Thomson (althomso)" <[email-masked]>
Date: Wed, 15 Jul 2009 14:45:30 -0700

a) no
b) no
c) no

The existing civic elements (building, floor...etc) provide a very
useful standard set of tags that allow a location aware system (e.g. a
server or client using location) to programmatically recognize important
building structures. I'm firmly against deprecation of the existing
elements.

One issue with your proposal suggests that for every customer
installation where that location aware system has to be installed has to
now learn the tag for "building" is making products harder to deploy.
Requires customization per installation. That costs money to the
installer and product producers. 

I also now have to configure all mobile products that will use the
location services in that environment to know what the term is for
"floor" so that I can learn where the nearest XXX resource is on my
floor.

Maybe your proposal is better thought of as a
language/internationalization solution. Where the tags that are defined
in PIDF are the base tags and there should be a mapping to localization
for those tags so that users/customers can map those tags to the local
tag. But such a scheme still needs a base tag (e.g. web/java
internationalization). If this proposal was thought of in this regard it
may be easier for people to agree that localization of the base PIDF
tags should be considered and a mechanism should exist to do that. But
replacing the base tags with a variable set of local tags is not
helpful.

allan thomson

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of [email-masked]
Sent: Wednesday, July 15, 2009 2:25 PM
To: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Geopriv] draft-rosen-geopriv-pidf-interior

a)  yes
b)  yes
c) don't care

It is true that there are too many elements already, yet not enough to
cover all use cases. If you do not want to increase the number of
elements, just deprecate the ones which will not be necessary once this
new 'INT' element gets defined (FLR, UNIT, ROOM, SEAT).

- Gabor

  >[mailto:[email-masked]] On 
  >> Behalf Of Rosen, Brian

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 15 Jul 2009 19:04:39 -0500

Allan said what I didn't originally.

We are using floor, room and seat tags in applications.  Those tags have semantics that our applications understand.  Removing or replacing these very useful tags would destroy those applications.

The amount of effort required to make sense of arbitrary tags would be massive.  Sounds like natural language processing to me.

--Martin

> From: Allan Thomson (althomso) [mailto:[email-masked]]
> Sent: Thursday, 16 July 2009 7:46 AM
> To: [email-masked]; Thomson, Martin; [email-masked];
> [email-masked]

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 15 Jul 2009 20:55:17 -0400

Actually, it's exactly the opposite: the tags provided aren't useful for
a very wide variety of buildings, and the INT proposal is much easier to
implement and understand.

While there certainly are buildings where the signage and the floor
plans, and any other derived data has a notion of building/floor/unit
and room, there are many, many addresses that do not.

Here are a number of examples:

Airport Terminal/Concourse/Gate
Railroad Terminals with Track numbers
Pier/Slip
Warehouses with aisles, racks and shelves
Hotel tower/floor/room (which is NOT building, you can have
building/tower/floor/room), and, within the same hotel, you can have
rooms in suites, ballrooms without floors and towers, "Lobby" which may
not have any other annotations, although it may.
A building with a "West Wing" and an "East Wing", such as the White
House
Buildings with large open areas with spaces named by a support column
label

In every case, you would force us to fit what all the rest of the
available documentation and data refer to into
Building/Floor/Unit/Room/.. without a way to document how this is done
for any given building

The problems with the fixed elements are:
There is no obvious way to write a document that would explain to a
programmer, or a user, how you map the wide variety of naming
conventions in use to the fixed elements.  It would be completely
arbitrary, and differ from building to building, despite any
similarities that the signage may have.

Consequently, there is no way to create a PIDF unless you know a priori
what conventions were used.  The local LIS may know, but there isn't any
way to create a PIDF unless you are the building owner/tenant.

There is no way to parse a string version of the location to XML, or
vice versa

There is no way to relate the XML tags to all the rest of the
documentation such as floor plans and signage, unless you are aware of
the (arbitrary) decisions on how to map those conventions into the fixed
fields.

There is very often an explicit hierarchy to interior space names, but
there isn't any way to express that hierarchy.  For example, some suites
have multiple floors, some floors have multiple suites.

INT is backwards compatible with the fixed elements (use the existing
element name as the type and the existing value as the value), the fixed
elements can't do what INT can do.

INT is trivial to program and use, because it maps exactly into existing
conventions.  

As a trivial exercise, suppose I gave you a Architectural CAD database,
and I asked you to write a program to display a PIDF location ("You are
here"). 

There is no way you could do that with the fixed tags.  The program
would have know how the mapping is done, which is non trivial to map to
the CAD (which only has spaces you can find, and text that names it).
You could, in most cases, do it with INT, because the things you find on
the floor plan match the tags in the PIDF.  

I think your product would be much easier to write and document with
INT:
You type in the name of the space, either in total or hierarchically,
and highlight the names (as opposed to the values).  Done.

To do it with the fixed labels, you have to get the customer to tell you
how they want to map what they have to the fixed elements you force them
to use, and you have to have the program be able to do that mapping.

The airport manager want to give you terminal/councourse/gate, not
building/unit/room, or maybe the terminal is a separate address, the
"concourse" goes in "BLD" and the gate goes in UNIT.  See the problem?

It's trivial to create INTs with names "Building" "Floor" "Unit" and
"Room".  It is not so trivial to decide how to map
Terminal/Concourse/Gate into them, especially in an interoperable, and
useful to many applications manner.

Brian
> Sent: Wednesday, July 15, 2009 5:46 PM
> To: [email-masked]; [email-masked]; Rosen, Brian;
> [email-masked]

---

From: <[email-masked]>
Date: Thu, 16 Jul 2009 03:02:03 +0200

>From: ext Thomson, Martin [mailto:[email-masked]] 
  >Sent: Wednesday, July 15, 2009 5:05 PM
  >To: Allan Thomson (althomso); Bajko Gabor 
  >(Nokia-CIC/MtView); [email-masked]; [email-masked]

Those only make sense if you think of an application which expects FLR, UNIT, ROOM, or SEAT CAs, and are not extensible.
If you are concerned about these applications, then do not deprecate these CAs.

  >We are using floor, room and seat tags in applications.  
  >Those tags have semantics that our applications understand.  
  >Removing or replacing these very useful tags would destroy 
  >those applications.

Then keep them.

  >The amount of effort required to make sense of arbitrary 
  >tags would be massive.

That shouldn't be your concern. You are not required to understand the new tag.

- gabor

  >  Sounds like natural language 
  >processing to me.
  >
  >--Martin
  >
  >> server or client using location) to programmatically recognize 
  >> important building structures. I'm firmly against 
  >deprecation of the 
  >> existing elements.
  >> 
  >> installation where that location aware system has to be 
  >installed has 
  >> to now learn the tag for "building" is making products harder to 
  >> deploy.
  >> language/internationalization solution. Where the tags that are 
  >> defined in PIDF are the base tags and there should be a mapping to 
  >> localization for those tags so that users/customers can 
  >map those tags 
  >> to the local tag. But such a scheme still needs a base tag (e.g. 
  >> web/java internationalization). If this proposal was thought of in 
  >> this regard it may be easier for people to agree that 
  >localization of 
  >> the base PIDF tags should be considered and a mechanism 
  >should exist 
  >> to do that. But replacing the base tags with a variable 
  >set of local 
  >> tags is not helpful.
  >> 
  >> allan thomson
  >> 
  >> elements, just deprecate the ones which will not be necessary once 
  >> this new 'INT' element gets defined (FLR, UNIT, ROOM, SEAT).
  >> 
  >> - Gabor
  >> 
  >>

---

From: "Allan Thomson (althomso)" <[email-masked]>
Date: Wed, 15 Jul 2009 18:38:57 -0700

Brian - Specifically to the example you quote

"The airport manager want to give you terminal/councourse/gate, not
building/unit/room, or maybe the terminal is a separate address, the
"concourse" goes in "BLD" and the gate goes in UNIT.  See the problem?"

In products that show graphical representations of a terminal it is
obvious the terminal is the building; concourse the floor (where the
floor is represented by a floormap of the concourse) and gate is an area
within the floor.

There is no problem using the existing civic tags.

I'm not trying to suggest INT tags are not useful for localization of
the base tags in PIDF-LO where a local tag name may help certain
applications. If we can think of your proposal as a mapping that can be
used by certain applications, rather than a replacement I'm more
comfortable with that approach. 

That way we get the best of both worlds. No?

allan

> important
defined
> elements, just deprecate the ones which will not be necessary once
this

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 15 Jul 2009 20:42:51 -0500

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

> From: Marc Linsner [mailto:[email-masked]]
> Sent: Wednesday, 15 July 2009 11:15 PM
> To: Thomson, Martin; [email-masked]
> addressing problem
> >> Several groups that tried to do interior addressing ran into the
> kind
> >> of
> > ---------------------------------------------------------------------
> ---------
> > ------------------
> > ---------------------------------------------------------------------
> ---------
> > ------------------
> > [mf2]

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 15 Jul 2009 21:59:51 -0400

Actually, no.  In most terminals, there are floors.  You can't use FLR for
concourse.

Think about nearly every terminal that has an upper floor where the loading
bridge is located, and a lower floor where you sometimes have to go to in
order to get to a small plane with its own air stairs: same concourse and
gate, different floor.

You can map the exiting tags into INTs, you can't go the other way.

It has to be clear to you that not every building, and in fact a great many
buildings, do not have an obvious mapping from their actual interior naming
conventions to any fixed set of tags.  There is way too much variability.

How about elevators?  Are they "UNITS" or "ROOMS"?

If I have "Suite A", is the value "UNIT" 'A' or 'SUITE A'?  Is FLR in "Floor
5" '5' or 'Floor 5'?  What if it's labeled "5"?  What if it's labeled "5th"?
What if it's labeled in some other language?

Suppose the 3rd level of the building is labeled "Lobby".  Is the content of
FLR '3' or 'Lobby'?

All of these are obvious with INT, and difficult with the existing labels.

The existing labels only work when the all the existing documentation uses
those labels.  It doesn't work when they don't.

Brian

> Behalf Of Allan Thomson (althomso)
> Sent: Wednesday, July 15, 2009 9:39 PM
> To: Rosen, Brian; [email-masked]; [email-masked];
> [email-masked]

---

From: Richard Barnes <[email-masked]>
Date: Wed, 15 Jul 2009 22:11:56 -0400

I actually kind of like Brian's document, but not because of anything 
related to interior geometry.  Rather, it seems like a good way to make 
the civic address structure extensible.

As some of Martin's comments earlier demonstrate, it can be kind of a 
pain to extend the current civic address structure (mainly because it 
requires defining and parsing a new namespace).

So I wonder if it might be reasonable to use something like the 
structure Brian proposes for interior fields as an alternative 
representation for all fields, with an IANA registry for types (just use 
the CAtypes registry?).  This would make extension as simple as adding a 
value to the registry, and wouldn't require any change to the XML 
structure.  In a lot of ways, this is closer to the way that RFC 5139 
structures things.

As a second-order issue, couldn't we separate the pretty-printing issue 
from the semantic issue using something like a "label" attribute?

--Richard

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 15 Jul 2009 22:57:49 -0500

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

> From: Brian Rosen [mailto:[email-masked]]
> Sent: Thursday, 16 July 2009 12:20 PM
> To: Thomson, Martin; 'Marc Linsner'; [email-masked]
> 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
> 
> > Behalf Of Thomson, Martin
> > Sent: Wednesday, July 15, 2009 9:43 PM
> > To: Marc Linsner; [email-masked]
> > 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
> >
> > > We must remember that PIDF-LO is used by many to fulfill many
> > different
> > > use
> > > for their use case(s).  The proponents of expanding PIDF-LO would
> > like
> > > to
> > > We need an standard mechanism to express various location
> attributes
> > > used
> > > > 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 document does not adequately describe how this might be
> > conveyed
> > > in DHCP.
> > > >
> > > > --Martin
> > > >
> > > > -----------------------------------------------------------------
> --
> > --
> > > ---------
> > > > ------------------
> > > > -----------------------------------------------------------------
> --
> > --
> > > ---------
> > > > ------------------
> > > > [mf2]
> --
> > -------------------------
> --
> > -------------------------
> > [mf2]

---

From: [email-masked]
Date: Wed, 15 Jul 2009 23:43:02 -0400 (EDT)

Anyone familiar with building information models and the NBIM standard? If
not, check out because defining content models and the corresponding XML
schema is all about the interoperable exchange of building interior
information. As such, they have defined extensive vocabularies related to
buildings. More info can be found at
http://www.buildingsmartalliance.org/nbims/

Regards

Carl

>>   >conveyed in DHCP.

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 16 Jul 2009 09:14:59 -0400

Okay, let's talk about use cases.

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

> Sent: Wednesday, July 15, 2009 11:58 PM
> To: Brian Rosen; Marc Linsner; [email-masked]
> 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
> 
> > > > inside a building/campus.  The use cases include both physical
> and
> > > > 'cyber'
> > > > locations.
> > > >
> > > > -Marc-
> > > >
> > > >
> > > >
> difficulty
> > > > > 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
> > > > >> From: [email-masked] [mailto:geopriv-
> [email-masked]]
> > > On
> > > > >> Behalf Of Rosen, Brian
> > > > >> b) Do the specifics look right (basically, it's an ordered
> list
> > of
> > > > >> c) Should we deprecate the existing mechanism in favor of
> this,
> > or
> > > > just
> > > > >> problems the existing mechanism couldn't handle and went for
> the
> > > > open

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 15 Jul 2009 22:19:56 -0400

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.

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.

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

> I have no objection to providing better localization support, but let's

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 15 Jul 2009 22:21:39 -0400

It's pretty hard to have a registry for interior spaces: there are so many
of them.

Brian

> From: Richard Barnes [mailto:[email-masked]]
> Sent: Wednesday, July 15, 2009 10:12 PM
> To: Brian Rosen
> Cc: 'Allan Thomson (althomso)'; Rosen, Brian; [email-masked];
> [email-masked]; [email-masked]
> >>> useful standard set of tags that allow a location aware system
> (e.g.
> >> a
> >>> installation where that location aware system has to be installed
> has
> >>> to
> >>> internationalization). If this proposal was thought of in this
> regard
> >>> it

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 16 Jul 2009 17:40:24 -0400

Brian,

I think you're missing the point - if I have an INT with the name  
"Raum" (to pick the German translation of "room"), all parties have to  
know what this means - otherwise, it's just a random string of  
letters. This is sufficient if the goal is to do label matching - the  
fireman needs to be able to recognize the label he saw on the map when  
entering the building.

In many cases, that's probably all that's needed and it wouldn't  
matter if the sub-division was called "xk17" instead, as long as the  
door signs all had "xk17" on them. You can imagine the confusion,  
however, if the INT label was just "xk17", and the fireman had to  
guess that this corresponded to the thing labeled 435 on the sign next  
to the door.

You are, however, assuming that the labels are meaningful to all the  
participants and parties. This isn't a given:

- Language: Many international companies use English internally, even  
if they are, say, located in Finland. Do you use "huone" or "room"? If  
location information is entered in a decentralized fashion, you  
probably get both, in addition to "Rm" and several other variations.  
This isn't a problem for the existing tags - a user interface can  
trivially render them in any suitable language. With INT, even if  
Nokia decided to use the English designation throughout their  
buildings, this would still be rather confusing to the local fire  
department.

- Convention: In many cases, things aren't tagged, they just have  
numbers or letter-number combinations on them. I suspect if you asked  
somebody in the building other than the building manager, you'd get  
three different descriptions or labels. Not a problem if location is  
entered centrally, a pain if every sys admin in every department does  
something slightly different, let alone if you leave that to users.

- Hierarchy: There doesn't appear to be a hierarchy implied. At least  
with the existing labels, I can guess that if I get "Kerros 3, Huone  
25" on a business card, that this is likely a floor and room. (These  
are on-line dictionary translations; my Finnish is too limited...)  
With no hierarchy in INT, I could get any permutation.

I don't thing anyone is disagreeing that you sometimes have things  
that aren't rooms in a traditional sense. However, it is unclear that  
adding tags helps much, beyond adopting the conventions that we  
already do today. (We would use 3L and 3U for the floors, if that's  
what's on the elevator button.)

Thus, for these reasons, I see only a limited applicability for INT.  
The "standard" terms will likely work in the vast majority of cases we  
care to identify for location purposes, possibly with the kind of  
simple local conventions that FLR = elevator button label.

Thus, I remain strongly opposed to deprecating the old terms.

Henning

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 16 Jul 2009 19:29:51 -0400

Of course we both think the other is missing the point :)

Raum is not a random string of letters: it's what you would find in ALL
other data that referred to the interior spaces.  You would not find "Room"
on any other data.

In order to go from Raum, which what is on all the other documents, to Room,
you need a mapping.  That in turn needs some kind of machine readable
document, which doesn't exist.  It's not possible to write a program that
deals with "Room", because you don't know the relationship between the fixed
tags and all the other documentation.

Of course, you can make assumptions, but assumptions are dangerous.  The
only thing that really works is to make the data in a PIDF match the other
documentation, which is what INT does.

The point of INT is to duplicate the signage (and the CAD database).  If the
doors have xk17 435 on them, then you want the INT name to be xk17 and the
value to be 435.

You actually have the opposite problem, if the PIDF says "Room" and the door
says "xk17" you have to guess that xk17 means "Room" and not "Unit"

On your points:
a) What you want is to have the INT tags match the other documentation (CAD
drawings or signage).  If they vary, that's okay.  What matters is that they
match.  You can't do that with fixed tags unless it happens that the tags
match the documentation.  There is no downside to having some buildings use
Room and others use huone if that is what the other documentation does.

b) It also doesn't matter if in one building they use "Room" and in another
one they use "space".  If the only signage and documentation they have is
the value, then the name of the tag doesn't matter.  There aren't any use
cases I know of where you need to compare the names of the tags in one
building to those in another.

c) The INT proposal has hierarchy: order of the INTs matters.  The problem
with the tags is that the hierarchy doesn't always work.  A common problem
is where "UNIT" goes: in some places, UNIT goes before floors. In others, it
goes after floors.  In some places, UNIT goes before Building.

Let's try to stick with use cases.

What is the use case where INT doesn't work, and fixed tags do?

I've given several where INT works, and fixed tags don't.

Brian

> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Thursday, July 16, 2009 5:40 PM
> To: Brian Rosen
> Cc: 'Thomson, Martin'; 'Marc Linsner'; [email-masked]
> >>>> ------------------------------------------------------------------
> -
> >> --
> >>> ---------
> >>>> ------------------
> >>>> ------------------------------------------------------------------
> -
> >> --
> >>> ---------
> >>>> ------------------
> >>>> [mf2]
> >> --------------------------------------------------------------------
> ---
> >> --------------------------------------------------------------------
> ---

---

From: Karl Heinz Wolf <[email-masked]>
Date: Tue, 28 Jul 2009 11:46:03 +0200

Brian,

one question on section 7.2 CAtype Registry Update. If you add CAType
40 for INT, how do you want to use this CAType, lets say, in DHCP?
There are just values, and no attributes.

PIDF-LO: <INT N='Room' R='A'>Westerns and Classics</INT>

DHCP: CAtype: 40, Value: Westerns and Classics
where should 'Room' go?

Do you have a thought on this?

cheers
karl heinz

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 28 Jul 2009 07:39:57 -0400

Hmmm.  Probably have to do something about that.

Brian

> From: Karl Heinz Wolf [mailto:[email-masked]]
> Sent: Tuesday, July 28, 2009 5:46 AM
> To: Rosen, Brian
> Cc: [email-masked]
> On Tue, Jul 14, 2009 at 11:06 PM, Rosen,
Brian<[email-masked]>
> wrote:
kind