[OSM-talk] OSM the mediocre alternative

[Christopher Schmidt]

On Sun, Apr 22, 2007 at 01:43:09AM +0100, Robert (Jamie) Munro wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Christopher Schmidt wrote:
> > 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.
> 
> I agree this is the state of the current OSM api, but I can't see why a
> topologically stored dataset can't be fetched as features in one go.
> Converting features to topology, however, seems like it is prone to errors.
> 
> > 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. 
> 
> Not if you use the new extension the the API that Richard Fairhurst has
> written for potlatch.

Where is the documentation on this API?

> In terms of underlying relational databases, this is a completely
> trivial query (albeit quite a long one because there are several joins
> going on):
> 
> select * from way_segments
>  inner join segments on way_segments.segment_id=segments.id
>  inner join nodes as nodeStart on segment.node_a = nodeStart.id
>  inner join nodes as nodeEnd on segment.node_b = nodeEnd.id
> order by way_segments.id,way_segments.sequence_id
> 
> A relational database, with the proper indexes in place, can do a query
> like this in no time at all.

I'll have to trust you, since I tried hard to make something like this
happen with the existing database and code, and failed miserably. 

> 
> The fact that OSM is missing this kind of query is not a function of
> it's data structure, it is a function of the fact that no one has added
> this kind of querying to the API.

I'll accept that, but I tried and couldn't get it to perform in a
time that seemed acceptable -- and that was under no load :( So, I'm
probably just wrong, but I have tried. 

> > However, all these are technical problems. Mapping to topology isn't
> > hard
> 
> Yes it is. It might not be hard in practise because there are libraries
> available, but it is much harder in theory than going the other way.

Hm. Okay. I'll take your word for this. Having exported simple features,
I was able to take it and build a topology for OSM trivially: I'm not
sure where the hard part is.

Basically, for me? I want features. Features make a map. I like making
maps. So I'll keep doing what I do best, and when I'm done, maybe
everyone will be able to share something that's better. 

Regards,
-- 
Christopher Schmidt
MetaCarta