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

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

From: Thomas Wrobel <darkflame@gmail.com>
Date: Mon, 23 Aug 2010 14:20:31 +0200
Message-ID: <AANLkTikGXNHCU=cGy+Hx99qancETFMxpBnKwAb7B=Ar4@mail.gmail.com>
To: Alex Hill <ahill@gatech.edu>
Cc: public-poiwg@w3.org
"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

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;
too, which prepossess a survive for delivering infer-structure models.

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
Received on Monday, 23 August 2010 12:21:04 UTC

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