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.
|RFC Template Version||(1.0)|
|Submission Date||19 Nov 2015|
|Last Modified||19 Nov 2015|
|Implementation Status||sandbox experimental|
|Assigned PSC guide(s)||(when determined)|
|Voting History||(vote date)|
NOTE: This RFC has been superceded by MapGuideRfc158
This RFC proposes to simplify all JSON responses from the mapagent, and adding GeoJSON output for SELECTFEATURES
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
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
" characters we save by not converting everything to string arrays
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.
Verify all new JSON response parse as valid JSON.
Funding / Resources