Not so brutal, really. My thoughts are copied inline.
Cliff
On 9/8/2011 2:51 AM, Thomson, Martin wrote:
> Hi Cliff,
>
> 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.
> 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.
What I am trying to imagine is how a PIDF-LO might evolve and certain
dependencies that its content entails. For example, a location value
assumes the existence of some localization technique, which in turn
assumes a spatial context. In the case of WiFi localization this might
involve search of a database of signal strength signatures sampled at
spatially-referenced grid points in a building, i.e., one kind of map.
However, this isn't to say that this grid map is the same document that
one would want to reference for purpose of determining relative
location, though the location value provided by localization would be
useful for finding such a document. But who knows where it is, or
whether one referenced in a PIDF-LO is actually useful?
> 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.
I just want to determine whether a map object exists for a location. I
think that Brian provided a means to do this using LoST. As for finding
other map data layers, its seems to me that location provided in a
PIDF-LO could be used to query other spatial databases, or one might
exploit information referenced in the map or data object itself, e.g.,
as provided in CityGML.
HTTP content negotiation sounds like a nice idea. I'm less familiar with
how this actually works. If a catalog is referenced rather than a map,
does the URI have to be typed to distinguish the difference between them
to facilitate negotiation?
>
>> 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.
In this case, "all" was used in the context of providing derived
information in the
PIDF-LO, e.g, uncertainty and relative location information.
>
>> 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.
So why not make it explicit in the current draft?
>
>> 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.
OK...but strikes me as the kind of application-specific complexity you
caution against below. If velocity, then why not acceleration, etc.?
>
>> 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.
Other metadata may be important. For example, CityGML BIMS come in five
levels of detail (LOD) ranging from something as simple as a digital
terrain model to a detailed, walkable indoor model. Merely knowing that
a CityGML BIM exists wouldn't be sufficient for deciding whether it
might be useful if I needed the higher LOD. Even with more simple
floorplans, it may be useful to know what floor in a building is involved.
>
>> 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.
OK...this sounds doable.
>
--
Clifford Behrens, PhD
Senior Scientist & Director
Information Analysis
Applied Research
Telcordia Technologies, Inc.
Phone: 732-699-2619
FAX: 732-336-7015
Email: cliff@research.telcordia.com
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
