- From: Carl Reed <creed@opengeospatial.org>
- Date: Fri, 29 Oct 2010 08:06:58 -0600
- To: "Seiler, Karl" <karl.seiler@navteq.com>, "Philipp Slusallek" <slusallek@cs.uni-saarland.de>, "Marengo Marco" <marco.marengo@telecomitalia.it>
- Cc: <cperey@perey.com>, "Raj Singh" <rsingh@opengeospatial.org>, <public-poiwg@w3.org>, <gary.gale@nokia.com>, <member-poiwg@w3.org>
I should add that your examples are very close to what a POI is as defined in the OGC Open Location Services standard. In the OGC definition, location is a property of the POI. Cheers Carl ----- Original Message ----- From: "Seiler, Karl" <karl.seiler@navteq.com> To: "Philipp Slusallek" <slusallek@cs.uni-saarland.de>; "Marengo Marco" <marco.marengo@telecomitalia.it> Cc: <cperey@perey.com>; "Raj Singh" <rsingh@opengeospatial.org>; <public-poiwg@w3.org>; "Carl Reed" <creed@opengeospatial.org>; <gary.gale@nokia.com>; <member-poiwg@w3.org> Sent: Friday, October 29, 2010 8:00 AM Subject: RE: WG Objectives - A Personal Take >I am concerned that we keep trying to define systems to define the richness >of stationary locations and not POIs. > > Back to... > > To kick off a thread on Gary's challenge > 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 > > I propose in the simplest sense: > A place is a location / anchor > A POI is what is at that place > > Thus: > Location/anchor - x/y, 123 Main st > POI - Karl's Car Wash... > > Location/anchor - x/y > POI - Buckingham Fountain in Grant Park... > > Location/anchor - x/y, 425 W Randolph..., 17th floor, Office 17B103... > POI - Karl Seiler - Office > > Location/anchor - POLY: (x/y >> x/y >> x/y >>x/y),... > POI - Sheppard's Crook Golf Course (area) > > ... > > Let's first tackle the simple definition of what is a POI and then link it > to location definitions. > > _______________________________ > Karl Seiler > Director Location Technology & Services > NAVTEQ - Chicago > (T) +312-894-7231 > (M) +312-375-5932 > www.navteq.com > > > -----Original Message----- > From: Philipp Slusallek [mailto:slusallek@cs.uni-saarland.de] > Sent: Thursday, October 28, 2010 11:20 PM > To: Marengo Marco > Cc: Seiler, Karl; cperey@perey.com; Raj Singh; public-poiwg@w3.org; Carl > Reed; gary.gale@nokia.com; member-poiwg@w3.org > Subject: Re: WG Objectives - A Personal Take > > 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. >> >> > > > > 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 Friday, 29 October 2010 14:56:02 UTC