[OSM-dev] Altitude data & (cycle) route profiles
sjors at sprovoost.nl
Sun Mar 30 12:05:53 BST 2008
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 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.
> > 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.
More information about the dev