MapGuide RFC 152 - Add mapagent support for GeoJSON and simplified JSON responses

This page contains a 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	19 Nov 2015
Last Modified	19 Nov 2015
Author	Jackie Ng
RFC Status	draft
Implementation Status	sandbox experimental
Proposed Milestone	3.1
Assigned PSC guide(s)	(when determined)
Voting History	(vote date)
+1
+0
-0
-1
no vote

Overview

This RFC proposes to simplify all JSON responses from the mapagent, and adding GeoJSON output for SELECTFEATURES

Motivation

All JSON responses from the mapagent are verbatim conversions from their XML counterparts.

However this conversion process results in JSON that is quite cumbersome to consume:

• All properties are arrays.
• All properties are string values.

This is due to the conversion process not taking the content model (and its data types/element cardinality) into account, taking the lowest common denominator approach.

Also for the SELECTFEATURES operation, the JSON response in its current form is horribly un-usable. A more practical and ubiquitous JSON format for feature data already exists: GeoJSON

Proposed Solution

The MgJsonConvert class that does the actual XML to JSON conversion will be modified to include a hard-coded list of XML element paths:

• For elements that contain 0 to many elements
• For elements that are not string data types

During the conversion process, we check the computed XML element path of the element we're converting and check if it is in one of these two lists

• If it is in the first list, the element is written as a JSON array
• If it is in the second list, the element will not have its value quoted

To retain compatibility with clients using the JSON responses of the older mapagent, using simplified JSON responses is opt-in, by including CLEAN=1 as part of your mapagent request parameters. When this parameter is not specified or set to 0, the old XML to JSON conversion behaviour will be used.

For the SELECTFEATURES operation, when CLEAN=1 is specified the response format will be GeoJSON

With the new JSON responses, not only are they more intuitive to use (not everything is an array and not everything is a string), but is also much more compact due to the amount of [ and " characters we save by not converting everything to string arrays

Implications

Any time a new schema or schema revision is introduced, this hard-coded list will have to be updated to know which elements in these new schemas require special processing.

Test Plan

Verify all new JSON response parse as valid JSON.

Funding / Resources

Community