Sameura Dam
The Sameura Dam (早明浦ダム Sameura-damu) is a dam on the Yoshino River on the island of Shikoku, Japan, completed in 1975.[1] It has the largest storage capacity in Shikoku. The dam holds back a reservoir, named Lake Sameura (さめうら湖 Sameura-ko)
Sameura Dam | |
---|---|
![]() Sameura Dam | |
Official name | Sameura Dam |
Country | Japan |
Location | Motoyama and Tosa, Kōchi, Japan |
Coordinates | 33.756933°N 133.550125°E |
Construction began | 1963 |
Opening date | 1975 |
Operator(s) | Japan Water Agency |
Dam and spillways | |
Impounds | Yoshino River |
Height | 106 m |
Length | 400 m |
Reservoir | |
Creates | Lake Sameura |
Total capacity | 316 ML |
Catchment area | 472 km2 |
Surface area | 750 ha |
Power Station | |
Installed capacity | 42 MW |
The dam is used for flood control, a source of irrigation, and provides tap water to surrounding areas. It also produces electricity using hydropower. The plant can generate 42 MW.
1994 Grumman A-6 Intruder Incident[2]
- On October 14, 1994, a US Navy training plane, the Grumman A-6 Intruder, crashed near the reservoir. The A-6 Intruder took off from NAF Atsugi in Kanagawa Prefecture, and was headed towards MCAS Iwakuni in Yamaguchi Prefecture. The plane crashed on a low-level flight following a river when it got to a bend and couldn't get out. The wing sliced into the water upon a reverse. Both pilots, Lt. Eric A. Hamm and B/N John J. Dunne, Jr., were killed in the crash.
Water Supply Crisis of 2005[3]
- The Sameura Dam supplies water to Takamatsu, Kagawa Prefecture and Tokushima Prefecture. In 2005, because of little rainfall and a series of dry spells from April to June, the Shikoku Region was hit by a very serious drought and Lake Sameura dried up twice. Luckily, they could get over this crisis thanks to the heavy rain brought Typhoon Nabi.
gollark: The advantage of XTMF is that your tapes would be playable by any compliant program for playback, and your thing would be able to read tapes from another program.
gollark: Tape Shuffler would be okay with it, Tape Jockey doesn't have the same old-format parsing fallbacks and its JSON handling likely won't like trailing nuls, no idea what tako's program thinks.
gollark: Although I think some parsers might *technically* be okay with you reserving 8190 bytes for metadata but then ending it with a null byte early, and handle the offsets accordingly, I would not rely on it.
gollark: Probably. The main issue I can see is that you would have to rewrite the entire metadata block on changes, because start/end in XTMF are offsets from the metadata region's end.
gollark: I thought about that, but:- strings in a binary format will be about the same length- integers will have some space saving, but I don't think it's very significant- it would, in a custom one, be harder to represent complex objects and stuff, which some extensions may be use- you could get some savings by removing strings like "title" which XTMF repeats a lot, but at the cost of it no longer being self-describing, making extensions harder and making debugging more annoying- I am not convinced that metadata size is a significant issue
References
- "Visit Kochi Japan│The blessings of nature". Visit Kochi Japan. Retrieved 2017-02-10.
- Ranter, Harro. "ASN Aircraft accident 14-OCT-1994 Grumman A-6E Intruder 162188". aviation-safety.net. Retrieved 2017-02-10.
- http://www.narbo.jp/data/02_ar/materials/ar_rbo_jwa_2005.pdf
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.