Hi Dirk,
I saw that you removed a bunch of my debugging code in here:
r4188 | stoecker | 2011-07-01 00:27:15 -0700 (Fri, 01 Jul 2011) | 1 line
improve TMS zoom handling
Is there some other way you'd like to see it done? Or, perhaps some way
that would be a little bit easier to re-enable it
From the code comment:
In general, smaller zoom levels are more readable. We prefer big,
block, pixelated (but readable) map text to small, smeared,
unreadable underzoomed text. So, use .floor() instead of rounding
to skew things a bit toward the lower zooms.
The second hunk changes the range
I'm seeing some regressions in the imagery portion of JOSM. It does not
seem to be drawing tiles from the non-current zoom level. It used to do
this. To reproduce:
1. Load an imagery layer
2. Turn off autozoom
3. Zoom out. As soon as the autozoom changes, you get a blank screen
instead of
On Tue, 2009-11-10 at 17:54 +0100, Dirk Stöcker wrote:
P.S. When I last tried git I found it very frustrating to reach otherwise
very easy tasks. It may be optimal for distributed development, but makes
the normal development more complicated.
It has a very steep learning curve which I think
This changeset:
http://josm.openstreetmap.de/changeset/2427/
removes the way_bbox_cache. Unfortunately, this just *KILLS*
performance. It makes some of my way search tests 10-20x slower. We
use getBBox() really, really often and the CPU we use repeatedly
recreating them ends up being
There have been some concerns that using QuadBuckets makes data set
iterations too slow. First of all, I hope that QuadBuckets will vastly
reduce the number of full iterations over the data set that are
*required* and replace them with coordinate-based searches. But, the
concern is valid.
I've
On Sat, 2009-10-31 at 16:28 +0100, Jiri Klement wrote:
To summarize, I would like to do following:
1) Replace public QuadBucketsNode nodes in Dataset with
CollectionNode getNodes(), that will return
Collections.unmodifiableCollection of nodes
That's fine with me, as long as you also add a few
On Sun, 2009-10-18 at 21:11 +0100, Andy Robinson (blackadder-lists)
Here are the jars:
http://daveh.dev.openstreetmap.org/josm/20091018/
I'll give it a try, thanks.
I just tried with your tiles and it has a jpg vs. png issue. I'll fix
it and post another set shortly.
Does anyone
On Tue, 2009-10-13 at 12:20 +0200, Martin Koppenhoefer wrote:
2009/10/11 Dave Hansen d...@sr71.net:
On Sun, 2009-10-11 at 23:05 +0200, Sebastian Klein wrote:
These are the problems I encountered:
* When a new area is loaded the entire map is colored red (with some
strange stripes
On Tue, 2009-10-13 at 22:14 +0200, Martin Koppenhoefer wrote:
Hi Dave:
java version 1.6.0_0
OpenJDK Runtime Environment (IcedTea6 1.4.1) (6b14-1.4.1-0ubuntu11)
OpenJDK Client VM (build 14.0-b08, mixed mode, sharing)
but I have also a sun-java (which I guess I am not using by standard
as
On Sun, 2009-10-11 at 11:04 +0200, Karl Guggisberg wrote:
Hi Dave,
I saw that your patch regarding selection handling was commited:
http://josm.openstreetmap.de/ticket/3676
When you introduce a new selection cache in the future, could you make
sure it's *ordered*, i.e. it reflects the
On Sun, 2009-10-11 at 12:31 +0200, Sebastian Klein wrote:
Is it just me, or is the slippy map plugin a pain to work with? It lags
on my system and is a memory hog.
Have you tried a recent version? For me, it is the single fastest way
to browse the slippymap. It's way faster and more
On Sun, 2009-10-11 at 19:31 +0200, Karl Guggisberg wrote:
Have you fixed up the ordering yet?
No, not yet, I just wanted to let you know, in case you want to continue
your work on this feature.
OK, I'll probably have time to go look at it later today.
-- Dave
On Sun, 2009-10-11 at 20:13 +0200, Martin Koppenhoefer wrote:
2009/10/11 Dave Hansen d...@sr71.net:
I use it for two things.
I use it for 2 things as well:
1. display the slippy-map-grid in JOSM. I know no other way to see the
grid of tiles in JOSM.
2. For editing it is best turned-off
On Sun, 2009-10-11 at 23:05 +0200, Sebastian Klein wrote:
Dave Hansen wrote:
Have you tried a recent version? For me, it is the single fastest way
to browse the slippymap. It's way faster and more responsive than any
browser. It also has features that allow you to tune the quantity
On Fri, 2009-10-09 at 07:47 +0200, Karl Guggisberg wrote:
So I would go even further and deprecate/remove the selection notion from
the primitive altogether. It is used in few places only anyway (beyond
painting) and would be well served by a selection set on the Layer anyway.
I support
It takes almost a second for me to do a mouse click and have a single
object be selected. I think it's worse for large data sets, but it
seems to exist most of the time despite the size of the data set.
Personally, I think a whole second to wait for a mouse click is pretty
bad.
Most of the time
On Thu, 2009-10-08 at 00:10 -0700, Dave Hansen wrote:
It takes almost a second for me to do a mouse click and have a single
object be selected. I think it's worse for large data sets, but it
seems to exist most of the time despite the size of the data set.
Personally, I think a whole second
On Thu, 2009-10-08 at 18:35 +0200, Karl Guggisberg wrote:
1. to migrate to node.setSelected(..) and way.isSelected()
2. to change the behaviour behind
OsmPrimitive:setSelected()/isSelected(),
possibly using a reference from
the primitive to it's parent dataset (see recent dicussion about
On Wed, 2009-09-16 at 10:01 +0100, A Morris wrote:
I ran josm with your patch. Here are some initial general observations
which do not include any analysis of the algorithm itself.
It seems the QuadBuckets class is referenced only through the
CollectionNode interface, and none of the
On Sat, 2009-09-12 at 23:52 +0200, Petr Nejedlý wrote:
Dave Hansen napsal(a):
On Sat, 2009-09-12 at 21:04 +0200, Petr Nejedlý wrote:
Dave Hansen napsal(a):
Ooh, I forgot about josm-ng. That one looks very usable. If mine
doesn't pan out, I'll certainly look at that one.
Well
+++ core-dave/src/org/openstreetmap/josm/data/coor/QuadTiling.java
2009-09-12 09:05:50.0 -0700
@@ -0,0 +1,111 @@
+// License: GPL. Copyright 2009 by Dave Hansen, others
+package org.openstreetmap.josm.data.coor;
+
+import org.openstreetmap.josm.data.osm.Node;
+
+import
QuadBuckets also happen to implement CollectionNode. So, we can
just plug it in for Collection like in the DataSet class.
---
core-dave/src/org/openstreetmap/josm/data/osm/DataSet.java |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff -puN
On Sat, 2009-09-12 at 17:58 +0100, Robert Scott wrote:
On Saturday 12 September 2009, Dave Hansen wrote:
I've been hacking on the JOSM validator plugin for a while. One of the
repeating hard problems that comes up are doing the UnconnectedWays tests.
You need to do searches for every
On Sat, 2009-09-12 at 17:25 +, Ævar Arnfjörð Bjarmason wrote:
On Sat, Sep 12, 2009 at 5:11 PM, Dave Hansen d...@sr71.net wrote:
If someone knows of any existing Java kd-tree implementations, I'd be
happy to look into it and see if it could be applied here. I love
nothing more than
On Sat, 2009-09-12 at 21:04 +0200, Petr Nejedlý wrote:
Dave Hansen napsal(a):
Ooh, I forgot about josm-ng. That one looks very usable. If mine
doesn't pan out, I'll certainly look at that one.
Well, the QTree in josm-ng is similar to yours in the way it distributes
the content
On Sat, 2009-09-12 at 21:36 +0200, Karl Guggisberg wrote:
Just recently, Node/Way/Relation require access to be via accessor
functions. That should help out quite a bit.
The one thing that we do need is for a list of PrimitiveChangeListeners or
something to call when primitives do change.
I've seen some SVN commits from jttt doing some refactoring of the
Way.nodes. First of all, very cool stuff. I'd like to use this to make
some of my ReverseLookup code and a bunch of the validator tests faster.
What's the end goal of all of the churn, though?
-- Dave
On Sat, 2009-06-13 at 14:04 -0700, Dave Hansen wrote:
I've been playing with the SlippyMap code again over the last
month or two. The following set of patches (I think) clean up
the code substantially. They also add some cool things like being
able to draw images that are not from
With the API down, I'm a little bored. So, I hacked up the SlippyMap
plugin a bit. If anything here looks interesting, I'd be happy to break
this out into some slightly more manageable pieces.
Also, has anyone tried adding some caching to the tile fetching? I'm
using a local squid cache which
On Sun, 2009-04-19 at 21:40 +0200, Ľubomír Varga wrote:
I have on mind some of this improvements, like limiting max cache ussage,
idealy by memmory.
Yeah, that was my first thought, too. But, the Image class seems pretty
weak. I don't know any good ways in java of querying object sizes.
On Wed, 2008-05-21 at 20:34 +1000, Roy Rankin wrote:
I have submitted a patch to TRAC, ticket 774. The following is from
the
report:
Could you post here, too?
I've been doing some hacking on it as well, to the same end. I also
added the ability to fix a small class of these overlapping ways
On Thu, 2008-05-22 at 07:11 +1000, Roy Rankin wrote:
A quick look at your patch suggests to me that not all conflicting
way
segments will show in the validation layer.
I don't doubt you, but care to elaborate? ;)
-- Dave
___
josm-dev mailing
---
core-dave/src/org/openstreetmap/josm/data/osm/OsmPrimitive.java | 21
++
1 file changed, 13 insertions(+), 8 deletions(-)
diff -puN src/org/openstreetmap/josm/data/osm/OsmPrimitive.java~osmprim
src/org/openstreetmap/josm/data/osm/OsmPrimitive.java
---
/ReverseWayCommand.java~core-ReverseWayCommand
2008-05-03 12:08:42.0 -0700
+++ core-dave/src/org/openstreetmap/josm/command/ReverseWayCommand.java
2008-05-03 12:08:42.0 -0700
@@ -0,0 +1,59 @@
+// License: GPL. Copyright 2007 by Dave Hansen and others
+package
Core reverse lookup code for caching the results of reverse-lookup
operations.
---
core-dave/src/org/openstreetmap/josm/command/AddNodeToWayCommand.java |
4
core-dave/src/org/openstreetmap/josm/command/ReplaceNodeInWayCommand.java |
20
This provides a convenient way for children of Command
to look up state from the original version of an object
before it had the Command run on it. It might be
used to look up the original 'osm.modified' before the
command, for instance.
---
This makes sure to keep the reverse lookup code in sync
when objects are added or deleted from data sets.
---
core-dave/./src/org/openstreetmap/josm/data/osm/visitor/AddVisitor.java|
12 +-
core-dave/./src/org/openstreetmap/josm/data/osm/visitor/DeleteVisitor.java |
11 +
This patch removes almost twice as much code as it adds. It greatly
simplifies SplitWayAction and makes it much more readable in the
process.
---
core-dave/src/org/openstreetmap/josm/actions/SplitWayAction.java | 110
+++---
1 file changed, 36 insertions(+), 74 deletions(-)
diff -puN
This starts using the new Commands in DeleteAction and
cleans it up a bit in the process.
---
core-dave/src/org/openstreetmap/josm/actions/mapmode/DeleteAction.java | 98
--
1 file changed, 46 insertions(+), 52 deletions(-)
diff -puN
---
core-dave/src/org/openstreetmap/josm/command/AddRelationMemberCommand.java |
70 ++
1 file changed, 70 insertions(+)
diff -puN
src/org/openstreetmap/josm/command/AddRelationMemberCommand.java~AddRelationMemberCommand
On Tue, 2008-04-29 at 15:28 +0200, Frederik Ramm wrote:
In understanding, a command can only fail if there's a programming
error in JOSM. Even so it is, of course, a good thing to handle that
gracefully rather than just throw an exception. - But are your
patches introducing commands that
On Tue, 2008-04-29 at 15:20 +0200, Frederik Ramm wrote:
@Override public final boolean equals(Object obj) {
- if (obj == null || getClass() != obj.getClass() || id == 0 ||
((OsmPrimitive)obj).id == 0)
+ if (obj == null || getClass() != obj.getClass())
+
On Tue, 2008-04-29 at 16:14 +0100, Alexander Wright wrote:
As a JOSM user, I can say that it would be much nicer if JOSM could handle
errors gracefully, rather than crash, potentially taking hours of work I'd
forgotten to back up with it.
I've actually been really happy with it after it
These are some modifications to help Way be more manageable. First,
it requires that object methods be used to access way.nodes. Doing
this gives us some chance of being able to track when people are
doing things to nodes and lets us do things like reverse lookup
caching.
---
---
core-dave/src/org/openstreetmap/josm/command/AddRelationMemberCommand.java |
70 ++
1 file changed, 70 insertions(+)
diff -puN
src/org/openstreetmap/josm/command/AddRelationMemberCommand.java~AddRelationMemberCommand
Reorganize some of the imports, and let DeleteCommand take a single
object into its constructor.
---
core-dave/src/org/openstreetmap/josm/command/DeleteCommand.java | 24
++
1 file changed, 15 insertions(+), 9 deletions(-)
diff -puN
---
core-dave/./src/org/openstreetmap/josm/gui/layer/OsmDataLayer.java | 16
++
1 file changed, 16 insertions(+)
diff -puN
./src/org/openstreetmap/josm/gui/layer/OsmDataLayer.java~give-layer-bounds-func
./src/org/openstreetmap/josm/gui/layer/OsmDataLayer.java
---
This uses the new reverse lookup code and some of the new commands
to greatly simplify the CombineWayAction code.
---
core-dave/src/org/openstreetmap/josm/actions/CombineWayAction.java | 89
--
1 file changed, 39 insertions(+), 50 deletions(-)
diff -puN
---
core-dave/src/org/openstreetmap/josm/command/RemoveRelationMemberCommand.java
| 68 ++
1 file changed, 68 insertions(+)
diff -puN
src/org/openstreetmap/josm/command/RemoveRelationMemberCommand.java~core-RemoveRelationMemberCommand
New command. Title says it all. :)
---
core-dave/./src/org/openstreetmap/josm/command/MergeWaysCommand.java | 100
++
1 file changed, 100 insertions(+)
diff -puN /dev/null ./src/org/openstreetmap/josm/command/MergeWaysCommand.java
--- /dev/null 2008-02-29 08:37:01.0 -0800
Use the new commands to clean up DrawAction. I think
this makes it much more readable.
---
core-dave/src/org/openstreetmap/josm/actions/mapmode/DrawAction.java | 99
--
1 file changed, 47 insertions(+), 52 deletions(-)
diff -puN
Maybe is is a weird version of the JDK that I have, but this
class won't compile for me without these fixes.
Also, return status from .executeCommand().
---
_
___
josm-dev mailing list
josm-dev@openstreetmap.org
53 matches
Mail list logo
