- From: Philipp Slusallek <slusallek@cs.uni-saarland.de>
- Date: Fri, 29 Oct 2010 06:19:44 +0200
- To: Marengo Marco <marco.marengo@telecomitalia.it>
- CC: "Seiler, Karl" <karl.seiler@navteq.com>, "cperey@perey.com" <cperey@perey.com>, Raj Singh <rsingh@opengeospatial.org>, "public-poiwg@w3.org" <public-poiwg@w3.org>, Carl Reed <creed@opengeospatial.org>, "gary.gale@nokia.com" <gary.gale@nokia.com>, "member-poiwg@w3.org" <member-poiwg@w3.org>
Hi, [For a short introduction of myself please see http://graphics.cs.uni-saarland.de/slusallek/] Let me comment a bit on the definition of POIs. I see two levels of specification here: One defines a point or a region in space and/or time directly, while the other defines some data that can be converted by some internal/external "service" into the former. We could call these "direct" and "indirect" POI specifications. In the latter case, e.g. an address/term of a place ontology/etc can be converted into a point on the street in front of the house (albeit typically not yet into the extent covered by the house/ground referred to by the address, see below) by Google Maps or such. I would call such direct or indirect addresses "absolute" with respect to some fixed coordinate system (such as WGS84). Having the ability to nest several such POIs relative to each other would certainly be very useful, in order to describe related POIs, e.g. multiple entries to a building/site. Having the ability to link POIs to each other via URLs and a href-like structure seems useful too as it allows for expressing the relationship without having to change the referred to POI. There are also "relative" POI markers, relative to some observer: E.g. given some optical features (e.g. SIFT or similar AR features), a service (AR) can convert them to coordinates relative to the camera ("some direction X relative to the viewing direction of the camera and about 150m away"). Such relative coordinates are often combined with at least rough absolute coordinates such that you do not have to search the complete data base of relative features to find the one that are likely to apply (this is more of an optimization but can also be used as a refinement of the absolute position). If relative features have associated absolute coordinates, the relation (transform) between the two is usually also given, such that an absolute position can be derived from seeing the relative features (and vice versa). But this is a separate and independent step. Let me comment also on the absolute coordinates some more: While points are simple, its often unclear how to interpret them -- they do not have any scale. E.g. the notion of two points being "near" to each other does not make any sense -- unless there is some sort of scale given as well. However, that scale (e.g. distance) essentially defines a region around one of the points and the "near" query really converts to a "point in region" query (that query is symmetric, though). Often the scale is implicitly defined by the query point ("being near" for a walking person is different to "being near" for a fast driving car) but this might not apply or make much sense in some applications. As a consequence, I believe it is useful to at least conceptually always consider POIs to be a region of some sort -- just to be able to have a notion of this "scale" independently from the query. A "point" would then simply be a region with a really small/zero extent/radius. This also generalizes nicely to cases where the POI really is defined by a region (polygon, 3D space enclosed by polygons, whatever). Finally, the definition should be extended to also include the time dimension, where similar concepts do apply almost equally. Things get quite a bit more involved though, when the space and time dimensions are no longer independent. In graphics we would talk of an "animated POI". And that might really be what we need to describe them and where to borrow the ideas for representations from. However, animations are often evaluated in a forward direction ("given some time, tell me what the object looks like at that point in time"). For many queries this is perfectly fine, as we know the current time and can thus find the query region to work with. Sometimes, however, we are facing a different issue that we want to answer a query in space-time ("what are the points/intervalls in time where this space-time point is inside the animated region"). They are a bit more difficult to answer and process. Finally, on a related note, let me point you to some new activities we have started recently to take a fresh look at interactive 3D for the Web: XML3D. "Not again a new format for 3D on the Web" is the usual reaction at this point, which we understand and actually share :-). However, as we argue in our recent paper (https://graphics.cs.uni-saarland.de/index.php?id=534) existing 3D approaches are severely lacking in respect to the Web. So XML3D starts exactly where the Web/HTML5 is today adding 3D as a minimal but orthogonal extension to HTML. Essentially our approach is to make 3D programming as similar to 2D Web design, such that all Web designers could immediately start applying their 2D Web experience also to 3D, expanding the pool of 3D application developers by several orders of magnitude. Instead of seeing 3D as an add on, our approach sees 3D as an integral part of HTML, even going to the point where 3D concepts (e.g. like procedural shaders) could apply as well to 2D content as they do for 2D content (note that not all of this described is in the above paper yet, but will be in a follow up). Initial alpha versions of our implementations in Firefox and Webkit/Chromium as well via WebGL are available on xml3d.org, of course also including the current spec for XML3D. We are organizing a "3D on the Web" session for the TPAC W3C conference next week (Monday afternoon), where we will discuss where we are with respect to 3D on the Web and suggest/discuss next steps to be taken. Note: that in addition to our XML3D approach, X3DOM will also be presented as we have joined forces with the Fraunhofer group now to define a common approach for 3D embedded directly into HTML. I believe this could be very interesting also for the POI working group. Thanks for listening, Philipp Slusallek Let me also comment Am 26.10.2010 16:38, schrieb Marengo Marco: > Hi, > +1 to extensibility. I think our goal as a W3C WG is to try to provide a recommendation which facilitates the distribution of point of interest information. Just as RSS did in other contexts: from news sharing to podcasting... that's a success story. > > I've been thinking of a definition of POI, starting from Carl Reed's input: > > "Point of Interest (POI): A location (with a known position at a certain time) where one can find a place, product or service, typically identified by name rather than by address and characterized by a URI, which may be used as a reference point or a target in a location based service request, e.g., as the destination of a route." > > And this is imho the smallest subset of information which can describe a POI (this is built on top of Gary Gale's contribution): > > 1. A centroid (latitude, longitude) > in a widely adopted system (e.g. WGS 84) > 2. An extent (described either by a vector set or by an MBR) > 3. A category / type > possibly referring to a Place Ontology. Otherwise every POI Provider will define its own vocabulary > 4. A URI > 5. An address (although the larger the place the less meaningful this becomes) > although the address may be really generic, as highlighted by Carl Reed > 6. Contact information (if applicable) > using a widely adopted standard (e.g. OMA CAB, or whatever standard we agree upon) > > We should also suggest a set of extensions, which will cover (hopefully) all the use cases that we want to support. > > Marco > > > > > Il giorno 26/ott/2010, alle ore 15.23, Seiler, Karl ha scritto: > >> Right, the key term here is extensibility. >> >> In defining the base / core attributes shared by most POIs our goal should be to make it easy for data to participate in the standard: >> >> Name (can range from legal name, chain/brand name, to doing-business-as name) - I recommend for the base attribution we try to define what a "common use" name is >> >> Location (this can range from a single point in the center of the building, to an address, to street geometry, to multiple locations to describe a place, to...) - I recommend making this as simple as a X/Y of the center point, and an optional (official) address >> >> Contact (this can range from phone, to URL, to lists of contacts) - Probably the minimum is an optional phone number >> >> Type (this can range from high level - is a business vs. a landmark, to industry standard business descriptors, to emerging models, to open ended hierarchical tagging) - I recommend we consider one or more existing business classification standards and not try to reinvent >> >> A universal ID would be very nice addition to the Core / Base attributes if possible... >> >> Beyond that the key to me is to define an open-ended way to define the richness of the world of places that enhances system to system use/reuse while maintaining ease of compliance. >> >> >> _______________________________ >> Karl Seiler >> Director Location Technology & Services >> NAVTEQ - Chicago >> (T) +312-894-7231 >> (M) +312-375-5932 >> www.navteq.com >> >> >> -----Original Message----- >> From: member-poiwg-request@w3.org [mailto:member-poiwg-request@w3.org] On Behalf Of Christine Perey >> Sent: Monday, October 25, 2010 11:19 PM >> To: Raj Singh; public-poiwg@w3.org >> Cc: Carl Reed; gary.gale@nokia.com; member-poiwg@w3.org >> Subject: Re: WG Objectives - A Personal Take >> >> +1 to what Raj wrote. >> >> Today's POI definition does not fit all evolving use cases. >> >> Keywords: >> >> - extensible >> >> - encoding standard >> >> - covers "stationary POI" (what I call the "fixed POI") as well as >> non-stationary (probably needs another name to say "everything that can >> be a trigger for an AR experience") >> >> +1+1 on >> >>> Basically, the same ethic that underlies HTML and Atom. >> >> Regards, >> >> -- >> Christine >> >> Spime Wrangler >> >> cperey@perey.com >> mobile +86 132 6171 6195 >> VoIP (rings in Beijing) +1 (617) 848-8159 >> Skype (from anywhere) Christine_Perey >> >> On 10/25/2010 7:30 PM, Raj Singh wrote: >>> I like this definition of POI (and not just because I'm also on OGC staff!). However, I also see that it will not fit all the evolving use cases in this group. >>> >>> I'd like to see us create an extensible POI encoding standard, such that very simple things--such as a stationary POI--can be encoded very simply and more complex things can still be encoded, but can also still be partially understood by software designed for the simpler markup. Basically, the same ethic that underlies HTML and Atom. >>> >>> --- >>> Raj >>> The OGC: Making location count... >>> http://www.opengeospatial.org/contact >>> >>> >>> On Oct 22, at 9:36 PM, Carl Reed wrote: >>> >>>> Gary - >>>> >>>> The OGC has a standard titled, "Open Location Services Core". That standard was originally developed by a number of OGC Members and continues to be enhanced and extended. The key Members involved were/are NavTeq, Hutchison 3G, ESRI, MobileMapping, Image Matters, Webraska, Intergraph, MapInfo, Oracle, Autodesk, ERDAS (now part of Hexagon), Tele Atlas, and DeCarta and then agreed to by the OGC Membership. In that document, there is a definition of POI as an abstract data type. Perhaps this can be a "strawman" definition. >>>> >>>> Point of Interest (POI): A location (with a fixed position) where one can find a place, product or service, typically identified by name rather than by address and characterized by type, which may be used as a reference point or a target in a location based service request, e.g., as the destination of a route. >>>> >>>> Now of course since this definition was agreed to in the OGC, there is the perhaps the issue of mobility to be considered. >>>> >>>> Regards >>>> >>>> Carl >>>> >>>> ----- Original Message ----- From:<gary.gale@nokia.com> >>>> To:<member-poiwg@w3.org> >>>> Sent: Friday, October 22, 2010 5:48 AM >>>> Subject: WG Objectives - A Personal Take >>>> >>>> >>>> Hi everyone, >>>> >>>> Here's my take on what I'd like to see coming out of the group ... >>>> >>>> 1) a definition of what actually constitutes a POI >>>> 2) following on from the previous definition ... what the difference is, if any, between a POI and a Place >>>> 3) what basic attributes and metadata should be utilized in order to define a POI/Place >>>> 4) how to articulate that definition and set of attributes in terms of best practice >>>> 5) how to showcase and encourage innovative uses of POI data >>>> >>>> Best >>>> >>>> G >>>> >>>> -- >>>> Gary Gale >>>> Director, Ovi Places Registry, Nokia Gate5 GmbH >>>> Invalidenstr 117, 10115 Berlin, Germany >>>> UK: +44.7508.000336 | DE: +49.1515.5150909 >>>> gary.gale@nokia.com >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>> >>> >> >> >> >> 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. > > > Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. > > This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks. > >
Received on Saturday, 30 October 2010 15:48:57 UTC