[Talk-us] Elevation in local units

Wed Mar 25 03:25:39 UTC 2015

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 <steve at 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:kliems at gmail.com] 
> Sent: Tuesday, March 24, 2015 7:18 PM
> To: Steve Friedl; talk-us at 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 <steve at unixwiz.net <mailto:steve at 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
> steve at unixwiz.net <mailto:steve at unixwiz.net> | Southern California | Windows Guy |  unixwiz.net <http://unixwiz.net/>
>  
> _______________________________________________
> Talk-us mailing list
> Talk-us at openstreetmap.org <mailto:Talk-us at openstreetmap.org>
> https://lists.openstreetmap.org/listinfo/talk-us <https://lists.openstreetmap.org/listinfo/talk-us>_______________________________________________
> Talk-us mailing list
> Talk-us at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-us/attachments/20150324/a1232f7f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1868 bytes
Desc: not available
URL: <http://lists.openstreetmap.org/pipermail/talk-us/attachments/20150324/a1232f7f/attachment-0001.bin>