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: Wed, 15 Jun 2011 18:41:41 +0200
Message-ID: <BANLkTi=agum+e51OOnSb5=0acyVH0GwC_w@mail.gmail.com>
To: Jens de Smit <jens@layar.com>, rsingh@opengeospatial.org
Cc: public-poiwg@w3.org
> I think we still do have the requirement that each POI specifies its own CRS with a default of WGS84.

Sure.

> Some of your points refer to moving objects, which I think we have agreed are a slightly different type of POI than we will fully describe in the Core.

Is it? Why?
If you have one "main" anchor co-ordinate (/location) for a POI, and
POIs can be positioned relative to eachother, you automatically get
the ability to move groups of POIs together as one unit.
(and, as you say, each POI can have its own CRS defaulting to WGS84)

I see no reason for a split here. Its analogous to positioning stuff
relative to a container on a html page - if one thing moves, so does
the other. No need for a separate spec in html for "movable divs" or
such. Does there really have to be for POIs?

Its really just down to the delivery method how the POIs are
moved/updated - be it http/json/xmpp etc. Its not really effecting the
data delivered intrinsically. Everything else is a question of
processing and efficiency. (ie, a balance between small package size
and low processing for the client).  I think Jen's suggestion below
seems fine for this.


Jens de Smit wrote;
>I didn't mean that specifically. Schema-wise, I'd say a point could be
>a long form <point><latitiude/><longitude/></altitude></point>
>element, or a short form <point>1.0 2.0 3.0</point>. A line or polygon
>could then consist of either a series of long form <point> elements or
>short form points.

+1


>





On 15 June 2011 11:03, Jens de Smit <jens@layar.com> wrote:
> On Fri, Jun 10, 2011 at 5:26 PM, 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.
>
> I didn't mean that specifically. Schema-wise, I'd say a point could be
> a long form <point><latitiude/><longitude/></altitude></point>
> element, or a short form <point>1.0 2.0 3.0</point>. A line or polygon
> could then consist of either a series of long form <point> elements or
> short form points. It would make the spec more complete/consistent and
> not make parsers that much more complex. In practice, I would suggest
> anyone use the short form for anything bigger than a triangle, unless
> they have a very specific case to use the long form (in which case it
> is useful that the spec supports long form too).
>
> Jens
>
>
Received on Wednesday, 15 June 2011 16:42:08 UTC

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