- From: Seiler, Karl <karl.seiler@navteq.com>
- Date: Wed, 15 Jun 2011 08:28:48 -0500
- To: Jens de Smit <jens@layar.com>, "public-poiwg@w3.org" <public-poiwg@w3.org>
In the POI publication business we see high demand for all city center POIs to come associated with a building footprint polygon. So a link list of long/short form points seems good to me for representing footprints, with additional long/short points for center point and for entrances/doorways (aka nav-points). _______________________________ Karl Seiler Director Location Technology & Services NAVTEQ - Chicago (T) +312-894-7231 (M) +312-375-5932 www.navteq.com -----Original Message----- From: public-poiwg-request@w3.org [mailto:public-poiwg-request@w3.org] On Behalf Of Jens de Smit Sent: Wednesday, June 15, 2011 4:03 AM To: public-poiwg@w3.org Subject: Re: ISSUE-19 (point-encoding): How should we represent points? [Core FPWD] 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 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, 15 June 2011 13:29:19 UTC