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

Now that we've gone further on describing how relative positioning will work, I agree that movement could be handled in the same way. I still think neither is in the core, as I said in response to the other ISSUE-31 email thread. 

---
Raj
The OGC: Making location count...
http://www.opengeospatial.org/contact


On Jun 15, at 12:41 PM, Thomas Wrobel wrote:

>> 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 19:07:30 UTC