Re: [Talk-us] FCC Antenna Structure Import
On Mon, 8 Feb 2010 15:35:20 -0600, Jeffrey Ollie j...@ocjtech.us wrote: On Mon, Feb 8, 2010 at 3:25 PM, Anthony o...@inbox.org wrote: On Mon, Feb 8, 2010 at 12:47 PM, Jeffrey Ollie j...@ocjtech.us wrote: Â Â tag k=ele v=278.9/ By the way, what is the datum for the elevation figure? I don't believe that it is specified explicitly, but the latitude and longitude are in NAD83 so I'm guessing that the elevation is the same. I convert the latitude and longitude to WGS84 using the GDAL Python bindings, I should probably figure out if converting the elevation is as easy as adding a Z component when I do the conversion. Unless I'm missing something, NAD83 is equivalent to WGS84 for the purpose of this source data (and most any practical purpose). They result in the same co-ordinates out to at least the 7th decimal place in degrees (~1 cm). My experience with FCC license data in the past has been that it is usually good to no more than 6 seconds (i.e. less than 3 decimal places in degrees). This is because before the GPS era, license applicants often copied or adjusted to locations reported for other nearby licensees, and I don't think there was a rigorous spec for how accurate they needed to be (or it was something like 1 minute). The AS database is likely similar, though in the ones I worked on, they were accurate to 1 second (and some even to 0.1 second - still only ~0.28 degrees). -- Alan Mintz alan_mintz+...@earthlink.net ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] FCC Antenna Structure Import
On Tue, Feb 9, 2010 at 2:46 PM, Alan Mintz alan_mintz+...@earthlink.net wrote: On Mon, 8 Feb 2010 15:35:20 -0600, Jeffrey Ollie j...@ocjtech.us wrote: On Mon, Feb 8, 2010 at 3:25 PM, Anthony o...@inbox.org wrote: On Mon, Feb 8, 2010 at 12:47 PM, Jeffrey Ollie j...@ocjtech.us wrote: Â Â tag k=ele v=278.9/ By the way, what is the datum for the elevation figure? I don't believe that it is specified explicitly, but the latitude and longitude are in NAD83 so I'm guessing that the elevation is the same. I convert the latitude and longitude to WGS84 using the GDAL Python bindings, I should probably figure out if converting the elevation is as easy as adding a Z component when I do the conversion. Unless I'm missing something, NAD83 is equivalent to WGS84 for the purpose of this source data (and most any practical purpose). They result in the same co-ordinates out to at least the 7th decimal place in degrees (~1 cm). You are spot on (or within a meter). Within the continental U.S, NAD83 = WGS84 to within 1 meter. My experience with FCC license data in the past has been that it is usually good to no more than 6 seconds (i.e. less than 3 decimal places in degrees). This is because before the GPS era, license applicants often copied or adjusted to locations reported for other nearby licensees, and I don't think there was a rigorous spec for how accurate they needed to be (or it was something like 1 minute). The AS database is likely similar, though in the ones I worked on, they were accurate to 1 second (and some even to 0.1 second - still only ~0.28 degrees). Agree! -- Alan Mintz alan_mintz+...@earthlink.net ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] US Chapter temporary Board Nomination
Alright then, I'm throwing my hat into the ring... I accept the nomination to run for the temporary board of the U.S. Chapter of OSM. I have been active in the Washington OSM community since late 2008. I have both helped organize and participate mapping parties in the Washington, DC area, contributed to the local OSM-based MappingDC effort (with particular attention to the Arlington County side of the metropolis). My particular interest is on capturing hyperlocal features that may be useful at a neighborhood or community level but aren't captured elsewhere. I believe OSM is unparalleled as a platform for enabling citizens at every level of ability to collect and use that data. Because of that interest, I have been an active contributor to the conference calls to organize the US Chapter. As a board member, I would act to stand up an OSM chapter that reflects the unique needs of the US and remains faithful to the vision of OpenStreetMap. I expect to launch an organization that will engage in community building, outreach to government agencies, grass roots organizations, and inspired individuals with a passion for creating usable public geographic information. Thanks for your consideration, SEJ Wretches, utter wretches, keep your hands from beans. -Empedocles ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Incorrect Summit Elevations - Colorado
Have seen it too in California. It's not only the elevation also lat/lon is wrong for many summits. If there is any better source correct it. I verify it by gps and topo 24k and yahoo. If there is any official and better data I am all for replacing GNIS data. On 9 Feb 2010, at 19:35 , Mike Thompson wrote: It appears that there is a systematic error in the summit elevations in OSM, at least in Colorado. For example, Longs Peak is listed in OSM as having an elevation of 4340 meters (14,239 ft). The topo map has it as 14,251 ft. I have noticed the same type of issue with nearby peaks. I suspect this has to do with the GNIS import. The elevations in the GNIS are from the National Elevation Dataset (NED), not spot (e.g. summit) elevations. The NED gives the (presumably average) elevation for a 3x3 arc second area. According to the metadata for the GNIS: == Elevation figures are not official and do not represent precisely measured or surveyed values. The data are extracted from the National Elevation Dataset (http://ned.usgs.gov/) for the primary coordinates and may differ from elevations cited in other sources. The differences will be most evident for features such as summits where precision is of more concern and where the local relief (rate of change of elevation) may be more prominent. However, the elevation figures are within tolerances for the data for most points and sufficiently accurate for purposes of general information. == Precise and official elevations are very important for hikers and mountineers, or at least we like to think they are. I believe that the National Geodetic Survey holds data on the official elevations for summits within the U.S., but I need to look into that. I am happy to start working on fixing this issue, but I didn't want to commence if someone else is already working on. Mike ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
