Re: [josm-dev] Difference between JOSM and JOSM-NG

[Alexander Wright]

On Monday 11 August 2008 23:41:09 Gervase Markham wrote:

> This and other considerations mean that any book you read on Java best
> practice (or any object-oriented language, for that matter) will
> recommend that you make your variables private and use accessor methods.

Ok, so I can't really comment, as I've no time to spend on JOSM code, but that 
aside, I'd say that a very good reason to stick to OO best practise is one of 
unit testing.

Not having accessor methods (with bounds checking for variables!) means that 
its a lot more tricky to adequately unit test classes. 

If I change a private variable, is the class still in a self consistent state?

If the answer is "I can't tell" then you really should be using accessor 
methods.

Alex.

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

[josm-dev] Ticket #488: Unnecessarily prompted to select way to split even though only one way extends through node

[Florian Heer]

Hi!

I think I have a solution for this nuisance, but first of all a 
question, as I don't know the data structure by heart yet:
is the list of nodes of a way guaranteed to be sorted by their occurence 
in the way? Meaning: is the first node in the list always the first of 
the way and likewise with the last?


If so, the attached patch solves Ticket #488.

Best Regards, Florian.


Index: src/org/openstreetmap/josm/actions/SplitWayAction.java
===
--- src/org/openstreetmap/josm/actions/SplitWayAction.java  (revision 771)
+++ src/org/openstreetmap/josm/actions/SplitWayAction.java  (working copy)
@@ -95,12 +95,14 @@
for (Node n : selectedNodes) {
for (Way w : Main.ds.ways) {
if (w.deleted || w.incomplete) continue;
+   int i = 0;
for (Node wn : w.nodes) {
-   if (n.equals(wn)) {
+   if (n.equals(wn) && (i>0) && 
(i<(w.nodes.size()-1))) {
Integer old = 
wayOccurenceCounter.get(w);

wayOccurenceCounter.put(w, (old == null) ? 1 : old+1);
break;
}
+   i++;
}
}
}
Index: .classpath
===
--- .classpath  (revision 771)
+++ .classpath  (working copy)
@@ -1,11 +1,11 @@
-
-
-   
-   
-   
-   
-   
-   
-   
-   
-
+
+
+   
+   
+   
+   
+   
+   
+   
+   
+
___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev

Re: [josm-dev] Difference between JOSM and JOSM-NG

[Nic Roets]

On Mon, Aug 11, 2008 at 8:11 PM, Frederik Ramm <[EMAIL PROTECTED]> wrote:
> But with JOSM-NG sitting around untouched by anyone but Petr himself,
> and this for the best part of a year, the argument that a properly
> designed JOSM would attract more programmers rings hollow. What JOSM
> currently needs most is a few people who share the responsibility, who
> make JOSM "their" project and who are willing to do more than submit the
> occasional patch. It seems to me that JOSM-NG, despite its clean
> architecture and technical superiority which I don't doubt for a second,
> has not managed to find these people either.

A few hints to finding these people :
* Don't call it JOSM-NG. JOSM already has a bad name.
* Get people to use it before you invite them to write plugins. That
means limit the scope of the project, but make sure it all actually
works (incl. uploads).

Is it true that JOSM-NG will have a different upload process ? Not at
the end, but while the user was editing ?? If so, I would not consider
it superior because of the added complexity.

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

Re: [josm-dev] Difference between JOSM and JOSM-NG

[Gervase Markham]

Frederik Ramm wrote:
> Hi,
> 
> Gervase Markham wrote:
>> By its very nature, it's impossible to tell how many more 
> 
> .. or less ..
> 
>> contributors
>> there would be, and how much better 
> 
> .. or worse ..

I think it's unlikely that moving code more towards standard Java-isms
and industry best practice would discourage developers from working on
it. I know you find this hard to accept :-) but best practice is best
practice because a large proportion of Java programmers over time have
discovered that it's the best thing to do for readability,
maintainability, etc., not because some arbitrary cabal is handing down
random decisions from on high.

Take accessor methods, for example. Without them it's hard or impossible
to use any of the Structural design patterns (Adapter, Bridge,
Composite, Decorator, Facade, Flyweight and Proxy) because they require
intercepting and controlling access to data. All of these patterns are
used in extending a class to do something it couldn't otherwise do. When
debugging, you can't easily find all the ocurrences where a particular
class variable is modified, or add in debugging code to log the value
every time it changes, or put a breakpoint on accesses. When
maintaining, you can't easily see in what circumstances the variable is
used (particularly if you have multiple variables of the same name which
are members of different classes) and you can't add constraints e.g. to
keep the variable's value in sync with another one, or prevent it being
set to certain forbidden values. If working on performance, because the
class used for internal storage is exposed to callers, you can't e.g.
replace a linked list with a hash for efficiency reasons, or decide to
lazily compute the value from other values.

This and other considerations mean that any book you read on Java best
practice (or any object-oriented language, for that matter) will
recommend that you make your variables private and use accessor methods.

Now here's the important point. You might say "OK, so if someone did
want to replace a linked list with a hash, they could implement accessor
methods in the relevant places at that point." But that changes the task
from a contained and testable performance optimisation in a single class
to a tree-wide change, which will also break 3rd party plugins who used
the "interface" of the public member variable. It's also harder to know
if the change is safe, because you have to read and understand the code
around every access to the variable to see if it's doing anything funny.
You have a whole bunch of extra stuff to test, and have to deal with the
breakage fallout. Multiply that up for each change of this sort you want
to make, and you can see why people don't start down that rocky road.
The "stop energy" barrier gets too great.

You're right, I can't magically produce more developers if you agreed to
let people refactor the code to match best practice better. But I can
give you some reasons why the average Java programmer will find diving
into the current JOSM codebase an unappealing prospect.

> But with JOSM-NG sitting around untouched by anyone but Petr himself,
> and this for the best part of a year, the argument that a properly
> designed JOSM would attract more programmers rings hollow. What JOSM
> currently needs most is a few people who share the responsibility, who
> make JOSM "their" project and who are willing to do more than submit the
> occasional patch. It seems to me that JOSM-NG, despite its clean
> architecture and technical superiority which I don't doubt for a second,
> has not managed to find these people either.

One reason perhaps is that open source projects are successful in
attracting developers when they already work (albeit imperfectly) for a
task. JOSM-NG is not yet even a basic OSM editor, because (as I
understand it) it can't return changes to the server.

Gerv

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

[josm-dev] JOSM Ubunbtu debugger searched

[Dirk Stöcker]

Hello,

ATM there are 7 reports related to an excpetion when calling preferences 
dialog on Ubuntu

http://josm.openstreetmap.de/search?q=ToolbarPreferences&wiki=on&changeset=on&ticket=on

None of the systems I have show that error, so I can't debug it.

It seems GTK+ style usage is required for that.

Anyone using Ubuntu, who can debug that?
Minimum would be to find out, which value is causing that error (i.e. 
what is zero).

Ciao
-- 
http://www.dstoecker.eu/ (PGP key available)

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

[josm-dev] JOSM cuts the top of the text in the GUI.

[Kai Stian Olstad]

Hi,

Maybe not the most descriptive subject, but all the texts in the GUI seams too 
be vertically aligned top and not center so that the text in some 
circumstances  goes beyond the top boundary of the box/element.

Is this a local problem or are the other that has the same problem?

Environment:
Xubuntu 8.04.1
$ java -version
OpenJDK  Runtime Environment (build 1.6.0_0-b11)

-- 
Kai Stian Olstad

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

Re: [josm-dev] Difference between JOSM and JOSM-NG

[Frederik Ramm]

Hi,

Gervase Markham wrote:
> By its very nature, it's impossible to tell how many more 

.. or less ..

> contributors
> there would be, and how much better 

.. or worse ..

> the code would be, if it was written
> more in line with standard Java best practice. But Petr and I are at
> least two data points.

And Imi and myself are probably people who get scared by it. It is 
totally moot to discuss "what if". We'd attract different people and it 
would be a different project. Some things would be better, some worse; 
some slower, some faster.

Now JOSM really isn't that big. And everything is Open Source. And Petr 
has made quite a good start with JOSM-NG. I'd hazard the guess that, if 
you want a clean implementation of JOSM's features, it would probably be 
*less* work to sit down with the code and copy or re-implement for 
JOSM-NG than it would be to completely change JOSM.

Why it hasn't been done yet, beats me.

And this situation is not new; JOSM-NG has been around for quite a while 
now and, as far as I am aware, while we hear occasional whining about 
how JOSM is badly designed and how people would love to help but cannot, 
nobody has actually taken the time to give JOSM-NG the push it needs to 
become a full-featured JOSM replacement. I'm sticking to JOSM myself 
because I like its structure more and because I feel that we JOSM 
developers have a certain responsibility vis-a-vis the JOSM users to 
maintain the software, but as soon as there is something that looks and 
feels more or less like JOSM but is better designed and faster, I won't 
hesitate for a second to tell everybody to switch.


I take the idea of changing code to be more attractive to potential 
programmers quite seriously. I have, for example, re-implemented the 
complete Osmarender XSLT code in Perl because I figured that this would 
attract more developers (anyone who has ever used trigonometry in XSLT 
will know why).

But with JOSM-NG sitting around untouched by anyone but Petr himself, 
and this for the best part of a year, the argument that a properly 
designed JOSM would attract more programmers rings hollow. What JOSM 
currently needs most is a few people who share the responsibility, who 
make JOSM "their" project and who are willing to do more than submit the 
occasional patch. It seems to me that JOSM-NG, despite its clean 
architecture and technical superiority which I don't doubt for a second, 
has not managed to find these people either.


Can we make it mandatory in the future for everyone whining about JOSM's 
programming model to explain why they're not working on JOSM-NG?

Bye
Frederik

-- 
Frederik Ramm  ##  eMail [EMAIL PROTECTED]  ##  N49°00'09" E008°23'33"

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

Re: [josm-dev] Difference between JOSM and JOSM-NG

[Jonathan Bennett]

Petr Nejedly wrote:
> When thinking of it now, I don't think starting josm-ng was a bad idea.
> It allowed me to prototype my ideas quickly and some of the ideas can
> still be taken from josm-ng and ported to josm.


Petr, just out of interest, why didn't you base josm-ng on the NetBeans 
platform, given your day job?
-- 
Jonathan (Jonobennett)

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

Re: [josm-dev] Difference between JOSM and JOSM-NG

[Gervase Markham]

Frederik Ramm wrote:
> I think if someone came along with a real good performance optimization 
> for JOSM that, as an aside, requires more encapsulation than JOSM 
> currently has, that would be a very good reason to add said encapsulation.
> 
> Trouble is, until now we have had a lot of textbook lectures on how 
> everything would be much better if only we had proper encapsulation, but 
> never anything tangible. (Much like on the talk list, where every few 
> weeks someone comes around and says "what, you n00bs not using 
> PostGIS?", to which the much-iterated reply is: show results.)

The trouble with this logic is that it doesn't reveal or account for the
hidden costs. For example, how can I evaluate how much more likely it
would have been that I would currently be a JOSM contributor if I hadn't
taken one look at the code and said "Ick"? I can't, but it's a non-zero
effect. And how many more people are there like me?

By its very nature, it's impossible to tell how many more contributors
there would be, and how much better the code would be, if it was written
more in line with standard Java best practice. But Petr and I are at
least two data points.

There's a great book called "Economics in One Lesson" by Henry Hazlitt.
Even though it was written 50 years ago, the one lesson is still
relevant. It is:

"The art of economics consists in looking not merely at the immediate
but at the longer effects of any act or policy; it consists in tracing
the consequences of that policy not merely for one group but for all
groups."
http://en.wikipedia.org/wiki/Economics_in_One_Lesson

The effects on some groups are particularly hard to measure if they
consist of someone not doing something they would otherwise do, such as
contributing to JOSM.

It's like governments putting up taxes. The visible benefit they claim
is that they can spend more money on improving the lives of their
citizens. The hidden cost is that each citizen has less money, and so
they don't buy things they otherwise would and there's less economic
activity. What things? Impossible to tell. But it's a cost nevertheless.

> Currently, JOSM doesn't care for plugins; everything is more or less 
> wide open, and a plugin can do almost anything that JOSM itself could. 
> Sometimes when you work on JOSM, you break a plugin; but on the whole, 
> JOSM development is not hindered by myriad plugin hooks that have to be 
> maintained, and plugin development is not hindered by having only access 
> to a small plugin API. This makes it easy for both plugin developers and 
> JOSM developers - at the occasional expense of stability.

This is an entirely reasonable plugin model IMO; but it makes it all the
more important for JOSM objects to hide their internal state from
plugins using accessor methods and protected member variables. That way,
you can override something if you need to be doing a derived class, but
it means that plugins can't accidentally mess with stuff they shouldn't be.

Gerv

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

Re: [josm-dev] Difference between JOSM and JOSM-NG

[Dirk Stöcker]

On Mon, 11 Aug 2008, [EMAIL PROTECTED] wrote:

> the main benefit of encapsulation is to make code more flexible
> for refactoring, internal changes, performance optimization
> through implementation hiding

That is true for new developments. For existing code other rules apply. 
The main rule here is: Changes should improve the software. Changes for 
the main benefit of cleaner style will be rejected. This is based on the 
fact that every change has side effects and very likely introduces new 
bugs.

And please do not assume that encapsulation is always good. It also has 
negative effects and the right balance is important.

> in case of modular software like josm with plugins is
> encapsulation a must for development and has not only something to do
> with clean style of code

Nothing is a must. As you see it works fine also without.

> refactoring and cleanups in an early phase of project are not
> so expensive and time-consuming like in a big grown old project.
> sometime it is to late to make big changes...

It is never to late. This is always possible.

BTW: Your shift and return keys are defective.

Ciao
-- 
http://www.dstoecker.eu/ (PGP key available)

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

Re: [josm-dev] Difference between JOSM and JOSM-NG

[Frederik Ramm]

Hi,

> the main benefit of encapsulation is to make code more flexible
> for refactoring, internal changes, performance optimization
> through implementation hiding

I think if someone came along with a real good performance optimization 
for JOSM that, as an aside, requires more encapsulation than JOSM 
currently has, that would be a very good reason to add said encapsulation.

Trouble is, until now we have had a lot of textbook lectures on how 
everything would be much better if only we had proper encapsulation, but 
never anything tangible. (Much like on the talk list, where every few 
weeks someone comes around and says "what, you n00bs not using 
PostGIS?", to which the much-iterated reply is: show results.)

> in case of modular software like josm with plugins is
> encapsulation a must for development and has not only something to do
> with clean style of code 

Developing a clean plugin interface is very hard work because you have 
to define lots of hooks for the plugin to access; you have to know in 
advance what a plugin might want to do and you have to actually write 
code for every single one of these hooks. A plugin might want to display 
something; might want to listen on a TCP port; might want to send events 
to various components; might want to show up in the load dialog; might 
want to be called before data is uploaded; and so on. All these 
interfaces will need to be maintained and tested every time you make 
changes, and half of the time the plugin developer would still not find 
the hook or access method that he needs, extending the JOSM core with 
extra stuff.

Currently, JOSM doesn't care for plugins; everything is more or less 
wide open, and a plugin can do almost anything that JOSM itself could. 
Sometimes when you work on JOSM, you break a plugin; but on the whole, 
JOSM development is not hindered by myriad plugin hooks that have to be 
maintained, and plugin development is not hindered by having only access 
to a small plugin API. This makes it easy for both plugin developers and 
JOSM developers - at the occasional expense of stability.

We operate in a very dynamic environment and it is very important for us 
that plugin developers can do whatever they need. It is very hard to 
predict what they will need; we have a much broader scale of plugins 
than, say, a graphics filter in a drawing program.

So I maintain that large-scale encapsulation in JOSM will make things 
much more difficult for plugin developers *and* JOSM maintainers, or at 
least take a lot of flexibility away from plugins that they currently enjoy.

I challenge you to implement a good plugin interface that doesn not 
suffer from these problems. If you can do that, we'll use it, including 
whatever necessary encapsulation comes with it. If you can't, or if half 
of the existing plugins will require ugly workarounds to keep working, 
then please re-think your condescending attitude towards JOSM's design.

Bye
Frederik


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

Re: [josm-dev] Difference between JOSM and JOSM-NG

[c . malolepszy]

On Mon, Aug 11, 2008 at 01:58:59PM +0200, Dirk Stöcker wrote:
> > When we're at it, I'm not sure the way josm is written makes it any easier
> > to work with the code. Using accessors is the standard way every java 
> > programmer
> > understands and the code clutter is not much of an argument.
> I do not like these either, but on the other side I also would not fix 
> these without a good reason. Making elements private and fixing the 
> sources to work with that is no big issue, but starting with current code 
> I would do so only in cases, where encapsulation really brings benefit. 
> Not for the general purpose of clean style.

the main benefit of encapsulation is to make code more flexible
for refactoring, internal changes, performance optimization
through implementation hiding
in case of modular software like josm with plugins is
encapsulation a must for development and has not only something to do
with clean style of code 

refactoring and cleanups in an early phase of project are not
so expensive and time-consuming like in a big grown old project.
sometime it is to late to make big changes...

best regards 
chr

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

[josm-dev] Difference between JOSM and JOSM-NG

[Evgeny Mandrikov]

Why are you using ant instead of maven in JOSM-NG?

--
Best regards,
 Evgeny Mandrikov aka Godin 
 homepage 

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

Re: [josm-dev] Difference between JOSM and JOSM-NG

[Dirk Stöcker]

On Mon, 11 Aug 2008, Petr Nejedly wrote:

> When we're at it, I'm not sure the way josm is written makes it any easier
> to work with the code. Using accessors is the standard way every java 
> programmer
> understands and the code clutter is not much of an argument.

I do not like these either, but on the other side I also would not fix 
these without a good reason. Making elements private and fixing the 
sources to work with that is no big issue, but starting with current code 
I would do so only in cases, where encapsulation really brings benefit. 
Not for the general purpose of clean style.

> Moreover, josm uses unusual L10N way (I must admit that for a reason this 
> time,
> though not a strong one)

>From my point of view Java uses an unusal system. The gettext is one of 
the best systems for that purpose I know of.

> Some of my ideas can be backported to JOSM directly ("Storage" class, which is
> a kind of HashMap with much smaller footprint), some with much more effort,
> "thanks" to the way josm is written (keeping a bbox of ways, having all the
> primitives stored in a QTree - the QTree approach needs the position writes 
> to be
> intercepted, public fields is a big no-no for this).

>From my point of view reworks to achieve major improvements are fine. I 
personally would support that, when the improvement achieved are worth the 
problems which will occur based on major code changes (and for sure there 
will be problems).

So if we have a situation where there is a statement like:
"For that or that reason these variables should use Set/Get functions",
then step by step migrating the code to use Set/Get and
then making the variables private and
then implementing new stuff would be fine.

As said: I would support that, when I'm conviced the benefits are worth 
the troubles (and we have no reworking-all-dont-work-at-all phase). And I 
think Frederik has an equal opinion.

Ciao
-- 
http://www.dstoecker.eu/ (PGP key available)

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

Re: [josm-dev] Difference between JOSM and JOSM-NG

[Petr Nejedly]

Dirk Stöcker napsal(a):
> On Mon, 11 Aug 2008, Frederik Ramm wrote:
> 
>> Gerv also hinted at the fact that JOSM is written in a way that is
>> somewhat untypical for Java, and whenever a newcomer to JOSM programming
>> said "this is all bullshit let's refactor it wholesale" I told them to
>> please find another project to refactor wholesale. I always thought that
>> the peculiar way in which JOSM is done has a lot going for it and makes
>> it easy to work with the code.

When we're at it, I'm not sure the way josm is written makes it any easier
to work with the code. Using accessors is the standard way every java programmer
understands and the code clutter is not much of an argument.
Moreover, josm uses unusual L10N way (I must admit that for a reason this time,
though not a strong one) and unusual (and harder for anybody writing DataSet
modification actions, easier to break) undo system.

I would put it this way: josm-ng currently is mostly an experimental platform*
trying whatever is posible to do regarding memory usage, editing/rendering 
speed,
and currently rendering accuracy (my current, uncommited code has a provision 
for
defining rendering of relations and can even render holes in multipolygons,
not taking about different rendering available for different zoom levels,
all this real-time up to the dataset of size of germany.osm).

Some of my ideas can be backported to JOSM directly ("Storage" class, which is
a kind of HashMap with much smaller footprint), some with much more effort,
"thanks" to the way josm is written (keeping a bbox of ways, having all the
primitives stored in a QTree - the QTree approach needs the position writes to 
be
intercepted, public fields is a big no-no for this).

*) Well there are only about two unimplemented things preventing josm-ng
to be used as a real editor - server I/O (reader part is there, of course)
and tagging UI.

> BTW: I never would suggest or accept "major" changes. Every major change 
> can be cut in pieces and introduced as smaller changes. This means you 
> always have a stable working software compared to a large refactoring 
> period. You have to write some intermediary code, but that also means half 
> finished reworks (when the author no longer has time or interest) are 
> better than nothing :-)

Well, I can write a List implementation that would notify me about all the
content changes, so I can keep the Way's bbox consistent even w/o disabling
direct access to the Way.nodes field (and thus preventing patching next to
every josm source file for this step just to start optimizations), but for
other things (again thanks to the josm "openness"), such a large change
might still be the very minimal prerequisite :-(

When thinking of it now, I don't think starting josm-ng was a bad idea.
It allowed me to prototype my ideas quickly and some of the ideas can
still be taken from josm-ng and ported to josm.

I'd like to write a summary wiki page, but haven't had much time for it yet.
(writing documentation is much harder for us, programmers, than writing code 
;-))
I'll try as soon as I return from vacation.
It might at least remove confusion and maybe help somebody porting useful things
from -ng or the other way around ;-)

-- 
Petr "Nenik" Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org
355/113 -- Not the famous irrational number PI, but an incredible simulation!

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

Re: [josm-dev] Difference between JOSM and JOSM-NG

[Dirk Stöcker]

On Mon, 11 Aug 2008, Frederik Ramm wrote:

> Gerv also hinted at the fact that JOSM is written in a way that is
> somewhat untypical for Java, and whenever a newcomer to JOSM programming
> said "this is all bullshit let's refactor it wholesale" I told them to
> please find another project to refactor wholesale. I always thought that
> the peculiar way in which JOSM is done has a lot going for it and makes
> it easy to work with the code.
>
> That having said, if at any time someone who has already done a lot of
> JOSM development would step forward and suggest major changes, I believe
> that would be a whole different thing than coming from someone who has
> yet to submit a single patch.

Actually that's true for every project. I once refactored freeciv (a 
C coded game) to use correct header files and touched nearly every source 
file in there. freeciv had/has a pretty active development and they 
stopped patch acception for approx. one and a half day to get that done 
(Only 4 or 5 people had CVS account - I did not have). I programmed for 
freeciv half a year at this time. To a newcomer they would have said: Go 
away. And I would say the same to everyone.

BTW: I never would suggest or accept "major" changes. Every major change 
can be cut in pieces and introduced as smaller changes. This means you 
always have a stable working software compared to a large refactoring 
period. You have to write some intermediary code, but that also means half 
finished reworks (when the author no longer has time or interest) are 
better than nothing :-)

Ciao
-- 
http://www.dstoecker.eu/ (PGP key available)

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

Re: [josm-dev] JOSM Ticket #263, cancelling an upload

[Shaun McDonald]

Dirk Stöcker wrote:
> On Sat, 9 Aug 2008, Frederik Ramm wrote:
>
>   
>> Dirk's suggestion sounds not too bad. If we manage to educate our users
>> a bit ("after a failed/cancelled upload, make sure to re-download the
>> area from the server before re-attempting the upload") then the problem
>> 
>
> When reuploading:
> "Warning. There is a upload in unknown state. Redownload area to verify." 
> :-)
>
>   

Watch out with this one, to make sure that you can download an 
appropriate area, rather than the whole bounding box that is loaded into 
JOSM. Most of the time that I'm editing I have to download in small 
chunks otherwise the osm server rejects the download based on too many 
nodes.

Shaun


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