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

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]

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.

Received on Wednesday, 8 June 2011 13:23:59 UTC