[OSM-dev] Altitude data & (cycle) route profiles

Andy Robinson (blackadder) blackadderajr at googlemail.com
Mon Mar 31 11:00:35 BST 2008

Sjors Provoost wrote:
>Sent: 30 March 2008 12:06 PM
>To: MilesTogoe
>Cc: dev at openstreetmap.org; Karl Newman
>Subject: Re: [OSM-dev] Altitude data & (cycle) route profiles
>On Sat, Mar 29, 2008 at 3:14 PM, MilesTogoe <miles.togoe at gmail.com> wrote:
>> Frederik Ramm wrote:
>>  > Hi,
>>  >> I was thinking about adding nodes to long ways. This may sound a bit
>>  >> ugly at first, but not if you consider the fact that the SRTM
>>  >> provides real information about these points along long ways. It is
>>  >> just that the latitude and longitude are not reliable, only the
>>  >> altitude is.
>>  >>
>>  >
>>  > Doesn't sound very good to me, adding nodes to existing ways just to
>>  > import height... I'd rather have the height as a separate info. Much
>>  > like a road that enters a forest; I don't put a node at that point
>>  > just to say that this node represents the road entering the forest - I
>>  > just model the forest as an extra entity and whoever needs to can
>>  > compute the point.
>>  >
>>  > Also, having SRTM data as nodes in OSM touches on the often discussed
>>  > topic of immutable data. Would it be ok for people to edit individual
>>  > SRTM nodes?
>>  >
>>  > I'd also recommend to first do an analysis about the impact on OSM
>>  > altogether, i.e. by how much would the planet file grow by importing
>>  > SRTM data like you suggest? If renderers would start to use that
>>  > information, then we'd suddenly have not a single "empty" tile
>>  > anymore, every land tile on the planet would have information on it
>>  > (right?), how would taht impact storage requirements for tile servers
>>  > etc.? - Not saying that any of these could be a show-stopper, it's
>>  > just that such an analysis should be part of the plan.
>>  >
>>  Actually the vertical inflection points (bottom, change, or top of
>>  vertical curve) along a way are very useful points to have even if they
>>  are along a tangent section.   The inflection points are used for sight
>>  distance, drainage issues, calculation of grade or steepness,
>>  calculation of traveled distance, etc.  Each node and inflection point
>>  should have the lat, long, and elevation.  A straight line but up and
>>  down way will have a greater travel distance than a flat way.  As a
>>  civil engineer, I've always thought 2-D points are lacking and should
>>  always be 3-D points.   Is it more storage, processing/retrieval cost ?
>>  Sure, but it's important data.
>I agree with Frederik that the SRTM nodes might not be a good idea,
>because they should then be immutable.
>I tend to agree with Miles here on the need to have 3-D in stead of
>2-D nodes. My current understanding of nodes is that they represent
>*where* something is, not *what* it is. In that case I would argue
>that the altitude is part of 'where' and whether it is a forest is
>part of *what*. In that case altitude should be part of the node and
>forest should be a tag. I am also thinking about cities here; you can
>have two subways, a road and a bridge at one lat & lon position. If
>altitude is not a seperate layer of information, but part of the nodes
>that make up these subways and roads, there is no problem here.
>I also agree with Frederik about analyzing the potential impact of
>different approaches. So I will include such an analysis in the
>proposal and somewhere during the project we will have this discussion
>again with some numbers and examples so support it.

Also as a civil engineer I can see some merit in having elevation data for
physical objects in the database. However, we don't really have a good way
of collecting data that is remotely accurate to the level at which it would
be significantly useful. Non survey grade GPS just doesn't cut muster for
height data so we should never rely upon that. Even the Ordnance Survey
doesn't currently record height data from survey grade GPS.

With respect to SRTM data I think this could be used to attach height data
to existing elements in the database. Again it has limited accuracy. But
perhaps at some point in the future further surveys with better accuracy
will be made available. I don't however see that it can be used on nodes
forming part of a way, simply because anyone can move these nodes along the
way without realising the impact and adding in user tools to deal with this
will just make editing too complicated. However I could see the possibility
that slope information could be added to a way, or a relation to help define
the vertical profile of the way. The issue here though is that when a way is
split its profile characteristics change.



>Kind regards,
>dev mailing list
>dev at openstreetmap.org

More information about the dev mailing list