D Tucny wrote:
Eddy Petrișor eddy.petri...@gmail.com wrote:
What's even more weirder is the fact that if I try to edit with
Potlatch, the way is displayed correctly, as if stale data was read of
as if Mapnik's data was read.
[...]
There was a post 12 hours ago to the talk list about the
Richard wrote:
It has been explained many times in the
past, not just
by me, that database freakiness _will_ happen because we don't
have
transactions, our server is often under high load, and there
may be memory
leaks or blocking processes in some of the software we use.
Do I understand
On Jan 12, 2009, at 13:45, Nevel Gandish wrote:
And can I be sure that when moving a node caused a new history entry
for the node and the way that both have the exact timestamp or might
they differ by a few seconds?
Just moving a node doesn't create a new history entry for the way, I
think.
Richard Fairhurst a scris:
D Tucny wrote:
Eddy Petrișor eddy.petri...@gmail.com wrote:
What's even more weirder is the fact that if I try to edit with
Potlatch, the way is displayed correctly, as if stale data was read of
as if Mapnik's data was read.
[...]
There was a post 12 hours ago to
Hi dev,
I've been given the opportunity to give a talk during a gathering of
Ruby developers in Amsterdam[1] next month.
I want to present them with a general high level introduction of OSM
and then make the link to Ruby by explaining a bit about the Rails
part of the OSM infrastructure.
It has been explained many times in the
past, not just
by me, that database freakiness _will_ happen because we don't
have
transactions, our server is often under high load, and there
may be memory
leaks or blocking processes in some of the software we use.
Do I understand
Martijn,
The goal of the talk will be to interest the (Amsterdam) Ruby
community in OSM in general, but also in becoming involved in OSM
Rails development. Is that helpful?
My personal take on this is that we actually have two, very different,
kinds of web interface, or better http
On 13 Jan 2009, at 09:22, Ed Loach wrote:
Richard wrote:
It has been explained many times in the
past, not just
by me, that database freakiness _will_ happen because we don't
have
transactions, our server is often under high load, and there
may be memory
leaks or blocking processes in
On 13 Jan 2009, at 12:14, Marc Schütz wrote:
It has been explained many times in the
past, not just
by me, that database freakiness _will_ happen because we don't
have
transactions, our server is often under high load, and there
may be memory
leaks or blocking processes in some of the
I get a 400 error when I try and upload nodes with more than 50 tags and about
4,300 bytes. This is to a test database, not www.openstreetmap.org/api. Is
anyone aware of any limitations?
Regards
Neil Penman
Stay connected to the people that matter most with a smarter inbox. Take
a
Diff uploads will not help online editor such as Potlatch. The
addition of transactions and exposure of the version numbers will help
more.
Why not? It may well utilize it for changes to multiple objects that should be
atomic, e.g. the example mentioned here.
Regards, Marc
--
Pt!
Hi Harald,
the one you pointed out seem pretty much to be errors.
Please see this:
http://www.openstreetmap.org/?lat=45.872858lon=11.031874zoom=18layers=B000FTF
On Tue, Jan 13, 2009 at 12:17 PM, Frederik Ramm frede...@remote.org wrote:
One is talking to users - letting them register, write blogs, write
messages (and if the trend continues, one day they'll be able to upload
images, have multi-page user profiles and forums and a full-blown E-Mail
system
Matt Amos wrote:
just because we're using ruby doesn't mean we have to use
rails+activerecord :-)
You mean I can put all the SQL back in amf_controller and get it running at
a reasonable speed again? ;)
cheers
Richard
--
View this message in context:
Hi,
Matt Amos wrote:
what do you see as the benefits of an old-fashioned compiled language
(presumably you mean C/C++/Java) over just plain ruby? just because
we're using ruby doesn't mean we have to use rails+activerecord :-)
I think nothing beats C/C++ (not so sure about Java) when it comes
Hi,
Dirk Stöcker wrote:
That would be easy for encapsulated data access. For current JOSM it will
be lots of work.
Explain? Can't you just when in doubt always put the object on the
visible list? It doesn't hurt if a few are not actually visible.
Bye
Frederik
Can someone help?
http://www.openstreetmap.org/?lat=-21.776lon=-41.863zoom=9layers=B000FTF
I oppened Ticket #1490 for this.
thanks
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
On Tue, Jan 13, 2009 at 1:02 PM, Richard Fairhurst rich...@systemed.net wrote:
Matt Amos wrote:
just because we're using ruby doesn't mean we have to use
rails+activerecord :-)
You mean I can put all the SQL back in amf_controller and get it running at
a reasonable speed again? ;)
not yet
Op 13 jan 2009, om 13:17 heeft Frederik Ramm het volgende geschreven:
Martijn,
The goal of the talk will be to interest the (Amsterdam) Ruby
community in OSM in general, but also in becoming involved in OSM
Rails development. Is that helpful?
My personal take on this is that we
On Tue, Jan 13, 2009 at 1:07 PM, Frederik Ramm frede...@remote.org wrote:
Matt Amos wrote:
what do you see as the benefits of an old-fashioned compiled language
(presumably you mean C/C++/Java) over just plain ruby? just because
we're using ruby doesn't mean we have to use rails+activerecord
Matt Amos wrote:
in which case we're trading development effort for performance.
i think we're operating in areas constrained by the lack of
available developers, so making the barrier to entry higher is a
tough decision.
(Speaking seriously for once...)
Kind of, but it's not a simple
On Tue, Jan 13, 2009 at 1:53 PM, Richard Fairhurst rich...@systemed.net wrote:
Matt Amos wrote:
in which case we're trading development effort for performance.
i think we're operating in areas constrained by the lack of
available developers, so making the barrier to entry higher is a
tough
Matt Amos wrote:
in the case of quadtile, i think the extra complexity was
worthwhile. in the case of SQL in the amf_controller, i'm not
so sure. this is just my opinion.
Sure. We can even do more nuanced than that, if you like. :)
In my opinion - and again, just that - the clarity of
2009/1/13 Marc Schütz schue...@gmx.net:
Diff uploads will not help online editor such as Potlatch. The
addition of transactions and exposure of the version numbers will help
more.
Why not? It may well utilize it for changes to multiple objects that should
be atomic, e.g. the example
Hi Alessandro!
You're right, this shouldn't be an error. But in my copy of the database
(2009-01-02) SS12 and Corso Verona are not yet connected. So the error
is not related to roundabouts, Corso Verona just looked like an open end.
Best regards,
HArald
Hi Harald,
the one you pointed out
Hi,
There was a reason behind it though. With the old queue based approach
sometimes there was no way to get the tasks connected properly without
using named pipes. With the stack based approach I think it's always
possible to connect tasks without using named pipes.
It seems you're
Martijn van Exel wrote:
Is there another source explaining the architecture of the Rails port?
Preferably with a
diagram or such.
Hardware wise...
1x Database Server (MySQL)
3x Dedicated Rails Application Servers (Ruby 1.8.6, Rails 2.0.x)
1x Frontend Web Server (lighttpd +
On Tue, Jan 13, 2009 at 8:18 AM, Frederik Ramm frede...@remote.org wrote:
Hi,
There was a reason behind it though. With the old queue based approach
sometimes there was no way to get the tasks connected properly without using
named pipes. With the stack based approach I think it's always
Hi,
Karl Newman wrote:
Why drop them?
Because it makes documenting what Osmosis does easier, and it makes
understanding what Osmosis does easier for those who start to work with
it now. Keeping everything that made sense at some time in the past
unnecessarily increases complexity.
Bye
2009/1/13 Robert Vollmert rvollmert-li...@gmx.net:
On Jan 12, 2009, at 13:45, Nevel Gandish wrote:
And can I be sure that when moving a node caused a new history entry
for the node and the way that both have the exact timestamp or might
they differ by a few seconds?
Just moving a node
Frederik Ramm wrote:
Hi,
Karl Newman wrote:
Why drop them?
Because it makes documenting what Osmosis does easier, and it makes
understanding what Osmosis does easier for those who start to work
with it now. Keeping everything that made sense at some time in the
past unnecessarily
Hmm, trying my post again with a message created from scratch! I didn't
realise I couldn't just reply all to another message, change the subject and
delete the old text! Its a bad habit anyway so time I stopped it.
I get a 400 error when I try and upload nodes with more than 50
tags and about
2009/1/13 Nevel Gandish koanti...@googlemail.com:
2009/1/13 Robert Vollmert rvollmert-li...@gmx.net:
On Jan 12, 2009, at 13:45, Nevel Gandish wrote:
And can I be sure that when moving a node caused a new history entry
for the node and the way that both have the exact timestamp or might
they
On Tue, Jan 13, 2009 at 12:58:38PM +0100, Rolf Bode-Meyer wrote:
What I don't understand - with your change and before - is that paint
speed seems to depend on the amount of data in the layer even if it's
outside the view.
That's to be expected. Even with a spatial index (AFAIK josm still
Hi,
Sascha Silbe wrote:
That's to be expected. Even with a spatial index (AFAIK josm still
doesn't use one yet), looking up the objects inside a give bounding box
(the view) is dependant on the total number of objects. For example, a
2D-PR-Tree lookup is about O(sqrt(n)) [1], with n being
On Tue, 13 Jan 2009, Frederik Ramm wrote:
That's to be expected. Even with a spatial index (AFAIK josm still
doesn't use one yet), looking up the objects inside a give bounding box
(the view) is dependant on the total number of objects. For example, a
2D-PR-Tree lookup is about O(sqrt(n))
On Tue, 13 Jan 2009, Rolf Bode-Meyer wrote:
This happens for all layers. It depends on the number of tiles you have
shown. The WMS plugin needs to learn some buffering to speed up work.
Currently it seems the stuff is recomputed and redrawn for every action.
After freshly starting JOSM, if
Sascha Silbe wrote:
On Tue, Jan 13, 2009 at 12:58:38PM +0100, Rolf Bode-Meyer wrote:
What I don't understand - with your change and before - is that paint
speed seems to depend on the amount of data in the layer even if it's
outside the view.
That's to be expected. Even with a spatial index
On Tue, 13 Jan 2009, Raphaël Jacquot wrote:
What I don't understand - with your change and before - is that paint
speed seems to depend on the amount of data in the layer even if it's
outside the view.
That's to be expected. Even with a spatial index (AFAIK josm still
doesn't use one yet),
Here are a few things that bug me in JOSM (which might well be doable):
* When I select two nodes (e.g. belonging to a way) and merge them
with m JOSM always moves one node to the other with no apparent way
to choose which node gets moved and which one maintains its position.
I've tried selecting
On Tue, Jan 13, 2009 at 3:13 PM, Frederik Ramm frede...@remote.org wrote:
Maybe this is a problem with my WM? I'm using Compiz under GNOME in Ubuntu
8.10.
Yes it is. Either tell your window manager not to capture the Alt+Click for
itself (Compiz does window dragging with Alt), or simply press
41 matches
Mail list logo
