Some nodes have altitiude (or alt) tag if the altitude is well known
(mountain peaks etc) as vertical precision of GPS is so inaccurate.
You can convert srtm data into OSM vector contours with
http://wiki.openstreetmap.org/wiki/Srtm2Osm
A general page about visualizing relief (including other
Hi,
In terms of altitude information, am I correct in thinking that integrating the
SRTM data (http://www2.jpl.nasa.gov/srtm/) is the
accepted approach to creating altitude based maps?
I have seen key=altitude in some of the OSM data, but not comprehensively. Is
there a SRTM enhanced version
On Mon, Dec 8, 2008 at 3:22 AM, Philip Fitzsimons [EMAIL PROTECTED]wrote:
Hi,
In terms of altitude information, am I correct in thinking that integrating
the SRTM data (http://www2.jpl.nasa.gov/srtm/) is the
accepted approach to creating altitude based maps?
I have seen key=altitude in
On Sun, 6 Apr 2008, Sjors Provoost wrote:
1 - import SRTM data for (part of) Australia
2 - write several algorithms to estimate the height of any given
coordinate (server side), using original STRM grid
3 - display (on the fly) an altitude profile given a route (a sequence
of nodes). Drawing
Steve Hill wrote:
Initially I would like to use Gnuplot for the visualization, because
it is simple to use. However, if time permits, I would like to
generate the profile plot client side and more fancy. The client will
simply receive a list of (x,y) coordinates from the server.
ISTR
Sjors Provoost wrote:
(Much of the below has already been said by other people, but I thought
I should express my views)
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
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
On Sun, Apr 6, 2008 at 2:43 PM, Sjors Provoost [EMAIL PROTECTED] wrote:
I was thinking about entering as a user with a name like 'SRTM-bot',
Sjors,
I urge you as strongly as I can - please DO NOT put SRTM-derived
height data into the OSM database.
One solution I can think of is to
Sjors Provoost wrote:
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.
I don't think you have explained what
Andy wrote:
I urge you as strongly as I can - please DO NOT put SRTM-derived
height data into the OSM database.
And Steve wrote:
I don't think you have explained what the benefits of your solution are?
What is the benefit of including this data in the OSM database rather than
having
a
Hello everyone,
Thank you for all the feedback and discussion about my proposal. It
seems clear to me that I should consider several approaches for
incorporating altitude data. It also became clear to me that using the
GPS data is probably not a good idea. I have made several changes to
my
On Mar 31, 2008, at 12:00, Andy Robinson (blackadder) wrote:
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
On Mon, Mar 31, 2008 at 4:02 PM, Robert Vollmert
[EMAIL PROTECTED] wrote:
On Mar 31, 2008, at 12:00, Andy Robinson (blackadder) wrote:
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
Andy Robinson (blackadder) wrote:
Sjors Provoost wrote:
Sent: 30 March 2008 12:06 PM
To: MilesTogoe
Cc: dev@openstreetmap.org; Karl Newman
Subject: Re: [OSM-dev] Altitude data (cycle) route profiles
On Sat, Mar 29, 2008 at 3:14 PM, MilesTogoe [EMAIL PROTECTED] wrote:
Frederik
Robert Vollmert wrote:
Not sure how common they are, but there's some GPS units with built-in
barometer (Garmin Etrex Vista HCX at least). The data they provide
should be good enough to be useful.
Those sensors need calibration against a known point and can give a huge
offset when
Lambertus wrote:
Robert Vollmert wrote:
Not sure how common they are, but there's some GPS units with built-in
barometer (Garmin Etrex Vista HCX at least). The data they provide
should be good enough to be useful.
Those sensors need calibration against a known point and can
From: MilesTogoe [mailto:[EMAIL PROTECTED] wrote:
Sent: 31 March 2008 3:40 PM
To: Andy Robinson (blackadder)
Cc: 'Sjors Provoost'; dev@openstreetmap.org; 'Karl Newman'
Subject: Re: [OSM-dev] Altitude data (cycle) route profiles
what is the accuracy on regular GPS elevation ? +- ? Here
On Mon, Mar 31, 2008 at 11:28 AM, Andy Robinson (blackadder)
[EMAIL PROTECTED] wrote:
From: MilesTogoe [mailto:[EMAIL PROTECTED] wrote:
Sent: 31 March 2008 3:40 PM
To: Andy Robinson (blackadder)
Cc: 'Sjors Provoost'; dev@openstreetmap.org; 'Karl Newman'
Subject: Re: [OSM-dev] Altitude data
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)
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 Wed, Mar 26, 2008 at 11:20 PM, Sjors Provoost [EMAIL PROTECTED] wrote:
Hi there,
I would to participatie in the Google Summer of Code and contribute to
OpenStreetMap. There are several projects on the wiki that I consider
interesting, but I'll start with asking some questions about the
21 matches
Mail list logo