Hi Karl and Andy, Thank you for your feedback.
Karl wrote: > Why not: Use that spatial database (or the raw SRTM grid) to interpolate the > elevation > of existing way nodes and then add "ele" tags to those nodes instead of > creating > new nodes only at the grid points (and with no other information)? In that case I will store the SRTM grid in a temporary location and will not create the nodes. The reason I wanted these nodes is that they are useful to have around in unexplored areas. A future version of JOSM / Potlatch could show these points as an aid to the user. I can write a script that adds elevation to all new nodes that do not have elevation information. Andy wrote: > If I can make a suggestion it would be to think of the heights along > each way, instead of just at nodes. If you look at the cycle map at > http://www.gravitystorm.co.uk/osm/ you can see SRTM contours with OSM > data overlaid. It's quite possible for a way to be straight yet cross > a valley or a peak, and if you only look at the nodes at each end of a > section you would miss this data. This is especially apparent for long > straight features like motorways or roads in the USA where the gap > between nodes can be many hundreds of metres or even kilometers, and > the same may apply to Australia too. So instead of importing the > heights as points and estimating the height of each node, I would > suggest a different approach: > > * Import the SRTM data into a spatial database (i.e. postgis) as > polylines (contours) > * Calculate the points along the OSM way where the way intersects a contour > * Use these points as the height data for the way I had not thought about those long roads. I could change my approach to solve that problem, perhaps while still using the original grid data. 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 actually provides real information about these points along long ways. It is just that the latitude and longitude are not reliable, only the altitude is. A future reputation system should then keep in mind that lon&lat data created by the user SRTM_Bot is not reliable, but its altitude data is more reliable. This may actually, as a side effect, also alleviate the problem that in [EMAIL PROTECTED] some large objects spanning multiple tiles are not rendered: http://wiki.openstreetmap.org/index.php/[EMAIL PROTECTED]/Problems About the contour data. Do you think that this derived data could actually be more reliable? I guess it is certainly more reliable than the crude interpolation that I had in mind. In that case, I will add to my proposal that I also calculate the position & altitude of nodes based on the intersection of ways with contour lines. Kind regards, Sjors On Sat, Mar 29, 2008 at 12:42 AM, Karl Newman <[EMAIL PROTECTED]> wrote: > On Fri, Mar 28, 2008 at 6:32 PM, Andy Allan <[EMAIL PROTECTED]> wrote: > > 2008/3/27 Sjors Provoost <[EMAIL PROTECTED]>: > > > > > My core objectives / deliverables are: > > > import SRTM data as nodes (points) in OSM, for Australia > > > estimate the altitude of each node in Australia from the SRTM nodes > > > display (on the fly) an altitude profile given a route (a sequence of > > > nodes) > > > estimate the altitude of each node in Australia from nearby GPS traces > > > analyze the difference between both methods _______________________________________________ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
