Re: [josm-dev] how does the transition to tested work ?

2010-03-09 Thread Sebastian Klein
Ævar Arnfjörð Bjarmason wrote:
 I just tried and I can't reproduce this or the issue with the number
 of objects to be uploaded drifting from what really needs to be
 uploaded.
 
 Now if I upload a per-object upload and it fails partway the objects
 that were uploaded up until that point will be counted as uploaded and
 won't be re-uploaded.
 
 But like I said I don't know if this issue in particular was what was
 causing some of the duplicates I was seeing initially.

Thanks for clearing this up. If you find other pitfalls, or run across
data destroying bugs, please let us know! (Power users like you and
Skyper seem to have a much higher probability of running into these. :)   )

__

Sebastian





___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev


Re: [josm-dev] Function to select or download a sequence of ways?

2010-03-09 Thread Karl Guggisberg
Hi Marko

To the best of my knowlege there is no such function yet  ...

  As a further development, it could be useful to create a selective 
download function (follow this way until reaching a branch or a given 
bounding box).
... except for this function which sounds like what the waydownloader 
plugin provides.

Selection is a core thing. You can use it from plugins in three ways.
(1) you can influence the current selection. See setSelected() on 
DataSet. Invoke it on the current data layer (Main.main.getEditLayer())
(2) you can get the current selection. See getSelected() on DataSet. 
Invoke it on the current data layer (Main.main.getEditLayer())
(3) you can listen to the current selection. See 
org.openstreetmap.josm.data.osm.event.SelectionEventManager

Regards
Karl



Am 09.03.2010 10:07, schrieb Marko Mäkelä:
 Before I start reinventing the wheel in JOSM, I would like to know if there
 is a function or plugin that allows to select a non-branching sequence of
 ways.  It would be nice if the selection function could optionally be
 restricted to the current selection, just like the search dialog, and if
 some predicates could be assigned to the ways, say, highway=tertiary or
 natural=coastline, so that any branches where the predicate does not hold
 would be ignored.

 With such a selection function, it would be easy to select the coastline of
 an area within a natural=coastline extract of the planet extract, or to select
 a section of highway or railway for defining a route relation, for instance.

 Last, some questions to help getting me started, in case this does not
 exist yet.  Is the selection a core thing, or can this be done in a plugin?
 Where should I start looking first?

 As a further development, it could be useful to create a selective download
 function (follow this way until reaching a branch or a given bounding box).

 Best regards,

   Marko

 ___
 josm-dev mailing list
 josm-dev@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/josm-dev



___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev


Re: [josm-dev] Painting

2010-03-09 Thread Petr Nejedlý
Jiri Klement wrote:
 One of the reason why painting appears slow is the fact that it's done
 in EDT thread. I think there should be special thread for painting.
   
Disagreed (with both sentences).
 EDT will only send request to repaint and copy offscreen buffer to
 screen when it's ready. Painting thread will wait for repaint
 requests. When request arrives it will start painting immediately. If
 another request arrives during painting, it will wait. If there are
 multiple repaint request after painting is finished, only the last one
 will be processed.
   
This is exactly what RepaintManager in Java does for you.
User events (mouse gestures, ...) and posted tasks are processed
and the repaint requests they caused are buffered and a repaint request
is posted at the end of the event queue. Once the queue drains, the repaint
happens, only once.

If you think of coleascing paints across more user gestures (like 
continuous dragging),
you'll face two problems:
1) the trade-off between UI responsivity and the amount of coalesced 
events. Too short delay
  before painting and you paint on every event anyway. Too long delay 
and the UI will feel slow
  most of the time.
2) Loss of feedback in the cases where the painting already takes 
considerable amount of time.

Separate thread won't help you neither on multicores, as you'll keep the 
problem serialized. Everything
else but painting is fast enough, so you'll have AWT thread idle happily 
waiting for next event while the
painting thread will fully load one core. Well, there will be the 
benefit of having the rest of the UI responsive,
but we're not here to solve multisecond painting of zoom-to-fit of large 
datasets this time, are we?

As for the initial comment regarding full repaint just to do rubber-band:
There's no problem with full repaint as long as you do it fast enough. 
And this is doable. Proved.

Moreover, I fear the increased code complexity necessary for partial, 
maybe filtered, repaints
may slow down the general painting so the net result will be worse.

 
For the record, I've tried current JOSM and must say that the rendering 
speed improved a lot.
What might help, IMO, is to disable painting plain points over given 
zoom level.
JOSM already paints large datasets when zoomed in and slight 
simplification, when zoomed out
can only improve the situation. (You don't need to see individual nodes 
when looking at half the
Germany, do you?)


Regards,
Nenik


___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev


Re: [josm-dev] Plugins not working with 3094 and Linux ?

2010-03-09 Thread Sebastian Klein
Karl Guggisberg wrote:
 I don't know when the JOSM core is going to be compiled for Java 6. On 
 this list I have been reading
 about plans to switch to Java 6 one or two weeks ago. Perhaps it has 
 been postponed by another month or two
 in the meantime. Plugins should probably wait to compile for Java 6 
 until the JOSM core is available for Java 6.

I think it is quite clear: The final decision on the Java 6 switch will 
be made after the stabilization  bugfixing phase. (Which has started 
early January and apparently isn't over.)

__

Sebastian

___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev


Re: [josm-dev] Painting

2010-03-09 Thread Petr Nejedlý
Sebastian Klein wrote:
 I was wondering: Is it save to paint to the Graphics of some component 
 from a random thread at a random time?
   
No, it is not safe, but that's not what you'd be doing.
The painting will proceed into a BufferedImage, which will then be painted
in the event thread using the component's Graphics.

--
Nenik


___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev