openARML augmented Reality Markup language ~ extended KML?

[Mike Liebhold]

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]  . . .
_______________________________________________
georss mailing list
georss@...
http://lists.eogeo.org/mailman/listinfo/georss

[Carl Reed]

Thought this might be interesting.

http://social.thewherebusiness.com/content/commercial-reality-ar

Carl

----- Original Message -----
From: "Mike Liebhold" <mnl@...>
To: <geowanking@...>; <georss@...>; "geojson"
<geojson@...>
Sent: Tuesday, September 22, 2009 3:29 PM
Subject: [georss] openARML augmented Reality Markup language ~ extended KML?

> 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]  . . .
> _______________________________________________
> georss mailing list
> georss@...
> http://lists.eogeo.org/mailman/listinfo/georss 

_______________________________________________
georss mailing list
georss@...
http://lists.eogeo.org/mailman/listinfo/georss

[Mike Liebhold]

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
mliebhold@...
mnl@...

---







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
> Geojson@...
> http://lists.geojson.org/listinfo.cgi/geojson-geojson.org
>
>

_______________________________________________
georss mailing list
georss@...
http://lists.eogeo.org/mailman/listinfo/georss

[Anselm Hook-2]

> 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.

ahhahahahaahaha.... ha... hahaha....... ha.  sob.

me
_______________________________________________
georss mailing list
georss@...
http://lists.eogeo.org/mailman/listinfo/georss

[Carl Reed]

Should be an interesting discussion!

I would also add that many government organizations and private sector
companies provide geospatial content as GML application schemas. I would
encourage the group to consider developments in Europe for sharing (and
visualizing) 3d urban models using an application schema of GML called
CityGML. The German community especially is looking at CityGML and its role
in the AR domain. From a standards perspective, the sharing and
visualization of geo content for AR applications is multi faceted. Both
CityGML and KML may have roles in AR. Further, if there are location
elements to be added to an AR "language" or "grammar", I would really
encourage that community to be consistent with ISO 19107, which the
foundation abstract model for spatial schemas/geometry used by GML, GeoRSS,
KML (yes, geometry in KML is consistent with 19107), OGC Simple Features,
and so forth.

Just a thought :-)

Also, as a standards geek I shudder when I hear "custom extensions".

Regards

Carl
----- Original Message -----
From: "Anselm Hook" <anselm@...>
To: "Mike Liebhold" <mnl@...>
Cc: "geojson" <geojson@...>; <geowanking@...>;
<georss@...>
Sent: Friday, October 09, 2009 11:16 AM
Subject: Re: [georss] [Geowanking] openARML augmented Reality Markuplanguage
~ extended 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.
>
> ahhahahahaahaha.... ha... hahaha....... ha.  sob.
>
> me
> _______________________________________________
> georss mailing list
> georss@...
> http://lists.eogeo.org/mailman/listinfo/georss 

_______________________________________________
georss mailing list
georss@...
http://lists.eogeo.org/mailman/listinfo/georss

[Anselm Hook-2]

Well, how about these three tests - which I could do myself or others
could pick up and try as well:

1) To actually try show the description of a polyhedra in KML, X3D and
GML ( and possibly CityGML and others ). What does it look like, how
verbose is the description?

2) To actually try show the description of some simple behavior
attached to a geometry. Say for example a script that makes an object
respond to the presence of an observer at a location.

3) Compare the sizes of a compressed description of the above in the
three primary grammars.

- me
_______________________________________________
georss mailing list
georss@...
http://lists.eogeo.org/mailman/listinfo/georss

[Anselm Hook-2]

A few other subjective notes:

4) Perhaps one more feature would be to look at how hard it is to
decorate the description of the geometry with style hints - is style
attached as a kind of CSS or the like?

5) And one other thing is ( a personal thing ) is it easy to multiply
instance a geometry?

6) Finally, for me, I just like the cleanest tidiest smallest grammar
- one that let's me read it easily; that is terse...  I know that the
conceptual notations are not tied to XML but I do like to see JSON
expressions or tidier expressions. I'm not a big fan of the XML
<markup> style notations because these days there is nothing that is
outside the markup zone. Markup meta-data today far overwhelms the
unmarked regions.  Therefore it seems to make little sense to have the
heavier tags.  You could just say something like "title { }" or
"title: " instead of <title>blah</title>.

7) I sure like having math operators in my grammar. CSS, even HTML for
me are sadly lacking and end up being very verbose. I know we all want
dirt simple parsers but I also really want some minimal abstraction.
This is why I like HAML and SASS - for terseness. It doesn't have to
be a fully procedural grammar with conditional expressions but the
fully dumb declarative grammars cause a lot of needless repetition
that doesn't very well capture the abstractions that are self-evident
to a human author.

Anyway... sorry to ramble on... I just do feel those are all empirical
tests which could be used to measure the utility of a new grammar
especially for AR which is now effectively making video-game concepts
mainstream... how well it maps the problem space and how easily humans
can understand it...  aside from the more mundane expected details of
capturing position, orientation, velocity, meta-data, relationships
and other kinds of things that one might want to capture.

 - me
_______________________________________________
georss mailing list
georss@...
http://lists.eogeo.org/mailman/listinfo/georss

[Carl Reed]

Some parts of this message have been removed. Learn more about Nabble's security policy.



To follow up on Greg's comments.

 

A few weeks ago, I attended Intergeo 2009 in Karlsruhe. I saw detailed demonstrations of some of the work being done by Fraunhofer for emergency services, disaster management, and alerting. A blend of mapping (2d and 3d), AR, CAD/GIS/BIM integration, and sensor fusion. Very impressive. I also saw a really cool AR type demonstration from CPA Systems (http://www.cpa-systems.de/). They had a CityGML file for all of Stuttgart (LOD3). The file was stored in its native format (no translation) in a database on a server. They had a game boy control linked to low end laptop that was linked wirelessly to the internet. They had a client application on the laptop that allowed the user to use the gameboy to control driving through the virtual city. All the urban model information was rendered directly from the CityGML file on the server. Very impressive. No hercky jerky. As they say, evidence that XML is not the enemy. Their next step is to fuse other layers, such as tree and annotation, into the virtual scene. They are also working on deploying a mobile version of the application. Everything they are doing is standards based - but very video game in concept.

 

 To add to the mix, there are now a number of applications for BIM (IFCs) <=> CityGML transformations, such as the work by Bentley or Snowflake or Onuma/BimStorm.

 

And finally a number of organizations, such as Hitachi, are intensively researching standards based approaches that blend indoor navigation and AR. And not a word about GIS - all the content is coming from CAD drawings.

 

And, Anselm, CityGML encodes position, orientation, metadata, and relationships as well as semantics.

 

I think the "pure" AR community would be well served to understand and learn from existing work.

 

Carl

 

 

 

----- Original Message -----

From: greg@...

To: anselm@...

Cc: geojson@... ; geowanking@... ; georss@... ; creed@...

Sent: Friday, October 09, 2009 7:38 PM

Subject: RE: [Geowanking] [georss] openARML augmented Reality Markuplanguage ~ extended KML?

GeoWankers,

Here is a thought from a real-world builder.  I consider this relatively important given that the size of the building industry in the U.S. is typically $1.3 trillion - and even in the current down market it is $850 billion.

Billions of existing CAD files (granted, most are simply 2D) already exist on architects' hard drives.  The very last thing the design and building world need is ANOTHER standard.  I consider it the very height of geo-arrogance that the wanker community considers GIS data more important than CAD/CAM/BIM data.  Don't overlook the fact that most people have far more interest in interacting with building data (especially their own house) than with GIS data.  THe importance and relevance of GIS data becomes many times more important when mashed-up with other data.  John Hanke publicly stated that he co-created Keyhole as a platform for real estate visualization.

Before you rush off to create yet another standard why not do a little due diligence and look at Carl Reed's existing work for the OGC regarding standards GIS-CAD-BIM and the design world's ongoing battle over standards for 3D geometry and object-level meta-data.  

I fully agree with David Colleen's views that supporting existing standards will inevitably prove far more beneficial.  I also believe it will open up unprecedented business opportunities for those willing and able to overlook their own domains and the ubiquitous silo-thinking that one finds in both academia and the commercial world. 

You can choose a different approach and remain years behind the augmented and virtual reality work already being done by the many Fraunhofer institutes.  Bear in mind that much of this work is very much standards compliant and supported by large industries in Germany and elsewhere.  I suspect this year's ISMAAR conference will further confirm who is really doing serious work mashing up data in real world commercial applications.

Or one can simply ignore it and choose irrelevance.

A builder's perspective,

Greg Howes

-------- Original Message --------
Subject: Re: [Geowanking] [georss] openARML augmented Reality
Markuplanguage ~ extended KML?
From: Anselm Hook <anselm@...>
Date: Fri, October 09, 2009 1:23 pm
To: Carl Reed <creed@...>
Cc: geojson <geojson@...>, geowanking@...,
georss@...

A few other subjective notes:

4) Perhaps one more feature would be to look at how hard it is to
decorate the description of the geometry with style hints - is style
attached as a kind of CSS or the like?

5) And one other thing is ( a personal thing ) is it easy to multiply
instance a geometry?

6) Finally, for me, I just like the cleanest tidiest smallest grammar
- one that let's me read it easily; that is terse... I know that the
conceptual notations are not tied to XML but I do like to see JSON
expressions or tidier expressions. I'm not a big fan of the XML
<markup> style notations because these days there is nothing that is
outside the markup zone. Markup meta-data today far overwhelms the
unmarked regions. Therefore it seems to make little sense to have the
heavier tags. You could just say something like "title { }" or
"title: " instead of <title>blah</title>.

7) I sure like having math operators in my grammar. CSS, even HTML for
me are sadly lacking and end up being very verbose. I know we all want
dirt simple parsers but I also really want some minimal abstraction.
This is why I like HAML and SASS - for terseness. It doesn't have to
be a fully procedural grammar with conditional expressions but the
fully dumb declarative grammars cause a lot of needless repetition
that doesn't very well capture the abstractions that are self-evident
to a human author.

Anyway... sorry to ramble on... I just do feel those are all empirical
tests which could be used to measure the utility of a new grammar
especially for AR which is now effectively making video-game concepts
mainstream... how well it maps the problem space and how easily humans
can understand it... aside from the more mundane expected details of
capturing position, orientation, velocity, meta-data, relationships
and other kinds of things that one might want to capture.

- me

_______________________________________________
Geowanking mailing list
Geowanking@...
http://geowanking.org/mailman/listinfo/geowanking_geowanking.org

_______________________________________________
georss mailing list
georss@...
http://lists.eogeo.org/mailman/listinfo/georss