2

I need to create a specific number of random points THAT FALL ON A RASTER with values between 0 and 1. The trick is the raster has a lot of holes - it is a grid of linear features where there are height values on the linear features, but everything in between is a NA. I have selected all my used locations that fall on the linear features in the raster, and intersected them to get the height value. Now I need to create the same number of random points, restricted to being where there are raster values (i.e no points are generated in the holes, where there are NA values).

Any advice? I've considered converting my raster to a polygon, however the raster is over a large extent (60 x 90 km) and is very high resolution (1m pixels), so this would probably take a long time.

Improve this question
5
  • What is the size of the raster in pixels? How many random points do you need and how long time is still acceptable for generating them? – user30184 Sep 9 '14 at 17:52
  • @user30184 see edits in question. Thank you for your time. – Mel Sep 9 '14 at 19:32
  • What values do you have in your raster? Integer, float? – Aaron♦ Sep 9 '14 at 20:55
  • @Aaron, its floating points – Mel Sep 9 '14 at 21:14
  • Are the only values in your raster between 0 - 1? Do you want random points distributed across your raster anywhere except for NoData areas? – Aaron♦ Sep 9 '14 at 21:22
1

Is the exact location of the point important, could they all be the centre of the pixel? If so why not turn you raster into a point dataset and choose the points at random? Notata cells would not turn to points.

Improve this answer
3
  • It is a good idea but (60000*90000)-(count of empty cells) is a rather big dataset. Not huge, though. – user30184 Sep 9 '14 at 20:30
  • 1
    But won't the cells of the raster with values be a fraction of the total number of cells? You say they represent linear features? Maybe an image would help? – Hornbydd Sep 9 '14 at 21:37
  • Sure, therefore I wrote "-(count of empty cells)". – user30184 Sep 10 '14 at 4:19
1

Before you convert your raster to polygon, you should reclassify it in 2 classes. E.g. using the raster calculator and :

IsNull("Raster")

Then you will have only a limited number of polygons that should not take too much place.

Improve this answer
0

It may be unnecessary to vectorize your raster at all. Access to raster data can be very fast and it may be worth having a try by selecting random points and checking if they hit the data in your raster. If point finds a hit, accept it, if not, discard. Continue until you have enough points to fill your sample size. If each query to raster data is fast enough it can be good strategy to sort the results afterwards instead of using time for preprocessing.

There must be effective scripting methods in ArcGIS for checking the pixel value at a certain location. It is also for sure possible to make the script to discard tha nodata hits immediately because nodata value is known. This gis.stackexchange question deals with it. I demonstrate the workflow with gdallocationinfo tool http://www.gdal.org/gdallocationinfo.html.

Lets find some sample image from the web. This site seems to have some images http://www.mapmart.com/Samples.aspx and we will have a try with the CONUS 10m m sample http://mapmart.com/DownloadArea/Mapmart_Samples/CONUS_10M_Sample.zip. It is a zip file which contains tiff file "CONUS_10M_Sample.tif". We do not need to download and unzip it because GDAL can access images directly from the web, even if they are zipped. We can demonstrate that at the same.

Acquire a fresh GDAL version and open a command shell where you can run gdallocationinfo. Here is a command to test with:

gdallocationinfo /vsizip/vsicurl/http://mapmart.com/DownloadArea/Mapmart_Samples/CONUS_10M_Sample.zip/CONUS_10M_Sample.tif 100 100

It will take a while but you should get a report:

Report:
  Location: (100P,100L)
  Band 1:
    Value: 34
  Band 2:
    Value: 46
  Band 3:
    Value: 31

If this was your image you would accept the random sample point (100 100) because obviously it is not nodata.

The gdallocationinfo query is slow but don't get frightened. Now it is decompressing some part of the zip file and reading some part of the geotiff and all this over the internet. With local image it would be must faster. Making an arcpy script could make it faster again. But if you deside to try this method make sure that your raster is tiled for making random access to some random pixel fast.

It may be good to know also for other geospatial needs that GDAL can read data from the web and from zipped files with /vsicurl/ and /vsizip/. They can be used with gdalinfo, gdal_translate, ogrinfo, ogr2ogr etc.

If you find that process would be faster if nodata-areas are known beforehand I would first separate nodata pixels for example by creating an alpha channel and vectorize the alpha channel into nodata-polygons.

Improve this answer
1
  • Thanks for this, I'll see if I can get help adapting this idea and writing a script in python – Mel Sep 9 '14 at 21:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.