Hi Steve, Thanks for your long reply.
> Sjors Provoost wrote: > > 2 - estimate the altitude of each node (point) in Australia from the > > neighboring SRTM points > > Remember to put a source tag on the data (maybe we need a source:ele tag > instead to show only the elevation data came from SRTM?) I was thinking about entering as a user with a name like 'SRTM-bot', so it does not need any special status or treatment. I will work out your suggestion as well, so people can choose. In general I want to build a 'modest' system, that doesn't touch other peoples work, but only fills in the gaps. > I am also concerned that elevation tags will become more inaccurate as > nodes are moved - you should think about adding some support into the > editors to warn people when they move nodes with elevation data attached and > ask them if they want to remove the elevation data. In the detailed version of my proposal I considered that situation. One solution I can think of is to automatically recalculate the altitude of a moved node, unless anyone changed it manually. With such a solution, there will be a bot that constantly calculates the altitude of new and changed nodes. The bot will not touch any altitude data entered by others, it will just be a default for users that do not provide altitude data. I will look at the effect on performance and usability / desirability of such a bot. It may also be useful to present the user with the altitude profile of the road he/she is working on. > > 3 - add extra nodes along long ways with few far-between nodes > > > > I'm unconvinced this is a good idea since you're introducing nodes which > could well have very inaccurate lat/lon data. Nodes are usually considered > to be relatively accurate since they are (generally) positioned by using > some real data (GPS track, photos, etc). What you are proposing introduces > a lot of nodes that have very little relation to the real world and for > which the elevation data will become inaccurate if someone moves them to > better represent the real world. > > I'm convinced that it is preferable to keep the SRTM data separate and just > calculate the intersection of the SRTM data with a way when producing an > altitude profile. The SRTM data could, of course, be pulled from a server > rather than having to keep the data set locally. I just don't think > polluting the OSM database with many potentially inaccurate nodes is a good > idea. 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. If I include extra nodes with lower horizontal accuracy, there has to be a way to tag them as such. If people move them to a new horizontal position, I can use one of the methods above to recalculate altitude. Unless a user also specifies the correct altitude, in which case I won't touch it. Also in order to reduce the number of additional and potentially inaccurate nodes, I will ignore ways that have more than 1 node every 200 meters or so. I could also add a criterion for straightness; e.g. only add nodes on very straight interstates. See also below about this. > > * apply to the whole planet > > If you are adding extra nodes this will massively increase the size of the > OSM data set. 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. 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. > Also, consider how you are going to handle nodes which already have an ele > tag - are you going to leave them alone? What about comparing the height > you calculate with the existing ele tag and do something smart if they are > grossly different (e.g. tag the node with a warning that the elevation > should be checked) I will make a comparison for some (or all?) of these cases, but probably I will not touch them, apart from a warning tag. > > * update render tool to show when roads do not intersect at equal hight > > > > I'm not sure what this means - a junction is a node which is a member of > multiple ways - that node is going to have a single elevation tag so all the > roads using it *must* have the same elevation (there is no other way of > expressing the junction). > > If you are talking about ways crossing without a junction (i.e. no shared > node), I'm unconvinced the elevation data is high enough resolution to make > a meaningful judgment as to whether the roads are at the same height as each > other. I was referring to the second part. The SRTM data will not be useful for this, but someone might edit the elevation data to put one road 10 meters above another one (whether that will be possible depends on the methodology of course). Even if the absolute elevation of both these roads is wrong, a rendering tool could show which road is on top. Kind regards, Sjors _______________________________________________ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
