[Openstreetmap-dev] Success, and some questions...

Tom Carden tom at tom-carden.co.uk
Wed Aug 31 15:28:15 BST 2005

Robert Merkel wrote:
> OK,
> I've now successfully edited some trial points (and deleted them again) 
> with
> the new applet.  My problems with the applet seemed to be related to 
> broken
> firefox chrome, when I reinstalled firefox the problem went away.

That's a relief!

> My congratulations to the developers, but a few questions/comments:
> * The scheme where points and lines have an "absolute width" (so that
> they scale up and down in visible size with the map scale) would seem to
> be a bit problematic, to say the least...

Yep - basically what I imagine will happen is that we will eventually settle 
on a small number of fixed increments for zooming.  Once we have that, we 
can set a sensible width for streets at each zoom level.

There's a bug at the moment where the minimum street width is also used for 
nodes, but it's so small you can't see the nodes.  I'll fix that as a high 
priority next time I take a look at the code.

> * Similarly, the line naming only works on absurdly large-scale maps...

Yeah, there's some issues with the line naming as it stands anyway because I 
wasn't finished testing the applet when Steve launched it :)

I'd like to be able to select multiple lines and name them all at once.  I 
have some seriously flaky code which just about does this, but it's not 
ready for prime-time yet :)

In the meantime, use '+' and '-' to make roads bigger/smaller...

> * Can the applet add key-value pairs to lines yet?

Nope.  Before adding new features I'm waiting for the switch to REST.

> * Is the combination of the Sun JVM on Linux/Mozilla running applets the
> EMACS of the 21st century - sufficiently slow to make even the fastest 
> computer
> seem sluggish?

It depends where you're editing, but there are lots of optimisations that 
can be made once the bugs are ironed out.  The fact that the applet uses 
100% of CPU when idle is a little obnoxious, but bear in mind that the idea 
is that it should also occupy 100% of your attention - it's an interactive 
process ;)

Seriously though, optimisations come after features and bug fixes, so soon, 

> and perhaps the most important question of all:
> * Given the fact the applet clearly could do with some additional 
> development
> assistance, is there a set of instructions for setting up a development 
> environment
> so I can start hacking on the codebase to deal with some of these (and 
> many other)
> issues?

Not exactly.  There's a SVN repository (documented on the wiki) and this 
development mailing list (hi!).  The applet was written in Processing, but 
now can be compiled on the command line using Processing's core classes as a 
library.  Steve was working on an ant build script, I think he finished it. 
What did you have in mind?

> Finally, I notice the list of key-value pairs.  It seems to me that to 
> make the
> data usable (for instance, for in-car navigation, one item on my personal 
> very long-term wishlist),
> some careful thought will have to be given to standards for assigning 
> key-value pairs to
> denote relevant road features;
> ultimately, I eexpect the applet and other editors will need to, um, 
> "encourage" the use
> of those standards to encourage consistent quality.  Is there a document 
> summarizing the present
> state of this issue?

"name" is name - everything else is up for grabs.  All documentation so far 
is public: on the wiki or the mailing list archives.  Nick and others were 
discussing schemes for classifying roads, I'll see if I can find the 
relevant posts at home tonight.  The main way tbe appletwill "encourage" the 
use of certain keys and values simply by virtue of using them to enhance the 
output.  Other consumers of OSM data should do the same.

One of the upsides to settling on a road type key/value scheme would be that 
when the viewers are zoomed out they will be able to work out which roads to 
draw and which to ignore.  That would be one way to speed up the applet.



More information about the dev mailing list