[OSM-dev] Altitude data & (cycle) route profiles
steve at nexusuk.org
Sun Apr 6 16:47:13 BST 2008
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.
xmpp:steve at nexusuk.org sip:steve at nexusuk.org http://www.nexusuk.org/
Servatis a periculum, servatis a maleficum - Whisper, Evanescence
More information about the dev