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

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 Sunday, 12 June 2011 18:03:46 UTC