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

[Steve Hill]

Sjors Provoost wrote:

> There was a lot of discussion about this issue and good arguments
> against my solution, which is why I included step 4: to apply
> different methods and compare them. I've now included real time
> calculation of altitude from SRTM data.

I don't think you have explained what the benefits of your solution are? 
  What is the benefit of including this data in the OSM database rather 
than having a separate "elevation server" which you can hand a list of 
lat/lon tuples and get a list of elevations derived from the SRTM dataset.

Surveying and putting elevation data in the node is a sensible idea (but 
the editors should do something like erase the elevation if someone 
moves the node).  However, what you are suggesting is not surveying for 
each node - you are suggesting interpolating from an existing data set 
and I think this will lead to inaccurate and misleading elevation data 
being recorded at the node.

For example, the elevation data for a path along the edge of a high 
cliff is going to be very inaccurate because you will be interpolating 
between a sample on top of the cliff and a sample below the cliff.  If 
the node were surveyed properly, you would know the actual elevation of 
the node instead of the inaccurate interpolated height.

> If I include extra nodes with lower horizontal accuracy, there has to
> be a way to tag them as such.

Which means all the programs which handle the data have to handle your 
nodes in a special way.  It doesn't seem like a good solution to me.

> I am not sure whether adding extra points for long roads really has
> such a big effect on the size of the planet file; if most of the
> database consists of windy roads and dense cities, there may be only a
> few ways that need extra nodes. I could ignore any way that has more
> than 1 node every 200 meters or so.

Not only are you adding new nodes (I suspect this will be a significant 
number since there are a lot of roads with low node frequency, such as 
motorways), but you are also adding several new tags to the 230 million 
existing nodes - this is a significant amount of data (there are about 
750 million tags on nodes at the moment, so the amount you are proposing 
adding is a significant proportion).

> I am not saying all will be fine, but I think it is worth trying and
> comparing with other methods. It would be great to have a true 3D map,
> especially when in a (far?) future you want to do Google Earth and KML
> like things.

Yes, it would be great to have a true 3D map, but I don't think you have 
made your case as to why you need to add this data into the main OSM 
database instead of keeping it separate.  Also, if you want to do 
something like Google Earth, you're going to need elevations for all of 
the land, not just the nodes along ways.

-- 

  - Steve
    xmpp:steve at nexusuk.org   sip:steve at nexusuk.org   http://www.nexusuk.org/

      Servatis a periculum, servatis a maleficum - Whisper, Evanescence