Talk:List of U.S. states and territories by elevation/Archive 1
![]() | This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 1 |
Untitled
This article desperately needs to have the elevations in US units - the current format means nothing to most of the people who live in the places catalogued. Bob Palin 23:13, 2 May 2005 (UTC)
- I agree with Bob. Also, the mean elevation data seems incorrect. Alaska having a mean elevation of 3,000+ m is incorrect, see [1]. -- hike395 05:05, July 23, 2005 (UTC)
Thank you for your suggestion! When you feel an article needs changing, please feel free to make whatever changes you feel are needed. Wikipedia is a wiki, so anyone can edit any article by simply following the Edit this page link. You don't even need to log in! (Although there are some reasons why you might like to...)
The Wikipedia community encourages you to be bold. Don't worry too much about making honest mistakes—they're likely to be found and corrected quickly. If you're not sure how editing works, check out how to edit a page, or try out the sandbox to try out your editing skills. New contributors are always welcome. --Allen3 talk 19:52, July 23, 2005 (UTC)
I certainly know how to edit pages but there are 1200 elevations listed on this page, it really needs a bot of some sort to do it, that I don't know how to do Bob Palin 21:31, 23 July 2005 (UTC)
- I agree with Bob (again!) This canned response (from {{sofixit}}) is useless. There is a lot of data on this page (hundreds of table rows): fixing it by hand would take me a long time, which I don't have. Checking the data by hand is going to be tedious. Was this page generated programmatically? If so, can whomever has the program check the data and regenerate the page with Imperial units? If not, perhaps someone can write a program to regenerate the page: I don't have time. -- hike395 21:32, July 23, 2005 (UTC)
- No program or automation other than a straight forward cut and paste was used to create any of the tables. The information source used to create the tables was the data tables for each of the individual state articles (using the links in the first table). As not all of the state articles provide information in imperial units, but all provide metric values, the choice of units was predetermined by the information source. Once the alphabetically sorted table was created, the other tables were built by hand sorting a copy of the original tables data. I realize that this is not the magic wand you were wishing to have waved, but if you look at the articles history you can see how the various pieces were built up over time. --Allen3 talk 21:35, July 24, 2005 (UTC)
- There's one canonical source for this data: The Statistical Abstract of the United States. This page should be a reflection of Table No. 351, Extreme and Mean Elevations by State and Other Areas, see [2]. That has both imperial and metric units, too. If someone doesn't get around to converting that to wiki, I'll do it eventually. -- hike395 01:53, July 25, 2005 (UTC)
This article is excellent. I trust that the authors are thinking of nominating it on Wikipedia:Featured list candidates? -- ALoan (Talk) 17:20, 1 August 2005 (UTC)
Datum?
I imagine all these heights are derived from USGS, so I guess that means they're expressed in terms of the NAD83 datum. If that's true (even for outlying points like Alaska and Hawaii) then I think the intro should link to it. -- Finlay McWalter | Talk 15:50, 6 November 2005 (UTC)
- Sadly, not :-(. For the high points that I'm familiar with, these are the 1927 datum values. Someone changed the Mount Whitney elevation to the latest NAVD88 datum value. Not sure what to do. -- hike395 18:03, 6 November 2005 (UTC)
Map?
Would it be worth producing an additional map showing the locations of the highest and lowest points? I was thinking of something much more schematic than the (excellent) topographic map, this time showing just the state outlines and having a blue and red mark indicating the lowest and highest points respectively. If there is support for this (and if there are geographic coordinates in the respective articles to allow me to do so) I can make the map (although not immediately, I confess). -- Finlay McWalter | Talk 16:12, 6 November 2005 (UTC)
- That would be so nifty! -- hike395 18:07, 6 November 2005 (UTC)
- I'll put it on my wiki-todo list. To make the map accessible for visitors with colour-blindness, I think I'll draw the high points like a red ^, and the lows like that symbol upside down. Things get complicated where the low point is a coastline - I suppose I'll just colour the coast all blue and leave it at that. -- Finlay McWalter | Talk 18:26, 6 November 2005 (UTC)
- Hey, I made an image [3]. I just red circles for high points, green squares for the low. For locations with low elevations on lake or ocean shores, I didn't not include them. What does everyone think? -- ChristopherM 21:58, 14 June 2006 (UTC)
- I'll put it on my wiki-todo list. To make the map accessible for visitors with colour-blindness, I think I'll draw the high points like a red ^, and the lows like that symbol upside down. Things get complicated where the low point is a coastline - I suppose I'll just colour the coast all blue and leave it at that. -- Finlay McWalter | Talk 18:26, 6 November 2005 (UTC)
conversion errors?
I've updated some of the state articles to match the elevation numbers from this list, and noticed some apparent conversion errors. For example Wyoming's highest point is listed as 13804 feet and 4210 meters (13804 feet is 4.2074592 km, and going the other way 4210m is 13812.336 feet). It looks like the data in the list is directly from [4], but it seems very odd that the feet and meters don't actually match. Anyone know why this might be so? -- Rick Block (talk) 18:08, 7 May 2006 (UTC)
- And how about the strange values for Kentucky? The first instance on the page lists the elevation difference as 1184 m. Elsewhere in the page it's 2084 m. The larger number appears incorrect. Teratornis 04:44, 25 July 2006 (UTC)
Coordinate system or Vertical datum?
This article uses the term "coordinate system" to describe the NGVD29 and NAVD88. I have never seen that term used to describe these vertical datums. Usually, a coordinate system defines a location in horizontal (x,y) space, such as the Lat/Lon, UTM, or State Plane coordinate systems. I suspect that the term is being misused here, and that "vertical datum" would be a more correct term, but I thought I would ask before making any changes. I don't frequently deal with vertical data, so it could be something I'm unaware of. - Justin 09:37, 4 December 2006 (UTC)
Making table sortable
Check out United States cities by crime rate, it has a simple class for making the table sortable. That would eliminate the duplicate tables sorted in different manners. The simple code applied is:
- class="toccolours sortable"
Discussion of using the code is Help:Sorting.
I tried to apply it here but had bad luck. First it sorted on the top line. I broke the table into two and it sorted on the correct headings but unfortunately its sorting was not correct (e.g., anything beginning with a "9" was higher than anything beginning with a "2" regardless of the digits). Also I had problems getting the top line to align correctly. Trimming the units (which turns the entries into text) might help but there's some footnotes in there which create mischief. If anybody could get it work, that would make this artilce ***MUCH*** more useful! Thanks. Americasroof 17:18, 1 July 2007 (UTC)
- I think my edit works, but I will grant there are a few minor presentation problems. Several characters in the numeric columns were forcing alphabetical sorting (your "9" and "2" problem above):
- units (removed - the headings should suffice)
- the &mdash for negative elevations (replaced by standard dashes - I don't know if that will be an issue for certain browsers)
- the two elevation references (moved over to the location column - not the best location, but I think it's OK)
- Also I re-titled the column headers to facilitate sorting, but I don't like how it includes the icons for centering, making the text appear un-centered. But it's definitely the lesser of two evils in my opinion. Hoof Hearted 18:08, 12 July 2007 (UTC)
- Thanks and nice job! Presumably we can nuke the other sections now. There's a header that makes mention of an impact on Template:Infobox U.S. state. I don't think this feeds that template rather I think it's just a link for an explanation on highest, mean and lowest. I put a note on the template talk page. If we nuke the sections the only graphics of use would be the map with the highpoints and perhaps the map with shows the physiology. Again nice job! Americasroof 18:28, 12 July 2007 (UTC)
- Ah, you beat me to the punch! I like all the images and think there's values to keeping them all. I only question the best display method. Still, if you think we may as well blow them away (perhaps because of the display issue), I can live with that. Hoof Hearted 18:36, 12 July 2007 (UTC)
Get rid of other sorted tables?
I started to delete these when I noticed the comment about them being used at Template:Infobox U.S. state. I propose simply unlinking "Highest point", "Mean", and "Lowest point" on that table, leaving the "Elevation" heading linked to the article. Is there value to leaving the "hand-sorted" subtables? Secondly, if you agree that we could dump the subtables, how should we present the images? In a gallery or just globbed on after the table? Maybe move them ahead of the table? Hoof Hearted 18:33, 12 July 2007 (UTC)
- This is great! (And I'm speaking as the person who typed in all of the manual tables!). The one problem is: when you click on "lowest elevation (ft)" to sort, and have them in descending order, then it sorts lexicographically, not numerically. Can this be fixed somehow?
- Does anyone know how to force the table to have a column that is initially sorted? That way, the Infobox can link to three different versions of the same table. It may not be possible, however. hike395 03:45, 13 July 2007 (UTC)
- Apparently negative numbers don't work correctly yet. There is a work around here Template_talk:Sort#.7B.7Bnts.7D.7D. You can implement if you want, I'll wait for the bug to be fixed ([5] ). Unfortunately there isn't a way to pass a sort type in that I know of. -Ravedave 04:45, 13 July 2007 (UTC)
- Given that this list is featured, I couldn't leave it as-is. I implemented correct sorting using {{sort}}. Thanks for the tip! hike395 14:22, 14 July 2007 (UTC)
Colorado
The lowest point for Colorado is not the Arkansas River at 3,350 feet. It is actually at the Arikaree river at 3,315ft presented by Dale Sanderson at usends.com --Slxception (talk) 07:10, 18 January 2010 (UTC)
Geodetic Survey versus Geological Survey
User:Buaidh has made a series of changes to this article (and associated state articles) citing the North American Vertical Datum of 1988 by the U.S. National Geodetic Survey. While I appreciate that an engineer would prefer the orthometric heights used by the Geodetic Survey, I think this list should include only the normal height data as provided by the United States Geological Survey. The USGS data is consistent, widely published and referenced, and relates to the natural elevations of the land, not to the regularly adjusted location of certain markers, as is the data used by the Geodetic Survey. Best, epicAdam(talk) 18:35, 23 October 2011 (UTC)
- I agree. The use of another height system is confusing particularly when readers expect it to be basic MF above sea level. Shadowjams (talk) 18:42, 23 October 2011 (UTC)
- Over at WP:WikiProject Mountains, the guideline has been to use NAVD88, because it is a more up-to-date reference system. Many editors use NGS elevation data, because the USGS data is quite old. I think it would be worthwhile to start a discussion at WT:WikiProject Mountains, becuase these decisions can potentially affect hundreds of pages. —hike395 (talk) 20:07, 23 October 2011 (UTC)
- I see what you're saying, but the NGS elevation data are not just "newer" but have also been standardized using a different height system for a specific purpose. As Shadowjams notes above, I don't think that information is what a user is looking to find when they come to this page. I have left a note at WP Mountains but, for this list, we have a very fine USGS source that provides the high and low points in all 50 states. That information is therefore consistent and should not be supplanted by data from a mishmash of other sources that some editors purport to be better or newer. We should trust the USGS that if their current data really are off by a significant amount, that they would issue a new release. Best, epicAdam(talk) 20:41, 23 October 2011 (UTC)
- I understand. That different height system is what the Wikiproject standardized on (if I understand NAVD88 correctly), so Buaidh was simply following the standard. If we revert this page, it would be inconsistent with many other pages. That's why I thought a broader discussion would be useful.
- I think that 99.9% of visitors to this page don't understand the subtleties of elevation measurements and geoids. So, I don't think we can appeal to user expectations to make the choice. —hike395 (talk) 21:33, 23 October 2011 (UTC)
- No, I don't expect visitors to understand these subtleties but there is a larger problem than just consistency with other articles on mountains. Using the District of Columbia as an example, Fort Reno Park (the highest natural point in the city) has a medallion marker ([6]) that advises visitors of the height of 409 feet. It's become something of a famous local landmark [7] [8] with all information about Fort Reno referencing that same height. If users were to read about that and then reasonably came to this list to find the highest and lowest elevations in other states, they would be greeted with information that is completely inconsistent with everything else. I'm sure there are other examples around the country where the generally accepted heights would differ from what is presented here. Best, epicAdam(talk) 22:14, 23 October 2011 (UTC)
- I would also point out that I think the NGS datasheets may fail WP:V because they don't say that the particular location is the highest point, it just provides the vertical distance of the NGS marker. So users would have to use the two sources, the USGS listing (but ignore the number listed there) and then just accept that the location cited in the datasheet is the same. That is a little bit too much original research for my tastes. Best, epicAdam(talk) 22:25, 23 October 2011 (UTC)
- I see what you're saying, but the NGS elevation data are not just "newer" but have also been standardized using a different height system for a specific purpose. As Shadowjams notes above, I don't think that information is what a user is looking to find when they come to this page. I have left a note at WP Mountains but, for this list, we have a very fine USGS source that provides the high and low points in all 50 states. That information is therefore consistent and should not be supplanted by data from a mishmash of other sources that some editors purport to be better or newer. We should trust the USGS that if their current data really are off by a significant amount, that they would issue a new release. Best, epicAdam(talk) 20:41, 23 October 2011 (UTC)
- Over at WP:WikiProject Mountains, the guideline has been to use NAVD88, because it is a more up-to-date reference system. Many editors use NGS elevation data, because the USGS data is quite old. I think it would be worthwhile to start a discussion at WT:WikiProject Mountains, becuase these decisions can potentially affect hundreds of pages. —hike395 (talk) 20:07, 23 October 2011 (UTC)
Very good point about synthesizing USGS high points with NGS elevations. Here's a possible solution: how about two different columns for the high points? One that lists the USGS elevation in the 1929 datum, as supplied by the source. The other which supplies the NGS elevation in NAVD88, for the same points? That would be neutral about which datum is "better", and remove the WP:SYN, because the conclusion of having the NGS elevation be the only correct would be removed. This would also keep consistency with other peak articles. —hike395 (talk) 00:29, 24 October 2011 (UTC)
- That would be fine. But we have to be sure that the NGS elevations are correct, first. I was looking through them and they all measure the vertical distance of the actual marker itself, not necessarily the elevation of the land. For example, it has the elevation of the Washington Monument at 595 feet. The monument is 555 feet high, which presumably means that the marker is on top of the building. Each datasheet will have to be checked, but this still seems like a lot of OR unless NGS has its own listing of highest and lowest elevations. Best, epicAdam(talk) 01:09, 24 October 2011 (UTC)
- As someone who has placed a few vertical benchmarks in the past 45 years, let me point out that any elevation stamped on a benchmark is merely an estimate of the elevation made at the time of its installation, and not a subsequently refined calculation of precise elevation. Not a few benchmarks are erroneously stamped. I suspect that the elevation stamped on the Reno Reset Benchmark has tranposed the last two digits. (The elevation digits may instead be transposed on NGS Data Sheet HV4384, but this is less likely since the elevation has been converted to NAVD 88.) USGS topographic maps show elevations between the NGS numbers. I have asked the NGS to confirm their data.
- The USGS datatsheet Elevations and Distances in the United States was last updated in 2001, prior to the implementation of the North American Vertical Datum of 1988 and uses the older National Geodetic Vertical Datum of 1929. The National Geodetic Survey, the United States Geological Survey, and other government agencies are in the midst of a multi-decade conversion from NGVD 29 to NAVD 88. The NGS now reports all elevations in meters based on the NAVD 88. The USGS depends upon the NGS for its vertical control data. The conversion of all USGS vertical data from NGVD 29 to NAVD 88 will take many more years.
- One of the significant differences between NGVD 29 and NAVD 88 is that the former tended to undercalculate the elevation of mountainous regions by as much as 11 feet in the United States. WikiProject Mountains has made a considerable effort to update the elevation of U.S. mountain summits from NGVD 29 to NAVD 88. We hope the USGS will soon update its list of Elevations and Distances to NAVD 88. Until that time, we must make the conversions ourselves. Yours aye, Buaidh 01:31, 24 October 2011 (UTC)
- There is a great deal of outdated and inaccurate information floating about on the Internet. It is the task of Wikipedia to present the most accurate information available, rather than to perpetuate widely disseminated inaccuracies. Yours aye, Buaidh 01:50, 24 October 2011 (UTC)
- Like all masses, mountains have their own gravitational field and pull other masses toward them. This tends to raise the apparent sea level in the vicinity of massive mountain ranges. NAVD 88 includes a correction for this elevation distorting effect. Yours aye, Buaidh 02:00, 24 October 2011 (UTC)
- To address Epicadam's point, above, the USGS elevations are not guaranteed to be elevation of the land, either.. —hike395 (talk) 03:08, 24 October 2011 (UTC)
- Hi Buaidh. Thank you for the detailed response. I agree that providing the most accurate information is certainly important, I just want to make sure it's done in a verifiable way. If the consensus is to use the NAVD 88 dataset, then that's fine, but I think it should be made clear exactly what was done so as to provide the reader with some explanation as to the two different sets of data. As for the D.C. issue, I had thought that the numbers were transposed and now I'm nearly certain of it. If the previous elevations for mountains were off by several feet then it seems incongruous that such a low-lying area like D.C. could have been off by 90 feet. Thank you for checking. Best, epicAdam(talk) 15:43, 24 October 2011 (UTC)
- I'm not worried about WP:V, because you can follow the {{cite ngs}} links to check. I am worried about WP:SYN --- this does seem to fall squarely within WP:SYN --- USGS says the highest point is X, NGS says the elevation of the X is Y, therefore the elevation of the highest point is Y. Seems impermissible. Buaidh: what do you think of having a USGS column and an NGS column? I think this would solve the problem. —hike395 (talk) 17:00, 24 October 2011 (UTC)
- I think two sets of elevations would be very confusing to most users. I've never seen elevations presented with two sets of vertical control data. The NGS has converted all their data (except for Alaska) to NAVD 88. The USGS is still quite a way from converting all their data to NAVD 88. That is the reason they have not updated Elevations and Distances in the United States. There is no conflict between the NGS and the USGS. The USGS just has an enormous amount of data and maps to convert. The USGS is also trying to clean up their vertical data as they convert to NAVD 88. Eventually all data will be converted to NAVD 88, hopefully before the next set of vertical datum.
- The conversion from NGVD 29 and NAVD 88 will have little effect east of the Mississippi River where most adjustments are less than a few inches. West of the Mississippi the effect is much more pronounced. Mount Whitney rose 11 feet and Mount Elbert and Mauna Kea rose 7 feet. Even Denver rose 5 feet, although the city lowered its vertical reference point 5 feet so it could remain the Mile High City.
- I think the most comparable change was the conversion from the Julian Calendar (O.S.) to the Gregorian Calendar (N.S.). George Washington was born on February 11, 1731 O.S., but we now observe his birthday on February 22 N.S. When we convert to Stardates, we'll convert his birthday to that system. Yours aye, Buaidh 20:53, 24 October 2011 (UTC)
- NAVD 88 will not be the last set of vertical datum for the United States. Elevation data is continually updated, with major revisions every 50 years or so. The shape of the Earth is still rebounding from the Quaternary Ice Age. Sea level is rising in the lower latitudes and dropping in the upper latitudes. The next revision of the World Geodetic System will need to deal with our dynamic Earth. Yours aye, Buaidh 03:16, 25 October 2011 (UTC)
changing the table data needs supporting reference
If editors are going to alter the entries in the table, they'll need to back it up with reliable sources. Note that reading data from a map is not a reliable source, but is instead original research. —hike395 (talk) 04:32, 2 December 2012 (UTC)
"U.S. states"?
Ummm... I don't really know how to point this out, or whether by "fixing" it, I might break links to it, but... you do know that the "U.S." in the title stands for "United States," and that, therefore, the title reads, "List of United States states by elevation"...?
This title is wrong in another way: it's really a list of elevations by state, or elevations within the United States, not states by elevation rowley 23:34, 25 December 2006 (UTC)
- Article title is parallel to List of U.S. states by area, List of U.S. states by population, List of U.S. states by unemployment rate, List of U.S. states by traditional abbrevation, List of U.S. states by date of statehood, etc. ad nauseum. If you'd like to propose a different name for all of the articles, I would suggest proposing it at Wikipedia:WikiProject U.S. States, although I predict a difficult argument, because you'll be claiming that the WikiProject itself is incorrectly named.
- As for list of elevations: look at sections 2-5 --- those are, indeed, lists of states ordered by elevation, where elevation is defined slightly differently for each section. Only section 1 is a list of elevations by state. hike395 00:27, 26 December 2006 (UTC)
- To say "List of United States states..." is admittedly awkward, but it is correct. The title distinguishes it from other countries that use "states" as political divisions. In addition, the United States has other political divisions besides states. For example, "United States territories" or "U.S. counties", etc.
- As far as the other item mentioned, it is a list of elevations by state, but it might depend on who you use the toggle buttons on the list to organize the data. APatcher (talk) 23:05, 28 April 2013 (UTC)
Delaware - Ebright Azimuth
I was working on the Ebright Azimuth article and found some stuff. See:
- "Ebright". NGS Data Sheet. National Geodetic Survey, National Oceanic and Atmospheric Administration, United States Department of Commerce.
- Schenck, William S. "Highest Point in Delaware". Delaware Geological Survey.
- "Regarding the highest point in Delaware". Delaware Repeater Association.
I think I was able to avoided the issue of the highest point in the article because its about the benchmark and not the highest point. Schench seems to be a reliable source. For more pictures see the Geocaching page. To be strickly truthful I guess the trailer park should to named as the highest point. Don't know how the people living there would like that. Also the NGVD27 to NAVD88 datum shift here is 1.024 feet and Schench does not mention which datum he used but probably NGVD27 as the letter was written in 1990. Although Google Maps shows the coordinates on the datasheet as being in Pennsylvania, the topo map shows them to be in Delaware. I'm not going to worry about it any more. --DRoll (talk) 23:34, 17 December 2008 (UTC)
- The dirt was moved when the trailers were installed because water pools up in the area when it rains. I'm not sure if the dirt moved by a tractor counts as a "higher" elevation than the benchmark. There are also huge rocks in the area that are higher than the benchmark, but they too could be moved by a tractor. Also, it's really splitting hairs since all of those things are all on the same small plot of land. Nevertheless, if it is to be determined that the trailer park is the highest elevation, I assure you the people there will not mind. As it is now, people come through there almost every weekend searching and surveying since it is also on the state line as well as near the highest point. APatcher (talk) 23:22, 28 April 2013 (UTC)