[OSM-dev] Altitude data & (cycle) route profiles
gravitystorm at gmail.com
Sat Mar 29 12:47:54 GMT 2008
On Sat, Mar 29, 2008 at 11:28 AM, Frederik Ramm <frederik at remote.org> wrote:
> 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 agree with Frederik here, and I'd say that both adding extra nodes
to ways and in fact adding SRTM-derived heights to the db are a bad
idea. All the SRTM values you use are simply extrapolations, and the
values that you use are only correct for your method or algorithm. Do
you use the nearest SRTM points, or a 3x3 weighted grid (or 4x4 etc);
how do you cope with voids, and so on. It should be kept out of the
database and added to whichever application (the cycle map, route
profiles etc) as and when needs be. There is nothing to be gained, and
lots to be lost, from adding this data to the database directly.
> 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.
> Frederik Ramm ## eMail frederik at remote.org ## N49°00'09" E008°23'33"
> dev mailing list
> dev at openstreetmap.org
More information about the dev