Re: [OSM-dev] Altitude data (cycle) route profiles
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 done server side. 5 - integrate with the main website (on a dev server) This sounds good to me. I'd also suggest considering implementing an API for clients to get at the SRTM altitude data. Ideas that spring to mind are: 1. A simplistic solution: clients can request the elevation at a given lat/lon and the server returns the interpolated elevation. 2. Slightly more complex: clients can supply two lat/lon tuples and the server returns a list of elevations along the line between them. 3. Even more complex: as with (2) but return the data as bezier (or similar) curves. You're going to need to be able to generate this data anyway, so making it accessible via an HTTP API should be quite trivial. For method 1 I will write a ruby script that imports the SRTM data and will use the source code of SRTM for inspiration. Where are you going to import it to? Consider using PostGIS since this will allow spacial referencing of the data (but you may need to experi For long straight roads there is another problem: a road may go up and down several times between two consecutive nodes. I will calculate the altitude along several extra points along this way, although this may not be very accurate. Generating parametric curves (as mentioned above) or the line between 2 points would probably be the best way of attacking this problem. For method 2 I will calculate the intersection of each way with an altitude contour. This method does not suffer from the long-straight-road problem. I'm not sure why this doesn't suffer from the same problem - the only issue I can see with ways that have very sparse nodes is that long straight sections may, in fact, not be straight in the real world (which there is nothing you can do about - the results are only as accurate as the source data). I think that method 2 will be more difficult to implement and require much more data and processing power. That's why I moved it to the secondary goals. If it turns out method 1 is resource intense and/or good enough, I will skip method 2. I posted some estimated figures for storing the entire SRTM3 data set as 10m contours in PostGIS a while ago - about half a terabyte. I think your best option is to stick with the raw grid and write a system to generate parametric curves of elevation for arbitrary vectors across it on-the-fly. 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 seeing a PHP library for generating graphs as SVG images - can't remember what it was called but something like that may be helpful. That separate server can use a stripped down version of the OSM database to improve its performance. This server doesn't really need the OSM database at all - instead of sending a list of node IDs to the server, you can just send it a list of lat/lon tuples. - Steve xmpp:[EMAIL PROTECTED] sip:[EMAIL PROTECTED] http://www.nexusuk.org/ Servatis a periculum, servatis a maleficum - Whisper, Evanescence ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] Altitude data (cycle) route profiles
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 seeing a PHP library for generating graphs as SVG images - can't remember what it was called but something like that may be helpful. There is a whole page on CSS, PHP, flash and AJAX charts that should be of help: http://www.roscripts.com/CSS_PHP_flash_and_AJAX_charts-128.html Sjors ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] Altitude data (cycle) route profiles
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 instead to show only the elevation data came from SRTM?) 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. 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. * apply to the whole planet If you are adding extra nodes this will massively increase the size of the OSM data set. 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) * 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. -- - Steve xmpp:[EMAIL PROTECTED] sip:[EMAIL PROTECTED] http://www.nexusuk.org/ Servatis a periculum, servatis a maleficum - Whisper, Evanescence ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] Altitude data (cycle) route profiles
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
Re: [OSM-dev] Altitude data (cycle) route profiles
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 automatically recalculate the altitude of a moved node This surely underlines that there is no benefit to having the SRTM data in the OSM database. If an application needs to know the SRTM-derived height of the nodes, it should calculate it as and when it needs to. You appear to have forgotten or not taken into account that there are many different algorithms for calculating the height of a given point from SRTM, and there is nothing to say that whichever algorithm you use will be the best. 3 - add extra nodes along long ways with few far-between nodes Please do not add nodes to the OSM database for this purpose. It provides no benefit to the OSM community. Thanks, Andy ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] Altitude data (cycle) route profiles
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 the benefits of your solution are? What is the benefit of including this data in the OSM database rather than having a separate elevation server which you can hand a list of lat/lon tuples and get a list of elevations derived from the SRTM dataset. Surveying and putting elevation data in the node is a sensible idea (but the editors should do something like erase the elevation if someone moves the node). However, what you are suggesting is not surveying for each node - you are suggesting interpolating from an existing data set and I think this will lead to inaccurate and misleading elevation data being recorded at the node. For example, the elevation data for a path along the edge of a high cliff is going to be very inaccurate because you will be interpolating between a sample on top of the cliff and a sample below the cliff. If the node were surveyed properly, you would know the actual elevation of the node instead of the inaccurate interpolated height. If I include extra nodes with lower horizontal accuracy, there has to be a way to tag them as such. Which means all the programs which handle the data have to handle your nodes in a special way. It doesn't seem like a good solution to me. 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. Not only are you adding new nodes (I suspect this will be a significant number since there are a lot of roads with low node frequency, such as motorways), but you are also adding several new tags to the 230 million existing nodes - this is a significant amount of data (there are about 750 million tags on nodes at the moment, so the amount you are proposing adding is a significant proportion). 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. Yes, it would be great to have a true 3D map, but I don't think you have made your case as to why you need to add this data into the main OSM database instead of keeping it separate. Also, if you want to do something like Google Earth, you're going to need elevations for all of the land, not just the nodes along ways. -- - Steve xmpp:[EMAIL PROTECTED] sip:[EMAIL PROTECTED] http://www.nexusuk.org/ Servatis a periculum, servatis a maleficum - Whisper, Evanescence ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] Altitude data (cycle) route profiles
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 separate elevation server which you can hand a list of lat/lon tuples and get a list of elevations derived from the SRTM dataset. My original idea was to convert the OSM database from 2D to 3D. Each node would then have not only latitude and longitude, but also altitude. I would populate the database with an initial guess of this altitude based on SRTM. Everyone would be free to change them, just like with latitudes and longitudes. The main advantage is that altitude would be nothing fundamentally different, which is very intuitive for me. You have made the disadvantages quite clear, so I will change my proposal. So no 3D nodes (and no interpolation). I'll get back to you quickly with the new version. Kind regards, Sjors ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] Altitude data (cycle) route profiles
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 proposal. This is the new summary: My core objectives / deliverables are: 1 - import SRTM data for Australia 2 - estimate the altitude of each node (point) in Australia from the neighboring SRTM points 3 - add extra nodes along long ways with few far-between nodes 4 - try and compare alternatives for 2 3. 5 - display (on the fly) an altitude profile given a route (a sequence of nodes) 6 - investigate methods to visualize and edit altitude data Secondary goals, if time permits: * apply to the whole planet * update editors to display and edit altitude data * update render tool to show when roads do not intersect at equal hight I have removed the GPS part of my proposal and will use that time in stead to consider the effect, problems and possibilities of altitude data in more parts of the OSM system than just the database. I also have more space to work on different approaches, in stead of just one. We can then have the discussion which one is best. Please let me know how you think about this version and if should make some more changes this weekend. Kind regards, Sjors ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] Altitude data (cycle) route profiles
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 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. 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. Cheers Robert ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] Altitude data (cycle) route profiles
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 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. 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. Cheers Robert Is the problem with non survey grade GPS that they are just inaccurate, or are they somehow biased? Are we talking about 1 meter, 10 meters or a 100 meters inaccuracy? Perhaps the average of of lot of measurements at the same spot is more reliable? Sjors ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] Altitude data (cycle) route profiles
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 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. 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
Re: [OSM-dev] Altitude data (cycle) route profiles
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 uncalibrated. I have such a GPS (GPSmap 60CSx) and never calibrate it as will most others presumably. As a cyclist all I'm interested in is the relative altitude differences not the precise actual altitude as opposed to, say, skydivers. Measuring relative altitudes is quite accurate (+/- few meters) though. The data is useless when you want to use it as a primary source, but it should be alright if you want to use it to determine offsets when compared with a known point. This requires you to process the GPX nodes trace-by-trace so you can determine the offset from which the trace started. I appose to using altitude data on nodes. E.g. one would not be able to move a node when that data is added without having to correct/remove the height data as well. Also adding altitude data invites to add -otherwise useless- nodes everywhere. I prefer to have altitude data kept apart from OSM database. Perhaps our own SRTM database corrected/enhanced using our traces. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] Altitude data (cycle) route profiles
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 give a huge offset when uncalibrated. I have such a GPS (GPSmap 60CSx) and never calibrate it as will most others presumably. As a cyclist all I'm interested in is the relative altitude differences not the precise actual altitude as opposed to, say, skydivers. Measuring relative altitudes is quite accurate (+/- few meters) though. The data is useless when you want to use it as a primary source, but it should be alright if you want to use it to determine offsets when compared with a known point. This requires you to process the GPX nodes trace-by-trace so you can determine the offset from which the trace started. I appose to using altitude data on nodes. E.g. one would not be able to move a node when that data is added without having to correct/remove the height data as well. Also adding altitude data invites to add -otherwise useless- nodes everywhere. I prefer to have altitude data kept apart from OSM database. Perhaps our own SRTM database corrected/enhanced using our traces. maybe one idea for opposing viewpoints would be to have a separate table of node elevations ie node_id, elevation I'm thinking in Rails code that anyone wanting to use elevation could do a has_one, belongs_to kind of simple relationship . ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] Altitude data (cycle) route profiles
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 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 For regular GPS receiver picking up just a handful of satellites the accuracy from GPS alone isn't much better than +/- 50m (or worse) and it doesn't get much more accurate when you have the maximum set in view. Don't ever expect GPS alone to deliver good vertical height data. Horizontal position can be established much more accurately. This is why some upper market GPS's have barometric pressure support, but as another has pointed out these need calibrating each time you go out to be reasonably accurate. Survey GPS systems work a better but still struggle to get reasonable accuracy in anything other than open space with a clear view to the maximum set of satellites. Cheers Andy 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. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] Altitude data (cycle) route profiles
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 (cycle) route profiles 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 For regular GPS receiver picking up just a handful of satellites the accuracy from GPS alone isn't much better than +/- 50m (or worse) and it doesn't get much more accurate when you have the maximum set in view. Don't ever expect GPS alone to deliver good vertical height data. Horizontal position can be established much more accurately. This is why some upper market GPS's have barometric pressure support, but as another has pointed out these need calibrating each time you go out to be reasonably accurate. snip Cheers Andy GPS vertical accuracy is much worse than horizontal accuracy because you can't receive signals from the satellites in the best location to correct your elevation (they're behind the earth from you). Andy is correct that for the best accuracy, the GPS models with barometric altimeters included need calibrating to a known pressure or elevation when you go out. However, the Garmin models do okay because they slowly auto-calibrate to the GPS elevation. Not perfect, but better than nothing. Karl ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] Altitude data (cycle) route profiles
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) estimate the altitude of each node in Australia from nearby GPS traces analyze the difference between both methods It would be great if I can get some feedback on my proposal before the deadline, so I can improve upon it. Hi Sjors, Firstly, good luck with your proposal, it sounds quite interesting to me. If I can make a suggestion it would be to think of the heights along each way, instead of just at nodes. If you look at the cycle map at http://www.gravitystorm.co.uk/osm/ you can see SRTM contours with OSM data overlaid. It's quite possible for a way to be straight yet cross a valley or a peak, and if you only look at the nodes at each end of a section you would miss this data. This is especially apparent for long straight features like motorways or roads in the USA where the gap between nodes can be many hundreds of metres or even kilometers, and the same may apply to Australia too. So instead of importing the heights as points and estimating the height of each node, I would suggest a different approach: * Import the SRTM data into a spatial database (i.e. postgis) as polylines (contours) * Calculate the points along the OSM way where the way intersects a contour * Use these points as the height data for the way Cheers, Andy ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] Altitude data (cycle) route profiles
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 the fly) an altitude profile given a route (a sequence of nodes) estimate the altitude of each node in Australia from nearby GPS traces analyze the difference between both methods It would be great if I can get some feedback on my proposal before the deadline, so I can improve upon it. Hi Sjors, Firstly, good luck with your proposal, it sounds quite interesting to me. If I can make a suggestion it would be to think of the heights along each way, instead of just at nodes. If you look at the cycle map at http://www.gravitystorm.co.uk/osm/ you can see SRTM contours with OSM data overlaid. It's quite possible for a way to be straight yet cross a valley or a peak, and if you only look at the nodes at each end of a section you would miss this data. This is especially apparent for long straight features like motorways or roads in the USA where the gap between nodes can be many hundreds of metres or even kilometers, and the same may apply to Australia too. So instead of importing the heights as points and estimating the height of each node, I would suggest a different approach: * Import the SRTM data into a spatial database (i.e. postgis) as polylines (contours) * Calculate the points along the OSM way where the way intersects a contour * Use these points as the height data for the way Cheers, Andy Why not: Use that spatial database (or the raw SRTM grid) to interpolate the elevation of existing way nodes and then add ele tags to those nodes instead of creating new nodes only at the grid points (and with no other information)? Karl ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] Altitude data (cycle) route profiles
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 Cycle Route Profiles. Well, I have decided to focus only on this project. I have read some more material and I have submitted a proposal. I will give a very short summary here, but please let me know if you want me to send the longer version over this list. I would like to create an altitude profile in two different ways. The first is based on the freely available NASA SRTM altitude data. Its horizontal resolution outside the United States is about 100 meters. The second one is based on the GPS tracking data. Altitude data from these devices is known to be quite inaccurate, but if more data is combined it may still yield a useful result. 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) estimate the altitude of each node in Australia from nearby GPS traces analyze the difference between both methods Secondary goals, if time permits: apply to the whole planet calculate a measure of uncertainty for the altitude of each node find a way to combine the estimates based on GPS and SRTM I am certainly not a professional programmer, but I do have experience with a geographical database with data contributed from different (human) sources. For my graduation research I created The Ducks On Rails, which visualizes duck migration data: http://ducks.sprovoost.nl/ It would be great if I can get some feedback on my proposal before the deadline, so I can improve upon it. Kind regards, Sjors ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
