[OSM-dev] Altitude data & (cycle) route profiles
miles.togoe at gmail.com
Mon Mar 31 15:40:08 BST 2008
Andy Robinson (blackadder) wrote:
> 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.
what is the accuracy on regular GPS elevation ? +- ? Here in mountain
territory we deal with a lot of roads and trails that may change 100's
of feet (or meters), thus even a low accuracy of +- 5-10 ft would still
be a help. And likewise to show off big things like the Chunnel or the
high bridge in France....
If accuracy is worse, well I guess you have a good point. Otherwise, we
could use it with a notice about the accuracy levels. At least it's a
start and accuracy can always be improved by manual editing.
I really see the value more in the near future when our tools are more
3-D but we are seeing the beginnings with Google Earth (and some SoC
projects are adding some 3-D to Inkscape. I would think(hope) GPS
elevation instruments might get more accurate as well. Re: grades
along ways, it's a good idea from the data perspective, but it may not
be too practical for people to measure in the field as they are hiking
or riding and their GPS is just collecting data.
More information about the dev