Minh Nguyen <[email protected]> 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 [email protected] https://lists.openstreetmap.org/listinfo/tagging
