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

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Howard Butler-3
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
_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: RFC 44: JSON/XML output for ogrinfo/gdalinfo

Mateusz Loskot
On 19 November 2013 16:42, Howard Butler <[hidden email]> wrote:
> 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,

"You don't parse the output of gdalinfo --format, do you?" :P

[1] http://lists.osgeo.org/pipermail/gdal-dev/2013-January/035117.html

Best regards,
--
Mateusz  Loskot, http://mateusz.loskot.net
_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: RFC 44: JSON/XML output for ogrinfo/gdalinfo

Howard Butler-3

On Nov 19, 2013, at 10:49 AM, Mateusz Loskot <[hidden email]> wrote:

> On 19 November 2013 16:42, Howard Butler <[hidden email]> wrote:
>> 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,
>
> "You don't parse the output of gdalinfo --format, do you?" :P
>
> [1] http://lists.osgeo.org/pipermail/gdal-dev/2013-January/035117.html
I don't, but I fully expect that are there are folks who have, simply due to not having a better, more convenient way to do things. JSON and XML output puts people on the right path at least...

Howard

_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev

signature.asc (506 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: RFC 44: JSON/XML output for ogrinfo/gdalinfo

Mateusz Loskot
On 19 November 2013 17:00, Howard Butler <[hidden email]> wrote:

> On Nov 19, 2013, at 10:49 AM, Mateusz Loskot <[hidden email]> wrote:
>> On 19 November 2013 16:42, Howard Butler <[hidden email]> wrote:
>>> 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,
>>
>> "You don't parse the output of gdalinfo --format, do you?" :P
>>
>> [1] http://lists.osgeo.org/pipermail/gdal-dev/2013-January/035117.html
>
> I don't, but I fully expect that are there are folks who have, simply due to not having a better,
> more convenient way to do things. JSON and XML output puts people on the right path at least...

Hobu, sure thing.
That was a bit of joke, and, on reflection I think a specified format
is actually useful idea.

Best regards,
--
Mateusz  Loskot, http://mateusz.loskot.net
_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: RFC 44: JSON/XML output for ogrinfo/gdalinfo

Howard Butler-3

On Nov 19, 2013, at 11:03 AM, Mateusz Loskot <[hidden email]> wrote:

>>> "You don't parse the output of gdalinfo --format, do you?" :P
>>>
>>> [1] http://lists.osgeo.org/pipermail/gdal-dev/2013-January/035117.html
>>
>> I don't, but I fully expect that are there are folks who have, simply due to not having a better,
>> more convenient way to do things. JSON and XML output puts people on the right path at least...
>
> Hobu, sure thing.
> That was a bit of joke, and, on reflection I think a specified format
> is actually useful idea.
Yes, I know, but it does bring up the issue of what to do when new things are added? Is there a specification/schema/something that provides some sort of forward compatibility? Do we promise to never change the name(s) of things? The free-form text format has been remarkably stable over the years, but it has accreted new items as time as gone on. Something to think about anyway...

Howard

_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev

signature.asc (506 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: RFC 44: JSON/XML output for ogrinfo/gdalinfo

Kralidis,Tom [Ontario]
In reply to this post by Mateusz Loskot
This would be a handy addition.  It would be helpful, to add to the RFC, sample XML output.

________________________________

From: [hidden email] on behalf of Mateusz Loskot
Sent: Tue 19-Nov-13 12:03
To: Howard Butler
Cc: [hidden email] dev
Subject: Re: [gdal-dev] RFC 44: JSON/XML output for ogrinfo/gdalinfo



On 19 November 2013 17:00, Howard Butler <[hidden email]> wrote:

> On Nov 19, 2013, at 10:49 AM, Mateusz Loskot <[hidden email]> wrote:
>> On 19 November 2013 16:42, Howard Butler <[hidden email]> wrote:
>>> 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,
>>
>> "You don't parse the output of gdalinfo --format, do you?" :P
>>
>> [1] http://lists.osgeo.org/pipermail/gdal-dev/2013-January/035117.html
>
> I don't, but I fully expect that are there are folks who have, simply due to not having a better,
> more convenient way to do things. JSON and XML output puts people on the right path at least...

Hobu, sure thing.
That was a bit of joke, and, on reflection I think a specified format
is actually useful idea.

Best regards,
--
Mateusz  Loskot, http://mateusz.loskot.net <http://mateusz.loskot.net/>
_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev


_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: RFC 44: JSON/XML output for ogrinfo/gdalinfo

Etienne Tourigny-3
In reply to this post by Howard Butler-3
You might think of adding json/xml output also to gdalsrsinfo, it should not be much work.

For example, if you have a <srs> node output by gdalsrsinfo, you could have the same (and only) node in gdalsrsinfo.  Also consider that there are various output formats for srs (mostly in gdalsrsinfo, but also proj4 for gdalinfo).

cheers
Etienne


On Tue, Nov 19, 2013 at 2:42 PM, Howard Butler <[hidden email]> wrote:
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
_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev


_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: RFC 44: JSON/XML output for ogrinfo/gdalinfo

Frank Warmerdam
In reply to this post by Howard Butler-3
Howard,

I was a bit surprised that the RFC doesn't actually define the format.  I gather we are supposed to deduce it from the modified ogrinfo code?

On the GDAL side, rather than have gdalinfo support some secondary reporting format, I *feel* it would be better to just have a method on a dataset to provide a summary report somewhat similar to what gdalinfo would give.  In XML this would essentially be what you would get from doing a "gdal_translate -of VRT abc.tif abc.vrt ".  

I must confess there isn't such a clean analog on the ogrinfo side, and if you want to also capture feature data written out by ogrinfo it gets someone more complicated.

Skimming the (json missing) example ogrinfo it seems like a lot of work - particularly to maintain in a way that will keep all output formats in line.  

I started out supportive, but the more I think about the approach the less keen I am.

Best regards,
Frank



On Tue, Nov 19, 2013 at 8:42 AM, Howard Butler <[hidden email]> wrote:
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
_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev



--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, [hidden email]
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Software Developer

_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: RFC 44: JSON/XML output for ogrinfo/gdalinfo

Daniel Morissette
In reply to this post by Howard Butler-3
FWIW I like the idea, but as others have pointed out some thinking needs
to be put into the json & xml output formats.

Daniel

On 13-11-19 11:42 AM, Howard Butler wrote:

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


--
Daniel Morissette
http://www.mapgears.com/
Provider of Professional MapServer Support since 2000

_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: RFC 44: JSON/XML output for ogrinfo/gdalinfo

Dan Little
In reply to this post by Frank Warmerdam
I'm not sure as to the purposed utility of the gdalinfo -vrt conversion approach.  It may very well be valid, I spend most of my time with vector data and can't take a position one way or the other.  Even so, I think having a script friendly output format for ogrinfo is very useful.  When Howard and I chatted about it, I started getting visions of a massive metadata site generating itself with not more than a couple of command line scripts.  These may be delusions of grandeur but this modification would overcome a first-line obstacle to making it a reality.

I too have some concern about maintaining three different formats.  I was actually inclined to generate an intermediate format that would then go to XML or JSON but the XML version came together rather cleanly in a few hours so I didn't go down that path.  The proof of concept came together far enough that we thought it prudent to get the ideas formally put into an RFC.

Multiple formats comes with the required multiple format maintenance penalty.  Sticking with XML minimizes some complications because MiniXML is always be available during a build and it keeps the code a little cleaner.  That said, JSON is currently the sexy format, and all the cool kids are doing it. (All technical arguments about JSON aside...) If we conceded to just supporting one additional output format, I would really like to see the XML output further refined.

ogrinfo and gdalinfo as they currently exist are a large collection of printf statements in the main function.  I logically removed the diagnostic messages (putting them on stderr) and ensured the intended content was separated into two different formatting functions.  The functions are currently responsible for doing their own output to stdout as to prevent the need to completely rewrite the standard output format.

Sorry, for not including an example of the XML sample.  I can certainly generate something as necessary.  The version I have in the proposed code works but can easily be changed in order to meet the needs and preferences to the project at large.



On Tuesday, November 19, 2013 12:45 PM, Frank Warmerdam <[hidden email]> wrote:
Howard,

I was a bit surprised that the RFC doesn't actually define the format.  I gather we are supposed to deduce it from the modified ogrinfo code?

On the GDAL side, rather than have gdalinfo support some secondary reporting format, I *feel* it would be better to just have a method on a dataset to provide a summary report somewhat similar to what gdalinfo would give.  In XML this would essentially be what you would get from doing a "gdal_translate -of VRT abc.tif abc.vrt ".  

I must confess there isn't such a clean analog on the ogrinfo side, and if you want to also capture feature data written out by ogrinfo it gets someone more complicated.

Skimming the (json missing) example ogrinfo it seems like a lot of work - particularly to maintain in a way that will keep all output formats in line.  

I started out supportive, but the more I think about the approach the less keen I am.

Best regards,
Frank



On Tue, Nov 19, 2013 at 8:42 AM, Howard Butler <[hidden email]> wrote:
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
_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev



--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, [hidden email]
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Software Developer

_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev


_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: RFC 44: JSON/XML output for ogrinfo/gdalinfo

Even Rouault
In reply to this post by Howard Butler-3
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[&quot;OSGB 1936 / British National
Grid&quot;,GEOGCS[&quot;OSGB
1936&quot;,DATUM[&quot;OSGB_1936&quot;,SPHEROID[&quot;Airy_1830&quot;,6377563.396,299.3249646]],PRIMEM[&quot;Greenwich&quot;,0],UNIT[&quot;Degree&quot;,0.017453292519943295]],PROJECTION[&quot;Transverse_Mercator&quot;],PARAMETER[&quot;latitude_of_origin&quot;,49],PARAMETER[&quot;central_meridian&quot;,-2],PARAMETER[&quot;scale_factor&quot;,0.9996012717],PARAMETER[&quot;false_easting&quot;,400000],PARAMETER[&quot;false_northing&quot;,-100000],UNIT[&quot;Meter&quot;,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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: RFC 44: JSON/XML output for ogrinfo/gdalinfo

Howard Butler-3

On Nov 19, 2013, at 2:01 PM, Even Rouault <[hidden email]> wrote:

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

Hehe, yeah. Hipster enablement.

> - 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? I've got no problem pushing this type of thing into the API stead of out in application-land if there's general support for it.

> 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?

> $ 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. Is there a gdal2vrt.py as well? I know about gdalbuildvrt, but that's mostly processing directives, not metadata, right?

Howard

_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev

signature.asc (506 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: RFC 44: JSON/XML output for ogrinfo/gdalinfo

Even Rouault
>
> > - 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[&quot;OSGB 1936 / British National
Grid&quot;,GEOGCS[&quot;OSGB
1936&quot;,DATUM[&quot;OSGB_1936&quot;,SPHEROID[&quot;Airy_1830&quot;,6377563.396,299.3249646]],PRIMEM[&quot;Greenwich&quot;,0],UNIT[&quot;Degree&quot;,0.017453292519943295]],PROJECTION[&quot;Transverse_Mercator&quot;],PARAMETER[&quot;latitude_of_origin&quot;,49],PARAMETER[&quot;central_meridian&quot;,-2],PARAMETER[&quot;scale_factor&quot;,0.9996012717],PARAMETER[&quot;false_easting&quot;,400000],PARAMETER[&quot;false_northing&quot;,-100000],UNIT[&quot;Meter&quot;,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
_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev