For what it is worth, I’ve become used to looking at distances on topo maps in meters/kilometers as that is what the UTM grid is on USGS topos but I just can’t deal with elevation in meters. Maybe for relative elevations (I’ve got another 500 meters vertical to go is almost okay, but very definitely not for spot elevations.
I’ve been using OSM data mashed with DEM data from the USGS to make paper trail maps. DEM data from the USGS is also in meters by the way. What I do is convert the meters to feet in the scripts that pull data the OSM data tables. So my paper maps have contour lines (generated from metric DEM) and spot elevations (from OSM) in feet. It actually is not too hard to do. And it is easiest, at least for me, to just assume that the elevation is in meters rather than having to parse it to find a “ft” suffix. So from my point of view leaving elevation in meters and having the render deal with localization is a reasonable way to go. Cheers, Tod > On Mar 24, 2015, at 7:55 PM, Steve Friedl <st...@unixwiz.net> wrote: > > I noticed that about other items, but the key:ele wiki page defines this > clearly: it’s in meters, and this suggests to me that others using 3643_ft or > 3643ft are doing it wrong, or at least inconsistently with advertised > expectations. > > If my goal is to just make local maps look nice, I’ll just set the ele = > “3643 feet”, but at what point is it detrimental to the project as a whole to > go against specific and explicit guidance, such that it will break software > that relies on people playing well in the sandbox [by setting numeric meters]. > > Put another way: am I being selfish to just do it my own way and screw > anybody else who’s counting on me to play by the rules? > > Seems to me that it *is* reasonable to set elevation to include a number + > unit of measure, but doesn’t this kind of thing go for a proposal, get input > from others who care about the matter, standardize on formats such that > validators can validate and harmonize, and go for some kind of vote? > > I’m much too new to the project to charge ahead I that way, but I do welcome > a discussion. > > Steve > > From: Harald Kliems [mailto:kli...@gmail.com] > Sent: Tuesday, March 24, 2015 7:18 PM > To: Steve Friedl; talk-us@openstreetmap.org > Subject: Re: [Talk-us] Elevation in local units > > Hi Steve: > one tag where units are in common use is maxspeed. The default is km/h but > you can also use mph or knots. I don't see why this wouldn't be feasible for > the ele tag as well. > > If you look at taginfo, you can also see that ft is used quite a bit -- > unfortunately often in an inconsistent way, e.g. ele=3643_ft or 3643ft. > http://taginfo.openstreetmap.org/keys/ele#values > <http://taginfo.openstreetmap.org/keys/ele#values> (you have to search for ft > in the search box). > > Harald. > > On Tue, Mar 24, 2015 at 8:57 PM Steve Friedl <st...@unixwiz.net > <mailto:st...@unixwiz.net>> wrote: > Hi all, > > I appreciated being able to join my first Mappy Hour yesterday, though > without mic/camera. I’m quite enamoured with this project and hope to fit in > with the goals and the vibe. > > One thing we talked about, and I’d like to explore more formally, is how to > deal with elevation in local units. > > I lead hikes in the local Santa Ana Mountains, and there is not a single > person who hikes here, not even those from Europe or those who personally > invented the metric system, who thinks of peak elevations in meters. The > guides and the maps are all in feet, the surveying markers are in feet, as > are the topo maps. > > This is just a fact of life even if we all [including me] agree that > Americans are foolish for not adopting the metric system. > > An obvious thought is to enter the elevation including the units, so Sierra > Peak would show as “3045 feet” rather than “928”, but this won’t work. > > The wiki page for the “ele” key defines the tag as meters, so it’s reasonable > to expect that some software out there relies on this, and it would have no > provisions to convert anything on the fly because it ought to expect numeric > meters. > > But even with this aside, that still doesn’t solve the rendering problem: I > believe that page tiles are rendered as images, so it’s got to pick > *something* for the text, and I don’t think there’s any way of having a user > preference to show these things in local units. > > My suspicion is that there is no easy fix here, but I think a discussion is > in order. I’ve added a section to the key:ele page that touches on this, not > so much to propose a solution, but to let others with this same issue know > that it’s seen as an issue. > > Ref: http://wiki.openstreetmap.org/wiki/Key:ele#Local_Units > <http://wiki.openstreetmap.org/wiki/Key:ele#Local_Units> > > Is this kind of thing suitable for the key:ele page? > > Steve > > --- > Stephen J Friedl | Security Consultant | UNIX Wizard | 714 345-4571 > st...@unixwiz.net <mailto:st...@unixwiz.net> | Southern California | Windows > Guy | unixwiz.net <http://unixwiz.net/> > > _______________________________________________ > Talk-us mailing list > Talk-us@openstreetmap.org <mailto:Talk-us@openstreetmap.org> > https://lists.openstreetmap.org/listinfo/talk-us > <https://lists.openstreetmap.org/listinfo/talk-us>_______________________________________________ > Talk-us mailing list > Talk-us@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-us
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
