[OSM-dev] What is the main API? (was Re: OWL + OSM Activity Server)

[Roland Olbricht]

> This specific functionality seems like something we'd want directly
> supported in the railsport, no? Or is it so expensive that it has to be
> tiered out into its separate application?

It is expensive. To do bboxing properly you have to look at each element in 
the changeset whether it is inside or outside the provided bounding box. This 
has roughly the same effort than downloading all elements in that bounding 
box.

This "export" feature is so expensive that it is limited to small bounding 
boxes, delegating people to third party services for larger bounding boxes.

On the other hand, you can implement it trivially on a third party service: 
just take the Augmented Diffs (which have full geometry), split it into small 
bounding box buckets (a tool for filtering bounding boxes, 
process_augmented_diffs, is at the Overpass API, another is in the osmconvert 
toolbox) and deliver the relevant stream to the user.


I think the core problem is that there are two different concepts of "main 
API" around:

There is the lean approach, or technical point of view, geared towards 
scalability: Obviously, we need a central instance for managing the id space, 
and that place can also seralize all edits to the database. This has good 
chances to scale, but means that anything beyond immediate editing support has 
to go off the main API sooner or later when it turns out to be the roadblocker 
at that time of scalability.

And there is some kind of "approval" point of view, or marketing point of 
view, seeing tools with a .osm.org domain in some sense 
approved/superior/preferred or whatever. This comes from our usual experience 
with brands or large companies that differentiate "the inside" from "the 
outside". It doesn't match neither the common sense nor the factual situation 
around the project, think of JOSM (which is not on osm.org) or the Geofabrik 
and CloudMade extracts and several others, but it is very straightforward.

I tend to prefer the first point of view, but I accept that the second point 
of view is fairly often unchallenged told. From the first point of view, it is 
pretty clear that a history stream belongs to a third party tool.

Cheers,

Roland
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20121019/0b086640/attachment.html>