For most of the past week I've been starting to set up the MNRR meandering simulation using the centerline coordinates and widths I digitized last month and the river simulation program from April. The first thing required was to convert the river {longitude, latitude} coordinates into {x, y} coordinates that are part of the same plane. Although this is not a complicated calculation, it is somewhat subtle and merits a little discussion just to make clear exactly what I have done.
The MNRR bank coordinates, and the calculated centerline, were digitized as {lon, lat} pairs from USGS topographic maps. These maps were made using polyconic projections, although that isn't specifically relevant to this discussion. What is relevant is that digitized points were converted from screen coordinates to lon/lat using two landmark reference points which straddle the river in both directions. Here is an image of the final river and valley coords, showing the positions of the two landmarks (which are at {-97d27m30s, 42d55m} {-96d35m, 42d32m30s}):
These coords are overlayed on the topo map mosaic and the Google satellite mosaic:
Lon/lat points were calculated by linear interpolation between the two landmarks under the (strictly incorrect) assumption that the mapping between them was bimorphic (i.e. separate scales for lon and lat) but constant across the field. Ideally, several landmarks along the path of the river should be used, with local lon/lat interpolated from the closest of these for each point on the river. Nevertheless, as will be shown below, the difference between using two landmarks or many is not terribly significant.
The river simulation needs x and y coordinates in meters, and all must reference the same origin. As you know, this is impossible for points on an oblate spheroid which are not all on the same geodesic, especially as the length of the river is over 95 km. Nevertheless, a good approximation can be performed using the distance calculation mentioned before (see 5/16/08 near middle of page), and one or more XY planes tangential to the surface of the Earth. The range of longitude and latitude from the beginning to the end of the river is only 0.83 deg and 0.30 deg, so the distortion isn't too great. However, it is not isomorphic, due to the difference in radius between a circle of longitude (great circle) and a circle of latitude (not a geodesic) at that latitude.
I've transformed to x and y first using a single tangent plane at the midpont in lon/lat (at {-97.064, 42.713} decimal deg) and two scales for Δlon-->Δdx and Δlat-->Δy, measured from small changes in lon/lat at that point. Angular changes of 1 micro-radian at this point produce linear distances of 4.694 and 6.365 meters respectively, yielding scales of 81919.690 and 111087.144 m/deg. Calculating x and y for the river using this constant scale yields values from {0.0, 0.0} to {68199.458, -32186.265} and a total length of 95402.556 m, which is close to the 'actual' centerline length of 95353.747 m.
I've also transformed to x and y using different scales along the length of the river, which correspond to using a set of many small XY tangent planes, each situated on the centerline at the midpoints between each of the 100 m digitized points. Each set of scales was calculated as above, and the pair for pts i and i+1 were used to calculate the Δx and Δy bewteen those two points, from the beginning to the end of the river. Transforming in this way yields values from {0.0, 0.0} to {68143.168, -32186.223} and a total length of 95353.747 m, which is good to within much less than 1 mm. The final x and y values for the single-plane vs. multiple-plane transform differ by about 56 m in x and 4 cm in y.
As a comparison, I also did the transform using an isomorpic scale in x and y derived from the Euclidean distance in lon/lat between the river start and end (i.e. as if the river was on a flat surface and lon = c * x and lat = c * y for some c). All 3 methods are plotted below in XY, along with the original digitized coords in lon/lat (at top). Red = isomorphic, green = single plane at midpoint, blue = multiple planes along centerline:
Here is a closeup of the end of the river for single vs. multiple planes:
Here is the river entered into the simulation program:
(Click for larger image)
I'm drawing the width by using a variable pen width, rather than calculating synthetic banks, which runs faster and looks pretty nice:
I'm initializing the program from an input file in anticipation of running many batch simulations later this summer. The file contains the x and y coordinates, widths, and several parameter settings, and currently looks like this:
depth 10.0
flow 2.0e3
slope 1.918e-04
diameter 0.001
# rates per year
erosion_rate 1.0
migration_rate 100.0
# time in years (1 day)
dt 2.739726e-3
method jp3
rk4 true
interpolate 150.0
remove_cutoffs true
keep_cutoffs -1
0.000000 0.000000 337.607851
94.166969 33.644584 304.865654
189.301508 64.423559 273.272731
286.510982 87.703152 251.233498
385.890451 98.347114 246.326393
485.858441 98.052150 253.451750
585.583510 90.824070 259.387774
684.138582 74.168666 251.372569
779.449051 44.191011 227.240134
871.661896 5.514147 201.377192
963.311937 -34.488356 186.790757
...
As I get data for depth, erosion rates (and artificial fortifications), and bed composition (or slope or scour factor), additional columns can be added to the input file. Several such files can be created. Currently flow is a guess to give 1 m/s at the narrowest part, as I need to look for yearly/seasonal variation based on dam management (I have some flow and depth references from Robb Jacobson). Slope is based on the river falling a little more than 18 m in just over 95 km. Do you think we'll need to include variation in water temperature (does the river freeze?)?
Next week I will begin testing the JP and other meandering methods. One thing I am concerned about is that there is no way for the width of the river to change (except by adding interpolated points or removing cutoffs). I still think we need a meandering method that allows the two banks to evolve separately. Or, we need a multiple-thread model as we discussed last week to create an aggregate river with parallel simultaneous evolution (e.g. ≥3 threads for banks and thalweg, etc...). Given time, I will look into this later this month. I'd like to have the 'single simulation' ready to go by the end of this month, and then either return to digitizing more data, or begin working on automated multiple simulations, next month.