W3C home > Mailing lists > Public > public-poiwg@w3.org > June 2011

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

From: Raj Singh <rsingh@opengeospatial.org>
Date: Wed, 8 Jun 2011 15:39:38 -0400
Message-Id: <85C142F5-CD7D-41DD-9A8B-B659A9B2C6C7@opengeospatial.org>
To: public-poiwg W3C <public-poiwg@w3.org>
Here's a place where I agree using some sort of engineering coordinate system with a relative reference from a lat/lon makes the most sense. My gut feeling is WGS84 just isn't designed to be used at that level of detail.

The OGC: Making location count...

On Jun 8, at 2:16 PM, Seiler, Karl wrote:

> Spent some time this week talking to different NAVTEQ teams that are rolling out micro-point addressing and interior mapping. My goal was to see what extensions we may want to add to our location primitive to enable this next generation of fidelity. As it pertains to the below, adding significant digits to the x/ys is what is coming.  Also, extending the civil address for building / floor / suite number demarcations.
> Was a bit disappointed. I think that the relative reference from a lower rez x/y using a bearing and distance allows for a more fine grained experience.
> _______________________________
> Karl Seiler
> Director Location Technology & Services
> NAVTEQ - Chicago
> (T)  +312-894-7231
> (M) +312-375-5932
> www.navteq.com
> From: public-poiwg-request@w3.org [mailto:public-poiwg-request@w3.org] On Behalf Of Alex Hill
> Sent: Wednesday, June 08, 2011 8:54 AM
> To: Thomas Wrobel
> Cc: Raj Singh; public-poiwg@w3.org
> Subject: 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
> The information contained in this communication may be CONFIDENTIAL and is intended only for the use of the recipient(s) named above.  If you are not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please notify the sender and delete/destroy the original message and any copy of it from your computer or paper files.
Received on Wednesday, 8 June 2011 19:40:13 UTC

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