" Interesting. I would think that the AR community would be
interested in more complex representations of a POI location than just
a simple point without having to dereference anything else, no?"
Just my very late, popping-back-in, 2 cents, but really a simple
point, orientation, and reference to an external resource is pretty
much all most AR purpose's need. Various timestamps could be added,
but there isn't actually too much strictly needed for AR.
At least, when talking about 3D models or similar assets that will
need remote loading anyway.
Dealing with annotations is another matter though. Positioning a bit
of text at a location raises all sorts of questions about how to store
style/layout information for it.
-Thomas
On 28 July 2011 16:00, Rob Manson <roBman@mob-labs.com> wrote:
> Ships that passed in the night 8)
>
> I'm happy to volunteer for 2. and 4.
>
>
> roBman
>
>
>
> On Thu, 2011-07-28 at 09:54 -0400, Matt Womer wrote:
>> Hi Rob,
>>
>> My responses are inline. Â I changed the subject line, as this goes far beyond the scope of the issue listed (I removed the number too), and I don't want to clutter the issue with this discussion.
>>
>> On Jul 26, 2011, at 9:38 PM, Rob Manson wrote:
>>
>> > Following up from a few points I raised in the conference call last
>> > week, I'm really concerned how the current model in the PWD doesn't meet
>> > the core needs of AR.
>>
>> I agree with you, that the current Core doesn't meet the needs of AR. Â I highly doubt, in the end, that the Core will meet all of the AR needs, but rather some middle ground between too light to be useful and too AR specific to be useful in other applications. Â So far we've been determining what is Core vs AR in a very informal fashion, and now with the Core as our top priority, the AR profile has begun to look like vaporware. Â If people are serious about volunteering to work on AR profile and we can still get the Core work done, then I think we should readjust our priorities. Â I'm saying this without having talked to the Chairs, this is just my opinion.
>>
>> As for concrete items, here is what I'd like to see:
>>
>> 1. Some WG guidance that can help us decide what should be core vs an extension. Â My rule of thumb has been, very roughly and in lieu of any other idea coming to mind: if it applies to just one application type, then it doesn't go in the Core. Â I see orientation, linking to visual representations, etc as having lots of uses, and should possibly go in the Core, or established as a link relation type.
>>
>> 2. A list of items that are AR specific. Â We haven't maintained a list of things we've rejected from the Core as being AR specific. Â We need someone to identify those things and document them for review. Â Create a page on our wiki at the very least.
>>
>> 3. AR folks on the calls and at meetings. Â My thanks to those that do attend, but we haven't had critical mass, and their dedication has not been rewarded. Â Calls and meetings, they're old fashioned, etc, but they're incredibly high bandwidth, and in my experience are the quickest way to resolve issues.
>>
>> 4. Technical AR experts who are willing to write spec-like text. Â I'm not saying we need a volunteer to edit the doc, I can do the grunt work. But we need people who understand the Core (both data model and XML syntax) and can integrate with those concepts. Â It's very difficult to try to integrate ideas that are developed in isolation of the rest of the spec, it's terminology, etc. Â Rob, you sound like the perfect candidate!
>>
>>
>> > This is not a criticism of the work that Matt and Raj have done. Â It's
>> > just a real concern I have. Â I know Raj mentioned that this may be
>> > treated through an "AR profile", but I'm not sure how or if that is
>> > proceeding.
>>
>> See above. Â It's not proceeding really, but could be with some volunteers.
>>
>> > So the wording in the subject above isn't really strong enough and
>> > doesn't capture the crux of the point I was raising.
>> >
>> > At the moment there is no way to link other digital content like images
>> > and 3d models to a POI in the current PWD. Â Without this there is no AR
>> > use for this standard 8(
>>
>> We could reuse or register a link type to handle both of those cases, but I suspect you mean "link other digital content with orientation". Â And that is correct. Â We need to figure out how to do that in this issue.
>>
>> >> From my perspective I'd rather see a stripped down data model that
>> > simply has a point based on fixed lat/lon or relative lat/lon and then
>> > almost all else able to be linked externally.
>>
>> Interesting. Â I would think that the AR community would be interested in more complex representations of a POI location than just a simple point without having to dereference anything else, no?
>>
>> > And optionally the linked
>> > data could then be pre-gathered and delivered inline along the lines of
>> > cid: links in MIME based email messages. Â But this last point is really
>> > just a serialisation discussion.
>>
>> That does strike me as a serialization issue too.
>>
>> >
>> > To me, a lot of the other mapping focused points around "near",
>> > "category" and "other geometry" discussions are distracting, open ended
>> > rabbit holes that are consuming a lot of discussion time with little
>> > resolution...while some critical hard requirements have been completely
>> > omitted.
>>
>> Please, let's enumerate them then. Â I tried to catalog requirements here:
>> Â Â Â http://www.w3.org/2010/POI/wiki/Requirements
>>
>> but it didn't catch on. Â I'd suggest creating:
>> Â Â Â http://www.w3.org/2010/POI/wiki/Requirements/Augmented_Reality
>>
>> And cataloging some of the ideas there.
>>
>> > If there's a process for working on the "AR profile" then please let me
>> > know what it is and I'll happily take on that task. Â Otherwise, I really
>> > have to push hard for simplifying the model and adding a more AR related
>> > focus back in.
>>
>> I would say start with some of the suggestions above, volunteer to write some text, and keep contributing, it's been very valuable so far!
>>
>> -M
>>
>>
>>
>
>
>