MapGuide RFC 56 - Add additional map commands to GETDYNAMICMAPOVERLAYIMAGE

This page contains an change request (RFC) for the MapGuide Open Source project. More MapGuide RFCs can be found on the RFCs page.

Status

RFC Template Version	(1.0)
Submission Date	October 6, 2008
Last Modified	Chris Claydon Timestamp
Author	Chris Claydon
RFC Status	(draft, proposed, frozen for vote, adopted, retracted, or rejected)
Implementation Status	(pending, under development, completed)
Proposed Milestone	2.1
Assigned PSC guide(s)	(when determined)
Voting History	(vote date)
no vote

Overview

The proposal is to add additional, optional parameters to the GETDYNAMICMAPOVERLAYIMAGE HTTP request format to allow setting the map view state. These parameters are already supported by the GETVISIBLEMAPEXTENT and GETMAPIMAGE HTTP request formats.

Motivation

The MGOS AJAX and Fusion viewers currently make (at least) two HTTP requests to render each new map image - one to GETVISIBLEMAPEXTENTS, which is used to set the current map view, and one to GETDYNAMICMAPOVERLAYIMAGE. The first request returns the extents of the map after the view state parameters have been applied. But in some cases this information is not required, and the two calls could easily be combined into one. This would provide increased efficiency and scalability.

Proposed Solution

The proposal is to add support for the following parameters to the GETDYNAMICMAPOVERLAYIMAGE HTTP request format:

SETDISPLAYDPI

SETDISPLAYWIDTH

SETDISPLAYHEIGHT

SETVIEWSCALE

SETVIEWCENTERX

SETVIEWCENTERY

CLIENTAGENT

SHOWGROUPS

HIDEGROUPS

SHOWLAYERS

HIDELAYERS

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

Funding/Resources

This section will confirm that the proposed feature has enough support to proceed. This would typically mean that the entity making the changes would put forward the RFC, but a non-developer could act as an RFC author if they are sure they have the funding to cover the change.