Re: FW: Recent improvements to the editing applet

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: FW: Recent improvements to the editing applet

Etienne Cherdlu
> Hi,
>
> > It may be a coincidence, but since the update the editing performance
> > has been appalling.  Either there are a lot of new users since
> > Christmas (entirely possible) or the update has introduced a big
> > performance problem.
>
> Since a too slow performance of the applet is not acceptable, it is not the
> main purpose to provide a speedy application for mass-cartographers.
> The applets goal is (as I understood it) for the "Arr, I just saw this
> street here is a bit wrong. lets just fix it." - guys.

I don't consider myself to be a mass-cartographer, just a regular user
(perhaps a bit too regular) - so I just go with the simplest, easiest
route.

What I'm saying is that the applet was more acceptable a week ago than
it is now.  I'm not sure if it would be better if the server was
faster - but the server isn't faster.

>
> That's what the offline - editors are for.
>
> You can't just write an application that fits them all (you can try, but
> better spend the resources into specializing for specific needs and so keep
> your complexitory small).
>
> So if you are going to add tons of data at once, have you considered
> switching to an offline editor?
>
> Currently, I am aware of 3 other editors: osmedit, osmpedit and JOSM.

I've tried JOSM but could not discover how to get the landsat images
displayed.  I also noticed that it seems to have it's lats and longs
mixed up.

I started to look at osmpedit but that only works on Linux.

I read about osmedit but gave up when the documentation said there was
no way to upload the work to OSM, only to Freemaps.

I hope someone will set me right on my misapprehensions about these
three editors - they can't all be unusable as well.

>
> > One problem with the new applet that makes it *very* tedious to use is
> > that if you pan the map even just a small bit, you have to WAIT about
> > 90 seconds for the nodes and segments to be redrawn before you can
> > continue adding segments.  Even then it has forgotten what I was doing
> > and I have to click on the segment button again.
>
> Is that different from the old applet? For me, I have always had to wait a
> bit after I moved around in the applet. (But it took me about 5-10
> seconds)

This afternoon the server was almost fast enough to be usable.  This
is how long it took to do anything.  Starting from the viewer in view
mode and clicking the edit button took 82 seconds before all the tiles
had been drawn.

Then panning the map in edit mode using Shift+drag, it took 20 seconds
before I was able to add the next node.  I don't really understand why
you cannot add nodes immediately after panning the map - that is more
frustrating than the old way even if it were just as slow.

After the map has been panned the applet seems to go into a state
where it redraws the nodes and segments.  While in this state it does
not allow nodes and segments to be added.  There are two things wrong
with the UI here that don't help.  Firstly I cannot tell when it comes
out of that state so I tend to sit there waiting longer than necessary
(this can be solved by displaying an hourglass cursor while it is in
this state).  Secondly, once it has completed redrawing the nodes and
segments I ofter still don't realise that it is ready because clicking
on the map does nothing - you have to go back and click the node or
segment button on the toolbar and then try clicking on the map (this
can be corrected by the applet not forgetting what the user was
doing). Both of these corrections would be unneccessary if it was
possible to add nodes and segments immediately after panning.

Etienne

>
> Ciao, Imi.
>
>
>
> _______________________________________________
> Openstreetmap mailing list
> [hidden email]
> http://bat.vr.ucl.ac.uk/cgi-bin/mailman/listinfo/openstreetmap
>
>
>
>

_______________________________________________
Openstreetmap mailing list
[hidden email]
http://bat.vr.ucl.ac.uk/cgi-bin/mailman/listinfo/openstreetmap
Reply | Threaded
Open this post in threaded view
|

Re: FW: Recent improvements to the editing applet

Thomas Walraet
Etienne Cherdlu wrote:
>
> Then panning the map in edit mode using Shift+drag...

My hero !

Shift+drag is not in the doc !


--
Thomas, Paris

_______________________________________________
Openstreetmap mailing list
[hidden email]
http://bat.vr.ucl.ac.uk/cgi-bin/mailman/listinfo/openstreetmap
Reply | Threaded
Open this post in threaded view
|

Re: FW: Recent improvements to the editing applet

Lars Aronsson
In reply to this post by Etienne Cherdlu
Etienne Cherdlu wrote:

> This afternoon the server was almost fast enough to be usable.  This
> is how long it took to do anything.  Starting from the viewer in view
> mode and clicking the edit button took 82 seconds before all the tiles
> had been drawn.

Currently the tiles (both in viewing and editing) are 256 x 128
pixels.  How would performance be different if the tiles were,
say, 512 x 256 pixels instead?  That would cause fewer tiles and
fewer calls to the server, but every tile would take a little
longer to process.


--
  Lars Aronsson ([hidden email])
  Aronsson Datateknik - http://aronsson.se

_______________________________________________
Openstreetmap mailing list
[hidden email]
http://bat.vr.ucl.ac.uk/cgi-bin/mailman/listinfo/openstreetmap
Reply | Threaded
Open this post in threaded view
|

Re: FW: Recent improvements to the editing applet

Steve Coast
* @ 30/12/05 06:49:22 PM [hidden email] wrote:

> Etienne Cherdlu wrote:
>
> > This afternoon the server was almost fast enough to be usable.  This
> > is how long it took to do anything.  Starting from the viewer in view
> > mode and clicking the edit button took 82 seconds before all the tiles
> > had been drawn.
>
> Currently the tiles (both in viewing and editing) are 256 x 128
> pixels.  How would performance be different if the tiles were,
> say, 512 x 256 pixels instead?  That would cause fewer tiles and
> fewer calls to the server, but every tile would take a little
> longer to process.

Matt came up with a mathematica notebook which spat out 256x256 as the
best size, but I have no idea how it worked / if it was correct.

I would imagine google and MSFT might have thought about this a little,
what are their tile sizes / format / colour depth / compression ratios?

have fun,

SteveC [hidden email] http://www.asklater.com/steve/

_______________________________________________
Openstreetmap mailing list
[hidden email]
http://bat.vr.ucl.ac.uk/cgi-bin/mailman/listinfo/openstreetmap