Fri 28 Nov 2014 02:47:35 PM UTC, comment #7:
No problem, the manual is not that fine...
Your suggestions make sense and would provide an added value to the utility. Implementing them is another issue. The code has already become rather complex as is due to features that have been consistently added over time. A redesign might be unavoidable at some stage.
|
Fri 28 Nov 2014 02:22:49 PM UTC, comment #6:
I just missed your earlier comment. This looks like a case of RTFM on my part. As you mention, the command below extracts ALL points under the polygon, which is exactly what I'm after:
pkextract -i inputraster.tif -s samplepolygon.sqlite -o outputsamples.sqlite -r point
In any case, it would still be nice to have some fine control over how the pixels are selected. In ArcGIS's "Extract by Polygon", you can specify whether pixels inside or outside the polygon are extracted (I'm guessing this is based on location of the centroid relative to the interior of the polygon) and/or the bounding box of the polygon. In R's raster package {extract}, there's even finer control of how the pixels are handled (e.g., "weights" and "small"). This latter capability would be nice in pkextract, although it is already quite functional as is.
|
Fri 28 Nov 2014 01:57:54 PM UTC, comment #5:
I now realise my comments were probably mostly incoherent. Not enough coffee. Here's another attempt:
I'm looking for pkextract to provide similar functionality as provided in the following examples:
1) ArcGIS' "Extract by Polygon" (Spatial Analyst Extension)
http://help.arcgis.com/en/arcgisdesktop/10.0/help/index.html#//009z0000002q000000.htm
and/or
2) Raster {package} in R
http://www.inside-r.org/packages/cran/raster/docs/extract
Both tools allow for all pixels under a polygon to be extracted without performing a summary function (e.g., mean, max, mode). I imagine this being implemented in pkextract by using the -r switch (e.g., -r none).
The feature would allow a user to work with all the pixel information related to the polygon/raster being used to sample the input image. At the moment, pkextract summarizes the pixel values, somewhat like "Zonal Statistics" in ArcGIS.
|
Fri 28 Nov 2014 01:53:24 PM UTC, comment #4:
Is it possible you currently have no rule defined (or a non-existing one like "-r none" (is not listed in the help info and therefore not defined). In that case, the utility falls back to its default mode, which is "centroid". This would explain why you only obtain a single point per polygon. To avoid misunderstanding, it would be helpful to include the commands you are using in future communications (ideally with a minimal test image as you described).
If you want to extract ALL points covered by all polygons and, therefore, create point features, use the following command:
pkextract -i input.tif -o extracted_points.sqlite -s sample.sqlite -r point
Make sure not to use option -polygon, as you are not interested to retain the polygons but rather point features (the ones covered by the polygons).
Notice that the following command would result in polygon features, where each feature has an attribute defined the raster cell value covered by the centroid point.
pkextract -i input.tif -o extracted_points.sqlite -s sample.sqlite -r point
|
Thu 27 Nov 2014 10:27:13 PM UTC, comment #3:
Whups. The examples should look like this:
a) all pixels extracted (not summarized)
polyno b0
1 23
1 29
1 33
1 30
2 4
2 5
2 5
2 6
b) all pixels are extracted (but are summarized or use centroid value)
polyno b0
1 23
2 5
|
Thu 27 Nov 2014 10:22:23 PM UTC, comment #2:
Apologies. Hopefully this is a little clearer: All the pixel values from the input (-i) contained in the overlay (-s) would be extracted, but no summary (centroid, mean, max, etc) would be peformed on the pixels (e.g., -r none).
Imagine that there are exactly 4 pixels in the input image (-i), which are perfectly aligned with 2 polygons in the overlay (-s). Extracting all pixels as I describe would result in output like this:
polyno b0
1 23
1 29
1 33
1 30
2 4
2 5
2 5
2 6
In the above example, all 4 pixels from the input file (-i) that are contained within the 2 polygons in the overlay (-s) are extracted. No summary is performed, nor is only the centroid reported.
Currently, pkextract summarizes all the pixel values under the overlay, or it takes the centroid value. The same example above would look something like this (e.g., centroid):
polyno b0 b1
1 10 100
2 5 26
|
Thu 27 Nov 2014 09:23:13 PM UTC, comment #1:
I am not sure if I understand the feature request correctly. The extraction utility is pkextract, which does support overlays of a sample image (raster or vector) to a raster dataset (from which the raster cell values will be extracted). It is already possible to extract all pixels from the input imagery in a number of ways. If the sample is a polygon vector dataset, all pixels indicate all pixels covered by the polygon (option -r point). If the sample is a raster dataset, you can use either a mask or even the the same input input image. In combination with the option -down, you can subsample the input image. An alternative option would be to create a grid or a random subset using the options -grid and -random respectively. You can also extract specific grid cells by using the utility pkinfo -r -x -y.
|
Thu 27 Nov 2014 08:46:20 PM UTC, original submission:
pkfilter (2.6.1) has various statistical summary options when using a vector/raster to extract information from the input image(s).
Another useful option would be the option to extract **all pixels** from the input imagery. This would be useful in situations where one is interested in peforming other types of analyses on the underlying data (e.g., geostatistical).
Ideally, this functionality would be similar to that offered in R {raster:extract}, but with higher performance offered by GDAL:
http://www.inside-r.org/packages/cran/raster/docs/extract
Like in R's raster package, a weighting option could be used to determine how semi-overlapping pixels are handled, etc.
Output could be csv and/or sqlite to avoid any limitations related to extracting potentially many hundreds/thousands of pixels per polygon
|