Apple’s Steve Jobs “Thoughts on Flash” where he has stated that “Flash is no longer necessary to watch video or consume any kind of web content” seems to have revived interest on HTML5 and also debates on Flash vs. HTML5. It is true that HTML5 lets web developers create advanced graphics, typography, animations and transitions without relying on third party browser plug-ins (like Flash).

HTML5, though still not released, is being supported by most browsers (of course, not all features are handled consistently) and has attractive features making it worthwhile to be considered right now. HTML5 supports video streaming, multi-threading, direct communications using Web sockets, asynchronous processing etc.  It is not just about Apple – Microsoft, Google, Mozilla etc. are committed to HTML5. Again it is not just Flash, HTML5 is capable of replacing technologies like Silverlight, Flex/AIR and JavaFX. Though there are debates about how each of them is better individually, the fact that HTML5 being a standard and supported by almost all browsers does make it attractive.

W3C recognized that HTML though used to describe a large variety of documents, was primarily designed for semantically describing scientific documents and is not adequate for “Web Applications”. Add the result is HTML5 that:

• Defines a single language (HTML5) which can be written in HTML syntax and in XML syntax.
• Defines detailed processing models to foster interoperable implementations.
• Improves markup for documents.
• Introduces markup and APIs for emerging idioms, such as Web applications.

HTML5, the draft effort of which has started in 2004, is still in the draft stage and has drawn considerable jokes about its possible release date (original proposed recommendation of 2022).  In Feb 2011, w3c finally announced that HTML5 release indeed has 2014 as the target. HTML5 aims at maintaining the openness of web technologies and reduce the need for proprietary presentation technology. HTML5 taking such a long time can be attributed to many factors – its history, scope, level of detail it aims at, inconsistencies in existing technologies and the need to be backward compatible etc. -detailed below.

HTML5 does have a broad scope and is intended to replace – DOM2HTML[Document Object Model Level 2 HTML Specification],HTML4,and XHTML1.

It is interesting to trace the history of HTML5 (which partially explains the long time it has taken).  At a W3C workshop in 2004, Mozilla and Opera presented the principles that underline the HTML5 and was rejected with membership voting for developing XML-based replacements instead. Shortly after, Apple, Mozilla, and Opera jointly announced their intent to continue working on the effort under the umbrella of a new venue called the WHATWG – Web Hypertext Application Technology Working Group. W3C showed interest in HTML5 in 2006 and in 2007 a working group was formed and later W3C published the specification under the W3C copyright, while WHATWG site kept a version with the less restrictive license. W3C points out that “HTML specification is not identical to what is published in the WHATWG site”.

One of WHATWG core principles is that specifications and implementations need to match even if this means changing the specification rather than the implementations, and that specifications need to be detailed enough that implementations can achieve complete interoperability without reverse-engineering each other.

HTML5 defines an HTML syntax that is compatible with HTML4 and XHTML1 documents published on the Web. But some attributes from HTML4 are no longer allowed in HTML5. HTML5 is backwards compatible, in the sense that user agents are required to support the older elements and attributes (no longer to be used by authors) and the specification defines how user agents should process them in legacy documents.

The following profound view from W3C is worth repeating: “It must be admitted that many aspects of HTML appear at first glance to be nonsensical and inconsistent. HTML, its supporting DOM APIs, as well as many of its supporting technologies, have been developed over a period of several decades by a wide array of people with different priorities who, in many cases, did not know of each other’s existence. Features have thus arisen from many sources, and have not always been designed in especially consistent ways. Furthermore, because of the unique characteristics of the Web, implementation bugs have often become de-facto, and now de-jure, standards, as content is often unintentionally written in ways that rely on them before they can be fixed.”

W3C points out that:

• HTML5 anchors the Open Web Platform that includes CSS (Cascading Style Sheets), SVG (Scalable Vector Graphics), WOFF (Web Open Font Format), various APIs, and more – the technologies already in use, at varying degrees of maturity and implementation.
• Stable standards play an important role as reference points, making it easier for large numbers of independent implementers to achieve interoperability across diverse platforms, devices, and industries.
• HTML5 is particularly important in the rich ecosystem of HTML producers and consumers, which includes authoring tools, browsers, email clients, security applications, content management systems, tools to analyze or convert content, assistive technologies, and unanticipated applications.
• HTML5 would become an important standard across multiple industries, for years to come.

HTML5 is a massive effort involving 50 organizations, and more than 400 individuals from all over the world in the group, including designers, content authors, accessibility experts, and representatives from browser vendors, authoring tool vendors, telecoms, equipment manufacturers, and other IT companies.

HTML5 is targeted specifically at applications that would be expected to be used by users from disparate locations, with low CPU requirements (suitable for mobile and other hand-held devices). As Steve Jobs points out, WebKit – the open-source HTML5 rendering engine – is used in Safari Web Browser (used in all Apple products) as well in Google’s Android Browser and other Smart phones including Palm and Nokia.

HTML5 is expected to be used for applications including online purchasing systems, searching systems, games (especially multiplayer online games), public telephone books or address books, communications software (e-mail clients, instant messaging clients, discussion software), document editing software, etc.

IBM’s project Vulcan that represents the next generation of Lotus Notes, uses HTML5 along with web services, xPages, RESTful APIs to deliver collaboration across company boundaries.

Gartner’s refers to HTML5 as one with “The Power of Rich, the Ubiquity of Thin” and it clearly conveys the aim (and hopefully the reality) behind HTML5. HTML5 does have the potential to make a large impact and bridging the gap between “Rich UI applications aimed at desktop” and “Web applications that can be accessed from any device, anywhere”. Today it does seem to have hiccups, but it seems to have the commitment from major players in the field and can be expected to get past them and become mainstream.

I believe with Apple, Microsoft, Google, IBM supporting W3C’s HTML, Steve Jobs statement “New open standards created in the mobile era, such as HTML5, will win on mobile devices (and PCs too)” would prove to be correct.

GeoTools is a free, open source Java geospatial toolkit for working with both vector and raster data. GeoTools is associated with the GeoAPI project that creates a vendor-neutral set of geospatial, Java interfaces derived from OGC specifications.

GeoTools is a general purpose geospatial library with a large feature set including:

• Create and Analyze graphs and networks
• Powerful “schema assisted” parsing technology using XML Schema to bind to GML content.
• Interact with OGC web services with both Web Map Server and Web Feature Server support
• JDBC plug-ins for DB2, H2, PostGIS, MySQL, SpatialLite, SQL Server

GeoTools implements Open Geospatial Consortium (OGC) specifications as they are developed including:

• Support for OGC Grid Coverage implementation
• Symbology using OGC Styled Layer Descriptor (SLD) specification
• Attribute and spatial filters using OGC Filter Encoding specification
• Supports Java Topology Suite (JTS), an implementation of OGC Simple Features Specification – that covers 2D constructs like Point, Line and Polygon. JTS allows 3D shapes (by having a third point) to be represented, but not used for calculations.
• Coordinate reference system and transformation support (for providing meaning to the Geometry or shapes of JTS)
• GeoTools plans to support OpenGIS ISO Geometry Interfaces for 3D and curves.

GeoTools includes two Renderers:

• LiteRenderer – a stateless, low memory renderer, particularly useful in server-side environments
• J2D – a stateful renderer with optimizations for update rate and good for interactive client-side displays

GeoTools supports additional formats through the use of Open plug-in system. The formats supported by an application can be controlled by including ONLY the required plug-ins. The plug-ins are available for raster formats – geotiff, gtopo30, world plus image files using common image formats such as JPEG, TIFF, GIF and PNG, imagemosaic, imagepyramid, JP2K. Plug-ins for the ImageIO-EXT project allows GeoTools to read additional raster formats from GDAL.

The GeoTools library forms a software “stack” with each jar building on the previous one (ref. http://docs.geotools.org/latest/userguide/welcome/geotools.html). GeoTools provides API (application programming interfaces) both for representing the data structures as well as to access public classes to execute a function. Only the jars needed for an application can be included. For referencing, gt-opengis, gt-referencing and gt-metadata are required. Similarly to use Data, you need gt-api, gt-data, gt-main, jts, gt-opengis, gt-referencing, gt-opengis, gt-metadata.

GeoTools code is distributed under the GNU Lesser General Public License (LGPL) and can be used for commercial applications. If the GeoTools library itself is modified, then you have to publish the source code to those changes to the users of your application (or optionally submit it back to GeoTools).

GeoTools uses a modular architecture with high extensibility allowing additional functionality to be easily incorporated. Modules with a gold star rating indicating their quality (3 or more stars means great) is listed in http://docs.codehaus.org/display/GEOTOOLS/Module+Matrix.

GeoTools can be used to access GIS data in many file formats and spatial databases, filter and analyze data in terms of spatial and non-spatial attributes, compose and display maps with complex styling and work with an extensive range of map projections.

Geographic Information Systems (GIS) are expected to become more and more useful in IT (as a picture is worth thousand words) and GeoTools is a good way to start exploring it and applying it in reallife applications – as it supports a large number of formats and more standardized (though some of the APIs are not – though the public access API are expected to remain stable).

IPv6 is again in the news with 8^th June 2011 designated as “World IPv6 Day” as Facebook, Google and Yahoo, are joining major content delivery networks Akamai and Limelight Networks (NASDAQ: LLNW), and the Internet Society, for the first global-scale trial of the new Internet Protocol, IPv6. On June 8, 2011, these participants will enable IPv6 on their main services for 24 hours. It is important to note that Google and Facebook had already provided IPv6 access to their services through a subdomain – “ipv6.google.com” and “www.v6.facebook.com“.

Internet protocol (IP) addresses, are critical for the operation of the Internet, as every device linked to the Internet needs a unique number to enable it to connect with the rest of the devices on the network.

IPv6 (Internet Protocol version 6) is an Internet layer protocol developed by the Internet Engineering Task Force as an alternative to IPv4 and published as early as December 1998. While IPv4 is a 32-bit system and can therefore support 2³² (4,294,967,296) addresses, IPv6 is based on 128-bit addresses that can support 2¹²⁸ addresses (approximately 340 undecillion or 3.4×10³⁸).

The exact number is 340,282,366,920,938,463,463,374,607,431,768,211,456. Obviously, IPv6 provides enough addresses to allow the Internet to continue to expand and the industry to innovate. This expansion allows for many more devices and users on the internet as well as extra flexibility in allocating addresses and efficiency for routing traffic.

IPv4 address exhaustion has been long anticipated but IPv6 didn’t really happen in a hurry. As a means of alleviating the pressure to move away from IPv4, Enterprises use private IP addresses, NAT (network address translation) and DHCP (Dynamic Host Configuration Protocol). Gartner’s April 2006 suggestion that “most should delay any move to IPv6 as there is no real pressure” reflects the mindset at that point in time.

IPv6 has been slowly – but steadily picking up since 2005 as shown in http://www.ipv6actnow.org/info/statistics/. But this is changing quickly as the IPv4 address pool is declining quickly as shown in http://webscannotes.com/?p=917. In any case, the best estimate is that IPv4 addresses available from Regional Internet Registries (RIRs) will be exhausted in mid-2012.

The reasons for the delay in IPv6 adoption are:

• IPv6 is not directly compatible with IPv4, meaning that a device connected via IPv4 cannot communicate directly with a device connected using IPv6.
• IPv6 implementation requires pro-active steps: technology must be upgraded, staff trained, business plans developed.

To ignore IPv6 any more means taking risk. The results predicted are loss of universal Internet interconnectivity, scattered performance issues, configuration and security problems and legal and financial issues (Gartner – May 2010).

Does that mean that every Enterprise should move to IPv6 right away? Thankfully, the answer seems to be “Not necessary”.

A Gartner Report (Sep 2010) points out that “Communications service providers (CSPs) in Japan received a report on IPv4address saturation likely to happen in 2012 from APNIC, an authority on Asian IP networks and CSPs should therefore move to use IPv6 immediately”. When IPv4 addresses run out, only IPv6 addresses will be available to new Internet users and websites have to be ready to offer their services over IPv6 by then. So service provider networks – especially the ones that support IPv6 enabled mobile devices – are expected to the first to adopt IPv6 (and the June 2010 tested also point to the same trend).

According to http://blogs.gartner.com/john_pescatore/2010/06/11/guest-blogger-lawrence-orans-on-ipv6-and-security/,  Enterprises need to be pay attention to IPV6, but there is still no need to panic – IPv4 will be around for a very long time. The Enterprises may not be able to adopt IPv6 (or actually do away with IPv4) right away as:

• Enterprise Packages like Oracle, SAP and others are not IPv6 Compatible.
• Network management solutions are not yet ready for IPv6.
• Security solutions don’t support IPv6 well and IPv6-based anomaly detection is also light.
• Support for IPv6 amongst SIEM vendors varies widely.

While taking minimum action to ensure that the external networks connectivity is not affected, implementing IPv6 in internal enterprise networks is not required to be done in a hurry. Most Enterprises are expected to have IPv6 internet presence by 2014 and till then the IPv4 addresses they already have should be sufficient.

IPv6 Deployment is quite challenging and though 2014 seems to be a long away deadline, for smooth implementation, IPv6 planning (refer http://www.ipv6actnow.org/info/how-to/enterprise/) should start right away. Gartner’s comment (on its Dec 2010 report), “IPv6: Its Time for (Limited) Action” nicely sums up the current situation.

Mashups are expected to be used by the business users directly (and not require programming skill) and the tag language EMML makes it easy to learn and use. Using the simple statements and commands of EMML, quite a few useful mashups can be created.

As usage of Mashup accelerates, the tendency to create more powerful and complex mashups would follow. In this blog, I have tried to give the crux of some of these advanced techniques.

Web clipping for direct use of HTML

Using the web clipping (or Screen scraping) technique, you can get the entire HTML from any URL as a service response. The EMML Reference Runtime Engine converts the HTML retrieved by the <directinvoke> statement is to XHTML in the http://www.w3.org/1999/xhtml namespace. You can filter, combine or transform with XHTML to create your own output.

Example of <directInvoke> resulting in web clipping:

The itemlink list in the XML result is as follows:

Normalizing Data for Effective Joins, Grouping or Filtering

Mashups – as the name suggests – is expected to get results from different services (not designed to work with each other). Though similar data is obtained from these services invoked, they would not be in identical forms. For effective usage of joins, grouping or filtering these results from different services, normalization of data to a single representation becomes essential. Creating a custom XPath function is the best method to normalize data.

The following example shows joining mortgage rates from two web sites – one refers to the APR and the second uses custom terms:

Create the custom XPath function – to normalize the custom terminology – as a Java class myFinanceFunction that extends org.oma.emml.client.EMMLUserFunction.

Compile this class, adding web-apps-home/emml/WEB-INF/lib/emml.jar to the classpath. Deploy the compiled class to web-apps-home/emml/WEB-INF/classes for the EMML Engine that host the mashups using this function.

Add a namespace for the class as an xmlns attribute to the <mashup> tag that uses this function.

Use the custom function in the XPath expressions in the <join> statement (or where data needs to be normalized).

Removing Duplicates With Filtering

To remove duplicates in a mashup, simply merge, join or group results. Sort the combined results (If needed) based on the key field that determines uniqueness to ensure that duplicates are contiguous. Use <filter> with a filtering expression that compares the key value of either the preceding or following ‘item’ to determine if this ‘item’ is unique. The filter expression can use the axis feature in XPath to compare preceding or following items.

Following is a simple <filter> statement:

<filter inputvariable=”$a” outputvariable=”$a” filterexpr=”/rss/channel/item[contains(title,'Java')" />]

In addition to the default XPath axis – the child axis, you can refer to previous nodes (preceding / preceding-sibling), following nodes (following / following-sibling), the parent node, ancestor nodes, descendant nodes and others. You can also use wildcards like following::* or following::node() to identify all following nodes of any name.

The following example checks the title of each item (after merging results from two RSS services) to remove duplicates:

I shall cover some more techniques in the second part of this blog. The Advanced Mashup Techniques are detailed in http://www.openmashup.org/omadocs/v1.0/emml/advMashupIntro.html.

Open Mashup Alliance (OMA) is a consortium aimed at successful use of Enterprise Mashup technologies and adoption of an open language – Enterprise Mashup Markup Language (EMML) – that promotes Enterprise Mashup interoperability and portability. EMML is an XML language to describe the processing flow for a mashup. The OMA provides the EMML schema and also a reference runtime implementation that processes mashup scripts written in EMML.

The EMML package can be downloaded from http://www.openmashup.org/download. Before installing the EMML package, install the JDK (1.5 or above) and Tomcat 5.5 or another compatible application server. EMML samples can be downloaded from http://www.openmashup.org/download.

You can create a mashup script using any XML editor. Adding the EMML schema, emml-install/EMMLSpec.xsd, to the XML editor – enables the editor to provide syntax assistance and validation. A Mashup script – an XML file that uses EMML – is created to define:

• the services and operations to be used by the mashup and
• the actions to apply to service responses to construct the results of the mashup.

Following is a simple mashup script that invokes a service (most viewed stories) and filters the output (business).

 Two categories of elements are added to mashups:

• Declarations for variables, parameters, data sources, namespaces, macros or metadata.
• Statements that perform actions – to invoke services, control flow, act on the results or use custom statements defined in macros – for the mashup.

Variables and Parameters

Variables and parameters must be declared (explicitly or implicitly) before they are used in any other EMML statement. Variables and parameters have a name, a datatype, data (a value), a scope (global or local) and optionally a default value. Variables can be created implicitly by assigning a name to the outputvariable attribute for any statement.

• <input> is an optional element to declare parameters that can be used as input to mashup, operation or macro.
• <output> is the parameter that holds the result returned from a mashup, operation or macro.
• <variables> is a list of variables to use for input, output or to hold any intermediate data or document content in the flow of mashup processing.

Accessing a database

To invoke SQL queries or statements, <datasource> with connection information for the database must be declared.  Each <datasource> declaration must have a URL that defines the JDBC connection and database login information (or) a JNDI name for connections to the database. Connection information can also be set dynamically as follows:

Note that, to use a <datasource>, you must add the JAR files containing JDBC drivers for your data source to the EMML Reference Runtime Engine classpath and add configuration for these drivers.

Use <sql>to issue individual SQL queries to a data source – for example:

Use <sqlUpdate> to execute any other SQL statement against a data source – for example:

<sql> and <sqlUpdate> can also be used to invoke stored procedures. SQL transactions can be managed using <sqlBeginTransaction>, <sqlCommit> and <sqlRollback>. EMML currently does not support distributed transactions.

Accessing a Web Service

Using <directinvoke>, you can invoke a publically accessible web service or website. In case of service invocation error, the EMML Reference Runtime Engine returns error information in two built-in variables: faultcode and faultmessage.

Transforming Intermediate Results

The mashup statements that can be used to select specific results, sort results, or otherwise transform the data in variables include:

• <assign> – to assign values or copy part of all of a variable
• <filter> – to filter a variable
• <group> – to group data in a variable and optionally filter or sort
• <sort> – to sort a variable
• <annotate> – to add nodes and data to a variable
• <xslt> – to transform data using XSLT stylesheets

Additionally, XPath functions can be used to transform data, change datatypes, perform calculations or determine boolean conditions.

Using the <script> statement, user-defined code can be executed within mashup processing. JavaScript and JRuby 1.0 are the scripting languages currently supported.

Combining Service Results

Results of two or more component services can be combined using:

1. <merge> – to merge service results that have homogenous, document-type structures (similar to database union operation)

2. <join> – to define how the data from disparate variables should be joined. Variable data should have repetitive structures that are related based on some criteria – say, the foreign keys that define the relation. It is comparable to inner joins for databases.

3. XQuery – to obtain outer joins in mashups.

Constructing the Mashup Result, Input or Intermediate Variables

The following statements can be used to define the structure of the result that is returned from a mashup, or to construct complex input parameters or any complex intermediate variable:

• <constructor> to construct a well-formed document.
• <appendresult> to add one or more well-formed items to a variable.
• <select> (within <mashup>, <operation> or <macro>)
• <select> within a <join> command to select specific items within a set of repeating items. See <join>.
• <group> constructs repeating structures from sorted and optionally filtered node sets.

Literal XML can also be used to construct the contents of variables or input parameters.

Controlling Mashup Processing Flow

The mashup commands to control the processing flow for a mashup operation includes:

• <if> for conditional processing
• <for> for looping based on simple counts
• <foreach> for looping through a set of nodes. This can be simple iterative loops or loops can be processed concurrently.
• <while> for looping as long as a condition is true
• <break> to forceably stop looping statements
• Concurrent Mashup Processing Flows using <parallel>.
• SQL Transactions using <sqlBeginTransaction>, <sqlCommit> and <sqlRollback>.

Using <emml-meta> and <user-meta>, metadata can be declared to allow setting of processing flags or pass other information to applications that will use a mashup, use a macro or handle mashup results.

EMML, like any other tag language, is quite simple to use and can be used by business users to create mashups quickly. EMML also supports various statements and commands that can be used to create complex Mashups depending on the needs of the user.

Drilling deeper into KML – OGC Geographic Visualization Standard

KML is an XML grammar used to visualize geographic data in an earth browser such as a 3D virtual globe, and 2D web browser of mobile mapping applications. KML has a tag-based structure with names and attributes used for specific display purposes and a KML instance is processed by web browsers in a way similar to that of HTML or XML.

KML can be used to:

• Annotate the Earth
• Specify icons and labels to identify locations on the surface of the planet
• Create different camera positions to define unique views for KML features
• Define image overlays to attach to the ground or screen
• Define styles to specify KML feature appearance
• Write HTML descriptions of KML features, including hyperlinks and embedded images
• Organize KML features into hierarchies
• Locate and update retrieved KML documents from local or remote network locations
• Define the location and orientation of textured 3D objects

KML uses the W3C XML Schema language to describe the grammar of conformant KML data instances. Conformant KML 2.2 files shall validate against the KML 2.2 schema. As stated in an earlier article, KML encoding uses geodetic longitude, geodetic latitude and altitude as define by the GML Coordinate Reference System (CRS) with identifier LonLat84_5773. The vertical datum is the WGS84 EGM96 Geoid.

A spatial extent of a Placemark is defined by extending the <Geometry> element. The spatial extent can include:

• the location of an anchor point on the earth, that serves as an origin for a 3D object in case of Model element.
• the encoding of explicit coordinate tuples in the coordinates element (as in Point, LineString or LinearRing).

In case of LineString, LinearRing and Polygon elements, subclauses are used to describe the interpolation schemes (used to represent Placemark that are not explicitly encoded).

The interpolation used for LineString and LinearRing depend on the values of the child altitudeMode (relativeToGround, absolute, clampToGround) and tessellate (1-true or 0-false) elements. It is worth noting that the control points of every LinearRing must lie on a common plane. The following KML instance, has the projected LineString that follow the earth’s curvature:

<kml xmlns="http://earth.google.com/kml/2.2">
  <Document>
    <Placemark>
      <LineString>
         <tessellate>true</tessellate>
         <altitudeMode>clampedToGround</altitudeMode>
         <coordinates>-135,30,500000 -80,30,500000</coordinates>
      </LineString>
   </Placemark>
  </Document>
</kml> 

The interpolation used for Polygon also depends on the values of the child altitudeMode (relativeToGround, absolute, clampToGround) and tessellate (1-true or 0-false) elements. In the following Polygon instance with the altitudeMode set to clampToGround, translates to a part in the earth’s terrain surface as shown below:

<kml xmlns="http://earth.google.com/kml/2.2">
  <Document>
    <Placemark>
      <Polygon>
        <altitudeMode>clampToGround</altitudeMode>
        <outerBoundaryIs>
          <LinearRing>
            <coordinates>-135,78.5,300000 -135,12.5,300000 -45,12.5,300000 -45,78.5,300000 -135,78.5,300000</coordinates>
          </LinearRing>
        </outerBoundaryIs>
      </Polygon>
    </Placemark>
  </Document>
</kml>

KML Polygon Interpolation - Example

• The outer boundary points of the polygon that are interpolated between the control points in the LinearRing form a rectangular perimeter in the plate carrée plane.
• Then the interior points of the rectangle are filled in linearly in this plane.
• Finally each (long,lat) point of the rectangle is mapped to a (long,lat,alt) point on the earth terrain surface.

Refer to http://blog.opengeo.org/2010/08/10/shape-of-a-polygon/ for Interesting examples on Polygon and their representation in KML.

Refer to http://code.google.com/apis/kml/documentation/kmlreference.html#polystyle for complete reference – including coloring of Polygons.

For more detailed information on KML models and syntax, the OGC Project document titled “KML 2.2 – An OGC Best Practice” with more details can be downloaded from http://portal.opengeospatial.org/files/?artifact_id=23689.

KML is the international standard language (actually an XML schema) for expressing geographic annotation and visualization within Internet based, two-dimensional (2D) maps and three-dimensional (3D) earth browsers (or GeoBrowsers). Objective of KML is to encourage broader implementation and greater interoperability and sharing of earth browser content and context.

KML (earlier called Keyhole Markup Language) was developed by Keyhole, Inc which was acquired by Google. Google uses KML as the file format to display geographic data in Earth browsers like Google Earth, Google Maps and Google Maps for mobile. Google submitted KML to the Open Geospatial Consortium (OGC) and KML ver 2.2 has been adopted as an OGC implementation standard. After KML has been accepted as an OGC standard, it is supported (in one way or another) on most of the major GeoBrowsers.

KML focuses on geographic visualization – namely the presentation of graphical data on the globe, control of the user’s navigation on where to go and where to look, and annotation of maps and images. Using KML files, we can specify the features – images, polygons, 3D models, place marks, photo overlays, paths, network links – for display in any 3D GeoBrowser implementing the KML encoding. KML files are used to pinpoint locations, add image overlays, and expose rich data in new ways. Typically, KML files are distributed in KMZ files, which are zipped files with a .kmz extension.

KML can also be used to represent astronomical data and display objects – stars, constellations, planets, moon and galaxies – in the sky using Google Sky or Microsoft’s WorldWide Telescope. You can define tours (using the set of extensions to the OGC KML standard – supported currently by Google Earth) by placing specific elements, in order, into a KML file. Tours basically use the tour primitives like FlyTos, Waits, TourControls, AnimatedUpdates and SoundCues – that run in series or in parallel.

Any KML feature can have time data associated with it, restricting the visibility of the data set to a given time period (TimeSpan) or point in time (TimeStamp). In Google Earth, the time slider controls which parts of the data is visible.

Usage of KML includes:

·         Casual users use KML to Place mark homes, plan and document tours, plan cross-country hikes and cycling ventures.

·         Scientists use KML to provide detailed mapping of resources, models and trends such as volcanic eruptions, weather patterns, earthquake activity, and mineral deposits.

·         Real estate professionals, architects, city development agencies use KML to propose construction and visualize plans.

·         Educational community uses KML to explore historic and current people, places and events.

·         National Geographic, UNESCO and such organizations use KML to display their rich sets of global data

·         Non-profit organizations use KML to highlight problems and advocate change

KML is complementary to other OGC standards including GML (Geography Markup Language), WFS (Web Feature Service) and WMS (Web Map Service). KML 2.2 utilizes certain geometry elements – point, line string, linear ring, and polygon – derived from GML 2.1.2.  In the near future, additional harmonization of KML with GML (e.g., using the same geometry representation) is expected. Together KML and GeoRSS makes information more searchable – with KML focus on visualization of resources and GeoRSS on tagging and linking of resources.

GeoRSS is an open and emerging standard aimed at describing geographic information (location) in an interoperable manner so that applications can request, aggregate, share and map geographically tagged feeds. GeoRSS, derived from RSS, extends existing web feeds – rendered by aggregators and web browsers – with geographic information. GeoRSS is designed for use with Atom 1.0, RSS 2.0 and RSS 1.0 and can also be easily used in non-RSS XML encodings.

The GeoRSS collaboration has completed work on two primary encodings namely:

1. GeoRSS-Simple – Lightweight format that supports basic geometries – point, line, box, polygon – and useful for encoding locations.

2. GeoRSS GML (Geography Markup Language) – Formal Open Geospatial Consortium (OGC) GML application profile supporting a greater range of features.

GeoRSS coordinates refers to World Geodetic System (WGS84) that defines a reference frame for the earth which is the accepted standard for use in geodesy and navigation. WGS84 comprises a standard coordinate frame for the Earth, a standard spheroidal reference surface for raw altitude data and a gravitational equipotential surface that defines the nominal sea level. It is to be noted that GeoRSS lines and boundaries are allowed to cross the dateline or circle the poles.

GeoRSS Simple is concise in both representation and conception and quite sufficient for many needs. The four GeoRSS objects require only a single tag.

1. A point contains a single latitude-longitude pair, separated by whitespace.

<georss:point>45.256 -71.92</georss:point>

2. A line contains a space separated list of latitude-longitude pairs (minimum two pairs) in WGS84 coordinate reference system, with each pair separated by whitespace.

<georss:line>45.256 -110.45 46.46 -109.48 43.84 -109.86</georss:line>

3. A box contains two space separate latitude-longitude pairs. The first pair is the lower corner and the second pair is the upper corner. A bounding box is a rectangular region used to define the extents of a map or a rough area of interest.

<georss:box>42.943 -71.032 43.039 -69.856</georss:box>

4. A polygon contains a space separated list of latitude-longitude pairs. There must be at least four pairs, with the last being identical to the first (so a polygon has a minimum of three actual points).

<georss:polygon>45.256 -110.45 46.46 -109.48 43.84 -109.86 45.256 -110.45</georss:polygon>

5. A circle contains three coordinates with centerpoint latitude, centerpoint longitude in the WGS84 coordinate reference system and radius in meters.

<georss:circle>42.943 -71.032 500</georss:circle>

As Earth is a spheroid, GeoRSS enforces some constraints on the geometries to avoid ambiguous shapes. For example, it requires that no two points in a line or polygon may have latitude values that are more than 179 degrees apart. This constraint allows the use of the simple convention with just asking the users to add an extra point in the geometries to avoid ambiguity.

GeoRSS geometry is meant to represent a real feature of the Earth’s surface. It has these additional case-sensitive properties with no constraints (intent being the folksonomy to emerge).

1. A single string containing a featuretypetag. The default is “location”.

<georss:featureTypeTag>city</georss:featureTypeTag>

2. A single string containing a relationshiptag. The default relationship, “is-located-at” simply indicates that the subject of the content is located at the GeoRSS feature.

<georss:relationshipTag>is-centered-at</georss:relationshipTag>

3. A single string containing a featureNametag which indicates the name or identifier of the referenced geographic entity.

<georss:featureName>Millis, MA</georss:featureName>

<georss:featurename>12 HURSTCOURT ROAD Sutton Surrey SM1 3JF</georss: featurename>

 In GeoRSS, Elevation can be expressed as “elev” or “floor”.

• “elev” is meant to contain height in meters from the WGS84 ellipsoid, easily obtainable from any GPS device.

<georss:elev>313</georss:elev>

• “floor” is meant to contain the floor number of a building.

<georss:floor>2</georss:floor>

GeoRSS Simple permits the uses of comma instead of whitespace and GeoRSS parsers should just treat commas as whitespace. Refer to http://www.windsorsolutions.biz/xsd/ENGeoTF/georss11.htm for details on the GeoRSS schema properties.

The downside to the GeoRSS Simple’s simplicity is the cost of direct upward compatibility with GML which represents a point as follows:

  <georss:where>

    <gml:Point>

      <gml:pos>45.256 -71.92</gml:pos>

     </gml:Point>

  </georss:where>

GeoRSS Simple meets the need for many applications and the transformation from Simple serialization to the GML serialization is straightforward.

GeoRSS is used in many sites and one such example is http://mapufacture.com/about/buildingmaps. Multiple GeoRSS-Simple Readers which will take the geographic data and display maps – say in Google Maps or Virtual Earth – are available in the web. GeoRSS using the fixed coordinate system of decimal longitude, latitude degrees (global WGS84) that is used by most online map services, makes it easy for “mashups” without complex coordinate transformations.