[OSM-talk] OSM the mediocre alternative (was: don't like you etc.)

Christopher Schmidt crschmidt at metacarta.com
Sun Apr 22 00:30:39 BST 2007


On Sat, Apr 21, 2007 at 07:06:41PM +0200, Lars Aronsson wrote:
> But very few of us know how the PostGIS extension to PostgreSQL 
> works internally or how you should program geographic datatypes 
> and indexes on your own.  The result from this is Steve's current 
> data model and the fact that the rest of us accept this as a 
> viable solution.  Those who don't, because they know more of GIS, 
> like Christopher Schmidt, are repelled by everything they find 
> under the hood of OSM.

I'm actually not repelled by everything. It's simply a different choice
than I would make. Specifically: 
 * OSM uses topology as its base storage. Topology is good for making 
   graphs, which is important when you need to do routing. For this
   reason, (it seems to me) that OSM was built towards the goal of
   creating driving directions. Great.

 * Most GIS uses Simple Features -- not topological -- for handling
   data. The result is very different -- Simple Features are designed
   for making maps. If you'd like evidence, look at how the mapnik maps
   are built: the topology is turned into simple features, and stored in
   PostGIS. My MapServer demos just under a year ago worked the same
   way. 

The difference to me is simple:
 
  If I want to drawn an OSM feature on a map, I have to fetch a large
  number of pieces of data fromm the API individually, and combine them
  to create a geographic feature.

Example: 

  Way ID 4213747:
    1 way.
    21 segments.
    22 nodes.

So, to visualize this one way, I have to make 44 fetches to the API. 

Now, if I switch to a simple features model:

  http://hypercube.telascience.org/~crschmidt/featureserver/featureserver.cgi/osm-line/4213747

I'm given a geometry ("Line"), list of coordinates, and list of
properties. (This is JSON output: you can also see it as html by adding '.html'
to the end, or as atom by adding '.atom' to the end.) 

"Line" can also be "Polygon", or "Point". (Or "MULTIPOLYGON", etc.,
though FeatureServer doesn't support those.)

This is one fetch. I can now draw the feature. I can also query for
other features which have the same name, and get the information for
those, too:

http://hypercube.telascience.org/~crschmidt/featureserver/featureserver.cgi/osm-line/all.html?queryable=name&name=Al%20Jami'ah%20Street

This shows me that there is also a feature, ID 4213746, which has the
same name. I can draw all these features on a map with the output of one
query.

In OSM, that would be 88. 88 queries to the API, just so I can display
two features.

If there was a strong reason for storing topology -- that is, if OSM was
really not about maps, and was instead about making driving directions
-- this could make sense. In fact, it may make sense: I may have a
serious lack of understanding about how the project data is being used.
However, I think that the most common usage of OSM is *making maps* --
in fact, Steve even backs me up on this, in his post at
http://www.opengeodata.org/?p=198 :

   "OpenStreetMap is driven by this principle that we just want 
     a fscking map."

Topology makes a graph, not a map. This is the reason why I'm in favor
of a simple features-based data model: Features-based models are what
you use for making maps. Topology is what you use for doing analysis.

The upshot of this? The tools to make topology out of simple features
*already exists*: GRASS will do it. PostGIS + pgdijkstra will do it. Any
application out there which needs topology knows how to get it, because
mapping data is almost always distributed as something that isn't
topological.

(I can go into more depth on building topologies from simple features,
but I expect it doesn't have value to anyone at the moment.)

> In fact, the only way to get this project started is *not* to be 
> carrying the burden of GIS knowledge.  And that's exactly why 
> people like Christopher haven't started OSM, despite having so 
> many years of head start in the field.

Careful here: I had never touched anything GIS related before 13 months
ago. (I started with Google Maps in October of 2005, and with MapServer
in April of 2005.) OSM was already well started by the time I knew
anything about GIS -- or even about maps.

The first thing I did with "GIS" was taking Open Data, making an open
server, and putting up an open map. I did it with data provided by the
State government where I live. It has since improved, but it's still
basically the same now as it was a year ago:

  http://boston.freemap.in/

My major dissappointment with OSM is that when I tried to do the same
thing, I couldn't. The reason I couldn't is because the data model isn't
map data: it's graph data. It wasn't impossible, but I spent a long set
of hours working out the basis for the things that now exist for mapnik
rendering. (I won't claim that the work was related: I'm pretty sure the
work I did either bitrotted or was just missed when the mapnik stuff
became popular.) 

However, all these are technical problems. Mapping to topology isn't
hard -- mapping back the other way isn't impossible. I'm working on the
tools to make that all possible: FeatureServer is a step in the right
direction. FeatureServer's internal storage is simple features, but it
exports .osm files -- a simple topology version of the feature data. It
works: I've got a .osm file built by drawing simple features, and some
post-analysis tools that I used to clean it up. THere are a half dozen
directions to go from here, and they all lead towards simpler UIs,
simpler tools, and more editors. 

And that's what we all want. OSM contributors or not, anyone who cares about
open geodata wants every person in the world to be
able to sketch out their street accurately, quickly, and correctly, tag
it right, and upload it. They need to be able to have a basemap of the
best available reusable data, and they need to have it interactively. 
That's how the project succeeds.

Regards,
-- 
Christopher Schmidt
MetaCarta




More information about the talk mailing list