[Tagging] Feature proposal - RFC - Documenting feet as an an optional elevation unit

[Brian M. Sperlongano]

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 <gdt at lexort.com> wrote:

> Minh Nguyen <minh at nguyen.cincinnati.oh.us> 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 at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20240127/e6c2fe1d/attachment-0001.htm>