Subject: [Geopriv] Interior Location Extensions internet draft available

From: Dorothy Stanley <[email-masked]>
Date: Mon, 19 Oct 2009 12:51:34 -0700

All,

An internet draft for Interior Location Extensions is now posted, see
http://www.ietf.org/id/draft-stanley-geopriv-int-ext-00.txt .

This document supports the request for Location by reference
extensions in 11-09-0718-01-000v-liaison-request-to-ietf-geopriv.doc,
(available at http://trac.tools.ietf.org/wg/geopriv/trac/wiki ).
Extensions to existing Civic definitions include reference point, offset and
shape
components.

I've asked Alissa & Richard for time to present this in Hiroshima.

Thanks,

Dorothy Stanley

------------------------

Dorothy Stanley

Aruba Networks

[email-masked]

630-363-1389

---

From: Brian Rosen <[email-masked]>
Date: Mon, 19 Oct 2009 17:24:23 -0400

Note that this draft builds on my INT draft
(draft-rosen-geopriv-pidf-interior-00).

The authors of this draft and I have cooperated on this aspect.  One of the
requests that these authors have made is that we include a registry of ³N²
names in the INT draft.  While I¹m not too thrilled with that idea, I¹m
willing to go along if the rest of the work group agrees it will be useful.

I think this draft has a lot of merit, and I'd like to see it progress.  I
have had extended discussions with these guys.  There is a significant use
case, they have the right idea of how to solve it, and it works within the
kinds of systems it's intended to be used with.

I think the syntax proposed is very awkward, and I'd like to propose
changes.

I think the "Reference Point" this draft defines is a bad idea.  I think
that the INTs should define the reference point, and the offset should be
relative to that.  

In the examples used, I think it might be expressed as:
...
<HNO>123</HNO>
<INT N="Suite">100</INT>
<INT N="Door">Front</INT>
And then something like
<POINT_OFFSET>
   <X>100</X>
   <Y>200</Y>
</POINT_OFFSET>

At this time, however, I think the syntax issues are not important and the
basic idea is.

Brian

On 10/19/09 3:51 PM, "Dorothy Stanley" <[email-masked]> wrote:

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

---

From: "Carl Reed" <[email-masked]>
Date: Mon, 19 Oct 2009 16:07:30 -0600

I also believe this draft has merit and am willing to help it progress.

That said, I am working multiple other standards activities related to 
indoor/outdoor navigation that have a role in a variety of domains, such as 
emergency response.

For example, there is a new activity just beginning titles "Open Floor Plan 
Display". From the activity plan:

"Conversations between industry specialists often break down in semantic 
frustration for many reasons. A primary reason is the lack of a common 
framework and strategic planning to evolve this framework. Secondly, 
documentation of building elements and building service performance 
requirements has exploded. Which parts of the living documents need to 
comply with long term exchange requirements for wide spread re-use?"

The work proposed envisions a next generation 9-1-1 using modern devices and 
open exchange languages to depict buildings and alerts in simple, 
interoperable formats via lightweight web services. One objective is the 
ability to read and pass along sensor alerts before emergencies such as 
fires are large enough to be observed by a by-stander phoning in. Data 
identities center around building addresses, standard building data 
representations, and alert classifications. The work will build on existing 
standards and practices as well as previous collaborations between the OGC, 
NIST, buildingSMART Alliance, GSA, and other organizations in the AEC 
community.

One reason I mention this work is that there are a variety of issues related 
to expressing location within a building and then using that information to 
say guide first responders.
>From the draft-stanley-geopriv-int-ext-00.txt document

"within X meters of the point which is 10 meters south and 15 meters east of 
the main elevator on Floor 4"

I understand that perhaps the focus of the document is not on semantics. 
That said, how does the application "know" what the main elevator is and 
where is is location or what is really meant by Floor 4. Does there need to 
be a statement about where the building floorplan information comes from? 
Further, what is meant by "south" and "east"? In reference to the cartesian 
coordinate system (actually, in the engineering world, these are engineering 
coordinate systems), where and how is the metadata about the local CRS 
accessed? How does the local CRS related to the real world CRS (such as WGS 
84)?

These are the types of questions that the indoor navigation community is 
dealing with. For example 
http://portal.opengeospatial.org/files/?artifact_id=35334 is one example.

So, expressing the location of IP enabled devices should probably be in the 
context of the larger in-building information domain. This way, location 
content provided in an interior extension encoding would "fit" or fuse 
directly into a larger common operational picture.

Sorry for the length of this posting, but this is a really important topic.

Regards

Carl

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 20 Oct 2009 10:49:49 +0800

It is clear that this is an important use case.

The problems that Carl references are real, but not ones that we need to address in this forum.  Instead, we should look to make use of the product of the work in the OGC and other areas.

In the meantime however, we have a use case that needs an immediate solution.  It's unlikely that the work Carl cites is going to be resolved in time for us to use its output.  We need something simple that addresses the current needs.

Then it comes down to what that solution looks like.  We currently have two proposals (assuming that this new submission supersedes Marc's relative location document):

  <http://tools.ietf.org/id/draft-thomson-geopriv-indoor-location-00>
  <http://tools.ietf.org/id/draft-stanley-geopriv-int-ext-00>

Each essentially address the same problem and produce a similar result.  The differences in representation seem significant, but they aren't fundamentally different.

draft-thomson-geopriv-indoor-location is geo-referenced, addressing the problems cited below.  It uses the existing XML shapes defined with a GML image CRS, which the authors believe is more useful for the problem at hand - an image may be referenced that includes a map upon which the location might be displayed.

draft-stanley-geopriv-int-ext inherits all the problems that exist in the interiors document (i.e. absence of associated semantics) as well as the problems I previously raised with the relative location document [1].

--Martin

[1] <http://www.ietf.org/mail-archive/web/geopriv/current/msg03461.html>

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Carl Reed
> Sent: Tuesday, 20 October 2009 9:08 AM
> To: Brian Rosen; Dorothy Stanley; GEOPRIV
> > The authors of this draft and I have cooperated on this aspect.  One
> of
> > the
> >> Extensions to existing Civic definitions include reference point,
> offset
> >> and
> >> shape
> >> components.
> >>

---

From: <[email-masked]>
Date: Tue, 20 Oct 2009 07:29:34 +0200

Hi Carl,

Some answers below:

> That said, how does the application "know" what the main elevator is and where is is location or what is really meant by Floor 4

The above are needed for navigation, but not for positioning. The first version of the draft was not intended to provide support for navigation. That capability would however be possible to add by including a link to a floorplan in a vector format, which would have objects and places tagged with the names of the INT elements (eg SVG).

> Further, what is meant by "south" and "east"?

I thought that we can safely assume that in a relatively small object like a building (relative to the dimentions of the Earth) , the axes of the Cartesian coordinate system can be assumed as being N-S and E-W (N being the true north) cardinal directions. Is this a wrong assumption?

> How does the local CRS related to the real world CRS (such as WGS 84)?

>From positioning pow, it doesn't have to. If you are looking to navigate in and out of the building, then you need it. But for that to work you need to have the WGS84 coordinates of the floorplan's edges and in/out gates.

Let me know if I am terribly wrong.

- Gabor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Carl Reed
Sent: Monday, October 19, 2009 3:08 PM
To: Brian Rosen; Dorothy Stanley; GEOPRIV
Subject: Re: [Geopriv] Interior Location Extensions internet draft available

That said, I am working multiple other standards activities related to indoor/outdoor navigation that have a role in a variety of domains, such as emergency response.

For example, there is a new activity just beginning titles "Open Floor Plan Display". From the activity plan:

"Conversations between industry specialists often break down in semantic frustration for many reasons. A primary reason is the lack of a common framework and strategic planning to evolve this framework. Secondly, documentation of building elements and building service performance requirements has exploded. Which parts of the living documents need to comply with long term exchange requirements for wide spread re-use?"

The work proposed envisions a next generation 9-1-1 using modern devices and open exchange languages to depict buildings and alerts in simple, interoperable formats via lightweight web services. One objective is the ability to read and pass along sensor alerts before emergencies such as fires are large enough to be observed by a by-stander phoning in. Data identities center around building addresses, standard building data representations, and alert classifications. The work will build on existing standards and practices as well as previous collaborations between the OGC, NIST, buildingSMART Alliance, GSA, and other organizations in the AEC community.

One reason I mention this work is that there are a variety of issues related to expressing location within a building and then using that information to say guide first responders.
>From the draft-stanley-geopriv-int-ext-00.txt document

"within X meters of the point which is 10 meters south and 15 meters east of the main elevator on Floor 4"

I understand that perhaps the focus of the document is not on semantics. 
That said, how does the application "know" what the main elevator is and where is is location or what is really meant by Floor 4. Does there need to be a statement about where the building floorplan information comes from? 
Further, what is meant by "south" and "east"? In reference to the cartesian coordinate system (actually, in the engineering world, these are engineering coordinate systems), where and how is the metadata about the local CRS accessed? How does the local CRS related to the real world CRS (such as WGS 84)?

These are the types of questions that the indoor navigation community is dealing with. For example
http://portal.opengeospatial.org/files/?artifact_id=35334 is one example.

So, expressing the location of IP enabled devices should probably be in the context of the larger in-building information domain. This way, location content provided in an interior extension encoding would "fit" or fuse directly into a larger common operational picture.

Regards

Carl

---

From: "Carl Reed" <[email-masked]>
Date: Tue, 20 Oct 2009 09:06:20 -0600

Gabor -

This is a follow on from yours and Martin's emails.

First, let me say I agree that we need a common, well understood mechanism 
for describing an arbitrary location inside a building.

That said, how does the application creating the Interior Location 
Extensions (ILE) payload "know" where the elevator is (or for that matter 
any fixed asset in the building)? I understand that semantics etc are 
outside the scope of this group. However, is there an assumption that I am 
missing? Is the actual compilation of all the reference information 
happening  in some external app and then being used in an ILE payload? 
Relative location means to locate a place relative to other landmarks. One 
has to know what and where the landmarks are for relative location to be 
useful. Perhaps at the very least, any document on IL needs to provide some 
guidance about where the reference locations (landmarks) come from.

Sorry if I am being dense here.

As to the CRS, an arbitrary Cartesian coordinate system for a building may 
or may not be oriented to some real world projected system. If one considers 
the building to be a singular self contained feature with no external 
references, then your assumption is correct - no need to worry. However, if 
we wish to plan ahead (as Martin also points out), then I would suggest that 
we need to make sure that any interior positioning approach can easily be 
integrated into a larger content infrastructure.

For example, within about 2 or 3 years, every building in Germany will be 
represented in a high quality 3d urban model in which the buildings are 
georeferenced (lat, long, and altitude) to a common CRS. Currently the work 
is for the exteriors of the building but they are rapidly moving into the 
interiors of the building. And in Korea, there is a massive government led 
program called the u-City. In the u-City, sensors permeate the information 
fabric of the entire city, including complete integration of  in-building 
sensors and sensor networks. These sensors are all network connected (and IP 
enabled). The Koreans are doing considerable work in defining how to map 
from one spatial reference system (such as outside building WGS-84) to 
another spatial reference system (such as an inside building local 
coordinate system). This is the group that Richard Barnes was so kind to 
meet with in Germany a few weeks ago. Similar work is also going on in 
Taiwan. In both cases, they are using absolute coordinates to describe the 
location of the ip enabled devices.

I just want to make sure that this work integrates well with other, strongly 
related activities - such as navigation, routing, augmented reality, 
information fusion for decision support, and so forth.

The integration of in-building and outside building information has been a 
weakness in the AEC and GIS communities for decades. Nice to see that 
perhaps many of these integration problems are being addressed and hopefully 
solved!

Regards

Carl

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>; 
<[email-masked]>; <[email-masked]>
Sent: Monday, October 19, 2009 11:29 PM
Subject: RE: [Geopriv] Interior Location Extensions internet draft available

>> where is is location or what is really meant by Floor 4
>
> The above are needed for navigation, but not for positioning. The first 
> version of the draft was not intended to provide support for navigation. 
> That capability would however be possible to add by including a link to a 
> floorplan in a vector format, which would have objects and places tagged 
> with the names of the INT elements (eg SVG).
>
> I thought that we can safely assume that in a relatively small object like 
> a building (relative to the dimentions of the Earth) , the axes of the 
> Cartesian coordinate system can be assumed as being N-S and E-W (N being 
> the true north) cardinal directions. Is this a wrong assumption?
>
> From positioning pow, it doesn't have to. If you are looking to navigate 
> in and out of the building, then you need it. But for that to work you 
> need to have the WGS84 coordinates of the floorplan's edges and in/out 
> gates.
>
> indoor/outdoor navigation that have a role in a variety of domains, such 
> as emergency response.
>
> The work proposed envisions a next generation 9-1-1 using modern devices 
> and open exchange languages to depict buildings and alerts in simple, 
> representations, and alert classifications. The work will build on 
> existing standards and practices as well as previous collaborations 
> between the OGC, NIST, buildingSMART Alliance, GSA, and other 
> organizations in the AEC community.
>
> One reason I mention this work is that there are a variety of issues 
> related to expressing location within a building and then using that 
> information to say guide first responders.
> where is is location or what is really meant by Floor 4. Does there need 
> to be a statement about where the building floorplan information comes 
> from?
> Further, what is meant by "south" and "east"? In reference to the 
> cartesian coordinate system (actually, in the engineering world, these are 
> engineering coordinate systems), where and how is the metadata about the 
> local CRS accessed? How does the local CRS related to the real world CRS 
> (such as WGS 84)?
>
> So, expressing the location of IP enabled devices should probably be in 
> the context of the larger in-building information domain. This way, 
> location content provided in an interior extension encoding would "fit" or 
> fuse directly into a larger common operational picture.
>

---

From: Brian Rosen <[email-masked]>
Date: Tue, 20 Oct 2009 11:31:15 -0400

If you do what I suggested, which is to use INT to define the reference
point, then if there is any structure to the plan you are referencing from
(either a 3D model or a 2D floor plan), you should be able to locate the
reference point.

There is a small problem with the "Front" door, because few plans would
label a door "Front", but I expect a couple of simple conventions from that
would work.

Elevators are marked in most cases, although sometimes the signage on them
is non-existent, but "Elevator A" is meaningful in most circumstances on
most plans.

That would be my goal: if you had a 3d model or 2D floor plan, in any
reasonable machine readable form, you should be able to locate the reference
point.  We need to be able to align the building axis (or really, the floor
plan or model axis) with the earth's in order to be able to specify the
offset in cardinal form.  All that takes is a north arrow on the plan.

We are then primarily limited by the fact that few floor plans are accurate
("as built").  My architect friends say less than 1% of plans are as built.
They may well be good enough however.  In most hotels, for example, there
are good enough floor plans.

While you can use a geo offset from a geo reference point, you can't usually
use a floor plan with that without a benchmark AND an axis alignment.  I do
think it's more likely we can get existing plans with just the north arrow.
I don't think I've ever seen a floor plan with an accurate benchmark
(building floorplates as part of a land survey would work I guess, but then
you have to overlay the floorplan on the footplate, and we get back to "as
built" problems).

Brian

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 20 Oct 2009 14:14:58 -0500

Hi Carl,

The strategies and initiatives you describe below are precisely what Martin and I designed our draft to address.

Cheers
James

-----Original Message-----
From: [email-masked] on behalf of Carl Reed
Sent: Tue 10/20/2009 10:06 AM
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: Thomson, Martin
Subject: Re: [Geopriv] Interior Location Extensions internet draft available
 
Gabor -

Regards

Carl

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>; 

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