Hi,
Tom Hughes wrote:
> Indeed, just one of the many reasons why MySQL sucks giant boulders
> through exceedingly small straws.
The only thing worse than doing an ALTER TABLE on a large table is doing
a Rails migration on it ;-)
Bye
Frederik
--
Frederik Ramm ## eMail frede...@remote.org #
Joachim Zobel wrote:
> Am Sonntag, den 28.12.2008, 18:00 -0500 schrieb Jeremy Adams:
>> I ran the same command on my box about 4 hours ago and it's still
>> cranking away. Should it really take that long to change a column
>> type? It's got one of the CPU cores pegged, so I assume it's still
>> d
Am Sonntag, den 28.12.2008, 18:00 -0500 schrieb Jeremy Adams:
> I ran the same command on my box about 4 hours ago and it's still
> cranking away. Should it really take that long to change a column
> type? It's got one of the CPU cores pegged, so I assume it's still
> doing something.
An ALTER T
Happy New Year ;)
Best Regards
Roberto Navoni
> D Tucny wrote:
>
>> I'm not seeing it...
>>
>
> Let me first enlight you with the non-variated idea.
>
>
>> You seem to miss the point that to see the rest of the way:
>>
>> 1) a request can be made with a new bbox like now is commo
D Tucny wrote:
> I guess you would like to make it:
>
> ---
> | |
> | |
> | ,.,o|o
> | o' '.,. |
> | '. |
> ,--|
> o
>
>
> And indeed this seems a much better appr
2008/12/31 Stefan de Konink
> D Tucny wrote:
>
>> I'm not seeing it...
>>
>
> Let me first enlight you with the non-variated idea.
>
> You seem to miss the point that to see the rest of the way:
>>
>>1) a request can be made with a new bbox like now is common practice
>>if you want to
D Tucny wrote:
> I'm not seeing it...
Let me first enlight you with the non-variated idea.
> You seem to miss the point that to see the rest of the way:
>
> 1) a request can be made with a new bbox like now is common practice
> if you want to edit a larger area
>
>
> But how do you
2008/12/31 Stefan de Konink
> D Tucny wrote:
>
>> That would be quite nasty, seeing node 8, but not having a line connecting
>> it anywhere? For rendering, that would be pretty useless, for editing it
>> would be a pain in the bum, especially if there was a node 9 somewhere else
>> outside the bb
D Tucny wrote:
> That would be quite nasty, seeing node 8, but not having a line
> connecting it anywhere? For rendering, that would be pretty useless, for
> editing it would be a pain in the bum, especially if there was a node 9
> somewhere else outside the bbox...
Notice variation. It is an e
Stefan de Konink writes:
> Matthias Julius wrote:
>> ... but not a tree of relations. Every relation is a tree (almost).
>> So I don't see a particular problem in making a boundary a relation,
>> too.
>
> Some people wanted to limit ways/relations to 2k of nodes. If you do
> allow relations to
2008/12/31 Stefan de Konink
> Don't make partial stuff more complex than it is. The editor reads any
> non-continuous list of integers as 'out of bbox'. For example the
> following returns:
>
> nds idx1
> nds idx2
> nds idx4
> nds idx5
> nds idx8
>
>
> The editor will now render 5 nodes within th
On Tue, Dec 30, 2008 at 11:00:46PM +0100, Martijn van Oosterhout wrote:
> On Tue, Dec 30, 2008 at 4:20 PM, Robert (Jamie) Munro
> wrote:
> > IMHO ways should be restricted to more like 256 nodes
[…]
> Eventually country boundaries are going to be the same order of
> magnitude and I don't want to
Maarten Deen wrote:
> You will have to keep the whole way
> for the off chance that you zoom out in the editor or really want to edit the
> whole way (like splitting it).
You don't have to, there is nothing preventing edits that happen in the
middle of a way. The problem only occurs at the cutpoi
Stefan de Konink wrote:
> Matt Amos wrote:
>> On Tue, Dec 30, 2008 at 10:18 PM, Maarten Deen wrote:
>>> Not wanting to plead for a certain limit of nodes per way, but what would
>>> be
>>> the technical problem with a single entity consisting of a million 2-node
>>> ways, as opposed to a way of a
Matt Amos wrote:
> On Wed, Dec 31, 2008 at 3:30 AM, Stefan de Konink wrote:
>> Maybe he made a typo and ment 2k-node... but that is just me parsing the
>> meaning behind a message.
>
> other than the obvious fact that 10^6 * 2k has three orders of
> magnitude more nodes* than a 10^6 node way?
Th
On Wed, Dec 31, 2008 at 3:30 AM, Stefan de Konink wrote:
> Maybe he made a typo and ment 2k-node... but that is just me parsing the
> meaning behind a message.
other than the obvious fact that 10^6 * 2k has three orders of
magnitude more nodes* than a 10^6 node way?
cheers,
matt
* after mergin
Matt Amos wrote:
> On Tue, Dec 30, 2008 at 10:18 PM, Maarten Deen wrote:
>> Not wanting to plead for a certain limit of nodes per way, but what would be
>> the technical problem with a single entity consisting of a million 2-node
>> ways, as opposed to a way of a million nodes?
>
> maybe we could
On Tue, Dec 30, 2008 at 10:18 PM, Maarten Deen wrote:
> Not wanting to plead for a certain limit of nodes per way, but what would be
> the technical problem with a single entity consisting of a million 2-node
> ways, as opposed to a way of a million nodes?
maybe we could call these 2-node ways "s
Maarten Deen wrote:
> Ok, it will take some time to connect those million nodes, but at present,
> osmarender likes the million ways better than the million-node way.
But think *why* this is; I presume osmarender is fed the million nodes
because it intersects that way. There are situations where
Martijn van Oosterhout wrote:
> On Tue, Dec 30, 2008 at 4:20 PM, Robert (Jamie) Munro
> wrote:
>> IMHO ways should be restricted to more like 256 nodes
>
> Oh god I hope not. Coastlines by themselves are tens of millions of
> nodes and there's already a huge number of ways needed to do it.
> Reduc
On Tue, Dec 30, 2008 at 4:20 PM, Robert (Jamie) Munro wrote:
> IMHO ways should be restricted to more like 256 nodes
Oh god I hope not. Coastlines by themselves are tens of millions of
nodes and there's already a huge number of ways needed to do it.
Reducing the number of nodes in a way to 256 is
2008/12/30 Robert (Jamie) Munro :
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Stefan de Konink wrote:
>> Shaun McDonald wrote:
>>> From API 0.6 there is a limit of 2,000 nodes in a way.
>>
>> Btw; Do you impose this also on a relation? If not, then it is pretty
>> useless to have an infr
Robert (Jamie) Munro wrote:
> Stefan de Konink wrote:
>> Shaun McDonald wrote:
>>> From API 0.6 there is a limit of 2,000 nodes in a way.
>> Btw; Do you impose this also on a relation? If not, then it is pretty
>> useless to have an infrastructure that is capable of holding an infinite
>> amount
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Stefan de Konink wrote:
> Shaun McDonald wrote:
>> From API 0.6 there is a limit of 2,000 nodes in a way.
>
> Btw; Do you impose this also on a relation? If not, then it is pretty
> useless to have an infrastructure that is capable of holding an inf
On Tue, Dec 30, 2008 at 1:05 PM, Stefan de Konink wrote:
> Frederik Ramm wrote:
>> Stefan de Konink wrote:
>>> Even in 0.5 relations can be ordered using the type='...'.
>>
>> You're getting (more) ridiculous.
>>
>> What are you trying to prove here? That you're right and the rest is
>> wrong? Tha
Frederik Ramm wrote:
> Stefan de Konink wrote:
>> The latter still requires the same client/server modifications +
>> modifications in all current node relations. Hence it will cost more
>> time.
>
> No it doesn't; 99.9% of all ways don't violate the new criteria so all
> tools will work perfec
Hi,
Stefan de Konink wrote:
> The latter still requires the same client/server modifications +
> modifications in all current node relations. Hence it will cost more time.
No it doesn't; 99.9% of all ways don't violate the new criteria so all
tools will work perfectly for them.
> Even in 0.5 r
Matt Amos wrote:
> On Mon, Dec 29, 2008 at 10:26 PM, Stefan de Konink wrote:
>> Some people wanted to limit ways/relations to 2k of nodes. If you do
>> allow relations to have all these extra subrelations then what are you
>> going to solve in the end? This is enforcing a clueless limit and not
>>
On Mon, Dec 29, 2008 at 10:26 PM, Stefan de Konink wrote:
> Some people wanted to limit ways/relations to 2k of nodes. If you do
> allow relations to have all these extra subrelations then what are you
> going to solve in the end? This is enforcing a clueless limit and not
> solving the fundamenta
Matthias Julius wrote:
> ... but not a tree of relations. Every relation is a tree (almost).
> So I don't see a particular problem in making a boundary a relation,
> too.
Some people wanted to limit ways/relations to 2k of nodes. If you do
allow relations to have all these extra subrelations the
Stefan de Konink writes:
> Matthias Julius wrote:
>> Stefan de Konink writes:
>>
>>> Frederik Ramm wrote:
Stefan de Konink wrote:
> So you actually suggest to implement a tree of relations to render a
> country?
I'm not convinced a tree is needed.
>>> What do you have in mind
> What is the TRAPI server? (besides apparently very quick?) Any
> specs/munin graphs for the curious?
>
> It's pretty much handling the load all by itself today.
I operate the physical server, not the application itself.
The server specs are:
Quad Xeon 2.13GHz, 8GB RAM, 2x1TB SATA DISK
Stats
Matthias Julius wrote:
> Stefan de Konink writes:
>
>> Frederik Ramm wrote:
>>> Stefan de Konink wrote:
So you actually suggest to implement a tree of relations to render a
country?
>>> I'm not convinced a tree is needed.
>> What do you have in mind to use as area that is bounded by a p
Stefan de Konink writes:
> Frederik Ramm wrote:
>> Stefan de Konink wrote:
>>> So you actually suggest to implement a tree of relations to render a
>>> country?
>>
>> I'm not convinced a tree is needed.
>
> What do you have in mind to use as area that is bounded by a polygon
> that has more tha
Shaun McDonald wrote:
> On 28 Dec 2008, at 20:50, Florian Lohoff wrote:
>
>
>> On Sun, Dec 28, 2008 at 08:25:54PM +0100, Stefan de Konink wrote:
>>
>>> So what is the fundamental problem that your tools break on 40k of
>>> nodes? Bbox them on the request, and return a partial result that
Jeremy Adams wrote:
> I ran the same command on my box about 4 hours ago and it's still
> cranking away. Should it really take that long to change a column
> type? It's got one of the CPU cores pegged, so I assume it's still
> doing something.
It should not do anything on your CPU; such actions
I ran the same command on my box about 4 hours ago and it's still cranking
away. Should it really take that long to change a column type? It's got one
of the CPU cores pegged, so I assume it's still doing something.
-Jeremy
Original Message ---
On Mon, Dec 29, 2008 at 03:
Seems like you're all on top of the problem now.
I updated the schema creation script on 3rd November to use an int
instead of smallint. Internally osmosis doesn't care, it uses a 32 bit
integer (more accurately, it uses a list index which is 32 bit). It is
just the schema itself which was us
What is the TRAPI server? (besides apparently very quick?) Any specs/munin
graphs for the curious?
It's pretty much handling the load all by itself today.
-Jeremy
Original Message ---
+--On 28 décembre 2008 14:31:40 -0500 Jeremy Adams
wrote:
| It's not the ROMA script tha
Frederik Ramm wrote:
> Stefan de Konink wrote:
>> So you actually suggest to implement a tree of relations to render a
>> country?
>
> I'm not convinced a tree is needed.
What do you have in mind to use as area that is bounded by a polygon
that has more than 2k of nodes?
>> Totally break lookup
Shaun McDonald wrote:
>> So you actually suggest to implement a tree of relations to render a
>> country? Totally break lookups such as 'is X in country Y', you will
>> make friends that is for sure :)
>
> That is not what relations are for. You determine which country is in
> based on the latitu
Hi,
Stefan de Konink wrote:
> So you actually suggest to implement a tree of relations to render a
> country?
I'm not convinced a tree is needed.
> Totally break lookups such as 'is X in country Y', you will
> make friends that is for sure :)
Someone who is so quick with taking complex programm
On 28 Dec 2008, at 22:10, Stefan de Konink wrote:
> Frederik Ramm wrote:
>> Stefan de Konink wrote:
>>> Shaun McDonald wrote:
From API 0.6 there is a limit of 2,000 nodes in a way.
>>> Btw; Do you impose this also on a relation?
>> Yes.
>
> So you actually suggest to implement a tree of rela
Stefan de Konink wrote:
> So you really want people first to change everything to 0.6 and then to
> something else ;) I wanted to write longer about this, but I think
> allowing everyone to send just a complete changeset (within one request)
> ditch REST for updating will give much more moment
Frederik Ramm wrote:
> Stefan de Konink wrote:
>> Shaun McDonald wrote:
>>> From API 0.6 there is a limit of 2,000 nodes in a way.
>>
>> Btw; Do you impose this also on a relation?
>
> Yes.
So you actually suggest to implement a tree of relations to render a
country? Totally break lookups such a
Hi,
Stefan de Konink wrote:
> Shaun McDonald wrote:
>> From API 0.6 there is a limit of 2,000 nodes in a way.
>
> Btw; Do you impose this also on a relation?
Yes.
Bye
Frederik
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33"
__
Hi,
Stefan de Konink wrote:
> Shaun McDonald wrote:
>> From API 0.6 there is a limit of 2,000 nodes in a way.
>
> ...and I hope this limit will be dropped again dropped
It won't. Partial modification of ways is a good idea but we lack the
coders to implement it in API and clients. It might be
Florian Lohoff wrote:
> Would be kind of complicated i guess.
>
> The point is that you have number 1..100 on a way - you edit the range
> from 50-60 and insert 5 nodes than you'll have 50-65 which will have an
> overlap with the ones in the database (sequence wise) so the database/api
> needs to
On Sun, Dec 28, 2008 at 09:15:34PM +0100, Stefan de Konink wrote:
> Subject: Re: [OSM-dev] ROMA servers down - osmosis large way problem
>
> Shaun McDonald wrote:
> > From API 0.6 there is a limit of 2,000 nodes in a way.
>
> ...and I hope this limit will be dropped ag
Shaun McDonald wrote:
> From API 0.6 there is a limit of 2,000 nodes in a way.
Btw; Do you impose this also on a relation? If not, then it is pretty
useless to have an infrastructure that is capable of holding an infinite
amount of nodes and one that is not ;)
Stefan
Shaun McDonald wrote:
> From API 0.6 there is a limit of 2,000 nodes in a way.
...and I hope this limit will be dropped again dropped and allow partial
modification for ways opposed to uploading the entire way.
Stefan
___
dev mailing list
dev@openst
On 28 Dec 2008, at 20:50, Florian Lohoff wrote:
> On Sun, Dec 28, 2008 at 08:25:54PM +0100, Stefan de Konink wrote:
>> So what is the fundamental problem that your tools break on 40k of
>> nodes? Bbox them on the request, and return a partial result that
>> will
>> work just as good for renderi
On 28 Dec 2008, at 20:56, Mathieu Arnold wrote:
> +--On 28 décembre 2008 20:50:00 +0100 Florian Lohoff
> wrote:
> | On Sun, Dec 28, 2008 at 08:25:54PM +0100, Stefan de Konink wrote:
> |> So what is the fundamental problem that your tools break on 40k of
> |> nodes? Bbox them on the request, and
Weird - I checked the schema that I used and it's a smallint. That must have
been changed recently.
I've altered the column type on my server - we'll see what happens when it's
finished.
-Jeremy
Original Message ---
+--On 28 décembre 2008 20:50:00 +0100 Florian Lohoff
wr
Florian Lohoff wrote:
> On Sun, Dec 28, 2008 at 08:25:54PM +0100, Stefan de Konink wrote:
>> So what is the fundamental problem that your tools break on 40k of
>> nodes? Bbox them on the request, and return a partial result that will
>> work just as good for rendering.
>
> The db schema uses sma
+--On 28 décembre 2008 20:50:00 +0100 Florian Lohoff
wrote:
| On Sun, Dec 28, 2008 at 08:25:54PM +0100, Stefan de Konink wrote:
|> So what is the fundamental problem that your tools break on 40k of
|> nodes? Bbox them on the request, and return a partial result that will
|> work just as good for
On Mon, Dec 29, 2008 at 03:43:27AM +0800, D Tucny wrote:
> osm=> select max(sequence_id) from way_nodes;
> max
> ---
>39767
> (1 row)
>
> osm=> select * from way_nodes where sequence_id = 39767;
> way_id | node_id | sequence_id
> --+---+-
>28098
On Sun, Dec 28, 2008 at 08:25:54PM +0100, Stefan de Konink wrote:
> So what is the fundamental problem that your tools break on 40k of
> nodes? Bbox them on the request, and return a partial result that will
> work just as good for rendering.
The db schema uses smallint for the node number on th
+--On 28 décembre 2008 14:31:40 -0500 Jeremy Adams
wrote:
| It's not the ROMA script that's failing - osmosis is failing while it's
| trying to update the database using changesets from the main API.
|
| Whatever db schema the main API uses must allow for this, while the one
| for osmosis that wa
2008/12/29 Jeremy Adams
> Hey all,
>
> There's an issue with the minute change file
> 200812290912-200812290913.osc.gz.
> It contains a way which has over 40k nodes. It's an administrative
> boundary
> which appears to enclose all of Quebec. It's way id is 29309772. When
> osmosis
> attempts t
Jeremy Adams wrote:
> It's not the ROMA script that's failing - osmosis is failing while
> it's trying to update the database using changesets from the main
> API.
>
> Whatever db schema the main API uses must allow for this, while the
> one for osmosis that was used to setup at least my server do
It's not the ROMA script that's failing - osmosis is failing while it's trying
to update the database using changesets from the main API.
Whatever db schema the main API uses must allow for this, while the one for
osmosis that was used to setup at least my server does not.
-Jeremy
Original Mes
Jeremy Adams wrote:
> There's an issue with the minute change file 200812290912-200812290913.osc.gz.
> It contains a way which has over 40k nodes. It's an administrative boundary
> which appears to enclose all of Quebec. It's way id is 29309772. When
> osmosis
> attempts to process this file it
Hey all,
There's an issue with the minute change file 200812290912-200812290913.osc.gz.
It contains a way which has over 40k nodes. It's an administrative boundary
which appears to enclose all of Quebec. It's way id is 29309772. When osmosis
attempts to process this file it fails. The relevant
64 matches
Mail list logo
