Subject: [Geopriv] Proposal to change the way we describe interior spaces in PIDF-LO

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 25 Mar 2009 23:42:16 -0400

In RFC5139, we defined a significant number of elements that are used to
describe civic location within an addressable structure.  Those include
BLD, UNIT, ROOM and SEAT.  In discussing PIDF with various experts, I
have come to the conclusion that we have made a mistake: too many
structures don't use the Building/Unit/Room/Seat arrangement.  A good
example is an airport, which commonly uses a Terminal/Concourse/Gate
arrangement. 

While we can always use the mechanisms similar to those the Austrian's
propose to force fit interior location elements into the available
fields, I think we should change the mechanism.  Rather than use
BLD/UNIT/ROOM/SEAT...., I propose we create a new element called "INT"
that can appear multiple times.  INT has name/value subelements.  The
order of INTs matters.  This allows Building/Unit/Room/Seat, but also
allows Terminal/Coucourse/Gate.

So
...
<INT nam="Terminal" val="1"/>
<INT nam="Concourse" val="A"/>
<INT nam="Gate" val="22"/>
...

Implementation would be like we handled street name: add the fields, and
recommend they be used rather than BLD/UNIT/FLR/ROOM/SEAT

Brian

---

From: Marc Linsner <[email-masked]>
Date: Fri, 27 Mar 2009 16:42:24 -0400

Brian,

I/we thought about this and concluded that regardless of where you do it,
you still have to register all the tags in order to provide interoperability
amongst vendors.  So I think this idea is simply pushing the registry off to
someone/something else. Yes, the interior tags you're referring to are
locally significant, but there are still multiple vendors in that space.

Yeah, I do foresee the civic location tag set increasing, but so?, it just
doesn't matter.  I'd rather have a complete registry of all tags for those
that chose to support them than unregistered tags and people guessing about
their usage.

-Marc-

On 3/25/09 8:42 PM, "Rosen, Brian" <[email-masked]> wrote:

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

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 27 Mar 2009 16:49:34 -0400

I propose no registry.  The names are only locally significant.  Commonality
of vendors is not the issue, the issue is commonality of building
designators.

With civic, you are constrained to what the signage and floorplans say the
space is called.  You don't need interoperability of the tags.  You only
need the address to be consistent with its floorplans and signage.  There is
no systematic way to classify the components.  That is the problem.

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Marc Linsner
Sent: Friday, March 27, 2009 4:42 PM
To: Rosen, Brian; GEOPRIV
Subject: Re: [Geopriv] Proposal to change the way we describe interior
spaces in PIDF-LO

Brian,

-Marc-

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 27 Mar 2009 17:08:48 -0400

The problem is that the unregistered tags are language-specific since  
they are exposed to humans. Which language do you choose for 'gate' in  
Canada?

---

From: Marc Linsner <[email-masked]>
Date: Fri, 27 Mar 2009 17:11:43 -0400

Brian,

Wouldn't you agree that the provider of the LIS (Cisco) and provider of the
floor plans (using AutoCAD) should have a common understanding of 'seat',
'cubicle', 'room', etc.?  Hence, you need a registry of those tags.

You are asking for all the tools to be customized by each and every building
admin (add each tag to each tool).  Sure, some admins may not utilize
'cubicle', but it should be in both the LIS and AutoCAD if they decide to
use it.

Building management/energy controllers are now looking at GeoPriv location
to use in their tools.  Yeah, the building admin and network admin will
agree on a set of tags for their environment, but all the tags should be
supported in the tools from the various vendors without requiring the
customer to add them to each and every tool.  That stuff comes from a
'standards-based-registry'.

-Marc-

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 27 Mar 2009 17:22:33 -0400

I'm telling you that I have consulted experts who have looked into this very
problem and concluded that there is no common understanding, and forcing one
is not possible except in centrally planned environments.

There is no common understanding of what "room" means.
Is a hallway a room?

There is no common understanding of what "floor" means.

There is no common understanding of what "building" means

Brian

-----Original Message-----
From: Marc Linsner [mailto:[email-masked]] 
Sent: Friday, March 27, 2009 5:12 PM
To: Brian Rosen; 'GEOPRIV'
Subject: Re: [Geopriv] Proposal to change the way we describe interior
spaces in PIDF-LO

Brian,

-Marc-

---

From: Marc Linsner <[email-masked]>
Date: Fri, 27 Mar 2009 17:38:01 -0400

Did you 'consulted experts' suggest that tools that deal with location
should be void of tags?

All I'm saying is the tags should be built into the tools out of the box,
customers shouldn't have to add them.  I don't think you'll get that without
a registry of the tags that vendors can look at when designing the tools.
Although I believe we could provide guidance on their usage (copy
Webster's?), the meaning of the tag is locally significant.

-Marc-

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 27 Mar 2009 17:58:48 -0400

The experts suggested not having a registry of tags.  There was no value.

If a hotel calls a suite a Room, and another one calls one of the sleeping
areas in a Suite a Boudoir, what tags would I use, and what value would
registering them be?

-----Original Message-----
From: Marc Linsner [mailto:[email-masked]] 
Sent: Friday, March 27, 2009 5:38 PM
To: Brian Rosen; 'GEOPRIV'
Subject: Re: [Geopriv] Proposal to change the way we describe interior
spaces in PIDF-LO

-Marc-

---

From: Marc Linsner <[email-masked]>
Date: Sat, 28 Mar 2009 00:53:23 -0400

Brian,

You're not listening!

> areas in a Suite a Boudoir, what tags would I use, and what value would

If your client doesn't understand a tag, it ignores it.  Are you suggesting
that your client should do such and not render such a tag to the UI?

I'm not suggesting the IETF dictate what a hotel calls their spaces they
rent.  I'm stating we need a registry of tags such that when you walk into
that hotel, your location client will not vomit with it sees 'Suite'.

-Marc-

---

From: "Brian Rosen" <[email-masked]>
Date: Sat, 28 Mar 2009 15:12:20 -0400

I'm trying to.

I'm suggesting that there is no structure to the tags other than some vague
notion of order.
Since there is no structure, there is no point in trying to register them;
there is no one to get confused that in one hotel there is a "Room" tag, and
in another there is a "Suite" tag.  The tag doesn't matter, only the order
matters.  As I said, you could skip the two part name/value and just have a
single string, but it's pretty universal to have a scheme, and thus I think
that the name/value pair notion is worth keeping.  If we decided not to
bother, not much would change, you would just have a set of (ordered)
strings:
"Tower 6", "Suite 113", "Master Bedroom".  I'd be okay with that, I just
think explicitly exposing the scheme is worthwhile.

Brian

-----Original Message-----
From: Marc Linsner [mailto:[email-masked]] 
Sent: Saturday, March 28, 2009 12:53 AM
To: Brian Rosen; 'GEOPRIV'
Subject: Re: [Geopriv] Proposal to change the way we describe interior
spaces in PIDF-LO

Brian,

You're not listening!

-Marc-

>>> need the address to be consistent with its floorplans and signage.
There
>> is
>>> amongst vendors.  So I think this idea is simply pushing the registry
off
>> to

---

From: <[email-masked]>
Date: Sun, 29 Mar 2009 19:40:25 +0200

I also believe what Brian suggests is the right way to go. The LIS would have floorplans in vector format (SVG, or GIS-friendly GDF) with the INT name/value subelements as tags. 

The way if goes today is that the client device identifies the building and the floor, accesses LIS and downloads the corresponding floorplan. The floorplan is then displayed with whatever tags it was created. In language sensitive regions, the LIS could contain eg an English and a French floorplan, and the client device would download the one with its preferred language tags. There is no need to register anything, not even any guidance necessary.

- gabor

  >From: [email-masked] [mailto:[email-masked]] On
  >Behalf Of ext Marc Linsner
  >Sent: Friday, March 27, 2009 2:38 PM

---

From: [email-masked]
Date: Sun, 29 Mar 2009 15:01:56 -0400 (EDT)

Has anyone looked at the standards work related to BIM? Check out the NIBS
and BuildingSMART web sites. Would be good to stray aligned with the
standard developed or in progress being done by the building industry.

Cheers

Carl

 I also believe what Brian suggests is the right way to go. The LIS would
> have floorplans in vector format (SVG, or GIS-friendly GDF) with the INT
> name/value subelements as tags.
>
> The way if goes today is that the client device identifies the building
> and the floor, accesses LIS and downloads the corresponding floorplan. The
> floorplan is then displayed with whatever tags it was created. In language
> sensitive regions, the LIS could contain eg an English and a French
> floorplan, and the client device would download the one with its preferred
> language tags. There is no need to register anything, not even any
> guidance necessary.
>
> - gabor
>
>
>   >> I'm telling you that I have consulted experts who have looked into
> this
>   >very
>   >> Wouldn't you agree that the provider of the LIS (Cisco) and provider
> of
>   >the
>   >> 'cubicle', but it should be in both the LIS and AutoCAD if they
> decide
>   >to
>   >> use it.
>   >>
>   >>> With civic, you are constrained to what the signage and floorplans
> say
>   >the
>   >Behalf
>   >>> I/we thought about this and concluded that regardless of where you
> do
>   >it,
>   >>> Yeah, I do foresee the civic location tag set increasing, but so?,
> it
>   >just
>   >>> that chose to support them than unregistered tags and people
> guessing
>   >> about
>   >>> their usage.
>   >>>
>   >>> -Marc-
>   >>>
>   >>>
>   >>>> In RFC5139, we defined a significant number of elements that are
> used
>   >to
>   >>>> Implementation would be like we handled street name: add the
> fields,
>   >and

---

From: "Brian Rosen" <[email-masked]>
Date: Sun, 29 Mar 2009 15:14:30 -0400

I'm somewhat familiar with BIM.  It's what we'll use in NG9-1-1 for floor
plans, etc.  It's  a pretty complex spec, but it's standard and it's
complete.  We're using it in combination with some sensor work NIST is doing
(BISACS).

It would be hard to get the structure we're talking about out of a BIM, but
you should be able to use a BIM to locate where you are in the building
given the ordered pairs.

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Sunday, March 29, 2009 3:02 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Geopriv] Proposal to change the way we describe interior
spaces in PIDF-LO

Cheers

Carl

---

From: "Winterbottom, James" <[email-masked]>
Date: Sun, 29 Mar 2009 14:17:13 -0500

The LIS does not serve out floorplans, the LIS only serves out locations. If you want to render that onto some local application display that is fine, but it is not the role of the LIS to do that or to supply the floor plan they come from somewhere else. These are not functions that we should conflate.

Cheers
James

-----Original Message-----
From: [email-masked] on behalf of [email-masked]
Sent: Sun 3/29/2009 12:40 PM
To: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Geopriv] Proposal to change the way we describe interior spaces in PIDF-LO

- gabor

------------------------------------------------------------------------------------------------
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: <[email-masked]>
Date: Sun, 29 Mar 2009 21:30:31 +0200

There we are again.
Ok, call it FIS (floorplan information server). There are already such databases out there in the market, I don't know if they have a name yet.

- gabor

  >From: ext Winterbottom, James [mailto:[email-masked]]
  >Sent: Sunday, March 29, 2009 12:17 PM
  >To: Bajko Gabor (Nokia-CIC/MtView); [email-masked];
  >[email-masked]; [email-masked]
  >Subject: RE: [Geopriv] Proposal to change the way we describe interior
  >spaces in PIDF-LO
  >
  >The LIS does not serve out floorplans, the LIS only serves out locations.
  >If you want to render that onto some local application display that is
  >fine, but it is not the role of the LIS to do that or to supply the floor
  >plan they come from somewhere else. These are not functions that we
  >should conflate.
  >
  >Cheers
  >James
  >
  >
  >
  >
  >and the floor, accesses LIS and downloads the corresponding floorplan.
  >The floorplan is then displayed with whatever tags it was created. In
  >language sensitive regions, the LIS could contain eg an English and a
  >French floorplan, and the client device would download the one with its
  >preferred language tags. There is no need to register anything, not even
  >any guidance necessary.
  >
  >- gabor
  >
  >
  >  >> agree on a set of tags for their environment, but all the tags
  >should
  >  >be
  >  >>> doesn't matter.  I'd rather have a complete registry of all tags
  >for
  >  >those

---

From: "Winterbottom, James" <[email-masked]>
Date: Sun, 29 Mar 2009 14:34:25 -0500

Hey Gabor,

I just want to make the distinction between the thing that determines the location, the LIS, and some application that uses it.

Cheers
James

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Sun 3/29/2009 2:30 PM
To: Winterbottom, James; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Geopriv] Proposal to change the way we describe interior spaces in PIDF-LO
 
There we are again.

- gabor

---

From: "Dawson, Martin" <[email-masked]>
Date: Sun, 29 Mar 2009 19:46:10 -0500

GIS?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of [email-masked]
Sent: Monday, 30 March 2009 6:31 AM
To: Winterbottom, James; [email-masked]; [email-masked];
[email-masked]
Subject: Re: [Geopriv] Proposal to change the way we describe interior
spaces in PIDF-LO

There we are again.
Ok, call it FIS (floorplan information server). There are already such
databases out there in the market, I don't know if they have a name yet.

- gabor

  >  >All I'm saying is the tags should be built into the tools out of
the
  >box,
  >  >customers shouldn't have to add them.  I don't think you'll get
that
  >  >without
  >  >> floor plans (using AutoCAD) should have a common understanding
of
  >  >'seat',
  >  >> You are asking for all the tools to be customized by each and
every
  >  >building
  >  >> Building management/energy controllers are now looking at
GeoPriv
  >  >location
  >  >> to use in their tools.  Yeah, the building admin and network
admin
  >will
  >  >> supported in the tools from the various vendors without
requiring
  >the
  >  >> customer to add them to each and every tool.  That stuff comes
from
  >a
  >  >>> space is called.  You don't need interoperability of the tags.
You
  >  >only
  >  >>> someone/something else. Yes, the interior tags you're referring
to
  >are
  >  >>> locally significant, but there are still multiple vendors in
that
  >  >space.
  >  >>>> describe civic location within an addressable structure.
Those
  >  >include
  >  >>>> structures don't use the Building/Unit/Room/Seat arrangement.
A
  >good
  >  >>>> BLD/UNIT/ROOM/SEAT...., I propose we create a new element
called
  >  >"INT"
  >  >>>> that can appear multiple times.  INT has name/value
subelements.
  >The
  >  >>>> order of INTs matters.  This allows Building/Unit/Room/Seat,
but
  >also
 
>-----------------------------------------------------------------------
--
  >-----------------------
 
>-----------------------------------------------------------------------
--
  >-----------------------

---

From: "Dawson, Martin" <[email-masked]>
Date: Sun, 29 Mar 2009 19:46:16 -0500

I have a question on applicability. The proposal appears to be for
"local significance" civic address fields yes? I think that's fine for
local devices and local applications (and local shops for local
people...). Emergency services is a great example of a local application
that could take advantage of such fields.

Given the other scenarios of applications on foreign devices visiting a
local network or sending PIDF-LO to foreign applications, what is your
commentary on the utility/impact of this approach Brian?

Cheers,
Martin

-----Original Message-----
Sent: Monday, 30 March 2009 4:40 AM

- gabor

this
  >> Wouldn't you agree that the provider of the LIS (Cisco) and
provider of
decide
should
say
You
do
it
for
guessing
used
fields,

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 30 Mar 2009 09:25:44 -0400

I'm not sure how far you could push this idea, but we (NENA) were planning
on defining a new service for LoST which returns a URI to a database
maintained by the building owner that has, among other things, floor plans.
It also happens to have the BISACS data.  It's in fact the NIST BISACS
portal.

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Sunday, March 29, 2009 3:31 PM
To: [email-masked]; [email-masked]; [email-masked];
[email-masked]

There we are again.

- gabor

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 30 Mar 2009 09:29:13 -0400

I think it works fine.  It would match local signage.  If you went into the
building, you could use the data to find the interior space the PIDF
referred to.

With the floor plan, you could do more.  That is true of any representation.

What I think you would have some trouble with is using the current fields,
because instead of being able to express the actual hierarchy of the
building, you are constrained to use the existing fields.  That means that
the order may or may not work for you.

Brian

-----Original Message-----
From: Dawson, Martin [mailto:[email-masked]] 
Sent: Sunday, March 29, 2009 8:46 PM
To: [email-masked]; [email-masked]; [email-masked];
[email-masked]

Cheers,
Martin

-----Original Message-----

- gabor

this
provider of
decide
should
say
You
do
it
for
guessing
used
fields,

----------------------------------------------------------------------------
--------------------
----------------------------------------------------------------------------
--------------------
[mf2]