[OSM-talk] Newbie - queries and usability suggestions (fwd)

[Lars Aronsson]

Calum, I'm forwarding your reply (with or without your consent) to 
the list, since that's where your questions will make any sense.


-- 
  Lars Aronsson (lars at aronsson.se)
  Aronsson Datateknik - http://aronsson.se


---------- Forwarded message ----------
Date: Mon, 20 Nov 2006 18:36:47 +0000
From: Calum Polwart <gps at wittongilbert.free-online.co.uk>
To: Lars Aronsson <lars at aronsson.se>
Subject: Re: [OSM-talk] Newbie - queries and usability suggestions

On Sun, November 19, 2006 2:32 pm, Lars Aronsson wrote:
> Calum Polwart wrote:
> 
>> OK I'm new here, but having a few issues - I'm reasonably
>> computer savy so it worries me slightly that you will loose
>> potential volunteers because the userfriendlyness is (a bit)
>> rough around the edges.
> 
> With time, the worry wears off.
---

Yes - but has anyone audited how many people register and perhaps 
upload a gpx log (if they even get that far) but then never upload 
anymore - that suggests to me they decided it was more hastle than 
it was worth.

My worry is not for me - you've probably hooked me.  My worry is 
the potential registrants who give up when it doesn't work like 
they thought it would.  I know these things take time, I know 
people are doing it in their > Well depending what 'play' means - 
done. I've exported from JOSM and tried a few attempts with saving 
data files etc and rendering is Osmarender myself.  But even it 
seems a bit clunky.  I'm working on the following square:  54.7N - 
54.9N x -1.6W - -1.69W.  Sometimes when I render it from JOSM 
(perhaps zoomed in - haven't investigated the detail of the 
reproducibility) I get two strange things happening: a road (way) 
appears from top left hand corner [somehow it may be confused 
because the road starts off the page?] instead of its correct 
position and/or some roads(ways) don't render. - More clunkyness 
to scare of the potential newbie!

Some things I've drawn don't seem to ever render ==> allotments? 
Parks?  I've seen map images with parks at least rendered.  I 
suspect the xml style file has the answer.  But as a newbie I was 
expecting an easier ride that to have to rewrite the style sheet!  
Obviously others have successfully rendered parks - so would be 
nice if that was either default on the style sheet or if there was 
a range of style sheets to download.  I assume it may be 
conventional in other countries to draw roads in different colours 
etc, again would have expected to find a list of style sheets to 
achieve this!.

However, if the slippy when it works wont draw parks etc then am I 
wasting my time putting them in at the moment... thats why it 
would be useful to see them on the slippy.

>Try the German algorithm (I
> put the link in my diary some time back, [[user:LA2]] on the wiki)
> for automatic map generation from track logs.
> 
OK will investigate that

> Ultimately, we need some solid GIS experience on how to make the
> database, API and slippy map generation fast and scalable.  A new
> tile must be generated in a tiny fraction of a second (20 ms or
> so), independent of the scale, and it must be possible to
> invalidate only the right parts of the tile cache.  

OK I'm new to this but several things seem strange about the 
general approach - they've probably been considered to death in 
the past!  A tile sounds like it may be quite large (London?)  Is 
there a play off of reducing tile size.  Think UK OS Map - you 
could tile a letter square like NX (100km x 100km).  You could 
tile NX 1n 2n (10km x 10km). You could tile NX 11 22 (1km x 1km) 
or you could even tile NX 111 222 (100m x 100m).  Clearly the UK 
OS Grid is not they way to tackle the world but the concept would 
work?

Clearly that would make a LOT more tiles, But rendering MAY be 
quicker per tile.  In the short term I guess it would actually 
take longer to render all the world's tiles.  However, if someone 
modified a single street in London then you might only need to 
re-render 1km x 1km - which would be quicker.

Two things to note about the frequency of updates.  I EXPECT that 
when this is fully up and running people will make a little tweak 
and expect to see it "instantly" on the slippy. But is it not 
possible for the slippy to know that a tile needs re-rendered and 
render it before showing it.  If that takes time it could pop up a 
message to say that the map is being re-rendered.  Given the 
amount of editing going on at the moment I'm sure that would work 
- although I don't know what happens when the world are using the 
data.

One worry would be that people will re-edit the map again and 
again thinking they are doing something wrong with their editing, 
if they don't see the change happen straight away.

I realise servers cost money - but can the world be divided up 
into say 5 and the work split over the 5 servers.  A small overlap 
(?100miles) could be used to make transition slicker.

> In a map of
> England, the tile that covers London is the real challenge.  It is
> based on many thousands of line segments, and doesn't really need
> to be redrawn if only a small street is modified.  

I think the problem is that people will want their update no 
matter how minor to appear ASAP.  Thresholds of say 10 updates 
will be problematic - London will still need lots of rendering - 
it will have frequent updates.  A village the size of mine will 
never be re-rendered!  But the change on my map might be far more 
important - like changing a error rather than adding a new street.

> I think there
> must be abstraction layers in the database and API that correspond
> to the zoom levels, so that changes in small details don't
> propagate to (and invalidate cached tiles at) all zoom levels. 

If I understand that correctly you are saying that if I add a new 
residential street to London then the 'whole of London' map 
doesn't need to know and shouldn't be redrawn.  That sounds 
sensible - presumably some rules could be written that work this 
out.  At some stage the tile should be redrawn of course for 
accuracy.

> If
> you can download the database dump, play with this, and create a
> fast slippy map, you could rescue the entire project.
> 

I'd love to.  I don't do perl script though!  I also don't do 
slick code - I would pretty much guarantee I could slow down you 
tile generation!  I did have a look at the current perl script but 
couldn't even begin to understand it.

As I understand it there are two issues:

- Rendering the world now, once.  That seems to be a problem but 
  I'm not clear why.  If it takes 6 months with the current script 
  it takes 6 months... if that is true then there are several 
  options - could the script be run on multiple machines? (I could 
  run a bit on my server etc.)  If it will take 6 years then 
  that's a bit crazy.  But could the BBC 'screensaver' super 
  computer approach be used to use hundreds of computers when they 
  run their screensaver?

- Maintaining the rendering.  The number of changes at the moment 
  surely aren't that massive that it can't be kept up to date 
  with?  With changes simply being added to a rendering queue and 
  re-rendered when the chance occurs.

- Final thought before I finally shut up.  I wonder if the slippy 
  could render on request. i.e. Request Durham today it renders 
  it. Anyone in the next ?24 hours requests Durham they get cached 
  Durham.  After that time it is re-rendered and again cached?  
  If there are caches at each zoom level then likewise the caching 
  rules would apply to each level.  Thus for the UK level map most 
  people will probably be seeing cached data - afterall - someone 
  has probably already been on for that day.  But at the highest 
  level perhaps no-one will have looked at that area at that zoom 
  level in the same day so you might need a newly rendered 
  version. (It may be able to avoid rendering using a cahced 
  version if there has been no changes?)

> 
> --
>   Lars Aronsson (lars at aronsson.se)
>   Aronsson Datateknik - http://aronsson.se
> 
> _______________________________________________
> talk mailing list
> talk at openstreetmap.org
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
> --
> This email has been verified as Virus free
> Virus Protection and more available at http://www.plus.net
> 


-- 
Calum Polwart