[OSM-talk] [OSM-dev] The OSM Applet

[Nick Whitelegg]

On Saturday 14 Oct 2006 11:47, David Earl wrote:
> > Nick Black wrote:
> >
> > I have been taking a look at the OSM Applet code, and at peoples
> > criticisms of it. Aside from the speed issues that are largely caused
> > by tile rendering GPX points onto Landsat tiles, other criticisms
> > point to the UI, so I have taken the JOSM icons and stuck them onto a
> > very hacky mock up.
> >
> > I'd be interested to hear what people think about this - especially
> > some of the newcommers to OSM who have been active on the list
> > recently.
>
> I wonder whether it is the best use of limited volunteer time to develop
> online editing at all. The icons are really rather superficial. Once having
> installed JOSM, I can't imagine any reason why I'd use the applet.
>
> JOSM is a much more efficient editor, though it is too close to being a
> visual representation of the underlying data structure rather than being
> task oriented, I think. It has other advantages too - you deliver a batch
> of related changes at once, rather than piecemeal.
>
> I think the effort would be better directed at
> - improving JOSM rather than a competing editor. The online one has the big
> advantage of showing street names, which JOSM doesn't, but with the
> mappaint and landsat plugins there's little other advantage. No doubt JOSM
> couldbe coerced into showing street names etc.; improving visual cues to
> show completeness or missing bits.

If I get the time - hopefully I will at some point - I'll add that to the 
mappaint plugin. 

> - improving the viewer (for example, by taking the entirely different
> approach of pre-rendering tiles as data in them changes rather than trying
> to do it on the fly),

Possibly but I think an improved caching algorithm would be better. Storing 
every tile in the world at every zoom level is going to use huge amounts of 
disc space. But a good caching algorithm will cache *frequently viewed* 
areas.

> - making an easy to use method for including maps on third-party web pages
> (a la google maps) (maybe this has already been done)
> - improving the final map presentation (improved algorithms for laying out
> names, avoiding text and symbols conflicting with each other in dense
> areas, reducing detail when zoomed out etc)
> - more features on maps - especially ones which add value from local
> knowledge, which other maps don't show - defined shops, petrol stations,
> pubs with their names, ATM locations, post boxes with final collection
> times - there's so much highly local detail that other maps don't show that
> a collaborative project like this could add.

This morning I have successfully converted the Freemap renderer 
(free-map.org.uk) to use ImageMagick rather than GD, which means that it will 
gain antialiasing and line joins. The Freemap renderer uses PHP, which I know 
much better than Ruby, so it's likely to progress much faster than the 
current slippy renderer could ever do (unless a Ruby expert works on it). So 
expect work in this area. There is also of course osmarender, which will 
probably remain the source of the highest-quality maps, and osmabrowser, 
which I also plan to work on as a web-based interface to osmarender (and the 
freemap rednerer for environments which cannot read svg)

> - improving search capabilities


> - recruitment, which, as well as outreach, means making the tools much
> easier to use,

Arguably JOSM is easy to use, though there are one or two areas for 
improvement. There's also the upcoming Potlatch  (Richard's Flash editor) 
which will likely be *very* easy to use.

> much more task oriented, improving documentation, better 
> indication of the quality and extent of data in an area, easier
> installation.

Available time is the biggest rate determining step.... 

Nick