On 12/10/12 15:14, Serge Wroclawski wrote:
On Fri, Oct 12, 2012 at 9:12 AM, Tom Hughes <[email protected]> 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 ([email protected])
http://compton.nu/
_______________________________________________
dev mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/dev
