[OSM-dev] Smallest possible package for OSM API

Blars Blarson openstreetmap-dev at scd.debian.net
Thu Feb 12 21:01:33 GMT 2009

In article <8293c01c0902120756r7a6a1ecboffd30e707efbffe9 at mail.gmail.com> 
kenn at wifi-bourgogne.com writes:
>Playing around with the OSM API, it seems to me that it should work
>for most, if not all, of these needs. I am able to download an XML
>file containing all OSM data in a given bounding box. Looking at this
>data, I see that there are <nd reference=...> sections they list the
>intersections with other roads and sections. Perhaps I should think of
>these more as nodes than intersections, but I haven't gotten that far
>yet in understanding what the results mean. In any case, it seems to
>me logical that I should be able to find connecting roads. (Please
>correct me if I'm wrong!) Once I have the connecting roads, I should
>be able to retrieve the associated nodes and calculate 2D layout and
>positions of the roads.

Many nodes in ways are only for shaping the road, and do not denote an

I'm a little confused about exactly what you are doing.  Will you be
pre-processing the OSM data on a "large" system with internet access,
then storing a subset on your small device?  How many of these devices
will you be producing?  (Cost optimization consumer devices is very
different than that for something you make 100 of.)  What are you
doing with the intersecting roads once you have found them?

You may want to have a look at the way Trapi stores data.  Trapi uses
about 16 GB to store the planet, the next version will be smaller.
You can use the existing Trapi servers to fetch larger areas than the
main API, and there are existing planet extracts that may have the
area you desire.
Blars Blarson			blarson at scd.debian.net

With Microsoft, failure is not an option.  It is a standard feature.

More information about the dev mailing list