MapGuide RFC 4 - KML Support

From OSGeo
Revision as of 10:28, 6 November 2006 by Wiki-Chrisclaydon (talk | contribs)
Jump to navigation Jump to search
This page contains an change request (RFC) for MapGuide Open Source.  
More MapGuide RFCs can be found on the MapGuide RFCs page.

Status

  • Submission Date:
  • Last Modified Date:
  • Author: Chris Claydon
  • RFC Status: (draft, proposed/pending vote, adopted or rejected)
  • Implementation Status: under development
  • Voting History:
  • Assigned PSC guide(s):

Overview

Google Earth allows external data to be overlaid upon its own vast collection of satellite imagery and vector graphics. It does this by supporting KML - an XML-based format that can be used to define how external vector and raster data may be dynamically loaded and displayed within the Google Earth application.

Motivation

By integrating MapGuide with Google Earth, we provide a compelling way for users to visualize their data in relation to the planet as a whole. In addition to satellite imagery, Google provides a large amount of useful content, such as road networks, points of interest, voting districts etc. By serving up MapGuide data via KML (and its compressed form, KMZ) we allow users to incorporate their specific data set with Google's.

So, for example, if a MapGuide data set contained information about underground pipes and sewers, this information could be overlaid on a satellite image showing individual streets and houses. This would greatly facilitate the process of estimating exactly which homes and streets would be affected by any maintenance required on those pipes.

Funding/Resources

Resources supplied by Autodesk.

Proposed Changes

A new service will be added to MapGuide that supports three request types - GetMapKml, GetLayerKml and GetFeaturesKml.

GetMapKml is designed to be the single point of user-initiated contact with the server. It takes the following parameters:

OPERATION=GetMapKml

VERSION=1

MAPDEFINITION=<map definition stored in repository>

DPI=<the resolution of the display used by the caller> (defaults to 96)

FORMAT=KML, KMZ or XML

This request can be made from a URL link in a web page. It generates a KML document representing the requested map definition. This document contains one NetworkLink element for each layer in the map. Google Earth uses these elements to make GetLayerKml requests back to MapGuide to retrieve further dynamic data for each layer.

If the format is KMZ, the KML document is compressed inside a zip file before being returned in the response. The mime types returned for KML and KMZ responses cause Google Earth to start up automatically and display the content of the document. If the requested format is XML, the mime type returned is text/xml, and the text of the KML document is typically displayed directly in the browser window.

GetLayerKml is designed to be called only by Google Earth. Its format may change in order to accomodate future enhancements to our KML support. It is therefore not recommended to call this operation directly. It supports the following parameters:

OPERATION = GetLayerKml

VERSION = 1

LAYERDEFINITION = <layer definition stored in repository>

DPI = <the resolution of the display used by the caller> (defaults to 96)

FORMAT = KML, KMZ or XML

BBOX = <minx,miny,maxx,mayy> the current map extent in WGS84 lat/lon coordinates

WIDTH = the current map width in pixels

HEIGHT = the current map height in pixels

The KML generated by the GetMapKml request populates the first 5 of these parameters, and the link is formatted in such a way that Google Earth provides the BBOX, WIDTH and HEIGHT parameters corresponding to its current view.

GetFeaturesKml is designed to be called only by Google Earth. Its format may change in order to accomodate future enhancements to our KML support. It is therefore not recommended to call this operation directly. It supports the following parameters:



Implications

This section allows discussion of the repercussions of the change, such as whether there will be any breakage in backwards compatibility, if documentation will need to be updated, etc.

Test Plan

How the proposed change will be tested, if applicable. New unit tests should be detailed here???