社区
消息协作
帖子详情
Special Database Object Can't Be Located !
yuhan21
2005-09-28 10:02:04
为什么我在打开数据库的时候 会出现 Special Database Object Can't Be Located !
这是什么原因啊!(以前我是能打开的)
...全文
107
1
打赏
收藏
Special Database Object Can't Be Located !
为什么我在打开数据库的时候 会出现 Special Database Object Can't Be Located ! 这是什么原因啊!(以前我是能打开的)
复制链接
扫一扫
分享
转发到动态
举报
写回复
配置赞助广告
用AI写文章
1 条
回复
切换为时间正序
请发表友善的回复…
发表回复
打赏红包
china1111
2005-09-28
打赏
举报
回复
说清楚点...
你是在Notes客户端上打开数据库时出现这个问题还是数据库打开后出现这个提示。
如果是数据库未打开出现这个问题,可能是这个数据库已经被删除了。
如果是数据库打开后出现这个提示,你去查看一下数据库资源中的数据库Script是否写了程序来获取其它数据库
计算机网络第六版答案
Computer Networking: A Top-Down Approach, 6th
Ed
ition Solutions to Review Questions and Problems Version Date: May 2012 This document contains the solutions to review questions and problems for the 5th
ed
ition of Computer Networking: A Top-Down Approach by Jim Kurose and Keith Ross. These solutions are being made available to instructors ONLY. Please do NOT copy or distribute this document to others (even other instructors). Please do not post any solutions on a publicly-available Web site. We’ll be happy to provide a copy (up-to-date) of this solution manual ourselves to anyone who asks. Acknowl
ed
gments: Over the years, several students and colleagues have help
ed
us prepare this solutions manual.
Special
thanks goes to HongGang Zhang, Rakesh Kumar, Prithula Dhungel, and Vijay Annapur
ed
dy. Also thanks to all the readers who have made suggestions and correct
ed
errors. All material © copyright 1996-2012 by J.F. Kurose and K.W. Ross. All rights reserv
ed
Chapter 1 Review Questions There is no difference. Throughout this text, the words “host” and “end system” are us
ed
interchangeably. End systems include PCs, workstations, Web servers, mail servers, PDAs, Internet-connect
ed
game consoles, etc. From Wikip
ed
ia: Dip
lo
matic protocol is commonly describ
ed
as a set of international courtesy rules. These well-establish
ed
and time-honor
ed
rules have made it easier for nations and people to live and work together. Part of protocol has always been the acknowl
ed
gment of the hierarchical standing of all present. Protocol rules are bas
ed
on the principles of civility. Standards are important for protocols so that people can create networking systems and products that interoperate. 1. Dial-up modem over telephone line: home; 2. DSL over telephone line: home or small office; 3. Cable to HFC: home; 4. 100 Mbps switch
ed
Ethernet: enterprise; 5. Wifi (802.11): home and enterprise: 6. 3G and 4G: wide-area wireless. HFC bandwidth is shar
ed
among the users. On the downstream channel, all packets emanate from a single source, namely, the head end. Thus, there are no collisions in the downstream channel. In most American cities, the current possibilities include: dial-up; DSL; cable modem; fiber-to-the-home. 7. Ethernet LANs have transmission rates of 10 Mbps, 100 Mbps, 1 Gbps and 10 Gbps. 8. Today, Ethernet most commonly runs over twist
ed
-pair copper wire. It also can run over fibers optic links. 9. Dial up modems: up to 56 Kbps, bandwidth is d
ed
i
cat
ed
; ADSL: up to 24 Mbps downstream and 2.5 Mbps upstream, bandwidth is d
ed
i
cat
ed
; HFC, rates up to 42.8 Mbps and upstream rates of up to 30.7 Mbps, bandwidth is shar
ed
. FTTH: 2-10Mbps up
lo
ad; 10-20 Mbps down
lo
ad; bandwidth is not shar
ed
. 10. There are two popular wireless Internet access techno
lo
gies today: Wifi (802.11) In a wireless LAN, wireless users transmit/receive packets to/from an base station (i.e., wireless access point) within a radius of few tens of meters. The base station is typically connect
ed
to the wir
ed
Internet and thus serves to connect wireless users to the wir
ed
network. 3G and 4G wide-area wireless access networks. In these systems, packets are transmitt
ed
over the same wireless infrastructure us
ed
for cellular telephony, with the base station thus being manag
ed
by a telecommuni
cat
ions provider. This provides wireless access to users within a radius of tens of ki
lo
meters of the base station. 11. At time t0 the sending host begins to transmit. At time t1 = L/R1, the sending host completes transmission and the entire packet is receiv
ed
at the router (no propagation delay). Because the router has the entire packet at time t1, it can begin to transmit the packet to the receiving host at time t1. At time t2 = t1 + L/R2, the router completes transmission and the entire packet is receiv
ed
at the receiving host (again, no propagation delay). Thus, the end-to-end delay is L/R1 + L/R2. 12. A circuit-switch
ed
network can guarantee a certain amount of end-to-end bandwidth for the duration of a call. Most packet-switch
ed
networks today (including the Internet) cannot make any end-to-end guarantees for bandwidth. FDM requires sophisti
cat
ed
ana
lo
g hardware to shift signal into appropriate frequency bands. 13. a) 2 users can be support
ed
because each user requires half of the link bandwidth. b) Since each user requires 1Mbps when transmitting, if two or fewer users transmit simultaneously, a maximum of 2Mbps will be requir
ed
. Since the available bandwidth of the shar
ed
link is 2Mbps, there will be no queuing delay before the link. Whereas, if three users transmit simultaneously, the bandwidth requir
ed
will be 3Mbps which is more than the available bandwidth of the shar
ed
link. In this case, there will be queuing delay before the link. c) Probability that a given user is transmitting = 0.2 d) Probability that all three users are transmitting simultaneously = = (0.2)3 = 0.008. Since the queue grows when all the users are transmitting, the fraction of time during which the queue grows (which is equal to the probability that all three users are transmitting simultaneously) is 0.008. 14. If the two ISPs do not peer with each other, then when they send traffic to each other they have to send the traffic through a provider ISP (interm
ed
iary), to which they have to pay for carrying the traffic. By peering with each other directly, the two ISPs can r
ed
uce their payments to their provider ISPs. An Internet Exchange Points (IXP) (typically in a standa
lo
ne building with its own switches) is a meeting point where multiple ISPs can connect and/or peer together. An ISP earns its money by charging each of the the ISPs that connect to the IXP a relatively small fee, which may depend on the amount of traffic sent to or receiv
ed
from the IXP. 15. Google's private network connects together all its data centers, big and small. Traffic between the Google data centers passes over its private network rather than over the public Internet. Many of these data centers are
lo
cat
ed
in, or c
lo
se to,
lo
wer tier ISPs. Therefore, when Google delivers content to a user, it often can bypass higher tier ISPs. What motivates content providers to create these networks? First, the content provider has more control over the user experience, since it has to use few interm
ed
iary ISPs. Second, it can save money by sending less traffic into provider networks. Third, if ISPs decide to charge more money to highly profitable content providers (in countries where net neutrality doesn't apply), the content providers can avoid these extra payments. 16. The delay components are processing delays, transmission delays, propagation delays, and queuing delays. All of these delays are fix
ed
, except for the queuing delays, which are variable. 17. a) 1000 km, 1 Mbps, 100 bytes b) 100 km, 1 Mbps, 100 bytes 18. 10msec; d/s; no; no 19. a) 500 kbps b) 64 seconds c) 100kbps; 320 seconds 20. End system A breaks the large file into chunks. It adds header to each chunk, thereby generating multiple packets from the file. The header in each packet includes the IP address of the destination (end system B). The packet switch uses the destination IP address in the packet to determine the outgoing link. Asking which road to take is ana
lo
gous to a packet asking which outgoing link it should be forward
ed
on, given the packet’s destination address. 21. The maximum emission rate is 500 packets/sec and the maximum transmission rate is 350 packets/sec. The corresponding traffic intensity is 500/350 =1.43 > 1.
Lo
ss will eventually occur for each experiment; but the time when
lo
ss first occurs will be different from one experiment to the next due to the randomness in the emission process. 22. Five generic tasks are error control, f
lo
w control, segmentation and reassembly, multiplexing, and connection setup. Yes, these tasks can be dupli
cat
ed
at different layers. For example, error control is often provid
ed
at more than one layer. 23. The five layers in the Internet protocol stack are – from top to bottom – the appli
cat
ion layer, the transport layer, the network layer, the link layer, and the physical layer. The principal responsibilities are outlin
ed
in Section 1.5.1. 24. Appli
cat
ion-layer message: data which an appli
cat
ion wants to send and pass
ed
onto the transport layer; transport-layer segment: generat
ed
by the transport layer and encapsulates appli
cat
ion-layer message with transport layer header; network-layer datagram: encapsulates transport-layer segment with a network-layer header; link-layer frame: encapsulates network-layer datagram with a link-layer header. 25. Routers process network, link and physical layers (layers 1 through 3). (This is a little bit of a white lie, as modern routers sometimes act as firewalls or caching components, and process Transport layer as well.) Link layer switches process link and physical layers (layers 1 through2). Hosts process all five layers. 26. a) Virus Requires some form of human interaction to spread. Classic example: E-mail viruses. b) Worms No user repli
cat
ion ne
ed
ed
. Worm in infect
ed
host scans IP addresses and port numbers,
lo
oking for vulnerable processes to infect. 27. Creation of a botnet requires an attacker to find vulnerability in some appli
cat
ion or system (e.g. exp
lo
iting the buffer overf
lo
w vulnerability that might exist in an appli
cat
ion). After finding the vulnerability, the attacker ne
ed
s to scan for hosts that are vulnerable. The target is basically to compromise a series of systems by exp
lo
iting that particular vulnerability. Any system that is part of the botnet can automatically scan its environment and propagate by exp
lo
iting the vulnerability. An important property of such botnets is that the originator of the botnet can remotely control and issue commands to all the nodes in the botnet. Hence, it becomes possible for the attacker to issue a command to all the nodes, that target a single node (for example, all nodes in the botnet might be command
ed
by the attacker to send a TCP SYN message to the target, which might result in a TCP SYN f
lo
od attack at the target). 28. Trudy can pretend to be Bob to Alice (and vice-versa) and partially or completely modify the message(s) being sent from Bob to Alice. For example, she can easily change the phrase “Alice, I owe you $1000” to “Alice, I owe you $10,000”. Furthermore, Trudy can even drop the packets that are being sent by Bob to Alice (and vise-versa), even if the packets from Bob to Alice are encrypt
ed
. Chapter 1 Problems Problem 1 There is no single right answer to this question. Many protocols would do the trick. Here's a simple answer be
lo
w: Messages from ATM machine to Server Msg name purpose -------- ------- HE
LO
Let server know that there is a card in the ATM machine ATM card transmits user ID to Server PASSWD User enters PIN, which is sent to server BALANCE User requests balance WITHDRAWL User asks to withdraw money BYE user all done Messages from Server to ATM machine (display) Msg name purpose -------- ------- PASSWD Ask user for PIN (password) OK last request
ed
operation (PASSWD, WITHDRAWL) OK ERR last request
ed
operation (PASSWD, WITHDRAWL) in ERROR AMOUNT sent in response to BALANCE request BYE user done, display welcome screen at ATM Correct operation: client server HE
LO
(userid) --------------> (check if valid userid) <------------- PASSWD PASSWD --------------> (check password) <------------- AMOUNT WITHDRAWL --------------> check if enough $ to cover withdrawl (check if valid userid) <------------- PASSWD PASSWD --------------> (check password) <------------- AMOUNT WITHDRAWL --------------> check if enough $ to cover withdrawl <------------- BYE Problem 2 At time N*(L/R) the first packet has reach
ed
the destination, the second packet is stor
ed
in the last router, the third packet is stor
ed
in the next-to-last router, etc. At time N*(L/R) + L/R, the second packet has reach
ed
the destination, the third packet is stor
ed
in the last router, etc. Continuing with this
lo
gic, we see that at time N*(L/R) + (P-1)*(L/R) = (N+P-1)*(L/R) all packets have reach
ed
the destination. Problem 3 a) A circuit-switch
ed
network would be well suit
ed
to the appli
cat
ion, because the appli
cat
ion involves
lo
ng sessions with pr
ed
ictable smooth bandwidth requirements. Since the transmission rate is known and not bursty, bandwidth can be reserv
ed
for each appli
cat
ion session without significant waste. In addition, the overhead costs of setting up and tearing down connections are amortiz
ed
over the lengthy duration of a typical appli
cat
ion session. b) In the worst case, all the appli
cat
ions simultaneously transmit over one or more network links. However, since each link has sufficient bandwidth to handle the sum of all of the appli
cat
ions' data rates, no congestion (very little queuing) will occur. Given such generous link capacities, the network does not ne
ed
congestion control mechanisms. Problem 4 Between the switch in the upper left and the switch in the upper right we can have 4 connections. Similarly we can have four connections between each of the 3 other pairs of adjacent switches. Thus, this network can support up to 16 connections. We can 4 connections passing through the switch in the upper-right-hand corner and another 4 connections passing through the switch in the
lo
wer-left-hand corner, giving a total of 8 connections. Yes. For the connections between A and C, we route two connections through B and two connections through D. For the connections between B and D, we route two connections through A and two connections through C. In this manner, there are at most 4 connections passing through any link. Problem 5 Tollbooths are 75 km apart, and the cars propagate at 100km/hr. A tollbooth services a car at a rate of one car every 12 seconds. a) There are ten cars. It takes 120 seconds, or 2 minutes, for the first tollbooth to service the 10 cars. Each of these cars has a propagation delay of 45 minutes (travel 75 km) before arriving at the second tollbooth. Thus, all the cars are lin
ed
up before the second tollbooth after 47 minutes. The whole process repeats itself for traveling between the second and third tollbooths. It also takes 2 minutes for the third tollbooth to service the 10 cars. Thus the total delay is 96 minutes. b) Delay between tollbooths is 8*12 seconds plus 45 minutes, i.e., 46 minutes and 36 seconds. The total delay is twice this amount plus 8*12 seconds, i.e., 94 minutes and 48 seconds. Problem 6 a) seconds. b) seconds. c) seconds. d) The bit is just leaving Host A. e) The first bit is in the link and has not reach
ed
Host B. f) The first bit has reach
ed
Host B. g) Want km. Problem 7 Consider the first bit in a packet. Before this bit can be transmitt
ed
, all of the bits in the packet must be generat
ed
. This requires sec=7msec. The time requir
ed
to transmit the packet is sec= sec. Propagation delay = 10 msec. The delay until decoding is 7msec + sec + 10msec = 17.224msec A similar analysis shows that all bits experience a delay of 17.224 msec. Problem 8 a) 20 users can be support
ed
. b) . c) . d) . We use the central limit theorem to approximate this probability. Let be independent random variables such that . “21 or more users” when is a standard normal r.v. Thus “21 or more users” . Problem 9 10,000 Problem 10 The first end system requires L/R1 to transmit the packet onto the first link; the packet propagates over the first link in d1/s1; the packet switch adds a processing delay of dproc; after receiving the entire packet, the packet switch connecting the first and the second link requires L/R2 to transmit the packet onto the second link; the packet propagates over the second link in d2/s2. Similarly, we can find the delay caus
ed
by the second switch and the third link: L/R3, dproc, and d3/s3. Adding these five delays gives dend-end = L/R1 + L/R2 + L/R3 + d1/s1 + d2/s2 + d3/s3+ dproc+ dproc To answer the second question, we simply plug the values into the equation to get 6 + 6 + 6 + 20+16 + 4 + 3 + 3 = 64 msec. Problem 11 Because bits are imm
ed
iately transmitt
ed
, the packet switch does not introduce any delay; in particular, it does not introduce a transmission delay. Thus, dend-end = L/R + d1/s1 + d2/s2+ d3/s3 For the values in Problem 10, we get 6 + 20 + 16 + 4 = 46 msec. Problem 12 The arriving packet must first wait for the link to transmit 4.5 *1,500 bytes = 6,750 bytes or 54,000 bits. Since these bits are transmitt
ed
at 2 Mbps, the queuing delay is 27 msec. Generally, the queuing delay is (nL + (L - x))/R. Problem 13 The queuing delay is 0 for the first transmitt
ed
packet, L/R for the second transmitt
ed
packet, and generally, (n-1)L/R for the nth transmitt
ed
packet. Thus, the average delay for the N packets is: (L/R + 2L/R + ....... + (N-1)L/R)/N = L/(RN) * (1 + 2 + ..... + (N-1)) = L/(RN) * N(N-1)/2 = LN(N-1)/(2RN) = (N-1)L/(2R) Note that here we us
ed
the well-known fact: 1 + 2 + ....... + N = N(N+1)/2 It takes seconds to transmit the packets. Thus, the buffer is empty when a each batch of packets arrive. Thus, the average delay of a packet across all batches is the average delay within one batch, i.e., (N-1)L/2R. Problem 14 The transmission delay is . The total delay is Let . Total delay = For x=0, the total delay =0; as we increase x, total delay increases, approaching infinity as x approaches 1/a. Problem 15 Total delay . Problem 16 The total number of packets in the system includes those in the buffer and the packet that is being transmitt
ed
. So, N=10+1. Because , so (10+1)=a*(queuing delay + transmission delay). That is, 11=a*(0.01+1/100)=a*(0.01+0.01). Thus, a=550 packets/sec. Problem 17 There are nodes (the source host and the routers). Let denote the processing delay at the th node. Let be the transmission rate of the th link and let . Let be the propagation delay across the th link. Then . Let denote the average queuing delay at node . Then . Problem 18 On linux you can use the command traceroute www.targethost.com and in the Windows command prompt you can use tracert www.targethost.com In either case, you will get three delay measurements. For those three measurements you can calculate the mean and standard deviation. Repeat the experiment at different times of the day and comment on any changes. Here is an example solution: Traceroutes between San Diego Super Computer Center and www.poly.
ed
u The average (mean) of the round-trip delays at each of the three hours is 71.18 ms, 71.38 ms and 71.55 ms, respectively. The standard deviations are 0.075 ms, 0.21 ms, 0.05 ms, respectively. In this example, the traceroutes have 12 routers in the path at each of the three hours. No, the paths didn’t change during any of the hours. Traceroute packets pass
ed
through four ISP networks from source to destination. Yes, in this experiment the largest delays occurr
ed
at peering interfaces between adjacent ISPs. Traceroutes from www.stella-net.net (France) to www.poly.
ed
u (USA). The average round-trip delays at each of the three hours are 87.09 ms, 86.35 ms and 86.48 ms, respectively. The standard deviations are 0.53 ms, 0.18 ms, 0.23 ms, respectively. In this example, there are 11 routers in the path at each of the three hours. No, the paths didn’t change during any of the hours. Traceroute packets pass
ed
three ISP networks from source to destination. Yes, in this experiment the largest delays occurr
ed
at peering interfaces between adjacent ISPs. Problem 19 An example solution: Traceroutes from two different cities in France to New York City in Unit
ed
States In these traceroutes from two different cities in France to the same destination host in Unit
ed
States, seven links are in common including the transatlantic link. In this example of traceroutes from one city in France and from another city in Germany to the same host in Unit
ed
States, three links are in common including the transatlantic link. Traceroutes to two different cities in China from same host in Unit
ed
States Five links are common in the two traceroutes. The two traceroutes diverge before reaching China Problem 20 Throughput = min{Rs, Rc, R/M} Problem 21 If only use one path, the max throughput is given by: . If use all paths, the max throughput is given by . Problem 22 Probability of successfully receiving a packet is: ps= (1-p)N. The number of transmissions ne
ed
ed
to be perform
ed
until the packet is successfully receiv
ed
by the client is a geometric random variable with success probability ps. Thus, the average number of transmissions ne
ed
ed
is given by: 1/ps . Then, the average number of re-transmissions ne
ed
ed
is given by: 1/ps -1. Problem 23 Let’s call the first packet A and call the second packet B. If the bottleneck link is the first link, then packet B is queu
ed
at the first link waiting for the transmission of packet A. So the packet inter-arrival time at the destination is simply L/Rs. If the second link is the bottleneck link and both packets are sent back to back, it must be true that the second packet arrives at the input queue of the second link before the second link finishes the transmission of the first packet. That is, L/Rs + L/Rs + dprop = L/Rs + dprop + L/Rc Thus, the minimum value of T is L/Rc L/Rs . Problem 24 40 terabytes = 40 * 1012 * 8 bits. So, if using the d
ed
i
cat
ed
link, it will take 40 * 1012 * 8 / (100 *106 ) =3200000 seconds = 37 days. But with F
ed
Ex overnight delivery, you can guarantee the data arrives in one day, and it should cost less than $100. Problem 25 160,000 bits 160,000 bits The bandwidth-delay product of a link is the maximum number of bits that can be in the link. the width of a bit = length of link / bandwidth-delay product, so 1 bit is 125 meters
lo
ng, which is
lo
nger than a football field s/R Problem 26 s/R=20000km, then R=s/20000km= 2.5*108/(2*107)= 12.5 bps Problem 27 80,000,000 bits 800,000 bits, this is because that the maximum number of bits that will be in the link at any given time = min(bandwidth delay product, packet size) = 800,000 bits. .25 meters Problem 28 ttrans + tprop = 400 msec + 80 msec = 480 msec. 20 * (ttrans + 2 tprop) = 20*(20 msec + 80 msec) = 2 sec. Breaking up a file takes
lo
nger to transmit because each data packet and its corresponding acknowl
ed
gement packet add their own propagation delays. Problem 29 Recall geostationary satellite is 36,000 ki
lo
meters away from earth surface. 150 msec 1,500,000 bits 600,000,000 bits Problem 30 Let’s suppose the passenger and his/her bags correspond to the data unit arriving to the top of the protocol stack. When the passenger checks in, his/her bags are check
ed
, and a tag is attach
ed
to the bags and ticket. This is additional information add
ed
in the Baggage layer if Figure 1.20 that al
lo
ws the Baggage layer to implement the service or separating the passengers and baggage on the sending side, and then reuniting them (hopefully!) on the destination side. When a passenger then passes through security and additional stamp is often add
ed
to his/her ticket, indi
cat
ing that the passenger has pass
ed
through a security check. This information is us
ed
to ensure (e.g., by later checks for the security information) secure transfer of people. Problem 31 Time to send message from source host to first packet switch = With store-and-forward switching, the total time to move message from source host to destination host = Time to send 1st packet from source host to first packet switch = . . Time at which 2nd packet is receiv
ed
at the first switch = time at which 1st packet is receiv
ed
at the second switch = Time at which 1st packet is receiv
ed
at the destination host = . After this, every 5msec one packet will be receiv
ed
; thus time at which last (800th) packet is receiv
ed
= . It can be seen that delay in using message segmentation is significantly less (almost 1/3rd). Without message segmentation, if bit errors are not tolerat
ed
, if there is a single bit error, the whole message has to be retransmitt
ed
(rather than a single packet). Without message segmentation, huge packets (containing HD videos, for example) are sent into the network. Routers have to accommodate these huge packets. Smaller packets have to queue behind enormous packets and suffer unfair delays. Packets have to be put in sequence at the destination. Message segmentation results in many smaller packets. Since header size is usually the same for all packets regardless of their size, with message segmentation the total amount of header bytes is more. Problem 32 Yes, the delays in the applet correspond to the delays in the Problem 31.The propagation delays affect the overall end-to-end delays both for packet switching and message switching equally. Problem 33 There are F/S packets. Each packet is S=80 bits. Time at which the last packet is receiv
ed
at the first router is sec. At this time, the first F/S-2 packets are at the destination, and the F/S-1 packet is at the second router. The last packet must then be transmitt
ed
by the first router and the second router, with each transmission taking sec. Thus delay in sending the whole file is To calculate the value of S which leads to the minimum delay, Problem 34 The circuit-switch
ed
telephone networks and the Internet are connect
ed
together at "gateways". When a Skype user (connect
ed
to the Internet) calls an ordinary telephone, a circuit is establish
ed
between a gateway and the telephone user over the circuit switch
ed
network. The skype user's voice is sent in packets over the Internet to the gateway. At the gateway, the voice signal is reconstruct
ed
and then sent over the circuit. In the other direction, the voice signal is sent over the circuit switch
ed
network to the gateway. The gateway packetizes the voice signal and sends the voice packets to the Skype user. Chapter 2 Review Questions The Web: HTTP; file transfer: FTP; remote
lo
gin: Telnet; e-mail: SMTP; BitTorrent file sharing: BitTorrent protocol Network architecture refers to the organization of the communi
cat
ion process into layers (e.g., the five-layer Internet architecture). Appli
cat
ion architecture, on the other hand, is design
ed
by an appli
cat
ion deve
lo
per and dictates the broad structure of the appli
cat
ion (e.g., client-server or P2P). The process which initiates the communi
cat
ion is the client; the process that waits to be contact
ed
is the server. No. In a P2P file-sharing appli
cat
ion, the peer that is receiving a file is typically the client and the peer that is sending the file is typically the server. The IP address of the destination host and the port number of the socket in the destination process. You would use UDP. With UDP, the transaction can be complet
ed
in one roundtrip time (RTT) - the client sends the transaction request into a UDP socket, and the server sends the reply back to the client's UDP socket. With TCP, a minimum of two RTTs are ne
ed
ed
- one to set-up the TCP connection, and another for the client to send the request, and for the server to send back the reply. One such example is remote word processing, for example, with Google docs. However, because Google docs runs over the Internet (using TCP), timing guarantees are not provid
ed
. a) Reliable data transfer TCP provides a reliable byte-stream between client and server but UDP does not. b) A guarantee that a certain value for throughput will be maintain
ed
Neither c) A guarantee that data will be deliver
ed
within a specifi
ed
amount of time Neither d) Confidentiality (via encryption) Neither SSL operates at the appli
cat
ion layer. The SSL socket takes unencrypt
ed
data from the appli
cat
ion layer, encrypts it and then passes it to the TCP socket. If the appli
cat
ion deve
lo
per wants TCP to be enhanc
ed
with SSL, she has to include the SSL code in the appli
cat
ion. A protocol uses handshaking if the two communi
cat
ing entities first exchange control packets before sending data to each other. SMTP uses handshaking at the appli
cat
ion layer whereas HTTP does not. The appli
cat
ions associat
ed
with those protocols require that all appli
cat
ion data be receiv
ed
in the correct order and without gaps. TCP provides this service whereas UDP does not. When the user first visits the site, the server creates a unique identifi
cat
ion number, creates an entry in its back-end
database
, and returns this identifi
cat
ion number as a cookie number. This cookie number is stor
ed
on the user’s host and is manag
ed
by the browser. During each subsequent visit (and purchase), the browser sends the cookie number back to the site. Thus the site knows when this user (more precisely, this browser) is visiting the site. Web caching can bring the desir
ed
content “c
lo
ser” to the user, possibly to the same LAN to which the user’s host is connect
ed
. Web caching can r
ed
uce the delay for all
object
s, even
object
s that are not cach
ed
, since caching r
ed
uces the traffic on links. Telnet is not available in Windows 7 by default. to make it available, go to Control Panel, Programs and Features, Turn Windows Features On or Off, Check Telnet client. To start Telnet, in Windows command prompt, issue the fol
lo
wing command > telnet webserverver 80 where "webserver" is some webserver. After issuing the command, you have establish
ed
a TCP connection between your client telnet program and the web server. Then type in an HTTP GET message. An example is given be
lo
w: Since the index.html page in this web server was not modifi
ed
since Fri, 18 May 2007 09:23:34 GMT, and the above commands were issu
ed
on Sat, 19 May 2007, the server return
ed
"304 Not Modifi
ed
". Note that the first 4 lines are the GET message and header lines input
ed
by the user, and the next 4 lines (starting from HTTP/1.1 304 Not Modifi
ed
) is the response from the web server. FTP uses two parallel TCP connections, one connection for sending control information (such as a request to transfer a file) and another connection for actually transferring the file. Because the control information is not sent over the same connection that the file is sent over, FTP sends control information out of band. The message is first sent from Alice’s host to her mail server over HTTP. Alice’s mail server then sends the message to Bob’s mail server over SMTP. Bob then transfers the message from his mail server to his host over POP3. 17. Receiv
ed
: from 65.54.246.203 (EH
LO
bay0-omc3-s3.bay0.hotmail.com) (65.54.246.203) by mta419.mail.mud.yahoo.com with SMTP; Sat, 19 May 2007 16:53:51 -0700 Receiv
ed
: from hotmail.com ([65.55.135.106]) by bay0-omc3-s3.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Sat, 19 May 2007 16:52:42 -0700 Receiv
ed
: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 19 May 2007 16:52:41 -0700 Message-ID: Receiv
ed
: from 65.55.135.123 by by130fd.bay130.hotmail.msn.com with HTTP; Sat, 19 May 2007 23:52:36 GMT From: "prithula dhungel" To: prithula@yahoo.com Bcc: Subject: Test mail Date: Sat, 19 May 2007 23:52:36 +0000 Mime-Version: 1.0 Content-Type: Text/html; format=f
lo
w
ed
Return-Path: prithuladhungel@hotmail.com Figure: A sample mail message header Receiv
ed
: This header field indi
cat
es the sequence in which the SMTP servers send and receive the mail message including the respective timestamps. In this example there are 4 “Receiv
ed
:” header lines. This means the mail message pass
ed
through 5 different SMTP servers before being deliver
ed
to the receiver’s mail box. The last (forth) “Receiv
ed
:” header indi
cat
es the mail message f
lo
w from the SMTP server of the sender to the second SMTP server in the chain of servers. The sender’s SMTP server is at address 65.55.135.123 and the second SMTP server in the chain is by130fd.bay130.hotmail.msn.com. The third “Receiv
ed
:” header indi
cat
es the mail message f
lo
w from the second SMTP server in the chain to the third server, and so on. Finally, the first “Receiv
ed
:” header indi
cat
es the f
lo
w of the mail messages from the forth SMTP server to the last SMTP server (i.e. the receiver’s mail server) in the chain. Message-id: The message has been given this number BAY130-F26D9E35BF59E0D18A819AFB9310@phx.gbl (by bay0-omc3-s3.bay0.hotmail.com. Message-id is a unique string assign
ed
by the mail system when the message is first creat
ed
. From: This indi
cat
es the email address of the sender of the mail. In the given example, the sender is “prithuladhungel@hotmail.com” To: This field indi
cat
es the email address of the receiver of the mail. In the example, the receiver is “prithula@yahoo.com” Subject: This gives the subject of the mail (if any specifi
ed
by the sender). In the example, the subject specifi
ed
by the sender is “Test mail” Date: The date and time when the mail was sent by the sender. In the example, the sender sent the mail on 19th May 2007, at time 23:52:36 GMT. Mime-version: MIME version us
ed
for the mail. In the example, it is 1.0. Content-type: The type of content in the body of the mail message. In the example, it is “text/html”. Return-Path: This specifies the email address to which the mail will be sent if the receiver of this mail wants to reply to the sender. This is also us
ed
by the sender’s mail server for bouncing back undeliverable mail messages of mailer-daemon error messages. In the example, the return path is “prithuladhungel@hotmail.com”. With down
lo
ad and delete, after a user retrieves its messages from a POP server, the messages are delet
ed
. This poses a problem for the nomadic user, who may want to access the messages from many different machines (office PC, home PC, etc.). In the down
lo
ad and keep configuration, messages are not delet
ed
after the user retrieves the messages. This can also be inconvenient, as each time the user retrieves the stor
ed
messages from a new machine, all of non-delet
ed
messages will be transferr
ed
to the new machine (including very old messages). Yes an organization’s mail server and Web server can have the same alias for a host name. The MX record is us
ed
to map the mail server’s host name to its IP address. You should be able to see the sender's IP address for a user with an .
ed
u email address. But you will not be able to see the sender's IP address if the user uses a gmail account. It is not necessary that Bob will also provide chunks to Alice. Alice has to be in the top 4 neighbors of Bob for Bob to send out chunks to her; this might not occur even if Alice provides chunks to Bob throughout a 30-second interval. Recall that in BitTorrent, a peer picks a random peer and optimistically unchokes the peer for a short period of time. Therefore, Alice will eventually be optimistically unchok
ed
by one of her neighbors, during which time she will receive chunks from that neighbor. The overlay network in a P2P file sharing system consists of the nodes participating in the file sharing system and the
lo
gical links between the nodes. There is a
lo
gical link (an “
ed
ge” in graph theory terms) from node A to node B if there is a semi-permanent TCP connection between A and B. An overlay network does not include routers. Mesh DHT: The advantage is in order to a route a message to the peer (with ID) that is c
lo
sest to the key, only one hop is requir
ed
; the disadvantage is that each peer must track all other peers in the DHT. Circular DHT: the advantage is that each peer ne
ed
s to track only a few other peers; the disadvantage is that O(N) hops are ne
ed
ed
to route a message to the peer that is c
lo
sest to the key. 25. File Distribution Instant Messaging Video Streaming Distribut
ed
Computing With the UDP server, there is no welcoming socket, and all data from different clients enters the server through this one socket. With the TCP server, there is a welcoming socket, and each time a client initiates a connection to the server, a new socket is creat
ed
. Thus, to support n simultaneous connections, the server would ne
ed
n+1 sockets. For the TCP appli
cat
ion, as soon as the client is execut
ed
, it attempts to initiate a TCP connection with the server. If the TCP server is not running, then the client will fail to make a connection. For the UDP appli
cat
ion, the client does not initiate connections (or attempt to communi
cat
e with the UDP server) imm
ed
iately upon execution Chapter 2 Problems Problem 1 a) F b) T c) F d) F e) F Problem 2 Access control commands: USER, PASS, ACT, CWD, CDUP, SMNT, REIN, QUIT. Transfer parameter commands: PORT, PASV, TYPE STRU, MODE. Service commands: RETR, STOR, STOU, APPE, AL
LO
, REST, RNFR, RNTO, ABOR, DELE, RMD, MRD, PWD, LIST, NLST, SITE, SYST, STAT, HELP, NOOP. Problem 3 Appli
cat
ion layer protocols: DNS and HTTP Transport layer protocols: UDP for DNS; TCP for HTTP Problem 4 The document request was http://gaia.cs.umass.
ed
u/cs453/index.html. The Host : field indi
cat
es the server's name and /cs453/index.html indi
cat
es the file name. The browser is running HTTP version 1.1, as indi
cat
ed
just before the first pair. The browser is requesting a persistent connection, as indi
cat
ed
by the Connection: keep-alive. This is a trick question. This information is not contain
ed
in an HTTP message anywhere. So there is no way to tell this from
lo
oking at the exchange of HTTP messages a
lo
ne. One would ne
ed
information from the IP datagrams (that carri
ed
the TCP segment that carri
ed
the HTTP GET request) to answer this question. Mozilla/5.0. The browser type information is ne
ed
ed
by the server to send different versions of the same
object
to different types of browsers. Problem 5 The status code of 200 and the phrase OK indi
cat
e that the server was able to
lo
cat
e the document successfully. The reply was provid
ed
on Tuesday, 07 Mar 2008 12:39:45 Greenwich Mean Time. The document index.html was last modifi
ed
on Saturday 10 Dec 2005 18:27:46 GMT. There are 3874 bytes in the document being return
ed
. The first five bytes of the return
ed
document are : ed to a persistent connection, as indi
cat
ed
by the Connection: Keep-Alive field Problem 6 Persistent connections are discuss
ed
in section 8 of RFC 2616 (the real goal of this question was to get you to retrieve and read an RFC). Sections 8.1.2 and 8.1.2.1 of the RFC indi
cat
e that either the client or the server can indi
cat
e to the other that it is going to c
lo
se the persistent connection. It does so by including the connection-token "c
lo
se" in the Connection-header field of the http request/reply. HTTP does not provide any encryption services. (From RFC 2616) “Clients that use persistent connections should limit the number of simultaneous connections that they maintain to a given server. A single-user client SHOULD NOT maintain more than 2 connections with any server or proxy.” Yes. (From RFC 2616) “A client might have start
ed
to send a new request at the same time that the server has decid
ed
to c
lo
se the "idle" connection. From the server's point of view, the connection is being c
lo
s
ed
while it was idle, but from the client's point of view, a request is in progress.” Problem 7 The total amount of time to get the IP address is . Once the IP address is known, elapses to set up the TCP connection and another elapses to request and receive the small
object
. The total response time is Problem 8 . . Problem 9 The time to transmit an
object
of size L over a link or rate R is L/R. The average time is the average size of the
object
divid
ed
by R: = (850,000 bits)/(15,000,000 bits/sec) = .0567 sec The traffic intensity on the link is given by =(16 requests/sec)(.0567 sec/request) = 0.907. Thus, the average access delay is (.0567 sec)/(1 - .907) .6 seconds. The total average response time is therefore .6 sec + 3 sec = 3.6 sec. The traffic intensity on the access link is r
ed
uc
ed
by 60% since the 60% of the requests are satisfi
ed
within the institutional network. Thus the average access delay is (.0567 sec)/[1 – (.4)(.907)] = .089 seconds. The response time is approximately zero if the request is satisfi
ed
by the cache (which happens with probability .6); the average response time is .089 sec + 3 sec = 3.089 sec for cache misses (which happens 40% of the time). So the average response time is (.6)(0 sec) + (.4)(3.089 sec) = 1.24 seconds. Thus the average response time is r
ed
uc
ed
from 3.6 sec to 1.24 sec. Problem 10 Note that each down
lo
ad
ed
object
can be completely put into one data packet. Let Tp denote the one-way propagation delay between the client and the server. First consider parallel down
lo
ads using non-persistent connections. Parallel down
lo
ads would al
lo
w 10 connections to share the 150 bits/sec bandwidth, giving each just 15 bits/sec. Thus, the total time ne
ed
ed
to receive all
object
s is given by: (200/150+Tp + 200/150 +Tp + 200/150+Tp + 100,000/150+ Tp ) + (200/(150/10)+Tp + 200/(150/10) +Tp + 200/(150/10)+Tp + 100,000/(150/10)+ Tp ) = 7377 + 8*Tp (seconds) Now consider a persistent HTTP connection. The total time ne
ed
ed
is given by: (200/150+Tp + 200/150 +Tp + 200/150+Tp + 100,000/150+ Tp ) + 10*(200/150+Tp + 100,000/150+ Tp ) =7351 + 24*Tp (seconds) Assuming the spe
ed
of light is 300*106 m/sec, then Tp=10/(300*106)=0.03 microsec. Tp is therefore negligible compar
ed
with transmission delay. Thus, we see that persistent HTTP is not significantly faster (less than 1 percent) than the non-persistent case with parallel down
lo
ad. Problem 11 Yes, because Bob has more connections, he can get a larger share of the link bandwidth. Yes, Bob still ne
ed
s to perform parallel down
lo
ads; otherwise he will get less bandwidth than the other four users. Problem 12 Server.py from socket import * serverPort=12000 serverSocket=socket(AF_INET,SOCK_STREAM) serverSocket.bind(('',serverPort)) serverSocket.listen(1) connectionSocket, addr = serverSocket.accept() while 1: sentence = connectionSocket.recv(1024) print 'From Server:', sentence, '\n' serverSocket.c
lo
se() Problem 13 The MAIL FROM: in SMTP is a message from the SMTP client that identifies the sender of the mail message to the SMTP server. The From: on the mail message itself is NOT an SMTP message, but rather is just a line in the body of the mail message. Problem 14 SMTP uses a line containing only a period to mark the end of a message body. HTTP uses “Content-Length header field” to indi
cat
e the length of a message body. No, HTTP cannot use the method us
ed
by SMTP, because HTTP message could be binary data, whereas in SMTP, the message body must be in 7-bit ASCII format. Problem 15 MTA stands for Mail Transfer Agent. A host sends the message to an MTA. The message then fol
lo
ws a sequence of MTAs to reach the receiver’s mail reader. We see that this spam message fol
lo
ws a chain of MTAs. An honest MTA should report where it receives the message. Notice that in this message, “asusus-4b96 ([58.88.21.177])” does not report from where it receiv
ed
the email. Since we assume only the originator is dishonest, so “asusus-4b96 ([58.88.21.177])” must be the originator. Problem 16 UIDL abbreviates “unique-ID listing”. When a POP3 client issues the UIDL command, the server responds with the unique message ID for all of the messages present in the user's mailbox. This command is useful for “down
lo
ad and keep”. By maintaining a file that lists the messages retriev
ed
during earlier sessions, the client can use the UIDL command to determine which messages on the server have already been seen. Problem 17 a) C: dele 1 C: retr 2 S: (blah blah … S: ………..blah) S: . C: dele 2 C: quit S: +OK POP3 server signing off b) C: retr 2 S: blah blah … S: ………..blah S: . C: quit S: +OK POP3 server signing off C: list S: 1 498 S: 2 912 S: . C: retr 1 S: blah ….. S: ….blah S: . C: retr 2 S: blah blah … S: ………..blah S: . C: quit S: +OK POP3 server signing off Problem 18 For a given input of domain name (such as ccn.com), IP address or network administrator name, the whois
database
can be us
ed
to
lo
cat
e the corresponding registrar, whois server, DNS server, and so on. NS4.YAHOO.COM from www.register.com; NS1.MSFT.NET from ww.register.com
Lo
cal Domain: www.mindspring.com Web servers : www.mindspring.com 207.69.189.21, 207.69.189.22, 207.69.189.23, 207.69.189.24, 207.69.189.25, 207.69.189.26, 207.69.189.27, 207.69.189.28 Mail Servers : mx1.mindspring.com (207.69.189.217) mx2.mindspring.com (207.69.189.218) mx3.mindspring.com (207.69.189.219) mx4.mindspring.com (207.69.189.220) Name Servers: itchy.earthlink.net (207.69.188.196) scratchy.earthlink.net (207.69.188.197) www.yahoo.com Web Servers: www.yahoo.com (216.109.112.135, 66.94.234.13) Mail Servers: a.mx.mail.yahoo.com (209.191.118.103) b.mx.mail.yahoo.com (66.196.97.250) c.mx.mail.yahoo.com (68.142.237.182, 216.39.53.3) d.mx.mail.yahoo.com (216.39.53.2) e.mx.mail.yahoo.com (216.39.53.1) f.mx.mail.yahoo.com (209.191.88.247, 68.142.202.247) g.mx.mail.yahoo.com (209.191.88.239, 206.190.53.191) Name Servers: ns1.yahoo.com (66.218.71.63) ns2.yahoo.com (68.142.255.16) ns3.yahoo.com (217.12.4.104) ns4.yahoo.com (68.142.196.63) ns5.yahoo.com (216.109.116.17) ns8.yahoo.com (202.165.104.22) ns9.yahoo.com (202.160.176.146) www.hotmail.com Web Servers: www.hotmail.com (64.4.33.7, 64.4.32.7) Mail Servers: mx1.hotmail.com (65.54.245.8, 65.54.244.8, 65.54.244.136) mx2.hotmail.com (65.54.244.40, 65.54.244.168, 65.54.245.40) mx3.hotmail.com (65.54.244.72, 65.54.244.200, 65.54.245.72) mx4.hotmail.com (65.54.244.232, 65.54.245.104, 65.54.244.104) Name Servers: ns1.msft.net (207.68.160.190) ns2.msft.net (65.54.240.126) ns3.msft.net (213.199.161.77) ns4.msft.net (207.46.66.126) ns5.msft.net (65.55.238.126) d) The yahoo web server has multiple IP addresses www.yahoo.com (216.109.112.135, 66.94.234.13) e) The address range for Polytechnic University: 128.238.0.0 – 128.238.255.255 f) An attacker can use the whois
database
and ns
lo
okup tool to determine the IP address ranges, DNS server addresses, etc., for the target institution. By analyzing the source address of attack packets, the victim can use whois to obtain information about domain from which the attack is coming and possibly inform the administrators of the origin domain. Problem 19 The fol
lo
wing delegation chain is us
ed
for gaia.cs.umass.
ed
u a.root-servers.net E.GTLD-SERVERS.NET ns1.umass.
ed
u(authoritative) First command: dig +norecurse @a.root-servers.net any gaia.cs.umass.
ed
u ;; AUTHORITY SECTION:
ed
u. 172800 IN NS E.GTLD-SERVERS.NET.
ed
u. 172800 IN NS A.GTLD-SERVERS.NET.
ed
u. 172800 IN NS G3.NSTLD.COM.
ed
u. 172800 IN NS D.GTLD-SERVERS.NET.
ed
u. 172800 IN NS H3.NSTLD.COM.
ed
u. 172800 IN NS L3.NSTLD.COM.
ed
u. 172800 IN NS M3.NSTLD.COM.
ed
u. 172800 IN NS C.GTLD-SERVERS.NET. Among all return
ed
ed
u DNS servers, we send a query to the first one. dig +norecurse @E.GTLD-SERVERS.NET any gaia.cs.umass.
ed
u umass.
ed
u. 172800 IN NS ns1.umass.
ed
u. umass.
ed
u. 172800 IN NS ns2.umass.
ed
u. umass.
ed
u. 172800 IN NS ns3.umass.
ed
u. Among all three return
ed
authoritative DNS servers, we send a query to the first one. dig +norecurse @ns1.umass.
ed
u any gaia.cs.umass.
ed
u gaia.cs.umass.
ed
u. 21600 IN A 128.119.245.12 The answer for google.com could be: a.root-servers.net E.GTLD-SERVERS.NET ns1.google.com(authoritative) Problem 20 We can periodically take a snapshot of the DNS caches in the
lo
cal DNS servers. The Web server that appears most frequently in the DNS caches is the most popular server. This is because if more users are interest
ed
in a Web server, then DNS requests for that server are more frequently sent by users. Thus, that Web server will appear in the DNS caches more frequently. For a complete measurement study, see: Craig E. Wills, Mikhail Mikhai
lo
v, Hao Shang “Inferring Relative Popularity of Internet Appli
cat
ions by Actively Querying DNS Caches”, in IMC'03, October 2729, 2003, Miami Beach, F
lo
rida, USA Problem 21 Yes, we can use dig to query that Web site in the
lo
cal DNS server. For example, “dig cnn.com” will return the query time for finding cnn.com. If cnn.com was just access
ed
a couple of seconds ago, an entry for cnn.com is cach
ed
in the
lo
cal DNS cache, so the query time is 0 msec. Otherwise, the query time is large. Problem 22 For calculating the minimum distribution time for client-server distribution, we use the fol
lo
wing formula: Dcs = max {NF/us, F/dmin} Similarly, for calculating the minimum distribution time for P2P distribution, we use the fol
lo
wing formula: Where, F = 15 Gbits = 15 * 1024 Mbits us = 30 Mbps dmin = di = 2 Mbps Note, 300Kbps = 300/1024 Mbps. Client Server N 10 100 1000 u 300 Kbps 7680 51200 512000 700 Kbps 7680 51200 512000 2 Mbps 7680 51200 512000 Peer to Peer N 10 100 1000 u 300 Kbps 7680 25904 47559 700 Kbps 7680 15616 21525 2 Mbps 7680 7680 7680 Problem 23 Consider a distribution scheme in which the server sends the file to each client, in parallel, at a rate of a rate of us/N. Note that this rate is less than each of the client’s down
lo
ad rate, since by assumption us/N ≤ dmin. Thus each client can also receive at rate us/N. Since each client receives at rate us/N, the time for each client to receive the entire file is F/( us/N) = NF/ us. Since all the clients receive the file in NF/ us, the overall distribution time is also NF/ us. Consider a distribution scheme in which the server sends the file to each client, in parallel, at a rate of dmin. Note that the aggregate rate, N dmin, is less than the server’s link rate us, since by assumption us/N ≥ dmin. Since each client receives at rate dmin, the time for each client to receive the entire file is F/ dmin. Since all the clients receive the file in this time, the overall distribution time is also F/ dmin. From Section 2.6 we know that DCS ≥ max {NF/us, F/dmin} (Equation 1) Suppose that us/N ≤ dmin. Then from Equation 1 we have DCS ≥ NF/us . But from (a) we have DCS ≤ NF/us . Combining these two gives: DCS = NF/us when us/N ≤ dmin. (Equation 2) We can similarly show that: DCS =F/dmin when us/N ≥ dmin (Equation 3). Combining Equation 2 and Equation 3 gives the desir
ed
result. Problem 24 Define u = u1 + u2 + ….. + uN. By assumption us <= (us + u)/N Equation 1 Divide the file into N parts, with the ith part having size (ui/u)F. The server transmits the ith part to peer i at rate ri = (ui/u)us. Note that r1 + r2 + ….. + rN = us, so that the aggregate server rate does not exce
ed
the link rate of the server. Also have each peer i forward the bits it receives to each of the N-1 peers at rate ri. The aggregate forwarding rate by peer i is (N-1)ri. We have (N-1)ri = (N-1)(usui)/u = (us + u)/N Equation 2 Let ri = ui/(N-1) and rN+1 = (us – u/(N-1))/N In this distribution scheme, the file is broken into N+1 parts. The server sends bits from the ith part to the ith peer (i = 1, …., N) at rate ri. Each peer i forwards the bits arriving at rate ri to each of the other N-1 peers. Additionally, the server sends bits from the (N+1) st part at rate rN+1 to each of the N peers. The peers do not forward the bits from the (N+1)st part. The aggregate send rate of the server is r1+ …. + rN + N rN+1 = u/(N-1) + us – u/(N-1) = us Thus, the server’s send rate does not exce
ed
its link rate. The aggregate send rate of peer i is (N-1)ri = ui Thus, each peer’s send rate does not exce
ed
its link rate. In this distribution scheme, peer i receives bits at an aggregate rate of Thus each peer receives the file in NF/(us+u). (For simplicity, we neglect
ed
to specify the size of the file part for i = 1, …., N+1. We now provide that here. Let Δ = (us+u)/N be the distribution time. For i = 1, …, N, the ith file part is Fi = ri Δ bits. The (N+1)st file part is FN+1 = rN+1 Δ bits. It is straightforward to show that F1+ ….. + FN+1 = F.) The solution to this part is similar to that of 17 (c). We know from section 2.6 that Combining this with a) and b) gives the desir
ed
result. Problem 25 There are N nodes in the overlay network. There are N(N-1)/2
ed
ges. Problem 26 Yes. His first claim is possible, as
lo
ng as there are enough peers staying in the swarm for a
lo
ng enough time. Bob can always receive data through optimistic unchoking by other peers. His second claim is also true. He can run a client on each host, let each client “free-ride,” and combine the collect
ed
chunks from the different hosts into a single file. He can even write a small sch
ed
uling program to make the different hosts ask for different chunks of the file. This is actually a kind of Sybil attack in P2P networks. Problem 27 Peer 3 learns that peer 5 has just left the system, so Peer 3 asks its first successor (Peer 4) for the identifier of its imm
ed
iate successor (peer 8). Peer 3 will then make peer 8 its second successor. Problem 28 Peer 6 would first send peer 15 a message, saying “what will be peer 6’s pr
ed
ecessor and successor?” This message gets forward
ed
through the DHT until it reaches peer 5, who realizes that it will be 6’s pr
ed
ecessor and that its current successor, peer 8, will become 6’s successor. Next, peer 5 sends this pr
ed
ecessor and successor information back to 6. Peer 6 can now join the DHT by making peer 8 its successor and by notifying peer 5 that it should change its imm
ed
iate successor to 6. Problem 29 For each key, we first calculate the distances (using d(k,p)) between itself and all peers, and then store the key in the peer that is c
lo
sest to the key (that is, with smallest distance value). Problem 30 Yes, randomly assigning keys to peers does not consider the underlying network at all, so it very likely causes mismatches. Such mismatches may degrade the search performance. For example, consider a
lo
gical path p1 (consisting of only two
lo
gical links): ABC, where A and B are neighboring peers, and B and C are neighboring peers. Suppose that there is another
lo
gical path p2 from A to C (consisting of 3
lo
gical links): ADEC. It might be the case that A and B are very far away physically (and separat
ed
by many routers), and B and C are very far away physically (and separat
ed
by many routers). But it may be the case that A, D, E, and C are all very c
lo
se physically (and all separat
ed
by few routers). In other words, a shorter
lo
gical path may correspond to a much
lo
nger physical path. Problem 31 If you run TCPClient first, then the client will attempt to make a TCP connection with a non-existent server process. A TCP connection will not be made. UDPClient doesn't establish a TCP connection with the server. Thus, everything should work fine if you first run UDPClient, then run UDPServer, and then type some input into the keyboard. If you use different port numbers, then the client will attempt to establish a TCP connection with the wrong process or a non-existent process. Errors will occur. Problem 32 In the original program, UDPClient does not specify a port number when it creates the socket. In this case, the code lets the underlying operating system choose a port number. With the additional line, when UDPClient is execut
ed
, a UDP socket is creat
ed
with port number 5432 . UDPServer ne
ed
s to know the client port number so that it can send packets back to the correct client socket. Glancing at UDPServer, we see that the client port number is not “hard-wir
ed
” into the server code; instead, UDPServer determines the client port number by unraveling the datagram it receives from the client. Thus UDP server will work with any client port number, including 5432. UDPServer therefore does not ne
ed
to be modifi
ed
. Before: Client socket = x (chosen by OS) Server socket = 9876 After: Client socket = 5432 Problem 33 Yes, you can configure many browsers to open multiple simultaneous connections to a Web site. The advantage is that you will you potentially down
lo
ad the file faster. The disadvantage is that you may be hogging the bandwidth, thereby significantly s
lo
wing down the down
lo
ads of other users who are sharing the same physical links. Problem 34 For an appli
cat
ion such as remote
lo
gin (telnet and ssh), a byte-stream orient
ed
protocol is very natural since there is no notion of message boundaries in the appli
cat
ion. When a user types a character, we simply drop the character into the TCP connection. In other appli
cat
ions, we may be sending a series of messages that have inherent boundaries between them. For example, when one SMTP mail server sends another SMTP mail server several email messages back to back. Since TCP does not have a mechanism to indi
cat
e the boundaries, the appli
cat
ion must add the indi
cat
ions itself, so that receiving side of the appli
cat
ion can distinguish one message from the next. If each message were instead put into a distinct UDP segment, the receiving end would be able to distinguish the various messages without any indi
cat
ions add
ed
by the sending side of the appli
cat
ion. Problem 35 To create a web server, we ne
ed
to run web server software on a host. Many vendors sell web server software. However, the most popular web server software today is Apache, which is open source and free. Over the years it has been highly optimiz
ed
by the open-source community. Problem 36 The key is the infohash, the value is an IP address that currently has the file designat
ed
by the infohash. Chapter 3 Review Questions Call this protocol Simple Transport Protocol (STP). At the sender side, STP accepts from the sending process a chunk of data not exce
ed
ing 1196 bytes, a destination host address, and a destination port number. STP adds a four-byte header to each chunk and puts the port number of the destination process in this header. STP then gives the destination host address and the resulting segment to the network layer. The network layer delivers the segment to STP at the destination host. STP then examines the port number in the segment, extracts the data from the segment, and passes the data to the process identifi
ed
by the port number. The segment now has two header fields: a source port field and destination port field. At the sender side, STP accepts a chunk of data not exce
ed
ing 1192 bytes, a destination host address, a source port number, and a destination port number. STP creates a segment which contains the appli
cat
ion data, source port number, and destination port number. It then gives the segment and the destination host address to the network layer. After receiving the segment, STP at the receiving host gives the appli
cat
ion process the appli
cat
ion data and the source port number. No, the transport layer does not have to do anything in the core; the transport layer “lives” in the end systems. For sending a letter, the family member is requir
ed
to give the delegate the letter itself, the address of the destination house, and the name of the recipient. The delegate clearly writes the recipient’s name on the top of the letter. The delegate then puts the letter in an enve
lo
pe and writes the address of the destination house on the enve
lo
pe. The delegate then gives the letter to the planet’s mail service. At the receiving side, the delegate receives the letter from the mail service, takes the letter out of the enve
lo
pe, and takes note of the recipient name written at the top of the letter. The delegate then gives the letter to the family member with this name. No, the mail service does not have to open the enve
lo
pe; it only examines the address on the enve
lo
pe. Source port number y and destination port number x. An appli
cat
ion deve
lo
per may not want its appli
cat
ion to use TCP’s congestion control, which can throttle the appli
cat
ion’s sending rate at times of congestion. Often, designers of IP telephony and IP videoconference appli
cat
ions choose to run their appli
cat
ions over UDP because they want to avoid TCP’s congestion control. Also, some appli
cat
ions do not ne
ed
the reliable data transfer provid
ed
by TCP. Since most firewalls are configur
ed
to b
lo
ck UDP traffic, using TCP for video and voice traffic lets the traffic though the firewalls. Yes. The appli
cat
ion deve
lo
per can put reliable data transfer into the appli
cat
ion layer protocol. This would require a significant amount of work and debugging, however. Yes, both segments will be direct
ed
to the same socket. For each receiv
ed
segment, at the socket interface, the operating system will provide the process with the IP addresses to determine the origins of the individual segments. For each persistent connection, the Web server creates a separate “connection socket”. Each connection socket is identifi
ed
with a four-tuple: (source IP address, source port number, destination IP address, destination port number). When host C receives and IP datagram, it examines these four fields in the datagram/segment to determine to which socket it should pass the pay
lo
ad of the TCP segment. Thus, the requests from A and B pass through different sockets. The identifier for both of these sockets has 80 for the destination port; however, the identifiers for these sockets have different values for source IP addresses. Unlike UDP, when the transport layer passes a TCP segment’s pay
lo
ad to the appli
cat
ion process, it does not specify the source IP address, as this is implicitly specifi
ed
by the socket identifier. Sequence numbers are requir
ed
for a receiver to find out whether an arriving packet contains new data or is a retransmission. To handle
lo
sses in the channel. If the ACK for a transmitt
ed
packet is not receiv
ed
within the duration of the timer for the packet, the packet (or its ACK or NACK) is assum
ed
to have been
lo
st. Hence, the packet is retransmitt
ed
. A timer would still be necessary in the protocol rdt 3.0. If the round trip time is known then the only advantage will be that, the sender knows for sure that either the packet or the ACK (or NACK) for the packet has been
lo
st, as compar
ed
to the real scenario, where the ACK (or NACK) might still be on the way to the sender, after the timer expires. However, to detect the
lo
ss, for each packet, a timer of constant duration will still be necessary at the sender. The packet
lo
ss caus
ed
a time out after which all the five packets were retransmitt
ed
.
Lo
ss of an ACK didn’t trigger any retransmission as Go-Back-N uses cumulative acknowl
ed
gements. The sender was unable to send sixth packet as the send window size is fix
ed
to 5. When the packet was
lo
st, the receiv
ed
four packets were buffer
ed
the receiver. After the timeout, sender retransmitt
ed
the
lo
st packet and receiver deliver
ed
the buffer
ed
packets to appli
cat
ion in correct order. Dupli
cat
e ACK was sent by the receiver for the
lo
st ACK. The sender was unable to send sixth packet as the send win
RxLib控件包内含RxGIF,全部源码及DEMO
RX Library 2.75 with Delphi 2009 support (by FlexGraphics software) ====================================================================== The Set of Native Delphi Components for Borland Delphi versions 1, 2, 3, 4, 5, 6, 7, 2005, 2006, 2009 and Borland C++ Builder 1, 3, 4, 5, 6, 2006 & 2009. 100% Source Code. Last revision date Oct 12, 1999. PLEASE FOL
LO
W THE INSTRUCTIONS PROVID
ED
IN THE INSTALLATION SECTION! TABLE OF CONTENTS ----------------- Latest Changes Overview History License Agreement Installation Demonstration Programs Source Files Using GIF Images Copyright Notes NEW FOR VERSION 2.75 -------------------- Delphi 5.0 & C++Builder 4.0 Compatibility New components: TRx
Lo
ginDia
lo
g New properties, events: TFormPlacement.RegistryRoot TFormPlacement.Version TFontComboBox.UseFonts TRxDBGrid.OnTopLeftChang
ed
TRxDB
Lo
okupCombo.DisplayValues TStrHolder.Macros, TStrHolder.OnExpandMacros RxSpin.TValueType.vtHex New routines, methods, constants: SaveClipboardToStream,
Lo
adClipboardFromStream (clipmon.pas) AppFileName, AppVerInfo (rxverinf.pas) XorString, XorEncode, XorDecode (strutils.pas) BUG FIXES. Overview -------- This version is the result of
lo
ng unactivity of RX Library authors and some imperfections and bugs of other RX adaptations to Delphi 6. The authors of this version disclaim all warranties as to this software, whether express or impli
ed
, including without limitation any impli
ed
warranties of merchantability or fitness for a particular purpose. Use under your own responsibility, but comments (even critique) in English (or in Russian) are welcome. RX Library contains a large number of components,
object
s and routines for Borland Delphi with full source code. This library is compatible with Borland Delphi 1, 2, 3, 4, 5, 6 and Borland C++ Builder 1, 3, 4. This collection includes over 60 native Delphi components. RX Library is a freeware product. Feel free to distribute the library as
lo
ng as all files are unmodifi
ed
and kep
雷达技术知识
关于雷达方面的知识! EFFECTIVENESS OF EXTRACTING WATER SURFACE S
LO
PES FROM LIDAR DATA WITHIN THE ACTIVE CHANNEL: SANDY RIVER, OREGON, USA by JOHN THOMAS ENGLISH A THESIS Present
ed
to the Department of Geography and the Graduate School of the University of Oregon in partial fulfillment of the requirements for the degree of Master of Science March 2009 11 "Effectiveness of Extracting Water Surface S
lo
pes from LiDAR Data within the Active Channel: Sandy River, Oregon, USA," a thesis prepar
ed
by John Thomas English in partial fulfillment of the requirements for the Master of Science degree in the Department of Geography. This thesis has been approv
ed
and accept
ed
by: Date Committee in Charge: W. Andrew Marcus, Chair Patricia F. McDowell Accept
ed
by: Dean of the Graduate School © 2009 John Thomas English 111 IV An Abstract of the Thesis of John Thomas English in the Department of Geography for the degree of to be taken Master of Science March 2009 Title: EFFECTIVENESS OF EXTRACTING WATER SURFACE S
LO
PES FROM LIDAR DATA WITHIN THE ACTIVE CHANNEL: SANDY RIVER, OREGON, USA Approv
ed
: _ W. Andrew Marcus This paper examines the capability ofLiDAR data to accurately map river water surface s
lo
pes in three reaches of the Sandy River, Oregon, USA. LiDAR data were compar
ed
with field measurements to evaluate accuracies and determine how water surface roughness and point density affect LiDAR measurements. Results show that LiDAR deriv
ed
water surface s
lo
pes were accurate to within 0.0047,0.0025, and 0.0014 s
lo
pe, with adjust
ed
R2 values of 0.35, 0.47, and 0.76 for horizontal intervals of 5, 10, and 20m, respectively. Additionally, results show LiDAR provides greater data density where water surfaces are broken. This study provides conclusive evidence supporting use ofLiDAR to measure water surface s
lo
pes of channels with accuracies similar to field bas
ed
approaches. CURRICULUM VITAE NAME OF AUTHOR: John Thomas English PLACE OF BIRTH: Eugene, Oregon DATE OF BIRTH: January 1st, 1980 GRADUATE AND UNDERGRADUATE SCHOOLS ATTEND
ED
: University of Oregon, Eugene, Oregon Southern Oregon University, Ashland, Oregon DEGREES AWARD
ED
: Master of Science, Geography, March 2009, University of Oregon Bache
lo
r of Science, Geography, 2001, Southern Oregon University AREAS OF
SPECIAL
INTEREST: Fluvial Geomorpho
lo
gy Remote Sensing PROFESSIONAL EXPERIENCE: LiDAR
Database
Coordinator, Oregon Department of Geo
lo
gy & Mineral Industries, June 2008 - present. LiDAR & Remote Sensing
Special
ist, Sky Research Inc., 2003 - 2008 GRANTS, AWARDS AND HONORS: Gamma Theta Upsi
lo
n Geographic Society Member, 2006 Gradutate Teaching Fel
lo
wship, Social Science Instructional Laboratory, 20062007 v VI ACKNOWL
ED
GMENTS I wish to express
special
thanks to Professors W.A. Marcus and Patricia McDowell for their assistance in the preparation of this manuscript. In addition,
special
thanks are due to Mr. Paul Blanton who assist
ed
with field data collection for this project. I also thank the members ofmy family who have been encouraging and supportive during the entirety of my graduate schooling. I wish to thank my parents Thomas and Nancy English for always being proud of me.
Special
thanks to my son Finn for always making me smile. Lastly,
special
thanks to my wife Kathryn for her unwavering support,
lo
ve, and encouragement. D
ed
i
cat
ed
to my mother Bonita Claire English (1950-2004). Vll V111 TABLE OF CONTENTS Chapter Page I. INTRODUCTION 1 II. BACKGROlTND 5 Water Surface S
lo
pe 5 LiDAR Measurements of Active Channel Features 7 III. STUDY AREA 10 IV. METHODS 22 Overview 22 LiDAR Data and Image Acquisition 23 Field Data Acquisition 24 LiDAR Processing 25 Calculation of Water Surface S
lo
pes 27 Evaluating LiDAR S
lo
pe Accuracies and Controls 33 V. RESULTS 35 Comparison of Absolute Elevations from Field and LiDAR Data in Reach 1 35 S
lo
pe Comparisons 41 Surface Roughness Analysis 46 VI. DiSCUSSiON 51 VII. CONCLUSION 57 APPENDIX: ARCGIS VBA SCRIPT CODE 58 REFERENCES 106 IX LIST OF FIGURES Figure Page 1. Return Factor vs. LiDAR Scan Angle 2 2. Angle of Incidence 3 3. Wave Action Relationship to LiDAR Echo 3 4. Site Map 11 5. Annual Hydrograph of Sandy River 13 6. Oregon GAP Vegetation within Study Area 15 7. Photo of Himalayan Blackberry on Sandy River 16 8. Reach 1 Site Area Map with photo 18 9. Reach 2 Site Area Map 20 10. Reach 3 Site Area Map 21 11. LiDAR Point Filtering Processing Step 26 12. Field DEM Interpolat
ed
using Kriging 29 13. Reach 1 LiDAR Cross Sections and Sample Point
Lo
cat
ion 31 14. Differences Between LiDAR and Field Bas
ed
Elevations 37 15. Regression ofLiDAR and Field Cross section Elevations 38 16. Comparison of LiDAR and Field
Lo
ngitudinal Profiles (5, 10,20 meters) 40 17. Regression ofField and LiDAR Bas
ed
S
lo
pes (5, 10,20 meters) 42 18. Differences Between LiDAR and Field Bas
ed
S
lo
pes (5, 10,20 meters) 44 19. Relationship of Water Surfaces to LiDAR Point Density 47 20. Marmot Dam: Orthophotographyand Co
lo
riz
ed
S
lo
pe Model 50 21. LiDAR Point Density versus Interpolation 53 LIST OF TABLES T~k p~ 1. Report
ed
Accuracies of 2006 and 2007 LiDAR 24 2. Results of LiDAR and Field Elevation Comparison 38 3. Results ofLiDAR and Field S
lo
pe Comparison (5, 10,20 meters) 45 4. Results of Reach 1 S
lo
pe Comparison 46 5. Water Surface Roughness Results for Reach 1,2, and 3 48 6. Results of Reach 1 Water Surface Roughness Comparison 49 7. Subset of Reach 3 Water Surface Roughness Analysis Near Marmot Dam 50 x 1 CHAPTER I INTRODUCTION LiDAR (Light Detection and Ranging) has become a common tool for mapping and documenting f
lo
odplain environments by supplying individual point elevations and accurate Digital Terrain Models (DTM) (Bowen & Waltermire, 2002; Gilvear et aI., 2004; Glenn et aI., 2005; Magid et aI., 2005; Thoma, 2005; Smith et aI., 2006; Gangodagamage et aI., 2007). Active channel characteristics that have been extract
ed
using LiDAR include bank profiles,
lo
ngitudinal profiles (Magid et aI., 2005; Cavalli et aI., 2007) and transverse profiles of gullies under forest canopies (James et aI., 2007). To date, however, no one has test
ed
if LiDAR returns from water surfaces can be us
ed
to measure
lo
cal water surface s
lo
pes within the active channel. Much of the reason that researchers have not attempt
ed
to measure water surface s
lo
pes with LiDAR is because most LiDAR pulses are absorb
ed
or not return
ed
from the water surface. However, where the angle of incidence is c
lo
se to nadir (i.e. the LiDAR pulse is fir
ed
near perpendicular to water surface plane), light is reflect
ed
and provides elevations off the water surface (Figure 1, Mas
lo
v et aI., 2000). Where LiDAR pulses glance the water surface at angles of incidence greater than 53 degrees, a LiDAR pulse is 2 more often
lo
st to refraction (Figure 2) (Jenkins, 1957). In broken water surface conditions the water surface plane is angl
ed
, which produces perpendicular angles of incidence al
lo
wing for greater chance of return (Mas
lo
v et al. 2000). Su et al. (2007) document
ed
this concept by examining LiDAR returns off disturb
ed
surfaces in a controll
ed
lab setting (Figure 3). LiDAR returns off the water surface potentially provide accurate surface elevations that can be us
ed
to calculate surface s
lo
pes. 1.0 08 ~ 0.6 o t5 ~ E .2 ~ 04 02 00 000 __d=2° d=10 ° --d=200 --d=300 d=40o d=50o I I 2000 4000 60.00 sensing angle, degree I 8000 Figure 1. Return Factor vs. LiDAR Scan Angle. Figure shows relationship between water surface return and scan angle. Return Factor versus sensing angle at different levels of the waving d (d = scan angle). Figure shows the relationship of scan angle of LiDAR to return from a water surface. Return factor is greatest at
lo
w scan angles relative to the nadir region of scan. (Mas
lo
v, D. V. et. al. (2000). A Shore-bas
ed
LiDAR for Coastal Seawater Monitoring. Proce
ed
ings ofEARSeL-SIGWorkshop, Figure 1, pg. 47). 3 reflect
ed
\\ :.;/ incident 1 I 1 . '\ I lAIR \ •••••••• ••••••••••••• •••••• ••••••••••••••••••••• • •• eo ••••••••••• o •••••••••••• _0 •••••••••• 0 ••• .•.•.•.•.•.•00 ,••••• ' 0•••• 0 ••••••••••• 0 ••I' .•.•.•.•.•.,................. .".0 ••••••••••••• , •••••••••••• , ••••••••••0••••. .....................................~ . ••••••••••••••••••••••••••••••••••••• • •••••••••••••••••••••••••• 0 •••••••••••••••••••• 0 ••••• 0 •• ~~~)}))}))})))))))))\..)}))?()))))))))))))))))j((~j< Figure 2. Angle of Incidence. Figure displays concept of reflection and refraction of light according to angle of incidence. The intensity of light is greater as the angle of incidence approaches nadir. (Jenkins, F.A., White, RE. "Fundamentals of Optics". McGraw-Hili, 1957, Chapter 25) 09 08 0.7 0.6 0.5 0.4 0.3 0.2 0.1 r - 0.\ O,j/6Y3- -500 17.5 35 52.5 70 horizonral scanning dislancC(lllm) 0.9 0.8 0.7 06 0.5 0.4 0.3 0.2 0.1 a b Figure 3. Wave Action Relationship to LiDAR Echo. "LiDAR measurements of wake profiles generat
ed
by propeller at 6000 rpm (a) and 8000 rpm (b). Su's work definitively show
ed
LiDAR's ability to measure water surfaces, and the relationship of wave action to capability of echo. From Su (2007) figure 5, p.844 . This study examines whether LiDAR can accurately measure water surface elevations and s
lo
pes. In order to address this topic, I assess the vertical accuracy of LiDAR and the effects of water surface roughness on LiDAR within the active channel. Findings sh
ed
light on the utility of LiDAR for measuring water surface s
lo
pes in different stream environments and methodo
lo
gical constraints to using LiDAR for this purpose. 4 5 CHAPTER II BACKGROlJND Water Surface S
lo
pe Water surface s
lo
pe is a significant component to many equations for modeling hydraulics, s
ed
iment transport, and fluvial geomorphic processes (Knighton, 1999, Sing & Zang, in press). Traditional methods for measuring water surface s
lo
pe include both direct and indirect methods. Direct water surface s
lo
pe measurements typically use a device such as a total station or theodolite in combination with a stadia rod or drop line to measure water surface elevations (Harrelson, et ai., 1994, Western et ai., 1997). Inaccuracies in measurements stem from surface turbulence that makes it difficult to precisely
lo
cat
e the water surface, e
special
ly in fast water where f
lo
ws pile up against the measuring device (Halwas, 2002). Direct survey methods often require a field team to occupy several known points throughout a reach. This is a time consuming process, e
special
ly if one want
ed
to document water surface s
lo
pe a
lo
ng large portions of a river. This method can be dangerous in deep or fast water. 6 Indirect methods of water surface s
lo
pe measurement consist of acquiring approximate water surface elevations using strand lines, water marks, secondary data sources such as contours from topographic maps, or hydraulic modeling to back calculate the water depth (USACE, 1993; Western et aI., 1997). Variable quality of data and modeling errors can lead to inaccuracies using these methods. The use of strand lines and water marks may not necessarily represent the peak f
lo
ws or the water surface. Contours may be calculat
ed
or interpolat
ed
from survey points taken outside the channel area. The most commonly us
ed
hydraulic models are bas
ed
on reconstruction of I-dimensional f
lo
w within the channel and do not account for channel variability between cross section
lo
cat
ions. LiDAR water surface returns have a great deal of promise for improving measurement of water surfaces in several significant ways. LiDAR measurements eliminate hazards associat
ed
with surveyors being in the water. LiDAR also captures an immense amount of elevation data over a very short period of time, with hundr
ed
s of thousands of pulses collect
ed
within a few seconds for a single swath. Within this mass of pulses, hundr
ed
s or thousands of measurements off the water's surface may be collect
ed
depending on the nature of surface roughness, with broken water surfaces increasing the likelihood of measurements (Figure 3). In addition, most terrestrial LiDAR surveys collect data by flying multiple overlapping flight lines, thus increasing the number of returns in off nadir overlapping areas and the potential for returns from water surfaces. 7 The accuracy of high quality LiDAR measurements is comparable to field techniques. The relative variability of quality LiDAR vertical measurements typically ranges between 0.03-0.05 meters (Leica, 2007), where relative variability is the total range of vertical error within an individual scan on surface of consistent elevation. Lastly, LiDAR has the ability to collect water surface elevations over large stretches of river within a single flight of a few hours. LiDAR Measurements of Active Channel Features Recent studies evaluating the utility of LiDAR in the active channel environment have document
ed
the effectiveness of using LiDAR DTMs to extract bank profiles. Magid et al. (2005) examin
ed
lo
ng term changes of
lo
ngitudinal profiles a
lo
ng the Co
lo
rado River in the Grand Canyon. The study us
ed
historical survey data from 1923 and differenc
ed
topographic elevations with LiDAR data f
lo
wn in 2000. LiDAR with three meter spot spacing was us
ed
to estimate water surface profiles bas
ed
on the LiDAR elevations nearest to the known channel. Cavalli et al. (2007) extract
ed
lo
ngitudinal profiles of the expos
ed
b
ed
of the Rio Cordon, Italy using 0.5 meter LiDAR DEM cells. This study successfully attribut
ed
LiDAR DEM roughness within the channel to instream habitats. Bowen and Waltermire (2002) found that LiDAR elevations within the f
lo
odplain were less accurate than advertis
ed
by vendors and sensor manufacturers. Dense vegetation within the riparian area prevent
ed
LiDAR pulses from reaching the 8 ground surface resulting in accuracies ranging 1-2 meters. Accuracies within unvegetat
ed
areas and flat surfaces met vendor specifi
cat
ions (l5-20cm). James et al. (2007) us
ed
LiDAR at 3 meter spot spacing to map transverse profiles of gullies under forest canopies. Results from this study show
ed
that gully morpho
lo
gies were underestimat
ed
by LiDAR data, possibly due to
lo
w density point spacing and bias
ed
filtering of the bare earth model. Today, point densities of 4-8 points/m2 are common and would likely alleviate some of the troubles found in this study. Additional studies have us
ed
LiDAR to extract geomorphic data from channel areas. Schumann et al. (2008) compar
ed
a variety of remotely sens
ed
elevation models for f
lo
odplain mapping. The study us
ed
2 meter LiDAR DEMs as topographic base data for f
lo
odplain modeling, and found that model
ed
f
lo
od stages bas
ed
on the LiDAR DEM were accurate to within 0.35m. Ruesser and Bierman (2007) us
ed
high resolution LiDAR data to calculate erosion fluxes between strath terraces bas
ed
on elevation. Gangodagamage et al. (2007) us
ed
LiDAR to extract river corridor width series, which help to quantify processes involv
ed
in valley formation. This study us
ed
a fix
ed
water surface elevation and did not attempt to demonstrate the accuracy of LiDAR deriv
ed
water surfaces. Green LiDAR also has been us
ed
to examine riverine environments. Green LiDAR functions much like terrestrial LiDAR (which uses an infrar
ed
laser) except that green LiDAR systems use green light that has the ability to penetrate the water surface and measure the elevation of the channel b
ed
. Green LiDAR is far less common than terrestrial LiDAR and the majority of studies have been center
ed
on studies of ocean shorelines. Wang and Philpot (2007) assess
ed
attenuation parameters for measuring bathymetry in near shore shal
lo
w water, concluding that quality bathymetric models can be achiev
ed
through a number of post-processing steps. Hilldale and Raft (2007) assess
ed
the accuracy and precision of bathymetric LiDAR and conclud
ed
that although the resulting models were informative, bathymetric LiDAR was less precise than traditional survey methods. In general, it is often difficult to assess the accuracy of bathymetric LiDAR given issues relat
ed
to access of the channel b
ed
at time of flight. 9 10 CHAPTER III STUDY AREA The study area is the Sandy River, Oregon, which f
lo
ws from the western s
lo
pes ofMount Hood northwest to the Columbia River (Figure 4). Recent LiDAR data and aerial photography capture the variety of water surface characteristics in the Sandy River, which range from shooting f
lo
w to wide pool-riffle formations. The recent removal of the large run-of-river Marmot Dam upstream of the analysis sites has also generat
ed
interest in the river's hydraulics and geomorpho
lo
gy. 11 545000 ,·......,c' 550000 556000 560000 Washington, I 565000 -. Portland Sandy River .Eugene Oregon 570000 ooo '~" ooo ~ ooo~ • Gresham (""IIIII/hill /flIt'r Oregon Clack. fna County Marmot Dam IHillshad
ed
area represents 2006 LiDAR extent. Ol1hophotography was collect
ed
only a
lo
ng the Sandy River channel within the LiDAR extent. 10 KiiomElt:IS t---+---+-~I--+--+----t-+--+---+----jl 545000 550000 555000 560000 565000 570000 Figure 4. Site Map. Site area map showing
lo
cat
ion of analysis reaches within the 2006 and 2007 LiDAR coverage areas. Olihophotography was also collect
ed
for the 2006 study, but was collect
ed
only a
lo
ng the Sandy River channel. 12 F
lo
odplain
lo
ngitudinal s
lo
pes a
lo
ng the Sandy River average 0.02 and reach a maximum of 0.04. The Sandy River has c
lo
sely spac
ed
pool-riffles and rapids in the upper reaches, transitioning to
lo
nger sequenc
ed
pool-riffle morpho
lo
gy in the middle and
lo
wer reaches. The Sandy River b
ed
is dominat
ed
by sand. Cobbles and small boulders are present mostly in areas of riffles and rapids. Much of the channel is incis
ed
with steep s
lo
pes a
lo
ng the channel boundaries. The f
lo
w regime is typical of Pacific Northwest streams, with peak f
lo
ws in the winter months ofNovember through February and in late spring with snowmelt runoff (Figure 5).
Lo
w f
lo
ws occur between late September and early October. The average peak annual f
lo
w at the Sandy River station be
lo
w Bull Run River (USGS 14142500) is 106cms. Average annual
lo
w f
lo
w for the same gauge is 13.9cms. 13 USGS 14142500 SRNDY RIVER BL~ BULL RUN RIVER, NR BULL RUN, OR 200 k.===_~~~=~~~=.......==",,=~-........==~ ~....J Jan 01Feb Ollar 01Rpr O:t1ay 01Jun 01Jul 01Rug OJSep 010ct 01Nov O:IJec 01 2006 2006 2006 2006 2006 2006 2006 2006 2006 2006 2006 2006 \ 11 ~I\\ ,1\ 1\ j\ 1"J'fn I\. I, ) \ , ,;' ) I I" 'I'•., I I' I' ] 30000 ~~-~----~-------------~-------, o ~ 20000 ~ 8'-. 10000 ~ Ql Ql ~ U '001 ~ ::::J U, Ql to 1000 to .= u Co? '001 Cl )- .....J. a: Cl H
ed
ian daily statistic <59 years) Daily nean discharge --- Estinat
ed
daily nean discharge Period of approv
ed
data Period of provisional data Figure 5, Annual Hydrograph of Sandy River. US Geo
lo
gical Survey gaging station annual hydrograph of Sandy River, Oregon at Bull Run River. Data from http://waterdata.usgs.gov/or/nwis/annual/ Vegetation is mostly a mixture of Douglas fir and western r
ed
hem
lo
ck (Figure 6). Other vegetation includes palustrine forest found in the upper portions of the study area, and agricultural lands found in the middle and
lo
wer portions. Douglas fir and western r
ed
hem
lo
ck make up 87% of vegetat
ed
areas, palustrine forest 5%, and agricultural lands 5%, the remaining 3% is open water associat
ed
with the channel and reservoirs (Oregon GAP Analysis Program, 2002). The city of Troutdale, OR abuts the
lo
wer reaches of the Sandy River. A
lo
ng this stretch of river Himalayan blackberry, an invasive species, dominates the western banks (Figure 7). The presence of Himalayan blackberry is significant because LiDAR has trouble penetrating through the dense clusters of vines. When this blackberry is c
lo
se to the water's
ed
ge it is difficult to accurately define the channel boundary. 14 15 545000 550000 555000 560000 565000 570000 Reach 3 10 !'
lock-W. R
ed
C
ed
ar Forest Grass-shrub-saplillg/Regeneratillg Forest Mix
ed
Conifer/Mix
ed
Deciduous Forest Open Water Palustrine Forest R
ed
Alder-Big Leaf Maple Forest Urban oo o o~ 545000 550000 555000 560000 565000 570000 Figure 6. Oregon GAP Vegetation within Study Area. 1999 Oregon GAP Analysis data for Sandy River area. Map shows how the Sandy River area is dominat
ed
by Douglas fir forest with areas of palustrine forest and agricultural lands (Oregon Natural Heritage Program, 1999). 16 Figure 7. Photo of Himalayan Blackberry on Sandy River. Himalayan blackberry near mouth of the Sandy River March, 25th 2007. Photo by John English. This study focuses on three reaches of channel that represent a range of water surface conditions a
lo
ng the river. Reach 1 is a I80-m
lo
ng pool-riffle reach
lo
cat
ed
3.7 river ki
lo
meters upstream from the mouth, and is where we collect
ed
field data shortly after the 2007 LiDAR flight (Figure 8a). The b
ed
is sandy in this reach and can change dramatically during high f
lo
ws. The bank full width of Reach 1 is approximately 108 meters at its widest point. At the downstream end of the riffle, the channel is constrict
ed
17 by riprap plac
ed
a
lo
ng the banks as the river f
lo
ws under a bridge. Vegetation comprises deciduous and conifer trees such as Douglas fir, hem
lo
ck, and cottonwoods. Blackberry is present a
lo
ng the channel, but is not so dense that it obscures the active channel boundary. 18 b. Figure 8. Reach 1 Site Area Map with Photo. Reach 1 site area. Top figure (a) shows approximate width at bank full and length of field data collections. Yel
lo
w circles represent points a
lo
ng stream margins where water surface elevations were survey
ed
. Bottom photo (b)
lo
oks downstream from total station
lo
cat
ion. 19 Reach 2 (Figure 9) is
lo
cat
ed
approximately 23.5 kIn upstream from the mouth of the Sandy River and is 1,815 meters in length. The widest portion of channel at approximate bank full is 116m. The channel consists of a large meander with sinuosity of 1.38 and consists of six riffles and five pools spac
ed
at regular intervals. The substrate consists of sands with small boulders and large cobbles dominating riffle areas. Cobbles and boulders have likely been introduc
ed
to the channel as a result of mass wasting. Douglas fir dominates a
lo
ng banks. 20 oJ> 0° 200 MetersO 0 ~~~~~~I O~~~OOO~ Figure 9. Reach 2 Site Area Map. Site map of Reach 2. Reach 2 contains 359 cross sections deriv
ed
from LiDAR and 3,456 sample points. Inset map shows cross section sample
lo
cat
ions deriv
ed
from LiDAR and smooth/rough water surface delineations us
ed
in analysis. 21 Reach 3 is
lo
cat
ed
40.7km upstream from the mouth of the Sandy and is 2,815 meters in length (Figure 10). The widest portion of this section at approximate banle full is 88 meters. The upstream extent of the channel includes the supercritical f
lo
w of Marmot Dam. The channel is incis
ed
and relatively straight with a sinuosity of 1.08. Fine sands dominate the channel b
ed
with some boulders likely present from mass wasting a
lo
ng valley walls. As with Reach 2, Douglas fir dominates bank vegetation a
lo
ng. 200 40) Inset mAp displays UDAR point I densily a
lo
l1g willl cross seel
lo
n Sanlpleing dala LiDAR cross section SAmple
lo
cat
ions were us
ed
to eX1mcl poinl density values. 503 fOC I 000 '.1..Hrs 1-.,...--,.-+--=1..,=-,---4I--+-1---11 . Reach 3 Figure 10. Reach 3 Site Area Map. Site map of Reach 3. Inset map shows point LiDAR water surface points. Reach 3 contains 550 cross sections and 3,348 sample points. Visual examination of this map al
lo
ws one to see how point density varies within the active channel. 22 CHAPTER IV METHODS Overview LiDAR data and orthophotography were collect
ed
in 2006 and additional LiDAR data were collect
ed
over the same area in 2007. Field measurements were obtain
ed
five days after the 2007 LiDAR flight in order to compare field measurements of water surface s
lo
pe to LiDAR-bas
ed
measurements. Time of flight field measurements of water surface elevations were not obtain
ed
for the 2006 flight, but the coincident collection of LiDAR data and orthophotos provide a basis for evaluating variability of LiDAR-bas
ed
s
lo
pes over different channel types as identifi
ed
from aerial photos. Fol
lo
wing sections provide more detail regarding these methods. 23 LiDAR Data and Image Acquisition All LiDAR data were collect
ed
using a Leica ALS50 Phase II LiDAR system mount
ed
on a Cessna Caravan C208 (see Table 1 for LiDAR acquisition specifi
cat
ions). The 2006 LiDAR data were collect
ed
October 2211d and encompass
ed
13,780 hectares of high resolution (2':4 points/m2 ) LiDAR data from the mouth of the Sandy River to Marmot Dam. Fifteen centimeter ground resolution orthophotography was collect
ed
September 26th , 2006 a
lo
ng the riparian corridor of the Sandy River from its mouth to just above the former site ofMarmot dam (Figure 4). The 2007 LiDAR were collect
ed
on October 8th and cover
ed
the same extent as the 2006 flight, but did not include orthophotography. Data includ
ed
filter
ed
XYZ ASCII point data, LiDAR DEMs as ESRI formatt
ed
grids at 0.5 meter cell size. Data were collect
ed
at 2':8 points per m2 providing a data set with significantly higher point density than the 2006 LiDAR data. The 2006 LiDAR data were collect
ed
in one continuous flight. 2006 orthophotography was collect
ed
using an RC30 camera system. Data were deliver
ed
in RGB geoTIFF format. LiDAR data were calibrat
ed
by the contractor to correct for IMU position errors (pitch, roll, heading, and mirror scale). Quality control points were collect
ed
a
lo
ng roads and other permanent flat features for absolute vertical correction of data. Horizontal accuracy ofLiDAR data is govern
ed
by flying height above ground with horizontal accuracy being equal to 1I3300th of flight altitude (meters) (Leica, 2007). 24 Table 1. Report
ed
Accuracies of 2006 and 2007 LiDAR. Report
ed
Accuracies and conditions for 2006 and 2007 LiDAR data. (Watersh
ed
Sciences PGE LiDAR Delivery Report, 2006, Watersh
ed
Sciences DOGAMI LiDAR Delivery Report, 2007). Relative Accuracy is a measure of flight line offsets resulting from sensor calibration. 2006 LiDAR 2007 LiDAR Flying height above ground level meters (AGL) 1100 1000 Absolute Vertical Accuracy in meters 0.063 0.034 Relative Accuracy in meters (calibration) 0.058 0.054 Horizontal Accuracy (l/3300th * AGL) meters 0.37 0.33 Discharge @ time of flight (cms) 13.05 20.8 - 21.8 LiDAR data collection over the Reach 1 field survey
lo
cat
ion was obtain
ed
in a single flight on October 8, 2007 between 1:30 and 6:00 pm. During the LiDAR flight, ground quality control data were collect
ed
a
lo
ng roads and other permanent flat surfaces within the collection area. These data were us
ed
to adjust for absolute vertical accuracy. Field Data Acquisition A river survey crew was dispatch
ed
at the soonest possible date (October 13, 2007) after the 2007 flight to collect ground truth data within the Reach 1. The initial aim was to survey water surface elevations at cross sections of the channel, but the survey was limit
ed
to near shore measurements due to high ve
lo
city conditions. We collect
ed
187 measurements of b
ed
elevation and depth one to fifteen meters from banks a
lo
ng both sides of the channel (Figure 8a) using standard total station
lo
ngitudinal profile 25 survey methods (Harrelson, 1994). Seventy-six and 98 measurements were collect
ed
a
lo
ng the east and west banks, respectively, at intervals of approximately 1 to 2 meters. Thirteen additional measurements were collect
ed
a
lo
ng the east bank at approximately ten meter intervals. Depth measurements were add
ed
to b
ed
elevations to derive water surface elevations. Discharge during the survey rang
ed
between 22.5 and 22.7 cms during the survey of the east bank and remain
ed
steady at 22.5 cms during the survey of the west bank (USGS station 14142500). LiDAR Processing The goal ofLiDAR processing for this project was to classify LiDAR point data within the active channel as water and output this subset data for further analysis. The LiDAR imagery was first clipp
ed
to the active channel using a boundary digitiz
ed
from the 2006 high resolution orthophotography. LiDAR point data were then reclassifi
ed
to remove bars, banks, and overhanging vegetation (Figure 11). 26 Figure 11. LiDAR Point Filtering Processing Step. LiDAR processing steps. Top image shows entire LiDAR point c
lo
ud clipp
ed
to active channel boundary.
Lo
wer image shows the final process
ed
LiDAR points representing only those points that reflect off the water surface. All bars and overhanging vegetation have been remov
ed
as well. 27 Water points were classifi
ed
using the ground classifi
cat
ion algorithm in Terrascan© (Soininen, 2005) to separate water surface returns from those off of vegetation or other surfaces elevat
ed
above the ground. The classifi
cat
ion routine uses a proprietary mathematical model to accomplish this task. Once the ground classifi
cat
ion was finish
ed
, classifi
ed
points were visually inspect
ed
to add or remove false positives and remove in-channel features such as bar islands. A total of 11,593 of 1,854,219 LiDAR points were classifi
ed
as water. Points classifi
ed
as water were output as comma delimit
ed
x,y,z ASCII text files (XYZ), then convert
ed
to a 0.5 meter linearly interpolat
ed
ESRI formatt
ed
grid using ESRI geoprocessing model script. Calculation of Water Surface S
lo
pes Water surface s
lo
pes were calculat
ed
using the rise over run dimensionless s
lo
pe equation where the rise is the vertical difference between upstream and downstream water surface elevations and run is the
lo
ngitudinal distance between elevation
lo
cat
ions. LiDAR data is typically us
ed
in grid format. For this reason grid data were us
ed
for calculation of water surface s
lo
pes. We us
ed
linear interpolation to grid the LiDAR point data as this is the standard method us
ed
by the LiDAR contractor. In order to compare the LiDAR and field data it was also necessary to interpolate field 28 measurements to create a water surface for the entire stream. The field data-bas
ed
DEM was creat
ed
using kriging interpolation within ArcGIS Desktop Spatial Analyst (Figure 12). No quantitative analysis was perform
ed
to evaluate the interpolation method of the field-bas
ed
water surface. The kriging interpolation was chosen because it producex the smoothest water surface bas
ed
on visual inspection when compar
ed
to linear and natural neighbor interpolations, which generat
ed
irregular fluctuations that were unrealistic for a water surface. The krig
ed
surface provid
ed
a water surface elevation model for comparative analysis with LiDAR. 29 Figure 12. Field DEM Interpolat
ed
using Kriging. Field DEM interpolat
ed
from field survey points using kriging method found in ArcGIS Spatial Analyst. DEM has been hiIlshad
ed
to show surface characteristics. The very small differences in water surface elevations generate only slight variations in the hillshadeing. To compare LiDAR and field-bas
ed
water surface s
lo
pes, water surface elevations from the LiDAR and field-bas
ed
DEMS were extract
ed
at the same
lo
cat
ions a
lo
ng Reach I. To accomplish this, 37 cross sections were manually construct
ed
at approximately Sm spacings (Figure 13). Cross sections comparisons were us
ed
rather than point-to-point comparisons between streamside field and LiDAR data points because the cross sections provide water surface s
lo
pes that are more representative of the entire channel. The Sm interval spacing was consider
ed
to be a sufficient for fine resolution s
lo
pe extraction. Because cross section center points were us
ed
to calculate the
lo
ngitudinal distance and because the stream was sinuous, the projection of the cross sections from the center line to the banks l
ed
to stream side distances between cross sections that differ
ed
from Sm. 30 31 Smooth 125 Meters I 100 I 75 I 50 I 25 I Cross Sections Cross Section Data Roughness Delineation Cross Section Sample
Lo
cat
ions _ Rough oI ~ each 1 Figure 13. Reach 1 LiDAR Cross Sections and Sample Point
Lo
cat
ions. Reach I LiDAR-deriv
ed
cross section sample
lo
cat
ions and areas of smooth and rough water surface delineations. 37 cross section and 444 sample points lie within Reach 1. 32 Cross sections were extract
ed
using a custom Arc
Object
s VBA script (Appendix A). This script extract
ed
1 cell nearest neighbor elevations a
lo
ng the transverse cross sections at 5 meter intervals creating 444 cross section sample
lo
cat
ions (Figure 13). Cross section averages were calculat
ed
using field-bas
ed
and LiDAR-bas
ed
elevation water surface grids. The average cross sectional elevation value for field and LiDAR data were then export
ed
to Excel files, merg
ed
with
lo
ngitudinal distance between cross section, and us
ed
to calculate field survey-bas
ed
and LiDAR-bas
ed
s
lo
pes between cross sections. Reaches 2 and 3, for which only LiDAR data were available, were sampl
ed
using the same cross sectional approach us
ed
in Reach 1. The data extract
ed
from these reaches were us
ed
to characterize how LiDAR-bas
ed
elevations, s
lo
pes and point densities interact with varying water surface roughness. Within Reach 2, 359 cross sections were drawn and elevations were sampl
ed
every five meters a
lo
ng each cross section creating 3,456 cross section sample
lo
cat
ions (Figure 9). Reach 3 contain
ed
550 cross sections and 3,348 cross section sample
lo
cat
ions (Figure 10). S
lo
pes were calculat
ed
between each cross section. 33 Evaluating LiDAR S
lo
pe Accuracies and Controls The accuracy of elevation data is the major control on s
lo
pe accuracy, so a comparative analysis was perform
ed
using field survey and LiDAR elevations. First, field-bas
ed
and LiDAR s
lo
pes were calculat
ed
at distance intervals of five, ten and twenty meters using average cross section elevations to test the sensitivity of the s
lo
pes to vertical inaccuracies in the LiDAR data. The field and LiDAR elevations were differenc
ed
using the same points us
ed
to create average cross section elevations. Differences were p
lo
tt
ed
in the form of histogram and cumulative frequency p
lo
t after transforming them into absolute values. Descriptive statistics were calculat
ed
to examine the range, minimum, maximum, and mean offset between data sets. Finally LiDAR and field-bas
ed
values were compar
ed
using regression analysis. This study also examin
ed
the effects of water surface roughness on LiDAR elevation measurements, LiDAR point density, and LiDAR deriv
ed
water surface s
lo
pes. Each reach was divid
ed
into smooth and rough sections bas
ed
on visual analysis of the orthophoto data. One-meter resolution s
lo
pe rasters were creat
ed
from the LiDAR water surface grids using ArcGIS Spatial Analyst. One meter resolution point density grids were creat
ed
from LiDAR point data (ArcGIS Spatial Analyst). Using the cross section sample points, values for water surface type, elevation, s
lo
pe, and point density were extract
ed
within each reach. Point sample data were transferr
ed
to tabular format, and average values were generat
ed
for each cross section. These tables were us
ed
to calculate 34 descriptive statistics associat
ed
with water surfaces such as elevation variance, average s
lo
pe variance, average point density, and average s
lo
pe. It is assum
ed
in this study that smooth water surfaces are associat
ed
with pools and thus ought to have relatively
lo
w s
lo
pes. Conversely rough water surfaces are assum
ed
to be representative of riffles and rapids, and thus ought to have relatively steeper s
lo
pes. Reach 1 contains field data, so s
lo
pes from LiDAR and field data were compar
ed
with respect to water surface conditions as determin
ed
from the aerial photos. 35 CHAPTER V RESULTS Results of this study encompass three analyses. Elevation analysis describes the statistical difference between LiDAR and field-bas
ed
water surface elevations for Reach 1. S
lo
pe analysis compares LiDAR deriv
ed
and field-bas
ed
s
lo
pes calculat
ed
at 5, 10, and 20m
lo
ngitudinal distances. These analyses aim to quantify both s
lo
pe accuracy and s
lo
pe sensitivity. Lastly, water surface analysis examines the relationship between LiDAR measur
ed
water surface s
lo
pes, point density, and water surface roughness. Comparison of Absolute Elevations from Field and LiDAR Data in Reach 1 The difference between water surface elevations from LiDAR affects the numerator within the rise over run equation, which in tum affects s
lo
pe. This elevation analysis evaluation quantifies differences between field and LiDAR data. LiDAR-bas
ed
cross section elevations were differenc
ed
from field-bas
ed
cross section elevations. Difference values were examin
ed
through statistical analysis. 36 In terms of absolute elevations relative to sea level, the majority of LiDAR-bas
ed
water surface elevations were
lo
wer than field-bas
ed
elevations, although the LiDAR elevations were higher in the upper portion ofReach 1. Differences rang
ed
between -0.04 and 0.05m with a mean absolute difference between field and LiDAR elevations of 0.02m (Figure 14 and Table 2). The range of differences is within the expect
ed
relative accuracies of LiDAR claim
ed
by the LiDAR provider. Elevations for field and LiDAR data are significantly correlat
ed
with an R2 of 0.94 (Figure 15). The negative offset was expect
ed
given that discharge at time of LiDAR acquisition was
lo
wer than discharge at time of field data acquisition. Discharge during field acquisition rang
ed
between 22.5 and 22.7 cfs, while discharge during LiDAR acquisition was between 20.8 and 21.8cfs. The portion of Reach 1 where LiDAR water surface measurements were higher than field measurements may be relat
ed
to difference in discharge or change in b
ed
configuration. Overall results show
ed
that LiDAR data and field-bas
ed
water surface measurements are comparable. 37 Distribution of Elevation Differences Between Field and LiDAR Water Surfaces 10 9 8 7 >. 6 u r:: ell 5 :l C'" ~ 4 u.. 3 2 0+---+ -0.05 -0.04 -0.03 -0.02 -0.01 0 0.01 0.02 0.03 0.04 0.05 More Elevation Difference, Field - L1DAR (m) Figure 14. Differences Between LiDAR and Field Bas
ed
Elevations. Elevation difference statistics between cross sections deriv
ed
from field and LiDAR elevation data. Positive differences indi
cat
e that field-bas
ed
elevations were higher than LiDAR; negative differences indi
cat
e LiDAR elevations were higher. Values on x axis represent minimum difference within range. For example, the 0.01
cat
egory includes values ranging from 0.01 to 0.0199. y-1.18x-1.03 .... R2 =0.94 ""..,; I •• ./... ./ .- ./ • ./ • ./. /""I ./iI ../. _._~. -? , 38 Table 2. Results of LiDAR and Field Elevation Comparison. Descriptive and regression statistics for absolute difference lField - LiDARI values between cross section elevations. All units in meters. Sample size is 37. Mean 0.028 M
ed
ian 0.030 Standard Deviation 0.013 Kurtosis -0.640 Skewness -0.484 Range of difference 0.093 Minimum difference 0.002 Absolute maximum difference 0.047 Confidence Level(95.0%) (m) 0.004 Elevation Comparison of Field and LiDAR Water Surface Elevations 5.72 5.70 ~_ 5.68 g 5.66 :0:; I1l 5.64 > iii 5.62 ell 5.60 () ~ 5.58 ~ 5.56 ~ 5.54 1\1 5.52 ~ IX 5.50
ed (x) and LiDAR-bas
ed
(y) cross section elevations. 39 Comparison of
lo
ngitudinal profiles offield and LiDAR water surfaces shows a clear relationship in overall shape (Figure 16), capturing similar trends in
lo
ngitudinal profiles. Figure 16 shows field and LiDAR profiles become more similar in shape as distance between cross sections increases. In terms of overall shape, the greatest differences occur in the upper 30 m, where LiDAR-bas
ed
profiles demonstrate a higher s
lo
pe than do field-bas
ed
measurements. Because of the five day lag between LiDAR and field measurements in this mobile b
ed
stream, it is impossible to know the degree to which this difference represents error in measurements or real change in the system. 40 5 meter
Lo
ngitudinal Profile Comparison 20 40 60 80 100 120 140 160 180 5.75 .s 5.70 ~" _ • •• • :. 5
Longitudinal Distance Down Stream (m) A 10 meter
Lo
ngitudinal Profile Comparison 5.75 5.70 . • [,.10 rreler Field Profile! I: I 5.65 • • , . • • • 10 rreter LiDAR Profile • • • I:: 5.60 • • 0 :;:; • • >Cll 5.55 • • ~ • • w 5.50 • • • • • • • • • 5.45 5.40 0 20 40 60 80 100 120 140 160 180
Lo
ngitudinal Distance Down Stream (m) B 20 meter
Lo
ngitudinal Profile Comparison 5.75 5.70 • ,. 20
Cll 5.55 •• Q) W 5.50 •• • , 5.45 . 5.40 0 20 40 60 80 100 120 140 160 180
Lo
ngitudinal Distance Down Stream (m) C Figure 16. Comparison of LiDAR and Field
Lo
ngitudinal Profiles (5, 10, 20 meters).
Lo
ngitudinal profiles of a) 5 meter, b) 10 meter, and c) 20 meter cross section elevations. 41 S
lo
pe Comparisons S
lo
pe in this study is calculat
ed
as the dimensionless ratio of rise over run. As not
ed
in the Methods section, s
lo
pes were calculat
ed
over three different horizontal intervals to test the sensitivity of the LiDAR's internal relative accuracy. Differences in Sm LiDAR and field-bas
ed
s
lo
pes deriv
ed
from cross sections reveal substantial s
cat
ter (Figure l7a), although they clearly covary. Ten meter interval s
lo
pes show a stronger relationship (Figure 17b), while s
lo
pes bas
ed
on cross sections spac
ed
20 m apart have the strongest relationship (Figure l7c). The s
lo
pe associat
ed
with regression of field and LiDAR elevation data is not approximately 1 as one might expect. This is because LiDAR elevations are higher than field elevations at the upstream end of the reach, and
lo
wer at the downstream end. 42 5m S
lo
pe Comparison -c: ~ -0:: Q) (/l ~ ~.01 Q) C. .2 en 0:: « 0 ::i A -c: ~ 0:: --Q) (/l i2 -0.01 Q) C. 0 en 0:: « 0 ::i B 0.004 = 0.58x - 0.001 R2 = 0.38 ~.008 -0.008 Field S
lo
pe (Rise/Run) 10 meter S
lo
pe Comparison 0.004 y = 0.63x - 0.001 R2 = 0.51 -0.008 -0.008 Field S
lo
pe (Rise/Run) 20 meter S
lo
pe Comparison • 0.004 0.002 0.004 C :::l -0:: Q) (/l i2 ~.01 -Q) c. o Ci5 0:: « o~ 0.004 =0.66x - 0.001 R2 = 0.80 ~.008 ~.006 -0.008 Field S
lo
pe (Rise/Run) 0.002 0.004 C Figure 17. Regression of Field and LiDAR Bas
ed
S
lo
pes (5,10,20 meters). S
cat
ter p
lo
ts showing comparisons between s
lo
pe values calculat
ed
at distance intervals of a) 5 meters, b) 10 meters, and c) 20 meters. 43 Figure 18 shows how the range of differences between LiDAR and field-bas
ed
water surface s
lo
pes decrease as
lo
ngitudinal distance increases. Five meter s
lo
pe differences rang
ed
between -0.004 and 0.004 (Figure 18a). Ten meter s
lo
pe differences rang
ed
between -0.002 and 0.003 (Figure 18b). Twenty meter s
lo
pe differences rang
ed
between 0 and 0.002 (Figure 18c). 44 Differences of S
lo
pe at 5m Between Field and LiDAR 10 » 8 0c Ql 6 :J 0" 4 .Q..l u. 2 0 SIll>< SIl"> SIll\- ~<::J <;:><::J <;:><::J SIl" ~ SIl" SIll\- SIl"> SIll>< ~/l, r;:,<::J ~'::; ~'::; ~'::; ~'::; ~o S
lo
pe Difference (Field-LiDAR) A Differences of S
lo
pe at 10m Between Field and L1DAR 7 6 ~ 5 lii 4 :J 0" 3 ~ u. 2 1 o +---+--~--;..J SIll>< ~<::J S
lo
pe Difference (Field-LiDAR) B Differences of S
lo
pe at 20m Between Field and LiDAR 4 ~~I\- ~~" ~ ~~" ~~I\- ~~"> ~~I>< o"/l, <;:>.~. ~.~.~.~. ~ S
lo
pe Difference (Field-LiDAR) o +---+--+--+--t- SIll>< SIl"> <;:><::J <;:><::J ~ 3 c Ql :J 2 0" ~ U. C Figure 18. Differences Between LiDAR and Field Bas
ed
S
lo
pes (5, 10,20 meters). Histogram charts showing difference values between field and LiDAR deriv
ed
s
lo
pes at a) 5 meter s
lo
pe distances, b) 10 meter s
lo
pe distances, and c) 20 meter s
lo
pe distances. 45 The mean difference between s
lo
pes decreases from 0.0017 to 0.0007 as s
lo
pe distance interval is increas
ed
. Maximum s
lo
pe difference and standard deviation of offsets decrease from 0.001 to 0.0005 and 0.0047 to 0.0014 respectively. Regression analysis of these data show a significant relationship for all three comparisons, and adjust
ed
R2 increas
ed
from 0.357 to 0.763 with s
lo
pe distance interval (Table 3). Table 3. Results of LiDAR and Field S
lo
pe Comparison (5, 10,20 meters). Descriptive and regression statistics for offsets between field and LiDAR deriv
ed
s
lo
pe values (Field minus LiDAR). S
lo
pe values are dimensionless rise / run. All data is significant at 0.01. Distance Interval 5m 10m 20m Mean 0.0017 0.0012 0.0007 Standard Deviation 0.0010 0.0007 0.0005 Range of Difference 0.0080 0.0047 0.0024 Minimum difference 0.0000 0.0000 0.0001 Maximum difference 0.0047 0.0026 0.0015 Count 36 16 8 Adjust
ed
R squar
ed
0.36 0.47 0.76 Water surface s
lo
pe for the entire length of Reach 1 (l59.32m) was compar
ed
and yield
ed
a difference of 0.0005. This difference is smaller (by 0.0002) than the difference between 20 meter s
lo
pe (Table 4). S
lo
pe was calculat
ed
by differencing the most upstream and downstream cross sections and dividing by total length of reach. Differences between LiDAR and field-bas
ed
s
lo
pes may represent real change due to the five day lag between data sets and difference in discharge. 46 Table 4. Results of Reach 1 S
lo
pe Comparison. Comparison of s
lo
pes calculat
ed
using the farthest upstream and downstream cross section elevation values. S
lo
pe values have dimensionless units stemming from rise over run. Upper
Lo
wer Reach Elevation (m) Elevation (m) Len2th (m) S
lo
pe Field 5.652 5.491 159.32 -0.0010 LiDAR 5.697 5.455 159.32 -0.0015 Surface Roughness Analysis Water surface condition was characteriz
ed
as smooth or rough bas
ed
on 2006 aerial photography (Figure 19). Surface roughness was examin
ed
to understand its effect on LiDAR data within the active channel, as well as LiDAR's ability to potentially capture difference in water surface turbulence. Table 5 shows statistics with relation to water surface condition for all three reaches. 47 Figure 19. Relationship of Water Surfaces to LiDAR Point Density. 2006 aerial photos were us
ed
to delineate rough and smooth water surfaces. Image on left shows a transition between rough water surface (seen as white water) and smooth water surface (seen as upstream pool). Image on right shows LiDAR point density in points per square meter. In all reaches point density, variance of elevations, and water surface s
lo
pes were significantly higher in rough surface conditions. These results indi
cat
e that LiDAR point density is directly relat
ed
to the roughness of a water surface and that is capturing the rough water characteristics one would expect in areas where turbulence generates surface waves. 48 Table 5. Water Surface Roughness Results for Reach 1,2, and 3. Water surface statistical output for rough and smooth water surface of Reaches 1, 2, and 3. Results within table represent average values for each Reach. S
lo
pe values have dimensionless units from rise over run equation deriv
ed
from ESRI generat
ed
s
lo
pe grid. Point density values bas
ed
on points/m2 • Elevation variance in meters. Reach 1 Reach 2 Reach 3 Rou~h water No. of Sample Points 153 1981 1968 Avg S
lo
pe -0.013 -0.011 -0.007 Point Density (pts/mL ) 1.195 1.002 1.217 Elevation Variance (m) 0.003 0.018 0.041 Smooth water No. of Sample Points 290 1474 1378 Avg S
lo
pe 0.0075 -0.0006 -0.0033 Point Density (pts/mL ) 0.149 0.550 0.480 Elevation Variance (m) 0.001 0.0077 0.024 Within Reach 1, cross section elevations were separat
ed
into rough and smooth water conditions and s
lo
pes were calculat
ed
using field and LiDAR data sets (Table 6). Again, results show
ed
that rough water surfaces have greater s
lo
pes than smooth water surfaces. The smooth water surface of Reach 1 yield
ed
a larger discrepancy between field and LiDAR deriv
ed
s
lo
pes compar
ed
to rough water surface. This is because small differences between LiDAR and field elevations generate larger proportional error in the rise / run equation when total elevation differences between upstream and downstream are small. 49 Table 6. Results of Reach 1 Water Surface Roughness Comparison. Reach 1 water surface roughness s
lo
pe analysis. Reach 1 was divid
ed
into smooth and rough water surfaces bas
ed
upon visual characteristics present in aerial photography. S
lo
pes were calculat
ed
for each area and compar
ed
with field data to examine accuracy. Surface Reach Upper
Lo
wer S
lo
pe Type Lenl!th (m) Elevation (m) Elevation (m) S
lo
pe Difference Field Smooth 83.11 5.652 5.642 -0.0001 N/A LiDAR Smooth 83.11 5.697 5.612 -0.0010 0.0009 Field Rough 71.73 5.635 5.491 -0.0020 N/A LiDAR Rough 71.73 5.592 5.455 -0.0019 -0.0001 Prior to collections of the 2007 data, Reach 3 contain
ed
the former Marmot Dam that was dismantl
ed
on October 19th , 2007 (Figure 20). The areas at and directly be
lo
w the dam are rough water surfaces. The super critical f
lo
w at the dam yield
ed
a s
lo
pe of - 0.896 (Table 7). The run be
lo
w the dam contain
ed
lo
w s
lo
pe values of less than -0.002. Both the dam fall and adjacent run yield
ed
high point densities of greater than 2 points per square meter. 50 Cross Sections o Cross Section Sample
Lo
cat
ions L1DAR deriv
ed
S
lo
pe Model Value Higll 178814133 25 50 75 100 125 150 ~.',eters I I I I I I La,·, 0003936 Figure 20. Marmot Dam: Orthophotography and Co
lo
riz
ed
S
lo
pe Model. Mannot Dam at far upstream portion of Reach 3. Image on left shows dam site in 2006 orthophotography. Image on right shows the increase in s
lo
pe associat
ed
with the dam. Marmot Dam was remov
ed
Oct. 19th , 2007. Table 7. Subset of Reach 3 Water Surface Roughness Analysis Near Marmot Dam. Subset of Reach 3 imm
ed
iately surrounding Marmot Dam roughness analysis containing values for Mannot Dam. The roughness results fell within expectations showing increases in s
lo
pe at the dam fall and high point densities at the dam fall and imm
ed
iate down stream run. Habitat Type Avg S
lo
pe Point Density Point Density Variance Dam Fall -0.896 2.284 1.003 Dam Run -0.001 2.085 5.320 51 CHAPTER VI DISCUSSION The elevation analysis portion of this study shows that LiDAR can provide water surface profiles and s
lo
pes that are comparable to field-bas
ed
data. The differences between LiDAR and field bas
ed
measurements can be attribut
ed
to three potential sources. The first is the relative accuracy of the LiDAR data which has been report
ed
between O.05m and O.06m by the vendor. The second source can be associat
ed
with the accuracy of field bas
ed
measurements which are similar to the relative accuracy of the LiDAR (O.03m-O.05m). Lastly, the discharge differ
ed
between field data collection and LiDAR collection by O.02cms. It is possible that much of the O.05m difference observ
ed
through most of the Reach 1 profile (Figure 16) could be attribut
ed
to the difference in discharge and changes in b
ed
configuration, but without further evidence, the degree of difference due to error or real change cannot be identifi
ed
. Even if one attributes all the difference to error in LiDAR measurements, the overall correspondence ofLiDAR and field measurement (Figure 15 and 16) indi
cat
es that LiDAR-bas
ed
surveys are useful for many hydro
lo
gic appli
cat
ions. 52 In the upper portion of the reach, the profiles display LiDAR elevations that are higher than the field data elevations, whereas the reverse is true at the base of the reach. This could be a function of difference in discharge between datasets, change in b
ed
configuration, or an artifact of
lo
w point density.
Lo
w density of points forces greater lengths of interpolation between LiDAR points leading to a coarse DEM (Figure 21). Overall, the analysis Reach 1 profile indi
cat
es that LiDAR was able to match the fieldbas
ed
elevation measurements within ±O.05m. 53 Rough & Smooth Wa~t:e:-r~S~u=rf;:a~c:e:s~rz~~J,;~~ Grid Interpolation in
Lo
w Point Density Figure 21. LiDAR Point Density versus Interpolation. Side by side image showing
lo
ng lines of interpolation associat
ed
with smooth water surfaces (right image). Smooth water surfaces tend to have
lo
w LiDAR point density. The image on the right shows a hillshade ofthe LiDAR DEM. The DEM has been visualiz
ed
using a 2 standard deviation stretch to highlight
lo
ng lines of interpolation. The comparability of LiDAR and field-bas
ed
s
lo
pes show
ed
a significant trend with increasing downstream distances between cross sections. Adjust
ed
R2 values increas
ed
from 0.36 to 0.76 and the range of difference between field and LiDAR bas
ed
s
lo
pes decreas
ed
from 0.0047 to 0.00 14 as
lo
ngitudinal distance increas
ed
from 5 to 20- 54 m. This suggests that the 0.05m of expect
ed
variation of LiDAR deriv
ed
water surface elevation has less effect on water surface s
lo
pe accuracy as distance between elevation measurements points increases. Likewise, s
lo
pes accuracies a
lo
ng rivers with
lo
w gradients will improve as the
lo
ngitudinal distance between elevation points increases. Overall, data has shown that LiDAR can measure water surface s
lo
pes with mean difference relative to field measurements of 0.017, 0.012, and 0.007 at horizontal distances of 5, 10, and 20 meters respectively. Although the discrepancy between field and LiDAR-bas
ed
s
lo
pes is greatest at 5-m intervals, the overall s
lo
pes (Fig 17) and
lo
ngitudinal profiles (Fig 16) even at this distance generally correspond. The use of a 5m interval water surface s
lo
pe as a basis for comparison is really a worst case example, as water surface s
lo
pes are usually measur
ed
over
lo
nger reach scale distances where the discrepancy between LiDAR and field-bas
ed
measurements is
lo
wer. The continuous channel coverage and accuracies deriv
ed
from LiDAR represent a new level of accuracy and precision in terms of spatial extent and resolution of water surface s
lo
pe measurements. Analysis of surface roughness found that rough water surfaces had significantly higher point densities than smooth water surfaces. Rough water surfaces averag
ed
at least 1 point/m2 , while smooth water surfaces averag
ed
less than 1 point/2m2 •
Lo
ngitudinal profiles of Reach 1 indi
cat
e the most accurate water surface measurements occur in areas of higher point density (Fig. 16). Future appli
cat
ions that attempt to use 55 LiDAR to measure water surface s
lo
pe ought to sample DEM elevations from high point density areas of channel. Water surface analysis also show
ed
trends relating water surface roughness and s
lo
pe. Rough water surfaces for all three analysis reaches averag
ed
larger average s
lo
pe values than smooth water surfaces. This is because rough water surfaces are commonly associat
ed
with steps, riffles, and rapids. All three of these habitat types are areas have higher s
lo
pes than smooth water habitats. Smooth water surfaces are commonly associat
ed
with pools or glides, which would be areas of
lo
wer s
lo
pe. Future research should examine the potential for using LiDAR to characterize stream habitats bas
ed
on in-stream point density and s
lo
pe. This study is not without its limitations. The field area us
ed
to test the accuracy of LiDAR is only representative of a small portion of the Sandy River. Comparisons of field and LiDAR data would be improv
ed
by having mid-channel field data. One might also question the use of field bas
ed
water surface s
lo
pes as control for measuring "accuracy". Water surface s
lo
pe is difficult to measure for reasons stat
ed
earlier in this paper. One might make the argument that there is no real way to truly measure LiDAR accuracy of water surface s
lo
pe, and that LiDAR and field bas
ed
measurements are simply comparable. In this context, LiDAR holds an advantage over field bas
ed
measurements given its ability to measure large sections of river in a single day. LiDAR has a distinct advantage over traditional methods of measurement in that measurements are return
ed
from the water surface, and consequently not subject to errors 56 associat
ed
with variability of surface turbulence piling up against the measuring device. LiDAR can also capture
lo
ng stretches of channel within a few seconds r
ed
ucing the influence of changes in discharge. LiDAR data in general does have its limitations. LiDAR data are only as accurate as the instrumentation and vendor capabilities. LiDAR must be correct
ed
for calibrations and GPS drift to create a reliable data set, and not all LiDAR vendors produce the same level of quality. LiDAR data may be more accurate in some river reaches than others. The study reaches of this study contain
ed
well defin
ed
open channels, which made identifying LiDAR returns off the water surface possible. Both LiDAR data sets were collect
ed
at
lo
w f
lo
ws. F
lo
ws that are too
lo
w or channels that are too narrow may limit ability to extract water surface elevations because of protruding boulders or dense vegetation that hinders accurate measurements. In some cases vegetation within and adjacent to the channel may interfere with LiDAR's ability to reach the water surface. Researchers should consider f
lo
w, channel morpho
lo
gy, and biota when obtaining water surface s
lo
pes from LiDAR. 57 CHAPTER VII CONCLUSION This paper examin
ed
the ability of LiDAR data to accurately measure water surface s
lo
pes. This study has shown that LiDAR data provides sufficiently accurate elevation measurements within the active channel to accurately measure water surface s
lo
pes. Measurement of water surface s
lo
pe with LiDAR provides researchers a tool which is both more efficient and cost effective in comparison with traditional field-bas
ed
survey methods. Additionally, analysis show
ed
that LiDAR point density is significantly higher in rough surface conditions. Water surface elevations should be gather
ed
from high point density areas as
lo
w point density may hinder elevation accuracy. Channel morpho
lo
gy, gradient, f
lo
w, and biota should be consider
ed
when extracting water surface s
lo
pes as these attributes influence water surface measurement. Further study should examine accuracy of LiDAR deriv
ed
water surface s
lo
pes in channel morpho
lo
gies other than those in this study. Overall, the recognition that LiDAR can accurately measure water surface s
lo
pes al
lo
ws researchers an unprec
ed
ent
ed
ability to study hydraulic processes for large stretches of river. Common: APPENDIX ARCGIS VBA SCRIPT CODE 58 Public g---.pStrmLayer As ILayer ' stream centerline layer select
ed
by user (for step 1) Public g_StrearnLength As Double ' stream centerline length (for step 1) Public g_InputDistance As Integer 'As Double 'distance enter
ed
by user (for step 1) Public g_NumSegments As Integer I number of sample points enter
ed
by user (for step 1) Public gyPointLayer As ILayer I point layer creat
ed
from stream centerline (for step 1) Public g]ntShpF1Name As String I point layer pathname (for step 1) Public gyMouseCursor As IMouseCursor 'mouse cursor Public g_LinearConverson As Double I linear conversion factor Public gyDEMLayer As IRasterLayer I DEM layer (for steps 3 and 4) Public g_DEMConvertUnits As Double I DEM vertical units conversion factor (for steps 3 and 4) Public g_MaxSearchDistance As Double 'maximum search distance (for step 4) Public L NumDirections As Integer I number of directions to search in (for step 4) Public g_Sampl
eD
istance As Double 'sample distance (for step 5) Public g_SampleNumber As Double ' total sample points (for step 5) Public g_VegBeginPoint As Boolean I where to start the calucaltion (for step 5) Public g_VegCaclMethod As Boolean 'which method for Vegetation Calculation (for step 5) Public gyContribLayer As ILayer ' contributing point layer (for step 6) Public gyReceivLayer As ILayer 'receiving point layer (for step 6) Public gyOutputLayerName As String I output shapefile (for step 6) Function VerifyField(fLayer As ILayer, fldName As String) As Boolean I verify that topo fields are in the stream centerline point layer Dim pFields As IFields Dim pField As IField Dim pFeatLayer As IFeatureLayer Dim pFeatClass As IFeatureClass Set pFeatLayer = fLayer Set pFeatClass = pFeatLayer.FeatureClass Set pFields = pFeatClass.Fields For i = 0 To pFields.FieldCount - 1 Set pField = pFields.Field(i) 'MsgBox pField.Name IfpField.Name = fldName Then VerifyField = True Exit Function End If Next VerifyField = False End Function Function Ca1cPointLat
Lo
ng(inPnt As IPoint, inLayer As ILayer) As IPoint , in point layer Dim pFLayer As IFeatureLayer Set pFLayer = inLayer , spatial reference environment Dim pInSpatialRef As ISpatialReference Dim pOutSpatialRef As ISpatialReference Dim pGeoTrans As IGeoTransformation Dim pInGeoDataset As IGeoDataset Set pInGeoDataset = pFLayer Dim pSpatRefFact As ISpatialReferenceFactory , get map units of shapefile spatial reference Dim pPCS As IProject
ed
CoordinateSystem Set pPCS = pInGeoDataset.SpatialReference 'set spatial reference environment Set pSpatRefFact = New SpatialReferenceEnvironment Set pInSpatialRef= pInGeoDataset.SpatialReference 'MsgBox pInSpatialRef.Name Set pOutSpatialRef= pSpatRefFact.CreateGeographicCoordinateSystem(esriSRGeoCS_WGS1984) Set pGeoTrans = pSpatRefFact.CreateGeoTransformation(esriSRGeoTransformation_NADI983_To_WGS1984_1) Dim pOutGeom As IGeometry2 Set Ca1cPointLat
Lo
ng = New Point Set CalcPointLat
Lo
ng.SpatialReference = pInSpatialRef Ca1cPointLat
Lo
ng.PutCoords inPnt.X, inPnt.Y Set pOutGeom = Ca1cPointLat
Lo
ng pOutGeom.ProjectEx pOutSpatialRef, esriTransformForward, pGeoTrans, 0, 0, ° 'MsgBox inPnt.X &" "& inPnt.Y & vbCrLf& Ca1cPointLat
Lo
ng.X &" "& Ca1cPointLat
Lo
ng.Y End Function Sub OpenGxDia
lo
gO Dim pGxdial As IGxDia
lo
g Set pGxdial = New GxDia
lo
g pGxdial.ButtonCaption = "OK" pGxdial.Title = "Create Stream Centerline Point Shapefile" pGxdial.Remember
Lo
cat
ion = True Dim pShapeFileObj As IGx
Object
Dim pGxFilter As IGx
Object
Filter Set pGxFilter = New GxFilterShapefiles 'e.g shp Set pGxdial.
Object
Filter = pGxFilter If pGxdial.DoModaISave(ThisDocument.Parent.hWnd) Then Dim p
Lo
cat
ion As IGxFile Dim fn As String 59 Set p
Lo
cat
ion = pGxdial.Final
Lo
cat
ion fn = pGxdial.Name End If If Not p
Lo
cat
ion Is Nothing Then LPntShpFlName = p
Lo
cat
ion.Path & "\" & fn frmlB.tbxShpFileName.Text = g]ntShpFlName frmlB.cmdOK.Enabl
ed
= True End If End Sub Function GetAngle(pPolyline As IPolyline, dA
lo
ng As Double) As Double Dim pi As Double pi = 4 * Atn(l) Dim dAngle As Double Dim pLine As ILine Set pLine = New Line pPolyline.QueryTangent esriNoExtension, dA
lo
ng, False, 1, pLine , convert from radians to degrees dAngle = (180 * pLine.Angle) / pi I adjust angles , ESRI defines 0 degrees as the positive X-axis, increasing counter-c
lo
ckwise I Eco
lo
gy references 0 degrees as North, increasing c
lo
ckwise If dAngle <= 90 Then GetAngle = 90 - dAngle Else GetAngle = 360 - (dAngle - 90) End If End Function Function FeatureExists(strFeatureFileName As String) As Boolean On Error GoTo ErrHandler: Dim pWSF As IWorkspaceFactory Set pWSF = New ShapefileWorkspaceFactory Dim pFeatWS As IFeatureWorksiJace Dim pFeatDS As IFeatureClass Dim strWorkspace As String Dim strFeatDS As String strWorkspace = SplitWorkspaceName(strFeatureFileName) & "\" strFeatDS = SplitFileName(strFeatureFileName) If PWSF.IsWorkspace(strWorkspace) Then Set pFeatWS = pWSF.OpenFromFile(strWorkspace, 0) Set pFeatDS = pFeatWS.OpenFeatureClass(strFeatDS) End If 60 FeatureExists = (Not pFeatDS Is Nothing) Set pWSF =Nothing Set pFeatWS = Nothing Set pFeatDS = Nothing Exit Function ErrHandler: FeatureExists = False End Function 'Returns a Workspace given for example C: \temp\dataset returns C:\temp Function SplitWorkspaceName(sWholeName As String) As String On Error GoTo ERH Dim pos As Integer pos = InStrRev(sWholeName, "\") If pos > 0 Then SplitWorkspaceName = Mid(sWholeName, 1, pos - 1) Else Exit Function End If Exit Function ERH: MsgBox "Workspace Split" & Err.Description End Function 'Returns a filename given for example C:\temp\dataset returns dataset Function SplitFileName(sWholeName As String) As String On Error GoTo ERH Dim pos As Integer Dim sT, sName As String pos = InStrRev(sWholeName, "\") Ifpos > 0 Then sT = Mid(sWholeName, 1, pos - 1) Ifpos = Len(sWholeName) Then Exit Function End If sName = Mid(sWholeName, pos + 1, Len(sWholeName) - Len(sT)) pos = InStr(sName, ".") If pos > 0 Then SplitFileName = Mid(sName, 1, pos - 1) Else SplitFileName = sName End If End If Exit Function ERH: 61 • MsgBox "Workspace Split:" & Err.Description End Function Public Sub BusyMouse(bolBusy As Boolean) 'Subroutine to change mouse cursor If g---'pMouseCursor Is Nothing Then Set g---'pMouseCursor = New MouseCursor End If IfbolBusy Then g---'pMouseCursor.SetCursor 2 Else g---'pMouseCursor.SetCursor 0 End If End Sub Function MakeCo
lo
r(lRGB As
Lo
ng) As IRgbCo
lo
r Set MakeCo
lo
r =New RgbCo
lo
r MakeCo
lo
r.RGB = lRGB End Function Function Mak
eD
ecoElement(pMarkerSym As IMarkerSymbol, _ dPos As Double)_ As ISimpleLin
eD
ecorationElement Set Mak
eD
ecoElement
[
Lo
tus开发问题]文档无法打开
Special
database
object
cannot be
lo
cat
ed
。
问题描述:web页面提示404错误。domino控制台报错:HTTP Web Server:
Lo
tus Notes Exception -
Special
database
object
cannot be
lo
cat
ed
解决办法:我看到控制台的报错信息后,从以下几个方面进行查找。Form设计中,设计元素是否使用了公式语言 @Db
Lo
okup之类的方法。最后发现此文档使用的form(form域值
Domino错误信息的详细分析
遇到不知原因的错误信息,可以到下面的地址来找找,没准就有你想要的东西。 http://codestore.net/errors.nsf/ 下面是一条样例: Full Error Message:
Lo
tus Notes Exception –
Special
Database
Object
cannot be
lo
cat
ed
Synopsis: Usu
消息协作
535
社区成员
39,101
社区内容
发帖
与我相关
我的任务
消息协作
企业开发 Exchange Server
复制链接
扫一扫
分享
社区描述
企业开发 Exchange Server
社区管理员
加入社区
获取链接或二维码
近7日
近30日
至今
加载中
查看更多榜单
社区公告
暂无公告
试试用AI创作助手写篇文章吧
+ 用AI写文章