3

I need to take a set of datafiles, generated by our sensor system that reads GPR (Ground penetrating Radar) deviations over a surface as we drive along. I have discrete readings from a set of sensors and can accurately place them relative to the GPS unit spitting out location values once a second, along with track and speed in meters/second. I want to create an Esri ASCII data file for each second, with each row representing the sensor values along the rail, with one row representing all 16 sensors (spaced equally apart), read every 1/25th of a second. I can figure out the offsets to accurately place the sensors, in meters, relative to the GPS unit and as each sensor is read. It is relatively easy to then figure out the location for each reading along the track the GPS unit is measuring in Meters/second, thus arriving at the separation, in meters, between rows of generated sensor data.

What I am having a hard time doing is converting this information into ESRI ASCII format, specifically the CELL size. My sensor rack is about 4 meters long and the GPS unit is centrally located with a small offset forward of the sensor array. How can I determine the cell size for my many rows of sensor data? I will locate this data with the GPS output, and have no problem calculating the boundaries for the one second time period. What has me stumped is the cell size.

Example data: Sensors 1 - 16 232.2 233. 244.4 256.8 260.1 ..... 211.5 next row 0.1 meter later next row 0.1 meter later 25 rows in all

Sensors separated 0.25 meter from each other

Any ideas folks? What does that pesky cell size have to be and more importantly, how did you figure out that number?

Improve this question
9
  • 3
    My first thought is that you have non-square cells: 0.1 m x 0.25 m. Velocity of device may affect the 0.1 m value. Or, build the sensor data as vector points, then convert to raster. For the cell size Q, does this help? webhelp.esri.com/arcgisdesktop/9.2/…
    – mkennedy
    Commented Sep 24, 2013 at 22:03
  • 1
    When "converting this information into ERSI [sic] ASCII format" what GIS software and version are you using?
    – PolyGeo ♦
    Commented Sep 24, 2013 at 22:09
  • I am going to import this ERSI Ascii file (its actually ARC Ascii format as well) into GRASS GIS as an overlay of data on a USGS map. I'm using GRASS 6.4.3, which is fine for my purposes. What I need to know is the CELL value I should put in my ASCII file. It is not clear to me if the CELL value is in DEGREES or METERS. Once I know that I can figure out the rest myself, with your sage advice and expert help, of course.
    – BigIslandDigger
    Commented Sep 24, 2013 at 23:10
  • MKennedy is right, the cells won't be SQUARE, but that can't be helped at this point and isn't really important. We'll up the resolution later. All I want to do at this point is demonstrate proof of concept, that we can overlay sensor data on a USGS raster map.
    – BigIslandDigger
    Commented Sep 24, 2013 at 23:12
  • Given that my cells will be .25m by .1m what sort of cell size does that translate to? And how was that figure derived?
    – BigIslandDigger
    Commented Sep 24, 2013 at 23:12

1 Answer 1

Reset to default
2

Rather than using an ASCII file, which can get quite large, use a binary file in BIP layout, so you can place the sensor band values next to each other. This format also allows rectangular (non-square) pixels, which the ASCII grid loader does not support.

Improve this answer
10
  • BIP looks good and not difficult to convert to from the data I have generated. HOWEVER, how does one register this BIP file with the GPS coordinates I am generating as I move merrily along over the surface of the earth? BIP seems to capture a sequence of data rows just fine, allowing me to make a very long 'strip' of data consisting of hundreds of rows of data, instead of just 25/second, as I was going to do with ASCII. But there seems to be no GPS/Lat/Lon registry capability for the BIP format. Or am I wrong?
    – BigIslandDigger
    Commented Sep 24, 2013 at 23:40
  • Another proviso is that tracking is never 'straight line', it deviates, around obstructions, trees, etc, and thus I must accommodate changes in Track/Speed for every reading once a second, thus my preference for ASCII format to provide the most accurate location info for my sensor readings.
    – BigIslandDigger
    Commented Sep 24, 2013 at 23:46
  • ALL raster formats are continuous. If you have discountinuous data, a vector format might be more appropriate. If you just want to anchor a corner to the globe, then you would use either the ulxmap/ulymax/xdim/ydim parameters, or if there's rotation, by creating a ".biw" world file en.wikipedia.org/wiki/World_file
    – Vince
    Commented Sep 24, 2013 at 23:49
  • I looked at the ulxmap/ulymax/xdim/ydim variables but they seem to indicate the internal 'size' of the map and its representative pixels. I don't understand how internally sizing raster data will 'anchor' a map to the real world and it's Lat/Lon values. What did I miss?
    – BigIslandDigger
    Commented Sep 25, 2013 at 3:07
  • I will look into vector map representation of the data, does anyone have a format that is easy to master, relatively? My data example is shown above.
    – BigIslandDigger
    Commented Sep 25, 2013 at 3:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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