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

Even Rouault even.rouault at mines-paris.org
Wed Nov 20 02:34:13 PST 2013


> 
> > - 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.
> 
> Are there other examples of this type of application-oriented capability
> available in the APIs of GDAL and OGR proper?

Not that I can think of. But this would be something along to FrankW's 
proposal, let's say a "char* GDALGetSummary(GDALDatasetH hDS, const char* 
pszFormat, char** papszOptions);" and same thing with an OGR datasource.

> 
> > 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 immediate desire was simply focused on metadata and summary data along
> with SRS info. I didn't really want to come up with a new way of
> representing geometry or features, and I don't want to reengineer anything
> that might already have been done. That's one reason why we kicked out the
> RFC a little prematurely.
> 
> > The "background" paragraph only
> > mentions metadata. In which case there could be some redundancy with the
> > GeoJSON and GML drivers (*)
> 
> Would it seem reasonable that if you ask for JSON, you get GeoJSON, and if
> you ask for XML, you get GML?

You could use ogr2ogr for that as well ? Just trying to understand the benefit 
of doing it in ogrinfo.

Below, I give a few possible inspirational sources. Not that I have a strong 
opinion for one or another, but I thought it might be usefull to know what we 
already have.

Or from Python, you can already use

from osgeo import ogr
ds = ogr.Open('poly.shp')
lyr = ds.GetLayer(0)
for feat in lyr:
	feat.ExportToJson()

We have a ExportToGML() at geometry level, but not at feature level. I guess 
it could be added similarly to how it has been done to ExportToGML()

> 
> > $ python swig/python/samples/ogr2vrt.py -schema poly.shp out.vrt
> 
> I didn't know about ogr2vrt.py. For summary information, this is pretty
> much what I require, other than wanting to have it within arm's reach
> inside of ogrinfo. 

Regarding ogr2vrt.py output, I can see that feature count and extents are 
missing. But looking at OGR VRT source, I see they can be mentionned.

<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>
    <FeatureCount>10</FeatureCount>
    <ExtentXMin>478315.531250</ExtentXMin>
    <ExtentYMin>4762880.500000</ExtentYMin>
    <ExtentXMax>481645.312500</ExtentXMax>
    <ExtentYMax>4765610.500000</ExtentYMax>
    <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>

One issue is that the OGR VRT format does not yet support RFC 41 new 
capabilities.

I'm also thinking to the .gfs file, that is sort of "proprietary" GML schema, 
generated by the OGR GML driver when it reads a GML file without a XSD file (or 
with a XSD file too complex to be understood)

<GMLFeatureClassList>
  <GMLFeatureClass>
    <Name>poly</Name>
    <ElementPath>poly</ElementPath>
    <GeometryType>3</GeometryType>
    <DatasetSpecificInfo>
      <FeatureCount>10</FeatureCount>
      <ExtentXMin>478315.53125</ExtentXMin>
      <ExtentXMax>481645.31250</ExtentXMax>
      <ExtentYMin>4762880.50000</ExtentYMin>
      <ExtentYMax>4765610.50000</ExtentYMax>
    </DatasetSpecificInfo>
    <PropertyDefn>
      <Name>AREA</Name>
      <ElementPath>AREA</ElementPath>
      <Type>Real</Type>
    </PropertyDefn>
    <PropertyDefn>
      <Name>EAS_ID</Name>
      <ElementPath>EAS_ID</ElementPath>
      <Type>Integer</Type>
    </PropertyDefn>
    <PropertyDefn>
      <Name>PRFEDEA</Name>
      <ElementPath>PRFEDEA</ElementPath>
      <Type>Integer</Type>
    </PropertyDefn>
  </GMLFeatureClass>
</GMLFeatureClassList>

But it has some GML specificities, like the <ElementPath> and some oddity like 
the numeric value for the OGRwkbGeometry enumeration in the <GeometryType> 
element instead of a text representation.


> Is there a gdal2vrt.py as well?

Sort of : it is called "gdal_translate -of VRT"

> I know about
> gdalbuildvrt, but that's mostly processing directives, not metadata,
> right?

In its most simple use (just one source dataset), gdalbuildvrt is somehow 
equivalent to gdal_translate -of VRT, but possibly with less metadata.

> 
> Howard

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


More information about the gdal-dev mailing list