Re: [Tagging] Feature proposal - RFC - Documenting feet as an an optional elevation unit
Minh Nguyen writes: >> It's a slippery slope, and pretty soon \pi is 3. > > Poor Indiana. ;-) The definition of the foot would apply to the ' and > ft abbreviations in every context, not just the ele=* key, so I'd > suggest considering it separately, probably without the formality of a > vote. The main unit symbol listing has come together more informally > over the years. [1] > > Sooner or later, OpenHistoricalMap will have a lot of fun with this issue... > > [1] https://wiki.openstreetmap.org/wiki/Map_features/Units A fair point that it's generic, and while that page does not say "international foot", the conversion given is the modern/interntional one. So I think we're all set. I would expect elevations in feet in NGVD29 to be in survey feet. It's not so much a special feet for surveying as the definition before the 50s, and too hard to change for horizontal control, while ignorable just about everywhere else. But, the difference is tiny, and elevations in NGVD29 are more or less by definition of poor accuracy anyway. I'm glad to see the usual suspects are still here! ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature proposal - RFC - Documenting feet as an an optional elevation unit
On 29/1/24 06:30, Philip Barnes wrote: The legal definition of a foot is of course 0.348 m. "Since an international agreement in 1959, the foot is defined as equal to exactly 0.3048 metres'. Phil (trigpoint) NPL has a nice history on length measurement http://resource.npl.co.uk/docs/educate_explore/posters/bg_historyoflength_poster.pdf Even in the USA the survey foot is depreciated. https://amerisurv.com/2023/02/09/the-deprecation-of-the-us-survey-foot/ Depreciation in the US may be 'complete', at least in government circles, in 2025... On 28 January 2024 18:57:45 GMT, Minh Nguyen wrote: Vào lúc 04:08 2024-01-28, Greg Troxel đã viết: Minh Nguyen writes: Vào lúc 19:50 2024-01-27, Brian M. Sperlongano đã viết: Uh so I did the math, and unless I've got this wrong, the difference between survey feet and international feet for tagging, let's say, Mount Everest, is less than seven one-hundredths of an inch. So I'm really not even sure why we're discussing it beyond the fact that we're all nerds about this sort of thing. You got me. :-) The actual proposal doesn't mention the foot's two definitions at all, and so far I'm planning to keep it that way. I think it's important to be definitionally correct, even if it doesn't really matter. It's a slippery slope, and pretty soon \pi is 3. Poor Indiana. ;-) The definition of the foot would apply to the ' and ft abbreviations in every context, not just the ele=* key, so I'd suggest considering it separately, probably without the formality of a vote. The main unit symbol listing has come together more informally over the years. [1] Sooner or later, OpenHistoricalMap will have a lot of fun with this issue... [1] https://wiki.openstreetmap.org/wiki/Map_features/Units ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature proposal - RFC - Documenting feet as an an optional elevation unit
On 1/29/24 02:12, Graeme Fitzpatrick wrote: https://japannews.yomiuri.co.jp/society/noto-peninsula-earthquake/20240111-161375/ See also: https://strokkur.raunvis.hi.is/gps/8h.html (Icelandic data, with maggma intrusions, tectonic movement, quakes and eruptions) -- Cheers, Jeremy ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature proposal - RFC - Documenting feet as an an optional elevation unit
In regard to "exact" accuracy, spotted this article a few weeks ago in regard to the Japanese earthquake: https://japannews.yomiuri.co.jp/society/noto-peninsula-earthquake/20240111-161375/ 70cm / 28" to 2m / 6'6" horizontal & 3cm / 1.25" to 1.3m / 4'4" vertical movement! :-( Thanks Graeme On Mon, 29 Jan 2024 at 11:39, Kevin Kenny wrote: > > > On Sat, Jan 27, 2024 at 7:06 PM Greg Troxel wrote: > >> As someone not happy about the deprecation of mailinglists, a few brief >> comments here: >> >> First, I think this proposal is fine, as documenting widespread >> practice. Regardless of my further comments, I think it's solidly >> progress to adopt it. >> >> While yonur comments about survey feet are valid, modern elevations >> (NAVD88) are as far as I can tell actually in meters, and when >> expressed in feet, in international feet. Elevations are small enough >> that 2 ppm is less than the errors in the values. >> >> I would expect the proposal to give an example. It seems that one >> would have a tag >> ele=6288 ft >> for Mount Washington (showing my East Coast bias). >> >> It would be good to explicitly state that in keeping with convention, >> ft means international feet, perhaps with a parenthetical comment that >> if someone meant US Survey Feet they would have written ftUS. Maybe >> this is already documented. >> > > As far as I know, Survey Feet are used only for horizontal measurements, > mostly in state plane coordinates. And I don't think that there are yet any > elevations, anywhere, for which precision to 2 parts per million matters. > > >> Further, WGS84's first height definition is ellipsoidal height, and >> that simply is not elevation. Obviously elevation should be in "WGS84 >> Orthometric Height", which is what GPS receivers provide as elevation. >> But elevations are not published in WGS Orthometric Height; they are >> published in a national or regional datum which is pretty close, as >> all datums at least roughly target a similar origin. >> > > In newer datums than WGS84, even horizontal position is reported relative > to an epoch, with corrections for phenomena like continental drift. I've > hiked to one of the stations used for such geodesy - a copper bolt placed > in 1870 in truly ancient and stable rock (Hawkeye Gneiss, ~1.15 Ga) with > accuracy that would have been considered first-order even a century after > its placement. > > The difference between survey feet and international feet for horizontal > coordinates is significant, because in UTM coordinates, the 2 > part-per-million error adds up to 20 metres in the polar regions (or 10 or > so in the mid-latitudes). It's somewhat less significant over the smaller > range of state plane coordinates, which is why most states don't plan to do > anything about it until 2025 at the earliest. In a few 'bad' planes like > Nevada North and Michigan East, the origins are far enough outside the > state that the errors can be about 15 m. > > Many "authoritative, official" data sets that I've worked with appear to > suffer from mixed horizontal datums, with NAD27 coordinates mistakenly > transferred over into WGS84 uncorrected. When working with county tax maps, > for instance, I always try to spot-check things like street intersections > or monumented corners, to make sure what datum I'm working with, because > it's often not what the map claims to be. Sometimes the error is backward - > the county has never made the conversion of its systems off of NAD27, but > WGS84 data have crept in! > > But for vertical coordinates, I'm willing to wager that no mapper has the > technology to measure absolute elevation to less than a mm. In fact, I > doubt that it's even meaningful to discuss that sort of precision in > elevation. The geoid isn't defined to that accuracy. So I can easily live > with the ambiguity in which 'ft' are used. (Moreover, I can't think of any > OSM tag at the moment in which a measure in feet would need a few parts in > 10**-6 precision.) > > I'd certainly approve of a proposal optionally to tag elevations with the > vertical datum used - but since the differences are typically on the order > of 1-2 metres, I surely don't insist on such a tag! I understand that most > GPS units use GRS80+EGM1984, but I'm sure that NAVD88 has crept in, even > among objects that I've mapped. And I betcha there's a ton of uncorrected > NGVD1929 in TIGER. For a metre or two, who cares (yet?). > > But I'll roundly condemn anyone who confuses height-above-ellipsoid with > elevation! (I'm looking at you, Android Location Services!) > > Changes in vertical datum together with LIDAR data have wrought confusion > among some of the hiking clubs around here, who maintain lists like the > Adirondack 46'ers (the 46 summits in the Adirondacks thought at the time of > the list's compilation to exceed 4000 feet elevation) or the Catskill > 3500's (the 34 summits thought at the time of compilation to
Re: [Tagging] Feature proposal - RFC - Documenting feet as an an optional elevation unit
On Sat, Jan 27, 2024 at 7:06 PM Greg Troxel wrote: > As someone not happy about the deprecation of mailinglists, a few brief > comments here: > > First, I think this proposal is fine, as documenting widespread > practice. Regardless of my further comments, I think it's solidly > progress to adopt it. > > While yonur comments about survey feet are valid, modern elevations > (NAVD88) are as far as I can tell actually in meters, and when > expressed in feet, in international feet. Elevations are small enough > that 2 ppm is less than the errors in the values. > > I would expect the proposal to give an example. It seems that one > would have a tag > ele=6288 ft > for Mount Washington (showing my East Coast bias). > > It would be good to explicitly state that in keeping with convention, > ft means international feet, perhaps with a parenthetical comment that > if someone meant US Survey Feet they would have written ftUS. Maybe > this is already documented. > As far as I know, Survey Feet are used only for horizontal measurements, mostly in state plane coordinates. And I don't think that there are yet any elevations, anywhere, for which precision to 2 parts per million matters. > Further, WGS84's first height definition is ellipsoidal height, and > that simply is not elevation. Obviously elevation should be in "WGS84 > Orthometric Height", which is what GPS receivers provide as elevation. > But elevations are not published in WGS Orthometric Height; they are > published in a national or regional datum which is pretty close, as > all datums at least roughly target a similar origin. > In newer datums than WGS84, even horizontal position is reported relative to an epoch, with corrections for phenomena like continental drift. I've hiked to one of the stations used for such geodesy - a copper bolt placed in 1870 in truly ancient and stable rock (Hawkeye Gneiss, ~1.15 Ga) with accuracy that would have been considered first-order even a century after its placement. The difference between survey feet and international feet for horizontal coordinates is significant, because in UTM coordinates, the 2 part-per-million error adds up to 20 metres in the polar regions (or 10 or so in the mid-latitudes). It's somewhat less significant over the smaller range of state plane coordinates, which is why most states don't plan to do anything about it until 2025 at the earliest. In a few 'bad' planes like Nevada North and Michigan East, the origins are far enough outside the state that the errors can be about 15 m. Many "authoritative, official" data sets that I've worked with appear to suffer from mixed horizontal datums, with NAD27 coordinates mistakenly transferred over into WGS84 uncorrected. When working with county tax maps, for instance, I always try to spot-check things like street intersections or monumented corners, to make sure what datum I'm working with, because it's often not what the map claims to be. Sometimes the error is backward - the county has never made the conversion of its systems off of NAD27, but WGS84 data have crept in! But for vertical coordinates, I'm willing to wager that no mapper has the technology to measure absolute elevation to less than a mm. In fact, I doubt that it's even meaningful to discuss that sort of precision in elevation. The geoid isn't defined to that accuracy. So I can easily live with the ambiguity in which 'ft' are used. (Moreover, I can't think of any OSM tag at the moment in which a measure in feet would need a few parts in 10**-6 precision.) I'd certainly approve of a proposal optionally to tag elevations with the vertical datum used - but since the differences are typically on the order of 1-2 metres, I surely don't insist on such a tag! I understand that most GPS units use GRS80+EGM1984, but I'm sure that NAVD88 has crept in, even among objects that I've mapped. And I betcha there's a ton of uncorrected NGVD1929 in TIGER. For a metre or two, who cares (yet?). But I'll roundly condemn anyone who confuses height-above-ellipsoid with elevation! (I'm looking at you, Android Location Services!) Changes in vertical datum together with LIDAR data have wrought confusion among some of the hiking clubs around here, who maintain lists like the Adirondack 46'ers (the 46 summits in the Adirondacks thought at the time of the list's compilation to exceed 4000 feet elevation) or the Catskill 3500's (the 34 summits thought at the time of compilation to exceed 3500 feet, plus Leavitt Peak - which had escaped the notice of the people who compiled the list, and minus Doiubletop and Mt Graham - which are now off-limits to hikers). The uniform decision of the clubs was to ignore the problem and simply say that the lists are by now traditional - it's _these_ summits, and no others. Most Adirondack 46'rs also climb Mt MacNaughton, which was not on the list, but was revealed in a 1953 survey to exceed 4000 feet. But then the change
Re: [Tagging] Feature proposal - RFC - Documenting feet as an an optional elevation unit
0.3048 m according to my ConvertPad app on my phone - and according to Wikipedia (so that must be true!) Regards,Peter (PeterPann99) On Sunday, 28 January 2024 at 19:36:06 GMT, Philip Barnes wrote: The legal definition of a foot is of course 0.348 m. "Since an international agreement in 1959, the foot is defined as equal to exactly 0.3048 metres'. Phil (trigpoint) On 28 January 2024 18:57:45 GMT, Minh Nguyen wrote: Vào lúc 04:08 2024-01-28, Greg Troxel đã viết: Minh Nguyen writes: Vào lúc 19:50 2024-01-27, Brian M. Sperlongano đã viết: Uh so I did the math, and unless I've got this wrong, the difference between survey feet and international feet for tagging, let's say, Mount Everest, is less than seven one-hundredths of an inch. So I'm really not even sure why we're discussing it beyond the fact that we're all nerds about this sort of thing. You got me. :-) The actual proposal doesn't mention the foot's two definitions at all, and so far I'm planning to keep it that way. I think it's important to be definitionally correct, even if it doesn't really matter. It's a slippery slope, and pretty soon \pi is 3. Poor Indiana. ;-) The definition of the foot would apply to the ' and ft abbreviations in every context, not just the ele=* key, so I'd suggest considering it separately, probably without the formality of a vote. The main unit symbol listing has come together more informally over the years. [1] Sooner or later, OpenHistoricalMap will have a lot of fun with this issue... [1] https://wiki.openstreetmap.org/wiki/Map_features/Units ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature proposal - RFC - Documenting feet as an an optional elevation unit
The legal definition of a foot is of course 0.348 m. "Since an international agreement in 1959, the foot is defined as equal to exactly 0.3048 metres'. Phil (trigpoint) On 28 January 2024 18:57:45 GMT, Minh Nguyen wrote: >Vào lúc 04:08 2024-01-28, Greg Troxel đã viết: >> Minh Nguyen writes: >> >>> Vào lúc 19:50 2024-01-27, Brian M. Sperlongano đã viết: Uh so I did the math, and unless I've got this wrong, the difference between survey feet and international feet for tagging, let's say, Mount Everest, is less than seven one-hundredths of an inch. So I'm really not even sure why we're discussing it beyond the fact that we're all nerds about this sort of thing. >>> >>> You got me. :-) The actual proposal doesn't mention the foot's two >>> definitions at all, and so far I'm planning to keep it that way. >> >> I think it's important to be definitionally correct, even if it doesn't >> really matter. It's a slippery slope, and pretty soon \pi is 3. > >Poor Indiana. ;-) The definition of the foot would apply to the ' and ft >abbreviations in every context, not just the ele=* key, so I'd suggest >considering it separately, probably without the formality of a vote. The main >unit symbol listing has come together more informally over the years. [1] > >Sooner or later, OpenHistoricalMap will have a lot of fun with this issue... > >[1] https://wiki.openstreetmap.org/wiki/Map_features/Units > >-- >m...@nguyen.cincinnati.oh.us > > > >___ >Tagging mailing list >Tagging@openstreetmap.org >https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature proposal - RFC - Documenting feet as an an optional elevation unit
Vào lúc 04:08 2024-01-28, Greg Troxel đã viết: Minh Nguyen writes: Vào lúc 19:50 2024-01-27, Brian M. Sperlongano đã viết: Uh so I did the math, and unless I've got this wrong, the difference between survey feet and international feet for tagging, let's say, Mount Everest, is less than seven one-hundredths of an inch. So I'm really not even sure why we're discussing it beyond the fact that we're all nerds about this sort of thing. You got me. :-) The actual proposal doesn't mention the foot's two definitions at all, and so far I'm planning to keep it that way. I think it's important to be definitionally correct, even if it doesn't really matter. It's a slippery slope, and pretty soon \pi is 3. Poor Indiana. ;-) The definition of the foot would apply to the ' and ft abbreviations in every context, not just the ele=* key, so I'd suggest considering it separately, probably without the formality of a vote. The main unit symbol listing has come together more informally over the years. [1] Sooner or later, OpenHistoricalMap will have a lot of fun with this issue... [1] https://wiki.openstreetmap.org/wiki/Map_features/Units -- m...@nguyen.cincinnati.oh.us ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature proposal - RFC - Documenting feet as an an optional elevation unit
Minh Nguyen writes: > Vào lúc 19:50 2024-01-27, Brian M. Sperlongano đã viết: >> Uh so I did the math, and unless I've got this wrong, the difference >> between survey feet and international feet for tagging, let's say, >> Mount Everest, is less than seven one-hundredths of an inch. So I'm >> really not even sure why we're discussing it beyond the fact that >> we're all nerds about this sort of thing. > > You got me. :-) The actual proposal doesn't mention the foot's two > definitions at all, and so far I'm planning to keep it that way. I think it's important to be definitionally correct, even if it doesn't really matter. It's a slippery slope, and pretty soon \pi is 3. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature proposal - RFC - Documenting feet as an an optional elevation unit
Vào lúc 19:50 2024-01-27, Brian M. Sperlongano đã viết: Uh so I did the math, and unless I've got this wrong, the difference between survey feet and international feet for tagging, let's say, Mount Everest, is less than seven one-hundredths of an inch. So I'm really not even sure why we're discussing it beyond the fact that we're all nerds about this sort of thing. You got me. :-) The actual proposal doesn't mention the foot's two definitions at all, and so far I'm planning to keep it that way. -- m...@nguyen.cincinnati.oh.us ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature proposal - RFC - Documenting feet as an an optional elevation unit
Uh so I did the math, and unless I've got this wrong, the difference between survey feet and international feet for tagging, let's say, Mount Everest, is less than seven one-hundredths of an inch. So I'm really not even sure why we're discussing it beyond the fact that we're all nerds about this sort of thing. On Sat, Jan 27, 2024 at 8:02 PM Greg Troxel wrote: > Minh Nguyen writes: > > > This proposal is using the ' symbol instead of the deprecated ft > > symbol, but in practice almost every data consumer understands both > > symbols equally. If someone feels strongly that ft would be less > > error-prone, I'd encourage them to start a new proposal that would > > affect other keys as well. > > I'm ok with that, but I didn't figure it out from the link. > > >>It would be good to explicitly state that in keeping with convention, > >>ft means international feet, perhaps with a parenthetical comment > that > >>if someone meant US Survey Feet they would have written ftUS. Maybe > >>this is already documented. > > > > As far as I know, no one has ever explicitly tagged a measurement in > > survey feet (as opposed to a survey _on_ feet). As you point out, it's > > a very small difference. I mainly brought it up because I didn't want > > to have to simultaneously propose new unit symbols, which would > > require developer intervention. Some imports have introduced very > > high-precision values, but this is probably not a good practice to > > optimize around. > > Agreed; I just meant to add a parenthetical clarification. > > > You can definitely count me among those whose eyes glaze over whenever > > datums enter the conversation, as they always seem to when discussing > > nationwide imports these days. I'm glad we have folks like you who get > > it. > > > > Hopefully it's OK to leave these issues out of the proposal's scope; I > > fear it would quickly sink the proposal because we don't have a very > > good handle on the datums that have already been used all over the > > map. We're only now starting to clean up incorrectly transformed GNIS > > features and TIGER boundaries from, what, 14 years ago, to say nothing > > of more recent imports. > > Yes, I think it's fine. All of those issues apply equally to elevations > in meters, and using feet does not make them any worse or harder > > >>Practically, people type in numbers from a sign, and this sign was > >>probably copied from some earlier sign, and may be in some ancient > >>datum, and may have been erroneous. This proposal has no bearing on > >>that, and that's ok. > > > > Yes, I'm very much approaching this key from the perspective of > > documenting what the world says about itself on the ground. More > > mission-critical applications of this elevation data would have their > > work cut out for them... > > Sure, but we should be careful because we do not as lat/lon coordinates > of objects the values chiseled in stone on the store front. We use > measurements and our best guess based imagery, etc. Elevation 100% > should be a similar process of the mapper's best estimate of the true > value. Writing down a sign value is acceptable as an approximation of > that. > > This is entirely different from using a signed name in the name tag. > The the self-labeled name is by definition the right answer. With > elevation, it is not. > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature proposal - RFC - Documenting feet as an an optional elevation unit
Minh Nguyen writes: > This proposal is using the ' symbol instead of the deprecated ft > symbol, but in practice almost every data consumer understands both > symbols equally. If someone feels strongly that ft would be less > error-prone, I'd encourage them to start a new proposal that would > affect other keys as well. I'm ok with that, but I didn't figure it out from the link. >>It would be good to explicitly state that in keeping with convention, >>ft means international feet, perhaps with a parenthetical comment that >>if someone meant US Survey Feet they would have written ftUS. Maybe >>this is already documented. > > As far as I know, no one has ever explicitly tagged a measurement in > survey feet (as opposed to a survey _on_ feet). As you point out, it's > a very small difference. I mainly brought it up because I didn't want > to have to simultaneously propose new unit symbols, which would > require developer intervention. Some imports have introduced very > high-precision values, but this is probably not a good practice to > optimize around. Agreed; I just meant to add a parenthetical clarification. > You can definitely count me among those whose eyes glaze over whenever > datums enter the conversation, as they always seem to when discussing > nationwide imports these days. I'm glad we have folks like you who get > it. > > Hopefully it's OK to leave these issues out of the proposal's scope; I > fear it would quickly sink the proposal because we don't have a very > good handle on the datums that have already been used all over the > map. We're only now starting to clean up incorrectly transformed GNIS > features and TIGER boundaries from, what, 14 years ago, to say nothing > of more recent imports. Yes, I think it's fine. All of those issues apply equally to elevations in meters, and using feet does not make them any worse or harder >>Practically, people type in numbers from a sign, and this sign was >>probably copied from some earlier sign, and may be in some ancient >>datum, and may have been erroneous. This proposal has no bearing on >>that, and that's ok. > > Yes, I'm very much approaching this key from the perspective of > documenting what the world says about itself on the ground. More > mission-critical applications of this elevation data would have their > work cut out for them... Sure, but we should be careful because we do not as lat/lon coordinates of objects the values chiseled in stone on the store front. We use measurements and our best guess based imagery, etc. Elevation 100% should be a similar process of the mapper's best estimate of the true value. Writing down a sign value is acceptable as an approximation of that. This is entirely different from using a signed name in the name tag. The the self-labeled name is by definition the right answer. With elevation, it is not. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature proposal - RFC - Documenting feet as an an optional elevation unit
Vào lúc 16:01 2024-01-27, Greg Troxel đã viết: I would expect the proposal to give an example. It seems that one would have a tag ele=6288 ft for Mount Washington (showing my East Coast bias). Thanks, I added this to the existing examples [1], though the summit sign unusually states the elevation in both units. This proposal is using the ' symbol instead of the deprecated ft symbol, but in practice almost every data consumer understands both symbols equally. If someone feels strongly that ft would be less error-prone, I'd encourage them to start a new proposal that would affect other keys as well. It would be good to explicitly state that in keeping with convention, ft means international feet, perhaps with a parenthetical comment that if someone meant US Survey Feet they would have written ftUS. Maybe this is already documented. As far as I know, no one has ever explicitly tagged a measurement in survey feet (as opposed to a survey _on_ feet). As you point out, it's a very small difference. I mainly brought it up because I didn't want to have to simultaneously propose new unit symbols, which would require developer intervention. Some imports have introduced very high-precision values, but this is probably not a good practice to optimize around. There is a much more serious problem in that few seem to understand that elevation is only meaningful relative to a vertical datum. OSM documents WGS84. Even fewer understand that this is a mess because WGS84 is an ensemble containing a low-accuracy member (WGS84(TRANSIT)), and that the only reasonable interpretation is that data should be expressed in the most recent realization. Further, WGS84's first height definition is ellipsoidal height, and that simply is not elevation. Obviously elevation should be in "WGS84 Orthometric Height", which is what GPS receivers provide as elevation. But elevations are not published in WGS Orthometric Height; they are published in a national or regional datum which is pretty close, as all datums at least roughly target a similar origin. You can definitely count me among those whose eyes glaze over whenever datums enter the conversation, as they always seem to when discussing nationwide imports these days. I'm glad we have folks like you who get it. Hopefully it's OK to leave these issues out of the proposal's scope; I fear it would quickly sink the proposal because we don't have a very good handle on the datums that have already been used all over the map. We're only now starting to clean up incorrectly transformed GNIS features and TIGER boundaries from, what, 14 years ago, to say nothing of more recent imports. Practically, people type in numbers from a sign, and this sign was probably copied from some earlier sign, and may be in some ancient datum, and may have been erroneous. This proposal has no bearing on that, and that's ok. Yes, I'm very much approaching this key from the perspective of documenting what the world says about itself on the ground. More mission-critical applications of this elevation data would have their work cut out for them... [1] https://wiki.openstreetmap.org/wiki/Special:Diff/2654695 -- m...@nguyen.cincinnati.oh.us ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature proposal - RFC - Documenting feet as an an optional elevation unit
As someone not happy about the deprecation of mailinglists, a few brief comments here: First, I think this proposal is fine, as documenting widespread practice. Regardless of my further comments, I think it's solidly progress to adopt it. While yonur comments about survey feet are valid, modern elevations (NAVD88) are as far as I can tell actually in meters, and when expressed in feet, in international feet. Elevations are small enough that 2 ppm is less than the errors in the values. I would expect the proposal to give an example. It seems that one would have a tag ele=6288 ft for Mount Washington (showing my East Coast bias). It would be good to explicitly state that in keeping with convention, ft means international feet, perhaps with a parenthetical comment that if someone meant US Survey Feet they would have written ftUS. Maybe this is already documented. There is a much more serious problem in that few seem to understand that elevation is only meaningful relative to a vertical datum. OSM documents WGS84. Even fewer understand that this is a mess because WGS84 is an ensemble containing a low-accuracy member (WGS84(TRANSIT)), and that the only reasonable interpretation is that data should be expressed in the most recent realization. Further, WGS84's first height definition is ellipsoidal height, and that simply is not elevation. Obviously elevation should be in "WGS84 Orthometric Height", which is what GPS receivers provide as elevation. But elevations are not published in WGS Orthometric Height; they are published in a national or regional datum which is pretty close, as all datums at least roughly target a similar origin. Practically, people type in numbers from a sign, and this sign was probably copied from some earlier sign, and may be in some ancient datum, and may have been erroneous. This proposal has no bearing on that, and that's ok. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
