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

On Jun 8, at 9:53 AM, Alex Hill wrote:
> 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.

I was surprised to hear this about CityGML since it goes counter to common GIS practice, although I believe CAD communities are more likely to use the relative coordinate system you mention, which I like to call "paper space" (don't know if this term is still used, but that's what it was called in my Autocad class back in 1992!).

So I dig into the CityGML specification, and my understanding is that CityGML uses absolute coordinates for geographic objects. It only recommends the use of relative coordinates -- an absolute coordinate for positioning plus coordinates relative to that for the rest of the object -- for objects that will be repeated many times in the model, like streetlights, trees, benches, etc. This allows you to describe the coordinates of the object once, then position it in different places with a single absolute point. 

I'm not saying using all absolute coordinates is a technically superior solution, but it's definitely the common practice in the geospatial world. I think relative coordinates become more prevalent when you're bringing architectural and engineering drawings into the geographic world. I also think the virtual reality community might be more used to employing this paper space concept. 

The bottom line for me is that we have to have at least that primary reference point in a geographic coordinate system, so adding another relative system adds more complexity for software developers writing parsers. So I think we should not encourage the use of relative coordinate systems, but allow for them. Maybe a profile of the POI spec (e.g. an AR profile) could recommend certain best practices for the use of optional features of the core POI spec, and this could be one issue to consider.

Raj Singh
The OGC: Making location count...

Received on Wednesday, 8 June 2011 19:36:51 UTC