W3C home > Mailing lists > Public > public-poiwg@w3.org > June 2011

Re: ISSUE-19 (point-encoding): How should we represent points? [Core FPWD]

From: Thomas Wrobel <darkflame@gmail.com>
Date: Mon, 13 Jun 2011 13:53:26 +0200
Message-ID: <BANLkTimPGHJ3Xiz7dSyQvWeyHnxj7o0kGw@mail.gmail.com>
To: Raj Singh <rsingh@opengeospatial.org>
Cc: Jens de Smit <jens@layar.com>, public-poiwg@w3.org
For those interested in conversion formula's between lat/long (along
the earths curvature) and meters (in a straight line), I used these as
a reference;

http://www.movable-type.co.uk/scripts/latlong.html

http://www.ngs.noaa.gov/PUBS_LIB/inverse.pdf

This stuff is, of course, only relevant at the moment when you need
accuracy over a certainly level , or dealing with large distances.
However, hopefully you can see its  a non-trival conversion from one
to the other - to do this to many points (like a curve) on the fly
might cause slowdown.

Also - my knowledge of building construction might be out of date
here, but don't they use lazers when surveying, and are thus dealing
with straight lines relative to a point (in mm) rather then lat/long
anyway?
For professional/architecture work, converting from one to the other
(and maybe back again) might lose accuracy necessary and rule out AR
use for this field.


~~~~~~

Reviews of anything, by anyone;
www.rateoholic.co.uk
Please try out my new site and give feedback :)



On 12 June 2011 20:03, Thomas Wrobel <darkflame@gmail.com> wrote:
> Depending on accuracy, calculating between lat/lon and meters can be
> massively, massively, complex. You get into such factors as the real
> shape of the earth - its not a simple bit of trig sadly.
> Of course these are all "solved problems", but if possible its nice if
> a client doesn't have to do them. (or, rather, as little as possible -
> working out a position in meters for lat/long, then displacements from
> that is less cpu then working out a large batch of conversions).
> Neither is insurmountable, however.
>
> From my perspective the most usefull scenario for relative
> co-ordinates is simply with stuff that can move - it would be nice if
> only one gps location change has to be passed to the client, rather
> then everything attached as well.
>
> I'm also still favouring the idea that each POI should specify its own
> reference system ( WGS84 default), and if it links to another POI
> ("relative too" or something), then it positions its own reference
> system (if not WGS84) relative to that one. This should make any
> inter-POI positioning no more verbose then anything else.
> This wouldn't solve multiple co-ordinate systems within the same
> POI....but I'm not sure how much that will be used in the AR Field.
>
> -Thomas
>
> On 10 June 2011 17:26, Raj Singh <rsingh@opengeospatial.org> wrote:
>> Jens, I think you probably mean to support both point formats, and only use the GeoRSS GML format (more brevity) for lines and polygons? I can live with that.
>>
>> ---
>> Raj
>> The OGC: Making location count...
>> http://www.opengeospatial.org/contact
>>
>>
>> On Jun 10, at 9:58 AM, Jens de Smit wrote:
>>
>>> I've heard (on the list and on the call yesterday) arguments for both
>>> the short, space separated form and the long, individual key form.
>>> Brevity and conformance to GML/GeoRSS are arguments for the short
>>> form, ease of lookups/XSLT and explicit naming of lat/lon/alt for the
>>> latter.
>>>
>>> Saying "let's use both" obviously places the burden on the
>>> implementors... but I think this is still manageable, so I'd like to
>>> see both.
>>
>>
>>
>
Received on Monday, 13 June 2011 11:54:03 UTC

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