Trying to incorporate OSM into research project

Hi–

For a research project designed to optimize fuel consumption, I need to incorporate a road map and road elevation data into my program. I think OSM is just right for this, but am having a little trouble getting started. I’m hoping that someone can steer me in the right direction for how best to do this.

As a first step, what I am looking specifically to do is:

1. Be able to identify all roads within a certain neighborhood (e.g. radius) of a given location
2. Be able to identify which of the above roads intersect
3. Do all this automatically, from some kind of C, Java, Fortran, etc. program that can run on a microcontroller or DSP
4. It must be open source, or at least have a free license.

I’m having a terrible time doing this, mostly because I’m just getting started into GIS. It should be a very easy question to answer, and it seems that any kind of GPS router can do this very easily and quickly. I’ve been staring at shapefiles, though, and don’t really see how this could be done. Someone, somewhere mentioned a shp database, but I’m fuzzy on what this could be and how I could use it.

I imagine that this should look something like a database where I query a specific “Road” and “section” and have it return all intersecting entries. For instance, every section of a road-- with the exception of dead ends-- would intersect with at least two other sections: the one immediately before and the one immediately after.

Right now, I don’t need to know the names and non-physical characteristics of roads and intersections. I just need to know where they are and what their orientation in space is.

Lastly, on a side note I’m interested in improving the OSM altitude references. I believe that our experiment will, as a side effect, allow us to greatly increase the altitude accuracy for certain roads, but am unsure how to incorporate this into OSM. Honestly, until our process is peer validated, we should not risk contaminating the official sources. However, it would be a shame not to be able to use the data just because there might be some bugs, especially since the SRTM data is so coarse for anything outside the US. I was thinking that this might play into the above question, as if there is a database format for roads and their intersections, it should be easy to add an extra altitude field.

Of course, maybe I’m just barking up the wrong tree. This is a serious research project, so any help, no matter how obscure, is welcome, especially paper links and references.

[edited to update opensource and C requirements]

Hi,

Quick start is to dowload some shapefiles from Geofabrik or Cloudmade and use almost any GIS software. OpenJUMP, QGis, uDig are good open source candidates but of course ArcGIS or MapInfo can do the same analysis for you. Or then you can do the same inside a spatial database, but then there is an extra step in importing OSM data. For importing data into PostGIS there is osm2pgsql utility but I haven’t heard that anybody here is working with OSM data and Oracle Spatial/Locator.

Oh, sorry, I should have mentioned that. We already have all have a geography department at the university, and they have full ArcGIS licenses. I’ll change my original post to reflect that we need this to be

3. open source
4. integrated into a C program, preferably something that can run on a microcontroller or DSP.

No problem importing things and changing formats. I had expected as such. If this were straightforward and easy, it wouldn’t be research!

I just looked into PostGIS, but admit that I have a lot of trouble understanding it. I’m a controls engineer, so all the GIS language and database language jargon is terribly new to me. Any tips?

Hi,

I think that most open source programs are using Java Topology Suite (JTS) or the C++ port GEOS under the hood for spatial operations. I would suggest contacting GEOS folks http://trac.osgeo.org/geos/.

I don’t think Openstreetmap is suited for altitude data. Though it’s something that many people really want, I could go so far to say that is one of the most off topic request we get in Openstreetmap, so it certainly would be something to strive for.

Sadly, considering how cheap it is to get meter precision DEMs (about 1000 euro for Stockholm), it’s usually better to use these.

Microcontroller… do you mean a 200MHz ARM, a 16MHz 8bit AVR, or an extremly slow PIC? GEOS works well on ARM with lots of memory (32MB) memory, last time I tried. Also even though this subject s really outside the scopeof OSM you should try to ask on the dev mailing lists since they might have some good insights.

Thanks for the help. In some searches on the side, I’ve found that the Openstreemap API is really quite easy to use and seems to fulfill many of my immediate purposes. I’ve been accessing it through http://api.openstreetmap.org/api/0.5/map?bbox=[left][lower][right][upper] as indicated in http://wiki.openstreetmap.org/index.php/OSM_Protocol_Version_0.5. So far, I don’t understand the query results very well (the wiki is incomplete and hard to navigate, as wikis are wont to be), but just looking at the plain text, it is clear that for any given way in the sections they list the intersections with other roads and sections. I’m not sure at all how to use this data, but it seems to me logical that I should be able to find connecting roads.

I even understand that I can download the entire planet.osm along with the API and do local searches. Perfect! Now the next question is to find out what’s the smallest platform I can run it on.

Well, we intend to generate this data. We won’t be using it from the SRTM mission, as that data is unreliable for roads (imagine bridges and tunnels). So what we need to do is store that data somewhere and somehow so it can be immediately useful to us, and, more importantly, the rest of the world. Are you saying that Openstreetmap’s database format cannot take altitude data into account?

Good lord, don’t you know it! Luxembourg and France are about the same. Much easier to make the data yourself.

All of those are okay. I’m most familiar with AVRs, and the XMEGA looks interesting, but I wouldn’t be against learing about ARMs. Speed is not of consequence in the slightest, and all we want is a read-only interface, so we shouldn’t need much memory.

You seem to say that you’ve already had GEOS running on an ARM. Can you link me to some code or examples? The GEOS webpage is rather spartan when it comes to anything other than Windows and Linux platforms.

Thanks, will do, especially if it turns out the OSM API can’t work for me.

I believe that the GPX tracks that I upload to the project contain an elevation (or at least they do if I’m picking up a sufficient number of satellites, which is usually). Here’s an example from where I was when I finished generating tracks last weekend:

<trkpt lat="51.920482000" lon="1.231117000">
  <ele>21.031200</ele>
<time>2009-02-07T15:52:45Z</time>
</trkpt>

It looks like the elevation is in metres.

I also know that the JOSM editor can optionally download the gpx data for you to trace over while editing. What I don’t know is where the stuff gets discarded when I upload the trace, and if not whether it is included in whatever method JOSM uses to retrieve the information.

Don’t know whether this helps at all.

With regards your question about whether the project handles altitude, I suspect it can handle anything that you can tag with a key/value combination (or multiple tags such as in the case of highway=construction/construction=residential as just one example, or the additional tags that go with place_of_worship to determine religion and denomination IIRC). Whether it would do anything with it afterwards is another question.

Ed

Of course it can, it’s just not suited for it. E.g. if you store it in the nodes of the ways, what happens when someone moves that node or delete it… Considering I have no idea how you intend to procure that data and at what resolution it’s very diffcult to say anything about it. Other than: there is no standard way of doing it right know, other that what EdLoach says about GPX files.

… ? How in the world would you do that for 1000 euro. That’s 80 hours of very cheap labour it will not get you anywhere.

Well… You can get 200MHz ARMs with Linux from 30euros including shipping, Sadly only 16MB of RAM… I’ve linked GEOS into applications running on ARM.

Would the Arduino or Ethernut project be any good for the hardware and OS?

That’s exactly what I’m trying to find out. With the exception that I’m developing my own Atmel board, instead of using the arduino. So far, it doesn’t look promising, but no one seems to say it can’t be done either.

That’s a very good point, one I hadn’t considered. I guess I’ll have to do a one-time import of the planet.osm file and then figure out someway to perform future imports without killing my elevation data. Moreover, it means that I won’t be able to reimport the data back in without adding tremendous amounts of new nodes. I guess I’m going to have to design my own database format from the ground up. Perhaps I can represent roads by parametric equations. That would save me having to add too many data points.

Sorry, I meant that similar sized areas were similarly priced. And since my ambition requires calculating elevation profiles for long sections of roads, including those that cross country boundaries, it’s absolutely out of the question to pay for it. So even at 12E50/hr, that’s too much. I think I can do much better. I think I can get centimeter level resolution with hardware costing around 75E, total. Of course, I haven’t proven the concept yet, so I can’t be for sure how good the resolution will be, but I feel confident it will be good enough for my purposes.

If you’re handy with a soldering iron, and are prepared to spend a little of your own cash (~50E) (sorry, my research budget doesn’t permit giving away completely free units) I’ll send you the parts you couldn’t make yourself, e.g. the printed circuit board and the code to tie it all together.). No pressure, just an offer that anyone is free to take me up on.

So you got it running on an embedded Linux? I guess I can go that route, although I would rather have integrated the database lookup command directly into the flash code. I’d rather not mess around with an O/S on an embedded chip doing real-time tasks.