Re: [josm-dev] first impressions

[Oliver Raupach]

Hi,

Am 10.01.2012 17:11, schrieb Frederik Ramm:

The main reason is that most of us are not Java developers by trade, but
instead many of us are allround developers who happen to code Java among
other things.

We also try to attract people from the general OSM hacker population to
help out with JOSM, and we cannot count on these people to have
state-of-the-art Java skills.

You will also find that reflected in the code, where more often than
not, we prefer a simple implementation over one that you would be taught
in a Java development course. We need to keep the learning curve down so
even people who are not Java developers can write a plugin without first
learning how to use the latest cool technologies or design patterns.


You did a very good job in any case. JOSM is certainly one of the main 
editors for OSM (if not the most important editor). But OSM is becoming 
increasingly important. And JOSM is also becoming increasingly 
important. Is it not then important to use modern architecture?




Having said that, if you truly believe that someone with knowledge of
only Makefiles, and neither ant nor maven, will find it easier to
understand maven than to understand ant, then maybe we should indeed
switch.


Yes, what is simple? A makefile? Ant? Not for me. Today is a makefile or 
a ant-build no longer "easy".



As for automated testing - we are an Open Source project and we can only
make limited demands on the time of our contributors. If someone
supplies tests - great. If they don't - we don't force a development
methodology on our contributors.


Yes, I agree with you.

--

  Oliver Raupach


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

Re: [josm-dev] first impressions

[Oliver Raupach]

Am 10.01.2012 18:36, schrieb Jiri Klement:

I have hudson running at my laptop that builds josm and plugins and
also checks for changes in josm that breaks backward compatibility
with plugins. Problem is that it's broken all the time (either
compilation error in plugins or some change in josm that breaks some
plugins) so I basically gave up and rarely fix found errors.


But this is not a good idea. Actually it shows that there is definitely 
a jenkins build required. Exactly the case that someone committed a 
plugin which breaks the build can be easily identified with Jenkins. If 
the build is broken constantly, then something is wrong


Is there somewhere a server for something like Jenkins available?


Maven vs ant - I also think that maven will be better but I don't want
to spend time on rewriting something that already works.


Yes, the time required is not negligible.


What I miss in JOSM is FindBugs - it can find lots of stupid errors
automatically (like possible NullPointer exceptions, calling equals on
object of different type, ...). It's already possible to run Find bugs
on JOSM (and I sometimes do it), but for it to be really useful, it's
also necessary to use annotations - it finds lots of false positives
so FindBugs version of @SupressWarning is needed and also FindBugs can
find much more errors if hints like @CheckForNull, @NonNull,
@OverrideMustInvoke are used.

So what do you think about introducing FindBugs annotations? They
doesn't have any effect on built jar, but they can clutter the code a
bit.


I agree with Dirk. It depends on the number of annotations. If there are 
too many, it quickly becomes confusing.


--

  Oliver Raupach


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

[josm-dev] "area too big"

[David Earl]

I got an "area too big" message doing "Update data" in JOSM on the 
eighth of eight areas in the file (or at least, it was at the end - 
maybe the message applied to one of the intermediate ones, but if so it 
didn't say so until the end). Presumably the density of nodes in that 
area has gone over the top since I first downloaded the data which I am 
updating.


A few questions:

(a) is the problem the last area; if not, how do I find out which it is? 
(or is it in some way the sum total of all 8 of the requests it is 
blowing up on).


(b) has it downloaded and incorporated the earlier seven that appeared 
to succeed? Or did it revert back entirely to my original data?


(c) if I get this from a planet file instead getting osmosis to extract 
the area, can JOSM open the result (subject to memory etc, as it is a 
large-ish file - I'm thinking of format rather than size).


Thanks,
David


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

Re: [josm-dev] License Change Plugin slows down drawing

[Paul Hartmann]

On 01/10/2012 11:23 PM, Frederik Ramm wrote:
> Hi,
> 
>whenver a license change layer is active and you have lots of objects
> loaded, JOSM becomes noticeably slower.
> 
> I could use a little help here. Since many of you have tweaked JOSM's
> drawing performance in the past, maybe you only need to take a quick
> look at this drawing code
> 
> http://trac.openstreetmap.org/browser/applications/editors/josm/plugins/licensechange/src/org/openstreetmap/josm/plugins/licensechange/LicenseProblem.java
> 
> 
> and you have an idea how it could be improved?

You can use QuadBuckets for the 'highlighted' collection. This helps a
lot if the user zooms in and has only few primitives in the current
viewport.

(In this case, you probably need to replace "QuadBuckets" by "QuadBuckets" and add a new
interface HasBbox.)

> The "sliding window" of four consecutive nodes in the visit function is
> there to determine whether linecaps need to be drawn or not.
> 
> Is it the trigonometry in drawSegment? (This is more or less copied from
> similar code in the validation layer.) 

You can draw a parallel line of fixed distance without trigonometry (see
the code in MapPainter [1]), but I'm not sure this will make a big
difference. Usually, most time is not spend in JOSM code, but in the
Java libs that actually do the painting.

> Would it perhaps make sense to
> cache the buffered outline instead of computing it each time?

Shouldn't be necessary, as far as I can tell.

[1]


Paul

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