Changes between Version 1 and Version 2 of MapGuideRfc56

Oct 6, 2008, 9:07:45 AM (15 years ago)



  • MapGuideRfc56

    v1 v2  
    1 Placeholder
     1= !MapGuide RFC 56 - Add additional map commands to GETDYNAMICMAPOVERLAYIMAGE=
     3This page contains an change request (RFC) for the !MapGuide Open Source project.
     4More !MapGuide RFCs can be found on the [wiki:MapGuideRfcs RFCs] page.
     7== Status ==
     9||RFC Template Version||(1.0)||
     10||Submission Date||October 6, 2008||
     11||Last Modified||Chris Claydon [[Timestamp]]||
     12||Author||Chris Claydon||
     13||RFC Status||('''draft''', proposed, frozen for vote, adopted, retracted, or rejected)||
     14||Implementation Status||('''pending''', under development, completed)||
     15||Proposed Milestone||2.1||
     16||Assigned PSC guide(s)||(when determined)||
     17||'''Voting History'''||(vote date)||
     18||no vote|| ||
     20== Overview ==
     22The 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.
     24== Motivation ==
     26The 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.
     28== Proposed Solution ==
     30The proposal is to add support for the following parameters to the GETDYNAMICMAPOVERLAYIMAGE HTTP request format:
     44== Implications ==
     46This 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.
     48== Test Plan ==
     50How the proposed change will be tested, if applicable.  New unit tests should be detailed here???
     52== Funding/Resources ==
     54This 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.