Hi.
I have searched for ways that are contained in other ways (see attached
SQL) and found 1+ (5000+ of length 2) in my local database
containing a post 0.6-migration map (from 2009-04) of germany. It seems
there are quite a lot of obvious inconsistencies like e.g. the ways
33816455,
Am Dienstag, den 07.07.2009, 18:50 -0400 schrieb Jeffrey Warren:
No, the data is not corrupt, nor are there duplicate entries. Quite a
few current_way_nodes are not getting deleted when they cease to be
'current', that is, once they're only
history and no longer part of the current planet.
Am Mittwoch, den 01.07.2009, 09:47 +1000 schrieb Brett Henderson:
Jeffrey Warren wrote:
And along those lines, should we remove the foreign key constraints
from the schema, Brett, if they're not necessary and they cause
Osmosis imports to fail?
I don't mind really. I only make them
Am Freitag, den 05.06.2009, 12:40 -0400 schrieb Jeffrey Warren:
and it's been running the following query for about 24 hours:
SELECT Count(*) AS changesetCount FROM changesets WHERE id=$1
Take a look on Brets pgsql-latest.sql script (after the COPYs) and add
the index on id:
ALTER TABLE
Am Freitag, den 05.06.2009, 14:58 -0400 schrieb Jeffrey Warren:
Detail: Key (node_id)=(395051992) is not present in table
current_nodes.
The field that is present is actually named node_id and that is the one
that is mentioned.
ALTER TABLE ONLY current_way_nodes ADD CONSTRAINT
Am Dienstag, den 02.06.2009, 11:52 -0700 schrieb Jeffrey Warren:
I was importing a planet dump to pgsql with the --write-apidb-0.6 and
got the error:
ERROR: insert or update on table current_way_nodes violates foreign
key constraint current_way_nodes_node_id_fkey Detail: Key
Hi.
I successfully used osmosis to load the cuurent map of germany into the
postgres schema from Brett Henderson:
http://gweb.bretth.com/apidb06-pgsql-latest.sql
Here is a short Howto:
1. I split the above skript into 2 parts at the COPY statements.
2. I ran the first part to create the schema
Hi.
Do you already have a
http://gweb.bretth.com/osm_schema_latest.sql
for the 0.6 API database. The above is still MySQL and looks outdated.
Thanks,
Joachim
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
Am Dienstag, den 21.04.2009, 18:29 +0200 schrieb Jonas Krückel
(John07):
The downtime seemed quite long for me
I myself was actually impressed by the speed. Congratulations :)
Sincerely,
Joachim
___
dev mailing list
dev@openstreetmap.org
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
Am Sonntag, den 30.11.2008, 21:38 +0100 schrieb Andreas Kalsch:
I have split up the sql script in two parts - 1st to create table
just
with primary keys on auto_increment fields, 2nd to alter the
populated
tables.
Be aware that an ALTER TABLE on MySQL (at least with InnoDb) always
copies
Am Mittwoch, den 26.11.2008, 12:54 + schrieb Matt Amos:
Well, as long as the API code is good, and makes this check, then
the
transaction should cover it for inserts/updates. I'd assume the
migration script will have to handle existing inconsistencies.
that is exactly why i'm
Am Montag, den 01.12.2008, 14:49 +0100 schrieb Andreas Kalsch:
Brett Henderson schrieb:
Whenever I have seen that error in the past it has been because I
have
data in the tables already. Changing table types shouldn't have
any
effect on duplicate key checks. It'd be worth double
Am Montag, den 01.12.2008, 19:15 +0100 schrieb Joachim Zobel:
Is there any chance there is a 0 PK? This may trigger an auto
increment.
To bee more specific:
mysql CREATE TABLE test (t INTEGER PRIMARY KEY AUTO_INCREMENT);
Query OK, 0 rows affected (0.11 sec)
mysql INSERT INTO test(t) VALUES(0
Am Sonntag, den 30.11.2008, 15:38 +0100 schrieb Andreas Kalsch:
com.mysql.jdbc.exceptions.MySQLIntegrityConstraintViolationException:
Duplicate entry '1' for key 1
Did you start with empty tables? This looks like remains from a
cancelled previous run.
Sincerely,
Joachim
Am Samstag, den 29.11.2008, 18:45 +0100 schrieb Andreas Kalsch:
I decompress the data before putting them into Osmosis, but it's still
slow.
So back to my question -- ;)
(The best would be raw dump files for MySQL's LOAD DATA INFILE - I
can
imagine that it would be pretty quick)
This has
Am Samstag, den 29.11.2008, 18:45 +0100 schrieb Andreas Kalsch:
I decompress the data before putting them into Osmosis, but it's still
slow.
So back to my question -- ;)
(The best would be raw dump files for MySQL's LOAD DATA INFILE - I
can
imagine that it would be pretty quick)
There is
Am Donnerstag, den 16.10.2008, 09:21 +1100 schrieb Brett Henderson:
Do you have any numbers to show what sort of performance increase can
be expected.
I can load europe.osm into the current_* tables in less than 12 hours
(on my laptop - overpowered CPU, 5400 disk).
If it's significant I
Hi.
I have written a utility named scabies to load data from osm files into
a mysql database. See
http://www.heute-morgen.de/scabies/
Usage is rather straightforward, but you need lots of disk space.
scabies_parse.pl parses the osm file and creates files that are then
loaded by scabies_load.sql
Hi.
Is there any documentation on the timestamp attribute? If no time zone
is given, can I assume it is UTC?
Sincerely,
Joachim
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
Hi.
Not shure if it isn't too late,...
Am Mittwoch, den 24.09.2008, 19:54 +0200 schrieb Jaume Figueras:
Then I
also changed the name of all static variables in my_mod_tile.c.
There should be a line
module AP_MODULE_DECLARE_DATA tile_module;
Did you change that? Did you add a second
Am Donnerstag, den 09.10.2008, 22:48 +0100 schrieb Shaun McDonald:
However they will still be in the history. Which need to be
converted
too in the api change.
Changing the history is a questionable thing to do. A history should IMHO
accurately reflect what has been.
Sincerely,
Joachim
Am Sonntag, den 05.10.2008, 17:10 +0100 schrieb Richard Fairhurst:
I did a few bits of SQL footling around recently on a UK planet and
it would _roughly_ suggest that more UK edits at present are done
with Potlatch than JOSM. I suspect the reverse is true in Germany!
See also
Am Freitag, den 26.09.2008, 11:10 +0200 schrieb Frederik Ramm:
My take is always that the users are grown-ups and responsible for
their
own actions. If there is something cool that would be useful for many
legit purposes, then I'd always do it.
[...]
Just make sure you *tell* people that
Hi.
Just in case nobody found this yet, here is a trick to compute a
quadtile in a single expression. The essence is to convert to the binary
representation (base 2) and interpret it as base 4. This inserts all the
0s between the bits. The rest is simple.
(CONV(BIN(FLOOR(0.5 +
Am Samstag, den 30.08.2008, 08:39 -0700 schrieb Karl Newman:
If I recall correctly, the database column is not actually set for
UTF-8 (but is double-encoded to return actual UTF-8 to the client...).
Wouldn't it be a better long-term fix to change the database to UTF-8
(or whatever), then
Am Montag, den 18.08.2008, 13:30 +0200 schrieb Marc Schütz:
Is there actually a valid use case for having the same node multiple
times in a row?
I don't see any.
I could write a script to korrect the existing ones. Do the sequence_ids
have to be in sequence (which means the ones above need to
Am Donnerstag, den 07.08.2008, 23:32 +0200 schrieb Frederik Ramm:
Tom Hughes wrote:
The schema is fully defined by the rails migrations which are
publically
available in subversion.
Or use Brett Henderson's ready made schema dump:
http://gweb.bretth.com/osm_schema_latest.sql
Hi.
http://wiki.openstreetmap.org/index.php/Database_schema#MySQL
does not have relations.
Sincerely,
Joachim
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
Am Donnerstag, den 24.07.2008, 09:29 +0200 schrieb Frederik Ramm:
The editor is the only instance that has the necessary information.
But
relying on clients to do the right thing will fail in the long run.
Don't see why.
Because thats what always happens if (especially multiple) clients
Am Freitag, den 16.05.2008, 20:59 +0200 schrieb Martijn van Oosterhout:
I agree that it should be moved out personally - any volunteers to
do the job?
Me, if this is still an issue.
Been done AIUI. Will be deployed at some time...
Shure? I did not find anything in
Am Donnerstag, den 29.05.2008, 16:51 +0200 schrieb Stefan de Konink:
Is there a reason not to implement it this way?
Quite simple. A way is not a relation.
Sincerely,
Joachim
___
dev mailing list
dev@openstreetmap.org
Am Montag, den 26.05.2008, 15:07 +0100 schrieb Tom Hughes:
The reason is that we have to allow about 600Mb or so for each call
and that quickly mounts up as you try and add extra simultaneous
accesses.
If _that_ amount of memory is needed this probably means the XML is
build in memory. This
Am Montag, den 26.05.2008, 15:10 +0100 schrieb Tom Hughes:
If you start using temporary tables you need to make shure that data
from temporary tables is not written to the database. INSERT, UPDATE
and
DELETE statements using temporary tables are forbidden.
No they're not. I know this
Am Samstag, den 24.05.2008, 09:24 +0100 schrieb Alex Wilson:
the database using temporary tables
If you start using temporary tables you need to make shure that data
from temporary tables is not written to the database. INSERT, UPDATE and
DELETE statements using temporary tables are forbidden.
Am Mittwoch, den 21.05.2008, 11:14 +0100 schrieb Alex Wilson:
Further to earlier discussion on this list, I've been looking into
writing a C++ version of the OSM API server. When discussing this
before, it was suggested that an Apache module would be the best way
to plug such an API into the
36 matches
Mail list logo
