W3C home > Mailing lists > Public > public-poiwg@w3.org > September 2010

Re: [uk-government-data-developers] Couple of Ordnance Survey things

From: Alex Hill <ahill@gatech.edu>
Date: Wed, 1 Sep 2010 10:26:52 -0400
Cc: public-poiwg@w3.org
Message-Id: <DD272BE5-C042-49EE-8166-ECDCBD06D231@gatech.edu>
To: Thomas Wrobel <darkflame@gmail.com>

On Aug 23, 2010, at 8:20 AM, Thomas Wrobel wrote:

> "Does one want to associate their content with -85.0,34.0 or at the
> Klaus Computing building?"
> I think most(all?) people agree that co-ordinates alone shouldn't be
> the only way to tie the real world to data.
> However, you have to think in terms of how it will physically work,
> and not just the easiest way for the content creators to assign
> things.
> For example; How will a device know what/where the "Klaus Computing
> building" is ?
> Surely by tieing it to that String, it would require an additional
> look up, from a government database, or another source every time a
> client needs to know. This could cause a lot of wasted bandwidth no?
> Surely its better for any "fixed" locations to be specified at
> creation time, not looked up at viewing time? You make one call to
> find out co-ordinates when your assigning content. But for every
> client looking at it, they dont need to look at the database because
> to those devices its just raw co-ordinates.
> Defining a region (like the shape of the building itself) is a good
> idea, and something being discussed too. (Although I suspect a center
> pivot point would need to be done anyway though, even in that
> scenario).Also  might be worth looking at;
> https://research.cc.gatech.edu/polaris/content/infrastructure-service
> too, which prepossess a survive for delivering infer-structure models.

If not clear already, this is the work from our lab.
The main point we make is that buildings and other structures are a resource that should be shared between multiple authored AR channels.
We merely break these models (which are useful for collision testing, content occlusion and relative referencing of content) out from the delivery of AR content.
A potential advantage of this approach is that "looking at the side of the building" can become a reflection of the infrastructure services and becomes a resource the author can take advantage of (i.e. when "staring at the side of ABCDEF1234" trigger event X) without having to manage that complexity.
Different infrastructure services may reference the same GUIDs, but can provide different levels of fidelity, accuracy, responsiveness, etc. (i.e. Verison's service vs. US Cellular's sevice)
Relative referencing (instead of absolute coordinates) makes it easier for authors to place content in prescribed locations (i.e. bulletin board, above our sign, etc.) that may change in time (i.e. renovations, moving objects) or may be generalized across multiple situations (i.e. on the bulletin board of any Chilli's, above the sign of any Chilli's)
We also make a similar point about tracking data sources; that they are a resource to be shared by multiple AR channels.
In ideal situations, all channels will take advantage of all available tracking data (i.e. Natural Feature Tracking against a building), however some channels of content may have been authored based on the best information available at the time and choose not to take advantage.
A simple example is using coordinates to define the location of an augmentation instead of relative to the feature desired (i.e. relative to the front door).

> For things that can't be done at all with co-ordinates (like your car
> example), we have to think of what other data to use so the device can
> get a fix on if its in view, and where it is.  My view is this pretty
> much has to be an image. Some sort of image recognition of the car,
> that can then be associated with data. It could also be a RFID, or
> another identifying technology....but that would require a physical
> change to the car, so it seems less practical.
> So overall we certainly shouldn't just limit ourselves to
> co-ordinates, but we do have to consider how things will work, and try
> to avoid too many remote-calls when possible.
> [/two cents]
> -Thomas Wrobel
> On 20 August 2010 16:13, Alex Hill <ahill@gatech.edu> wrote:
>> Sorry for the delay in weighing in.
>> Please let know if I am not following any protocol.
>> On Aug 18, 2010, at 6:27 AM, Dan Brickley wrote:
>> Might be of interest here, re current trends/activities...
>> Dan
>> ---------- Forwarded message ----------
>> From: John Goodwin <John.Goodwin@ordnancesurvey.co.uk>
>> Date: Wed, Aug 18, 2010 at 12:23 PM
>> Subject: [uk-government-data-developers] Couple of Ordnance Survey things
>> To: uk-government-data-developers@googlegroups.com
>> Hi all,
>> The OS OpenSpace Wiki is now live:
>> http://osopenspacewiki.ordnancesurvey.co.uk/wiki/index.php?title=Main_Page
>> and the TOID lookup service is now back up and running:
>> http://opentoids.ordnancesurvey.co.uk/toidservice/
>> example:
>> http://opentoids.ordnancesurvey.co.uk/toidservice/location/300000,300000
>> Does this effort seek to assign a GUID to each physical object (buildiings,
>> lakes, etc.)?
>> I find this very interesting since I feel that only being able to refer to
>> coordinates in space is inadequate for AR.
>> It might suffice for the current crop of applications, but I imagine a
>> future where content is very tightly registered with the content in the
>> physical world.
>> For one thing, no one wants to author a sign on the top of a store by
>> climbing to the roof (if accessible) and determining the coordinates.
>> And, authoring content on the side of a vehicle means referring to the
>> vehicle and not any specific coordinates.
>> Another reason I am in favor of a GUID is that I suspect there will be
>> numerous competing representations of buildings and structures to choose
>> from.
>> And, given multiple databases providing model data (likely) for structures,
>> one would want to avoid collisions (i.e. two models of the same building
>> visible).
>> A GUID aids some of the discussions about where content is meant to be
>> placed (i.e on the corner of 5th and Spring, in the middle of the
>> courtyard).
>> Does one want to associate their content with -85.0,34.0 or at the Klaus
>> Computing building?
>> Both have different semantic meanings and practical consequences.
>> I'd also like to call into question this whole concept of giving buildings
>> and structures coordinates.
>> Although the utility on a map is obvious, the practical value of a floating
>> tag at the exact center of a building is unclear when on is viewing a small
>> section of it.
>> The actual "location" of a building needs to be tied to the "extent" of that
>> structure and hence to the "officially accepted model" of that structure
>> (and it's origin's relation to the coordinates).
>> Granted, a combination of a model and coordinates is likely sufficient, but
>> this just highlights that coordinates in themselves are inadequate for any
>> real AR application.
>> see British National Grid for more coordinates:
>> http://www.ordnancesurvey.co.uk/oswebsite/images/userImages/misc/education/nationalgrid/natgrid2.gif
>> John
>> This email is only intended for the person to whom it is addressed and
>> may contain confidential information. If you have received this email
>> in error, please notify the sender and delete this email which must
>> not be copied, distributed or disclosed to any other person.
>> Unless stated otherwise, the contents of this email are personal to
>> the writer and do not represent the official view of Ordnance Survey.
>> Nor can any contract be formed on Ordnance Survey's behalf via email.
>> We reserve the right to monitor emails and attachments without prior
>> notice.
>> Thank you for your cooperation.
>> Ordnance Survey
>> Romsey Road
>> Southampton SO16 4GU
>> Tel: 08456 050505
>> http://www.ordnancesurvey.co.uk
>> Alex Hill Ph.D.
>> Postdoctoral Fellow
>> Augmented Environments Laboratory
>> Georgia Institute of Technology
>> http://www.augmentedenvironments.org/lab

Alex Hill Ph.D.
Postdoctoral Fellow
Augmented Environments Laboratory
Georgia Institute of Technology

Received on Wednesday, 1 September 2010 14:27:13 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:48:25 UTC