| | 1 | = RFC 32: gdallocationinfo utility = |
| | 2 | |
| | 3 | Authors: Frank Warmerdam[[BR]] |
| | 4 | Contact: warmerdam@pobox.com[[BR]] |
| | 5 | Status: Development |
| | 6 | |
| | 7 | == Summary == |
| | 8 | |
| | 9 | This document proposes the addition of a new standard commandline utility for GDAL to report details about a location |
| | 10 | (pixel) in a raster. |
| | 11 | |
| | 12 | == Rationale == |
| | 13 | |
| | 14 | 1) A user has a use case where they would like to be able to identify the VRT file used to satisfy requests for a particular pixel / location. |
| | 15 | |
| | 16 | 2) Many users have requested a tool to find the value of a location, often expressed in a coordinate system different than that of the image. For instance, "what is the elevation at a given lat/long location?". |
| | 17 | |
| | 18 | The gdallocationinfo utility is intended to address both sorts of requests, and hopefully in a way that will have some general value as a "raster point query" tool. |
| | 19 | |
| | 20 | == gdallocationinfo == |
| | 21 | |
| | 22 | Full docs are available at: http://www.gdal.org/gdallocationinfo.html |
| | 23 | |
| | 24 | {{{ |
| | 25 | Usage: gdallocationinfo [--help-general] [-xml] [-lifonly] [-valonlyl] |
| | 26 | [-b band]* [-s_srs srs_def] [-geoloc] [-wgs84] |
| | 27 | srcfile x y |
| | 28 | }}} |
| | 29 | |
| | 30 | The key aspects of the utility are control over the coordinate system of the location (-s_srs, -geoloc, -wgs84) and various controls over the output format (-xml, -lifonly, -valonly). An example of full output in xml might be: |
| | 31 | |
| | 32 | {{{ |
| | 33 | $ gdallocationinfo -xml -wgs84 utm.vrt -117.5 33.75 |
| | 34 | <Report pixel="217" line="282"> |
| | 35 | <BandReport band="1"> |
| | 36 | <LocationInfo> |
| | 37 | <File>utm.tif</File> |
| | 38 | </LocationInfo> |
| | 39 | <Value>16</Value> |
| | 40 | </BandReport> |
| | 41 | </Report> |
| | 42 | }}} |
| | 43 | |
| | 44 | == LocationInfo Metadata Domain == |
| | 45 | |
| | 46 | The pixel values and location transformation logic is all built into gdallocationinfo and doesn't require much elaboration. The more exotic portion is reporting of "LocationInfo" queried from the datasource. |
| | 47 | |
| | 48 | For our immediate needs the requirement is to have the VRTSourcedRasterBand return information on the file(s) overlapping the target pixel. But, in theory different drivers might return different sorts of information about a location. For instance, a WMS driver might issue a GetFeatureInfo for the location and return the result. |
| | 49 | |
| | 50 | The mechanism to query the datasource is a specially named GetMetadataItem() request against the "LocationInfo" domain of the target band(s). The following requested item name is of the form "Pixel_x_y" where x and y are the pixel and line of the pixel being queried. |
| | 51 | |
| | 52 | The returned value from this item should either be NULL, or an XML documented with the root element "<LocationInfo>". The contents of the document are otherwise undefined as long as they are well formed XML. The VRT driver returns a series of <File>xxx</File> entries for each of the files at that location. |
| | 53 | |
| | 54 | == Test Suite == |
| | 55 | |
| | 56 | A test will be introduced in the gdal utilities suite, and the gdrivers/vrt.py script for the utility and VRT behavior respectively. |
| | 57 | |
| | 58 | == Documentation == |
| | 59 | |
| | 60 | Documentation for the utility has already been prepared and is referenced above. |
| | 61 | |
| | 62 | == Implementation == |
| | 63 | |
| | 64 | Implementation is already complete, and in trunk. Adjustments can be made by Frank Warmerdam as needed due to RFC revisions. |
| | 65 | |
