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

[Greg Troxel]

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.