[gdal-dev] RFC 44: JSON/XML output for ogrinfo/gdalinfo

[Even Rouault]

Le mardi 19 novembre 2013 17:42:32, Howard Butler a écrit :
> All,
> 
> Dan Little and myself would like to put forward an RFC proposing -xml and
> -json output support for both ogrinfo and gdalinfo. No changes are
> proposed to the current text format (which would continue to be the
> default output format), but having JSON and XML available would greatly
> ease the integration of gdalinfo and ogrinfo into existing processing
> workflows without requiring that someone jump into scripting land. Though
> it might have been overkill to have an RFC, I thought it would be useful
> to have something to collaborate on if others have ideas about these
> particular features.
> 
> http://trac.osgeo.org/gdal/wiki/rfc44_gdalinfoxml
> 
> We look forward to your feedback,

Howard,

Certainly a proposal that would please people that don't want to study GDAL or 
OGR API ;-)

A few points, with some overlap with previous email exchanges :

- so that users can anticipate how to parse the output, documenting the 
grammar of the JSON and XML outputs seems to be necessary and should be the 
main topic of discussion in this RFC phase.

- some stability of the output would be appreciated, although it is always 
difficult to guaranty it will stay stable forever. For example, when adding RFC 
41 (multiple geometry fields per layer/feature), I tried to not change the 
output of ogrinfo when there's a single geometry but that implied some if else 
logic. But json / xml content have in their nature at least the capacity of 
being extended with new elements/nodes, so users would be encouraged to be 
robust to elements/nodes that were not documented in the GDAL version on which 
they based their implementation. And if breakage in the format occurs at some 
point for valid reasons, the action will be to document that in the release 
notes.

- I saw on IRC that you didn't anticipate to make that capability as an API 
call but still rely on parsing the output of the utilities. That make its use 
a bit complicated (in my opinion), but I don't see this as a blocking point. 

By the way, regarding ogrinfo, do you intend to dump all the features in the -
al mode or just the summary of the layers ? The "background" paragraph only 
mentions metadata. In which case there could be some redundancy with the 
GeoJSON and GML drivers (*)
Another point to take into account is that CPLMiniXML builds a DOM, as well as 
libjson-c. So, if dumping a huge layer that could possibly not fit into RAM 
(for that reason, the GML driver write "at hand" its output, and the GeoJSON 
builds a JSON object for each object that it dumps into the output, but not a 
JSON object for the whole collection. The inconsistency being that for read 
support, a global JSON object is reconstructed. End of slightly out of topic 
consideration). Not necessarily a use case that we want to cover, and to go 
back to my remark about an API call, you could raise that an API call would 
return a string, so with that same problem ;-)

- regarding Etienne's remark regarding all various way of encoding projection, 
I don't think we need to cover all the possibilities. <SRS 
type="WKT">PROJCS[...]</SRS> could be the base possibility. And we can then 
easily add other variants if needed.

- regarding the possible sources of inspiration for XML formats, for GDAL, we 
have PAM .aux.xml and .vrt as examples (both share common XML elements). For 
OGR, we also have the .vrt format

$ python swig/python/samples/ogr2vrt.py -schema poly.shp out.vrt
$ cat out.vrt
<OGRVRTDataSource>
  <OGRVRTLayer name="poly">
    <SrcDataSource relativeToVRT="0" shared="0">@dummy@</SrcDataSource>
    <SrcLayer>@dummy@</SrcLayer>
    <GeometryType>wkbPolygon</GeometryType>
    <LayerSRS>PROJCS["OSGB 1936 / British National 
Grid",GEOGCS["OSGB 
1936",DATUM["OSGB_1936",SPHEROID["Airy_1830",6377563.396,299.3249646]],PRIMEM["Greenwich",0],UNIT["Degree",0.017453292519943295]],PROJECTION["Transverse_Mercator"],PARAMETER["latitude_of_origin",49],PARAMETER["central_meridian",-2],PARAMETER["scale_factor",0.9996012717],PARAMETER["false_easting",400000],PARAMETER["false_northing",-100000],UNIT["Meter",1]]</LayerSRS>
    <Field name="AREA" type="Real" width="12" precision="3"/>
    <Field name="EAS_ID" type="Real" width="11"/>
    <Field name="PRFEDEA" type="String" width="16"/>
  </OGRVRTLayer>
</OGRVRTDataSource>


(*) . Well, I've just actually looked at the proposed ogrinfo code and see 
that the XML format is a custom one. I'm not particularly a huge fan of GML, 
although I spent (too) much time with it, but I'm not particularly 
enthousiastic that we invent our own OGR specific vector format... Someone 
would need to write a OGR driver to read it ;-)

Best regards,

Even

-- 
Geospatial professional services
http://even.rouault.free.fr/services.html