I think that we've understood each other on most of the hard points. Some responses inline. I've been fairly brutal editing my response; let me know if you think I've missed something important.
On 2011-09-08 at 07:13:21, Cliff Behrens wrote:
> > Discovery shouldn't really be necessary - the document includes the
> > means to provide a link (URI) to a map or BIM resource. We haven't
> > nailed down exactly what it is that is identified by the URI, simply
> > because we haven't seen any clear indications that any one solution is
> > going to be chosen.
>
> When is this URI added to the PIDF-LO, and how? If the facility that
> does this is impaired during an emergency, then it may be necessary to
> determine whether another copy or source is available. Or, if all you
> get from a caller is a civic address, then it may be desirable to
> determine whether a map doc, e.g., BIM or floorplan, exists for this
> location.
The specifics of how the PIDF-LO is created is largely out of scope for the work that we are doing, but there's a general expectation that the document will be created by a machine.
In the most common cases, I imagine that there will be some sort of network service that creates the PIDF-LO. Perhaps this a server somewhere in the local access network (a LIS in the nomenclature). If you are talking about an office space in a building somewhere, then the local network administrator
> I'm not suggesting that the IETF specify geospatial catalog services.
> The OGC and others have already provided this. I am merely trying to
> anticipate situations like the ones I mentioned above, and recognize
> as others in the geospatial data community already have that
> geospatial objects, e.g., maps, images and BIMs, can be very large.
> So it makes sense to search a catalog/registry of their metadata
> rather than parse the object itself. This idea is consistent with OGC architecture.
> Also, in many situations it is desirable to search one or a few
> locations for these metadata. I am thinking of "call before you dig"
> as an outdoor example.
That's an interesting example - you mean that you might want to consult the maps for water, electric, gas, etc... all for the same location. The great advantage of punting on this problem (which you do when you use a URI) is that people invent ways of dealing with limitations that far exceed your expectations.
Imagine that you could use HTTP content negotiation to retrieve different maps. Or maybe the "map" is instead a reference to a catalogue.
> These metadata may be sufficient from some purposes. But it seems to
> me that other information in the PIDF-LO (and applications that use
> it) may require additional information. For example, uncertainty is
> likely tied to localization technique or resolution of an image.
> Guess what I am looking for here is a mechanism whereby one can find
> all the metadata needed for an application without necessarily
> expecting to find in in the PIDF-LO or having to parse the entire map
> object, e.g., BIM, to get it.
"All" sounds scary to me.
> What I found in RFC 5491 is, "It is RECOMMENDED that uncertainty is
> expressed at a confidence of 95% or higher. Specifying a convention
> for confidence enables better use of uncertainty values. What wasn't
> clear is how this is expressed in the PIDF-LO. Is the implicit
> assumption that the probability of finding a target in the shape provided is 0.95?
It is implied rather than explicit.
> Even if this is the case, I didn't see mention of this in the March 28
> revision. Here again, computation of this uncertainty is a function
> of data accuracy and precision, and these are intimately related to
> attributes of the map document and localization technique. Having
> said all of this, I find it difficult to imagine point sampling of
> locations provided by a localization technique might yield the regular
> shapes specified in this draft...but if this it what some want, I
> guess it is up to them to figure it out. It seems to me that it would
> be easier to specify an uncertainty value for a shape, rather than a
> shape for an uncertainty value.
The shapes we use are fairly commonplace approximations. In practice, a "localization technique" can produce a result that either fits the shape, or something that is quite inconvenient to represent. In the latter case, some data is lost when a shape is fit to it.
> I guess that I imagined something like velocity being computed by
> an application that uses location information in a series of PIDF-LOs.
> In other words, this struck me as derivative information.
Velocity can be measured in other ways. For instance, the Doppler of a satellite signal can be used to get a (crude) estimate of velocity for a GPS receiver.
> Again, other metadata and catalog standards (and their
> implementations) exist for doing this. Why not leverage them? The
> issue I am struggling with is, how much information should actually be
> "stuffed" into a PIDF-LO, and how much should be derived by
> applications/services that can use locations conveyed by it?
That's a perpetual struggle. There is always some application for more data, but adding data always has a cost. Any representation (PIDF-LO included) represents a compromise. In my limited experience, the IETF tends to be quite sensitive to complexity, because experience has shown that complexity has a lot of non-obvious costs. That's one reason that generic pointers (e.g., the "map" URI) are favoured: you can get emergent complexity without necessarily burdening those who care little for your more complex applications.
> Interesting. In fact, after reviewing 5491 I thought that
> <gp:method>GPS</gp:method> was at least providing some of this
> information. Moreover, it seems that the need/uses for this
> information was already anticipated the GML 3.1.1 PIDF-LO Shape
> Application Schema for use by the Internet Engineering Task Force
> (IETF):
> "[...] The range of technologies available for
> determining LI are numerous and range from user-provided LI, to
> automatic methods such as wire mapping, radio timing, and GPS."
Indeed. The <method> element is a much-requested element that carries very little useful information. It is provided, and it can be useful, but I've found that too much weight is attributed to the value.
> > Relative Location = { Baseline, Reference, Relative }
> >
> > The actual location is (Baseline ∩ Reference) + Relative.
>
> I need to think more about this. I am hoping to get some
> clarification from the OGC folks on how one might discover baseline
> and reference locations in a CityGML model.
I don't know a lot about CityGML, but I'm happy to help you work out the implications.
One thing that I found helps: think of the reference location as establishing a new CRS (the location identifies 0,0,0 and the orientation of the axes).
> I believe this gets to my last point. I would also assume that no one
> would bother searching for a BIM unless they had the means to actually
> make sense of it. Here again, metadata would help one quickly decide
> whether they could actually use a map document.
The only metadata we currently provide is the "type" attribute of the map. That might be exactly what you are looking for, assuming of course that your BIM has a MIME media type (application/citygml+xml perhaps?). A processor can use this as a hint about what the identified resource might be able to produce for them.
> What I was also hoping for was support for a URI to find the map doc.
> I
> am also trying imagine all of the data bases and applications required
> to create this association, and whether some co-location or "shared
> context" is required for these. For example, when I enter a building,
> does this send a request to a local LIS which choses a localization
> technique, computes a location, then creates a PIDF-LO with the
> relative location information and references to a map document?
That would be reasonable. More likely, however, that the PIDF-LO is created at the time that you ask for one. In the simplest case, the LIS identifies the WiFi access point you are attached to, works out where that access point is (using a database that might be cross-referenced to your BIM, though that depends entirely on your LIS implementation) and provides that information in the form(s) that it knows best.
If it knows where the access point is in WGS84 terms, then you might get that. On the other hand, if it uses a local reference frame, then it uses the reference frame to populate the baseline/reference locations and provides your location based on that.
> http://www.xkcd.com/927/
>
> OK...the nice thing about standards is there are so many good ones to
> choose from. But might it be possible to use an existing standard if
> one wanted to interoperate with other BIM users and providers?
Certainly. Though when you choose a standard, you also choose a set of peers with which you will then interoperate.
I think that we covered all the hard questions. :)
--Martin
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
