[OSM-talk] Data layer

[Tom Hughes]

In message <489C6FC7.6030303 at frankieandshadow.com>
        David Earl <david at frankieandshadow.com> wrote:

> I'd like to say how useful I've found the new data layer recently. I 
> don't know who did this (Tom?) but well done and thank you! I 
> particularly like the ability to see what's changed in the History 
> Detail page.

Chris Schmidt wrote it actually, so I can't claim the credit for it.

> It would be really useful if itoworld's ways were linked to it as more 
> than one of us has suggested on the wiki page for osm mapper.

I think I was the first person to suggest that ;-)

> Is there a reason why, when looking at an object in the data layer, the 
> history summary can't be displayed straight away rather than via another 
> link, 'show history'. The space is there unused. I guess it is another 
> database access, but that doesn't mean it also needs to be a user 
> interface gesture. If you're not interested in it, well I guess you just 
> don't read it, but if you are, you always need a second click.

Mostly because nobody has written code to do it.

> The history dates would be a little easier to read if the 'T' in the 
> data/time string were replaced with a space.

What T would that be? I assume you're seeing dates in raw ISO format
but I'm certainly not. When I look at a history page like:

  http://www.openstreetmap.org/browse/way/20169321/history

the dates look like:

  Fri Aug 08 10:37:58 +0100 2008

> Could the user names in the history summary be linked to the relevant 
> user pages?

Again, it is in my browser...

> How about the number of objects before you get the "more than 100 
> objects" message be configurable based on user logged in (if any) - 
> presumably up to some maximum that won't overload the server, but the 
> API does that anyway IIRC. My browser is apparently quite comfortable 
> with many hundreds of objects - I just did the whole of Ely with more 
> than 1,000 objects at zoom 14 and there was no perceptible performance 
> problem (though some of the features are a little small to select at 
> that scale).

That limit is nothing to do with the server, it's to do with the
browser - most browsers can't cope with large numbers. Firefox 3 does
seem to manage rather more though I agree.

Tom

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