0

A "brute force" method of solving GIS problems that involve acquiring values from raster cells and storing them on spatially overlapping vector features is to first convert the raster to a vector. The main issue with this approach is that converting a raster to vector can lead to very large file sizes - and slow operations. Furthermore, if using ArcGIS without spatial analyst extension, raster to vector converstion is not available.

Could you provide a few of your own examples where you had a project and choose a work-path that purposely avoided a raster-vector conversions? This might have happened either because

i) you had to avoid the conversion because you did not have access to a raster to vector conversion tool, or

ii) you chose to avoid the conversion becuase doing so was a more elegant solution.

EDIT: (Here is an example I used in a previous version of my question before the comments below. It is an example I gave that is referred to in some answers).

Say you had a river network, and you wanted to store the elevation in each line segment in a new column - but elevation values in your GIS database is in raster format (a very large raster). What would be a workaround?

PolyGeo
  • 65,136
  • 29
  • 109
  • 338
GIStack
  • 709
  • 1
  • 7
  • 16
  • 3
    I like the topic but am struggling to find a definite, answerable question here. Do you perhaps have a concrete example in mind? – whuber Nov 10 '11 at 07:14
  • 1
    The decision to use raster or vector is usually determined by the task and the input data. I don't think that a generic set of situations on what is optimal is really possible. It could be useful to ask what tools are available to work between raster and vector beyond just conversion. – Matthew Snape Nov 10 '11 at 18:39
  • thanks for both of your suggestions, I've rephrased the question based on the feedback. – GIStack Nov 10 '11 at 19:59
  • 1
    As whuber notes the general thrust of the post is interesting and bears exploring. It's a quest though, which is distinct from a question. I think you need to break it down into a series of questions to get answers which are truly useful. – matt wilkie Nov 10 '11 at 22:45

2 Answers2

2

For your stream example, you could use the Feature Vertices to Point tool to convert your stream vertices to a point layer, then use the Extract Values to Points tool to grab the elevation values from the raster. You could then do a spatial join to push those values back to the original stream layer from the point layer.

artwork21
  • 35,114
  • 8
  • 66
  • 134
  • Thanks - this is a good process for my example problem. It would be better than a raster to vector conversion if the conversion produces too big a file. Interestingly, three steps are required simply because there is no tool that extracts raster cell values below a line segment (or polygon for that matter). My guess is that to program such a tool is quite difficult since it would involve complications in dealing with raster and vector storage formats – GIStack Nov 10 '11 at 20:21
  • 3 steps is not that much. It seems like you are looking for the tools which are specificly designed to the specific task. Probably you could find something to fulfill your needs in one click, if you'd look long enough. On the other hand, GIS software is more like toolbox, you combine tools i.e. in Modelbuilder, Python etc. or you build your own tools in order to receive the algorithm that will process your data in way you want it. Also if there would be a tool for any possible task, than it would be a lot more complicated to find the right one than simply connect the right dots. – Tomek Nov 10 '11 at 22:07
  • You're right Tomek, 3 steps is not that much. I guess GIS tools are designed to be used in combination than alone - which may better explain why, for example, ArcGIs does not have a tool that directly allows line segments to extract raster cell values – GIStack Nov 11 '11 at 00:08
  • This wont't work perfectly for two reasons: First, "Feature vertices to point" will create overlapping points where reaches merge. A spatial join will likely result in incorrect results due to those overlapping points. An attribute join may work better. Secondly, for raster based river networks, the "feature to vertex" tool will produce unevenly spaced points along a river reach, because vertices are only placed whenever the line changes angle. whubers route-based approach is the best, IMHO. – G-wizard Jan 21 '12 at 01:34
1

For the stream example what you need is a true 3D line instead of 2.5D. A true 3D line stores 3 coordinates at every vertex, X,Y,Z while a 2.5D line stores 2 coordinates per vertex, X,Y, and then looks up Z from an attribute table. Since this latter approach means every segment of one feature (one line) has the same elevation it's only suitable for things like contour lines.

By convention the value stored in Z is elevation, but there's no reason it can't be any other numeric value and then associated by lookup table to something else like rate of stream flow or number of fish spawning beds, water turbidity, flavour, colour,...

For arcgis see deriving height from an existing surface, e.g. use the Interpolate Shape or Add Surface Information tools from 3D analyst. This would be only one step.

matt wilkie
  • 28,176
  • 35
  • 147
  • 280
  • matt - good thinking for making the process one step. I wonder though if creating a 3D line and working with a large raster in such an environment would create for a slower process/performance than simply doing a raster to vector conversion followed by a spatial join? probably depends on many factors. – GIStack Nov 10 '11 at 22:53