On Sun, Mar 08, 2009 at 07:56:15PM +, Tom Hughes wrote:
I think mod_evasive may be the problem, so I've disabled it for now.
It has been on for a while now though so I'm not sure why it has
started causing problems now.
Maybe SVN content got large enough to exceed the hash table?
From
I don't care as long as I can still use it in my GPL3-software.
Marcus
___
osmosis-dev mailing list
osmosis-...@openstreetmap.org
http://lists.openstreetmap.org/listinfo/osmosis-dev
On Mon, 09 Mar 2009 21:25:59 +1100, Brett Henderson br...@bretth.com
wrote:
I've finished writeable dataset support.
The DatasetReader class has been renamed to DatasetContext and now
contains methods to get a NodeManager, WayManager and RelationManager.
The existing getNode, etc methods
marcus.wolsc...@googlemail.com wrote:
On Mon, 09 Mar 2009 21:25:59 +1100, Brett Henderson br...@bretth.com
wrote:
I've finished writeable dataset support.
The DatasetReader class has been renamed to DatasetContext and now
contains methods to get a NodeManager, WayManager and
I consider my contributions so minor that i hereby give you all the
power to relicense them as you please.
Stefan
/trying to shorten possibly never-ending license debate :)
Brett Henderson wrote:
I hate to bring this topic up because I don't know if I have the
necessary patience for it :-)
I had the same issues as the initial reporter yesterday.
Probably related:
There is a mirror of Merkaartor on Launchpad. However, bazaar was unable to
sync the branch from the OSM svn since nearly 6 months.
Since Tom disabled mod_evasive (whatever it is), the sync happens again...
- Chris -
On
sly (sylvain letuffe) wrote:
I used to download relation from small to big size with a call like :
$ wget http://www.openstreetmap.org/api/0.5/relation/8654/full
Either from wget or from JOSM those requests now only get a 500 interval
server error.
Size might be the cause because it
Calm down...
I'm not woried ;-) I am just checking the cause
A 500 error nearly always just means the object is corrupt
in some way.
M
Then it sounds an hurricane just pass over the database ;-)
Those are almost randomly chosen relations from medium (~70 members) to huge
size
On Mon, 9 Mar 2009, sly (sylvain letuffe) wrote:
None does download correctly.
Most likely the 500 is there because the Rails script doesn't reply a
valid content-type. Thus the error is not really passed through.
Stefan
___
dev mailing list
sly (sylvain letuffe) wrote:
A 500 error nearly always just means the object is corrupt
in some way.
M
Then it sounds an hurricane just pass over the database ;-)
No, the problem is that the rails daemons are segving processing
requests for a full relation, so they never get a
Hi devs,
Update on changes in the osm server code.
You now require to be using libxml-ruby 1.0.0 or later if you are
using the latest rails_port head or the api06 branch.
TomH has resynced the api06 branch to include the latest changes in
head. This includes a new migration. To continue
Dirk Stöcker wrote:
On Mon, 9 Mar 2009, David Earl wrote:
You have 3 ways to replace this:
a) Press ESC instead of Shift
b) Press U instead of Shift
c) Double-Click to end drawing a node.
Methods a and b are long-time and only c is new.
These are all workable, but require extra clicks
On Mon, 9 Mar 2009, Jiri Klement wrote:
Calling functions twice is always bad design for multiple reasons. Use a
temporary variable here.
OK, I've fixed that. Way is calling functions twice bad design? Is
OsmPrimitive supposed to be thread safe?
Code will be changed later. When a variable
On 09/03/2009 11:24, Frederik Ramm wrote:
Hi,
Stefan Breunig wrote:
Try double clicking.
Would we lose anything by simply reinstating the old shift behaviour?
Indeed. AFAICS shift is unused now. Remember
Habit gets built into the fingers, changing it arbitrarily is not a good
thing to
On 09/03/2009 11:34, David Earl wrote:
On 09/03/2009 11:24, Frederik Ramm wrote:
Hi,
Stefan Breunig wrote:
Try double clicking.
Would we lose anything by simply reinstating the old shift behaviour?
Indeed. AFAICS shift is unused now. Remember
Oops, half finished paragraph. I was going to
create a node ready for extension when in open
space, and select a node ready for extension when shift+click near a node.
A normal click does just that. Pressing Shift was superfluous even
before the change got checked in.
--
Please encrypt your mail:
On 09/03/2009 11:40, Stefan Breunig wrote:
Would we lose anything by simply reinstating the old shift behaviour?
Shift now prevents JOSM from re-using nodes, but still inserts nodes
into existing ways. Old way to deal with this was to zoom in so the
snap distance would be too large, then
On 09/03/2009 11:42, Stefan Breunig wrote:
create a node ready for extension when in open
space, and select a node ready for extension when shift+click near a node.
A normal click does just that. Pressing Shift was superfluous even
before the change got checked in.
There was a time when it
On 09/03/2009 11:54, David Earl wrote:
I don't really get what you're taking about with how you've switched
SHIFT to something else. Can you illustrate it some how. My feeling from
your description is that if you're nowt zoomed in far enough to
distinguish things, you probably don't know
On Mon, 9 Mar 2009, Frederik Ramm wrote:
Stefan Breunig wrote:
Try double clicking.
Would we lose anything by simply reinstating the old shift behaviour?
Well, I was not totally happy with that change, but I agreed with it. I
would not have accepted such change if I would think previous
Ah, I see you found out yourself what shift does now :). Double
clicking to end, or clicking last node again makes it especially easy
for Potlatch switchers because that's how drawing is ended in Potlatch
since like always. Also, there is a little indication of what will
happen when you have a
Shaun McDonald wrote:
If you are zoomed in enough, you will find a little plus in the middle
of the line. You simply need to drag that plus to get a new node.
But then you drag the segment into a direction you don't want it to go. If you
want the segment to be where it was you will have to
Dirk Stöcker wrote:
The remaining users will learn about that change and we have a better
interface :-) Especially new users had lots of problems with the dangling
rubber band which are now solved.
I don't see that. When I click, I still get the rubber band. Maybe you mean
something else,
Jiri Klement napsal(a):
Hi,
Attached patch replaces timestamp and parsedTimestamp in OsmPrimitive
with DateContainer class accessible only using setter and getter. The
patch is not much usefull on itself but hopefully its the first step
to make OsmPrimitive encalupsed (without public
I've just gone back through my mail, and I have nothing with your name
on it about these changes, unless it is buried in something with an
unrelated subject heading. They just appeared. I only updated Friday
after a long period of using an older version in the mid 900s(*).
Nah, I meant the
On Thu, Mar 5, 2009 at 7:12 PM, Ævar Arnfjörð Bjarmason
ava...@gmail.com wrote:
Would a patch that only enabled this feature under X11 be acceptable?
Or perhaps some win32/OSX hacker can take a look at it.
I've submitted one at http://josm.openstreetmap.de/ticket/2279
26 matches
Mail list logo
