[OSM-dev] OSM Wishlist

[Tom Hughes]

On 12/10/12 15:14, Serge Wroclawski wrote:

> On Fri, Oct 12, 2012 at 9:12 AM, Tom Hughes <tom at compton.nu> wrote:
>
>> That's not strictly accurate - the JSON API one did not get closed.
>
> That's true, but my two bugs did get closed.

In case you haven't noticed they have been reopened now.

> More on this below.
>
>> Personally I'm not a fan of using bug trackers for things that aren't either
>> actual bugs, or concrete proposals with patches attached.
>
> I added two issues. First was one about caching of
> .../:element/:id/:version calls.
>
> Looking at the code, we set no cache headers, even though OSM elements
> of a certain version are immutable; that seems like a mere oversight.
>
> And I suggested that we could make a redirect of ../:element/:id calls
> to the object's version url.

I have no problem setting the cache headers, but I am concerned about 
the redirect idea because those URLs are almost certainly used far more 
often than the version specific ones and that change would mean that 
every one of those requests would wind up getting redirected, hence 
turning one request into two.

> I made a second issue at the same time regarding gathering histrorical
> data around way geometry. Right now, due to the way OSM stores its
> geometry data, the only way to know about a way's geometry history is
> to call the history call for the way, then make a history call for
> each and every node that was ever in the way.
>
> This is expensive.
>
> Talking with Matt about this a month ago on IRC, he suggested a new
> call could be made, one that would do the above work in a single call.
> This would allow the same work to be done with less server overhead,
> and greater resource management.

We have been planning a history call, but that was more along the lines 
of a history version of the map call rather than individual objects.

That is really aimed at supporting P1 style rollback rather than 
changeset analysis, which should ideally be done offline without having 
to hit the API if possible.

The question of how far to go in recursively resolving objects, and the 
history of objects is a tricky one, because the cost of the call can 
quickly escalate as you do this.

What people who ask for the history of a way really tend to want is not 
a full history of every node, but rather they want to know how it's 
geometry has changed over time, which leads to the kind of fake version 
creation the P1 call does.

Maybe instead we should just return full history for the nodes and leave 
the client to figure out how to show a view of the sequence of changes 
to tags and geometry by examining both way and node history?

Recursing into relations is a whole other issue, because that can 
recurse many times and lead to massive inflation of work and size of 
response.

Tom

-- 
Tom Hughes (tom at compton.nu)
http://compton.nu/