Hi Raj I agree. I believe that Mike's shopping list is already fully supported by X3D. That's may be why the two largest players in AR, Fraunhofer (Instant Reality) and Metaio (uses Bit Management's viewer), already use X3D in their AR viewers. I can understand why it is important to be able to import 2D KML data but as a central format it seems very limited and not suited to the task. AR platforms need 2D, 3D, video and ideally support for diverse data types from many other domains.
Fraunhofer has written some AR specific extensions to X3D. The Web 3D Consortium is beginning to discuss the topic to decide if any new nodes are needed to support the AR community. I hope that you and others in OGC will participate. This is a good time to get involved and see that it is done properly. Attending Mike's AR Devcamp would be a good first step. David Colleen Planet9 These sound like the same requirements for X3D: http://www.web3d.org/x3d/specifications/x3d/ "X3D is a scalable and open software standard for defining and communicating real-time, interactive 3D content for visual effects and behavioral modeling. It can be used across hardware devices and in a broad range of applications including CAD, visual simulation, medical visualization, GIS, entertainment, educational, and multimedia presentations." --- Raj On Oct 9, at 10:11 AM, Mike Liebhold wrote: > I've been granted a guest role by the AR Consortium to contribute to > the open ARML process. Here is my first post to their, so far, closed > forum: > > --- > I wish creation of an ARML would be easy by simply adopting a KML > framework. I'm afraid this approach is strictly limited, and needs a > broader perspective. KML is a reasonable starting place for > discussion, but there are many dimensions of the ARML design > requirement that go well beyond the KML framework. Here are some first > principles I suggest we resolve in setting the specifications for a > Universal ARML: > > * A Universal ARML will support both fundamental kinds of AR requiring > semantic frameworks be harmonized: 1. Image Triggered and 2. Location > Based. > > * A universal ARML will support many image trigger types, and many > coordinate systems. > > * A Universal ARML is a description of what happens on the focal plane > of the view, including user interface conventions, and rendering > rules. > > * A Universal ARML is a description of the properties of a specific > object or place, including data type, decoding and rendering > requirements and resources > > * A Universal ARML will support local media types produced by many > applications domains including 2D Web, 3D web, web maps, GIS, CAD, 3D > game and virtual worlds > > * A Universal ARML will support local rendering rules and coordinate > systems for specific places and objects e.g. html, CAD objects and > spaces, video, rendered graphics game objects, etc. > > * a Universal ARML will be a harmonized and interoperable semantic > framework with adjacent semantic domains within overlapping computing > and media domains, e.g. web, CAD, mapping, games, virtual worlds, etc. > > * a Universal ARML will support secure transactions and data exchange > > * a Universal ARML will support sensors and sensor networks > > * etc. > > We are planning an AR Devcamp here in the San Francisco Bay Area, now > perhaps in November to explore these issues. In the meantime I will > post some follow up thoughts here on how we can organize to support > these principles. > > I think it's important to realize that AR is not really a discrete > medium, it is the intersection of many media, So an ARML process, > needs to be inclusive, rather than exclusive. So, this private forum > is a good place to starting the process, ultimately a broad and deep > interaction with outside communities will be required to fullfill the > Augmented Reality vision. > > Cheers- > > Mike Liebhold > Institute for the Future > [email protected] > [email protected] > > --- > > > > > > > > Mike Liebhold wrote: >> H'mmm.... Since no-one here is directly engaged with these people, >> I'm wondering how to channel experienced contributions to this >> process... I've tried, but have been rebuffed. Was told that data >> interchange is too "researchy" for the " AR industry" And here they >> are running off, missing some pretty important issues. >> >> Talking to ourselves about this is somewhat silly. Somehow the key >> players need to be engaged here. Mobilzy - the proponents of this >> inititive are already shovelling in 2d KML into their service, >> oblivious of some of the issues we've thrashed to death here re, >> CRSs, epsg pointers etc.... >> >> See: http://www.openarml.org/ >> >> "Workgroup: >> Markus Tripp, Mobilizy GmbH >> Robert Rice, Neogence Enterprise >> >> " Since mid 2009 companies started to develop augmented reality >> (AR) applications for the latest generation of smart phones (iPhone, >> Android, ...). Many of those applications overlay the phone's cam >> view with interesting location aware data. Such information can be >> points of interest from travel or tourist services or real time data >> for instance from Twitter. >> >> There is already a standard available to describe geo data. KML is an >> open standard officially named the OpenGIS KML Encoding Standard (OGC >> KML). It is maintained by the Open Geospatial Consortium, Inc. >> (OGC). The complete specification for OGC KML can be found at >> http://www.opengeospatial.org/standards/kml/ >> . >> >> Many companies and organizations have their geo data already >> available in KML. Therefore it makes perfect sense to base the AR >> data on KML and enrich it with custom extensions. >> >> The basic idea behind this specification is that data that is >> prepared using this specification can be viewed on augmented reality >> browsers like Wikitude but also in Google Earth. Augmented reality >> browsers can include an open URL dialog where the user can enter an >> URL pointing to a valid ARML document. For instance such a document >> can contain all affiliates of a company. People can easily bookmark >> those URLs. >> >> Augmented reality (AR) specific data is defined in an own KML >> extension namespace. >> Examples >> Very Simple ARML Document >> >> The simplest ARML documents are just plain KML. Any ARML compliant >> browser must support these documents. Only the elements <kml>, >> <Document>, <Placemark>, <name>, <description>, <Point>, >> <coordinates> are required. >> >> simple.kml: >> view source >> print? >> 01.<?xml version="1.0" encoding="UTF-8"?> 02.<kml >> xmlns="http://www.opengis.net/kml/2.2";> >> 03. <Document> 04. <Placemark id="153630"> >> 05. <name>Getreidegasse</name> >> 06. <description> >> 07. Getreidegasse (also known as Grain Lane) is a >> busy shopping street in the Old Town section of Salzburg. >> 08. The house at no. 9 Getreidegasse is where the >> famed Wolfgang Amadeus Mozart was born and lived ... >> 09. </description> >> 10. <Point id="153630"> >> 11. <coordinates>13.048056,47.797222,432.0</ >> coordinates> >> 12. </Point> >> 13. </Placemark> >> 14. </Document> >> 15.</kml> " >> >> [snip] . . . >> _______________________________________________ >> Geojson mailing list >> [email protected] >> http://lists.geojson.org/listinfo.cgi/geojson-geojson.org >> >> > > _______________________________________________ > Geojson mailing list > [email protected] > http://lists.geojson.org/listinfo.cgi/geojson-geojson.org _______________________________________________ Geowanking mailing list [email protected] http://geowanking.org/mailman/listinfo/geowanking_geowanking.org _______________________________________________ Geowanking mailing list [email protected] http://geowanking.org/mailman/listinfo/geowanking_geowanking.org
