[OSM-talk] [OSM-dev] The OSM Applet
nick at hogweed.org
Sat Oct 14 12:24:58 BST 2006
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
> - 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*
> - 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
Available time is the biggest rate determining step....
More information about the talk