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: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
> Behalf Of Carl Reed
> Sent: Tuesday, 20 October 2009 9:08 AM
> To: Brian Rosen; Dorothy Stanley; GEOPRIV
> Subject: Re: [Geopriv] Interior Location Extensions internet draft
> available
>
> 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
>
> ----- Original Message -----
> From: "Brian Rosen" <br@brianrosen.net>
> To: "Dorothy Stanley" <dstanley1389@gmail.com>; "GEOPRIV"
> <geopriv@ietf.org>
> Sent: Monday, October 19, 2009 3:24 PM
> Subject: Re: [Geopriv] Interior Location Extensions internet draft
> available
>
>
> > 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" <dstanley1389@gmail.com>
> wrote:
> >
> >> 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
> >>
> >>
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
