On Nov 19, 2013, at 2:01 PM, Even Rouault <even.roua...@mines-paris.org> 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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
