[OSM-dev] OSM Wishlist

[Serge Wroclawski]

On Oct 12, 2012 10:24 AM, "Tom Hughes" <tom at compton.nu> wrote:
>
> 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 true, but my two bugs did get closed.
>
>
> In case you haven't noticed they have been reopened now.
>

Hadn't noticed yet... Been getting ready for the conference and github
doesn't notify on reopen.

>> 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

Okay I'll just do that for now.

>

>
> 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.

Change analysis (changeset or otherwise) needs to touch some history
resource... Don't see a way around that.

> 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.

Right.. So if that information can be provided another way, I'll take it.

> 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?

That was the plan, and yes it's a pain in the butt for the client, but I
was writing the client :-)

> 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.

Yeah.. I agree it's a hairy mess and I'm willing to put it aside for now.

Also I hope to announce a public beta of Changemonger so we should get some
real world data on its api call patterns in the real world.

Up until today it's been testers looking to feed it huge changesets to
break it.

- Serge
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20121012/59b013f3/attachment.html>