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 _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev