On Mon, Sep 29, 2008 at 11:51 AM, Andreas Kalsch [EMAIL PROTECTED]wrote:
Hi,
I haven't found a solution by search to this problem. Osmosis cannot
connect to my database. I can connect on my system with the same
user/password. The same input worked in the past - and I haven't changed
the
Steve Hill wrote:
What are the postgres version requirements for patch mode?
= postgresql 8.2 with GIST and GIN index support compiled in.
/ Grant
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
... are nearly 4 times faster than multi.colum indices for lat/lon in
MySQL. Extracting 1 column / 17.000 rows out of 1 million takes .39 secs
vs. 1.39 - I think all Postgres guys know a similar value. I think this
is a pretty impressing result.
On Mon, September 29, 2008 15:47, Andreas Kalsch wrote:
Sure - this is the pipeline for the geofabrik belgium file - so I am
sure that it's their fault, cause luxembourg and liechtenstein worked
properly:
[ ... ]
at com.bretth.osmosis.core.xml.v0_5.XmlReader.run(XmlReader.java:109) at
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Frederik Ramm schreef:
Stefan de Konink wrote:
In NL we would call this ultimate anarchy and unless one of our
dictators steps in to stop anyone nothing happens. So if someone doesn't
like automatic edits it should be able to be reverted
Thanks
thank FSM we don't use multi column indexes then huh?
On 29 Sep 2008, at 06:50, Andreas Kalsch wrote:
... are nearly 4 times faster than multi.colum indices for lat/lon in
MySQL. Extracting 1 column / 17.000 rows out of 1 million takes .39
secs
vs. 1.39 - I think all Postgres guys
Hi devs,
I have been looking at the work required for getting the API 0.6 branch
to be ready for production usage. There appears to be quite a lot of
work still to do. The todo list is on the wiki:
http://wiki.openstreetmap.org/index.php/OSM_Protocol_Version_0.6#Todo_List
One of the problems I
On Mon, Sep 29, 2008 at 6:27 PM, Shaun McDonald
[EMAIL PROTECTED] wrote:
One of the problems I see with the migrations is that there is no
linkage between the changesets and the revisions of the nodes, ways and
relations. Is it simply a case of adding a changeset field to each of
the following
Hi,
Has anybody done any work on storing OSM data into a sqlite database? I
mean large quantities of data (even planet-size)? I looked through our
wiki and googled a little but couldn't find any information about it.
I'm wondering if it is feasible at all and what kind of performance it
would
Marcus Wolschon schrieb:
Andreas Kalsch schrieb:
... are nearly 4 times faster than multi.colum indices for lat/lon
in MySQL. Extracting 1 column / 17.000 rows out of 1 million takes
.39 secs vs. 1.39 - I think all Postgres guys know a similar value.
I think this is a pretty impressing
On Mon, Sep 29, 2008 at 08:25:11PM +0200, Igor Brejc wrote:
Has anybody done any work on storing OSM data into a sqlite database? I
mean large quantities of data (even planet-size)? I looked through our
wiki and googled a little but couldn't find any information about it.
I'm wondering if
Stefan Keller wrote:
sqlite reports to have a limit to a few dozen GB.
You could also give a try to db4o: It's also a embedded ODBMS in pure
Java. It's program limit is set to 254GB per database-file.
Stefan
Well I was interested in sqlite since it has .NET support (I'm evil, you
know
Jochen Topf wrote:
On Mon, Sep 29, 2008 at 09:46:40PM +0200, Stefan Keller wrote:
db4o is also native .NET (but yeah, .NET *and* relational means that
you are really on the dark side of the force :-).
But Jochen could be right: I fear all embedded DBMS - whether
relational or OO - are
On Mon, Sep 29, 2008 at 09:46:40PM +0200, Stefan Keller wrote:
db4o is also native .NET (but yeah, .NET *and* relational means that
you are really on the dark side of the force :-).
But Jochen could be right: I fear all embedded DBMS - whether
relational or OO - are slow beyond some hundert
On 29 Sep 2008, at 18:48, Martijn van Oosterhout wrote:
On Mon, Sep 29, 2008 at 6:27 PM, Shaun McDonald
[EMAIL PROTECTED] wrote:
One of the problems I see with the migrations is that there is no
linkage between the changesets and the revisions of the nodes, ways
and
relations. Is it simply
Hi,
I guess it also depends of what exactly you're trying to do with the
data. I was thinking about using the DB for map rendering, which can be
quite data- and processing-intensive.
It looks like I'll have to test it myself when I get the chance and
write something about it in the Wiki.
On Mon, Sep 29, 2008 at 9:59 PM, Igor Brejc [EMAIL PROTECTED] wrote:
Jochen Topf wrote:
On Mon, Sep 29, 2008 at 09:46:40PM +0200, Stefan Keller wrote:
db4o is also native .NET (but yeah, .NET *and* relational means that
you are really on the dark side of the force :-).
But Jochen could be
17 matches
Mail list logo
