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

On Jun 8, 2011, at 9:23 AM, Thomas Wrobel wrote:

> I'm certainly all for efficiency when using a large number of points,
> but as I said, my concern was staying implementation neutral.
> A lot of typical use, especially for AR, wont actually be defining
> area's, but rather placing remotely linked things (ie, meshs or sound)
> at specific locations. In 3d terms this would be a pivot point or a
> single centre point - essentially the one point by which the remote
> data is placed relative too. As AR systems might not be using XML
> (indeed, mine wont be, and existing ones already seem to favour Json),
> it would be good if at least for specifying the main point there is
> key name fields defined for the geolocation values.
> 
> For that mater, even when specifying an area for other use, doesn't it
> still make sense to have "main" point and position the rest relative
> to that? If I'm defining the area of a building, putting the corners
> in meters relative to one lat/long is probably more efficient/easier
> then all the points as lat/longs? [/suggestion]

+1
From what I've seen, establishing a "main" point and then defining points relative to it is exactly what CityGML does.

> 
> Is there any downside to defining them, but having this as optional
> optimisation for XML? (or, at least, just used for area or spline
> specification rather then the center point)
> 
> 
> ~~~~~~
> Reviews of anything, by anyone;
> www.rateoholic.co.uk
> Please try out my new site and give feedback :)
> 
> 
> 
> On 7 June 2011 02:12, Raj Singh <rsingh@opengeospatial.org> wrote:
>> comments inline...
>> ---
>> Raj
>> 
>> On Jun 6, at 1:59 PM, Thomas Wrobel wrote:
>> 
>>> Really not sure about merely having space-separate lat/long/alt co-ordinates.
>>> This means we arnt specifying a name field for them - how well does
>>> this work with none xml formatting like JSON? (co-ordinates will need
>>> to be passed into separate, likely double, variables for use after
>>> all).
>> 
>> Specifying lat/long/alt in attributes adds clarity if you have a single point, but when you start dealing with lines and polygons and you have -- as is often the case with natural features like shorelines -- thousands of points along the line, that clarity bloats the message. That's why the practice has evolved in the geospatial community to go with a format that's as terse as possible when it comes to the coordinates.
>> 
>>> Also, does the point itself need an ID ? (the POI itself is required
>>> to have a unique one, but does each point it might use within it
>>> also?)
>> 
>> No the point doesn't need an ID. Most elements in GML can have an ID, and I copied that from an example where it made more sense for <Point> to have an ID. Please ignore that part of the verbose example.
> 

Alex Hill Ph.D.
Postdoctoral Fellow
Augmented Environments Laboratory
Georgia Institute of Technology
http://www.augmentedenvironments.org/lab