Hi Frederik,
I'm running minutely updates on south-east asia. The DB is comparably
small. After I did this:
On 07.08.2011 21:19, Frederik Ramm wrote:
DROP INDEX planet_osm_ways_nodes;
DROP INDEX planet_osm_rels_parts;
CREATE INDEX planet_osm_ways_nodes ON planet_osm_ways USING gin (nodes)
Hello,
I have detected some extrange problems with Dominican Republic country.
All reverse geocoding were from Virgin Islands country (country_code
rq). This error was on 05/08/2011, now all is recovered.
My server is periodically downloading to do a recover:
Hi!
After starting this command:
osm2pgsql/osm2pgsql -s -C 3000 -d gis -U gisuser -S default.style gis.osm
I get this output from osm2pgsql:
osm2pgsql SVN version 0.80.0 (32bit id space)
(...)
The target database has the intarray contrib module loaded.
While required for earlier versions of
Hi,
On 08/08/11 19:08, mar...@gmx.eu wrote:
The target database has the intarray contrib module loaded.
While required for earlier versions of osm2pgsql, intarray
is now unnecessary and will interfere with osm2pgsql's array
handling. Please use a database without intarray.
Simply drop your
On Mon, 2011-08-08 at 19:08 +0200, mar...@gmx.eu wrote:
Hi!
After starting this command:
osm2pgsql/osm2pgsql -s -C 3000 -d gis -U gisuser -S default.style gis.osm
I get this output from osm2pgsql:
osm2pgsql SVN version 0.80.0 (32bit id space)
(...)
The target database has the
Hi Frederik and Jon,
thanks a lot, this worked!
There was no uninstall procedure available but the database could be recreated
easily.
Markus
Original-Nachricht
Datum: Mon, 08 Aug 2011 19:30:03 +0200
Von: Frederik Ramm frede...@remote.org
An: dev@openstreetmap.org
Hi,
Stephan Knauss wrote:
Sorry, for me it's not fully clear. Maybe for my small DB it's fine to
reimport, but for others having the whole planet:
There's a misunderstanding here.
The old intarray method and the now builtin PostgreSQL arrays method
lead to a slightly different structure in
On 07.08.2011 21:19, Frederik Ramm wrote:
To be a bit clearer on the procedure to fix things: Either re-import, or
re-create indexes with
DROP INDEX planet_osm_ways_nodes;
DROP INDEX planet_osm_rels_parts;
CREATE INDEX planet_osm_ways_nodes ON planet_osm_ways USING gin (nodes)
WITH
Hi,
Stephan Knauss wrote:
On 07.08.2011 21:19, Frederik Ramm wrote:
To be a bit clearer on the procedure to fix things: Either re-import, or
re-create indexes with
DROP INDEX planet_osm_ways_nodes;
DROP INDEX planet_osm_rels_parts;
CREATE INDEX planet_osm_ways_nodes ON planet_osm_ways USING
On 09.08.2011 00:00, Frederik Ramm wrote:
Stephan Knauss wrote:
This did lead to huge problems on my DB as it was still using the
intarray for the updates.
I don't understand. The intarray/no intarray question is completely
unrelated to the fastupdate on/off question?
The problem was that
Hi,
Stephan Knauss wrote:
The problem was that the INDEX is different. It has the gin__int_ops
included on my installation with intarray in place.
Ah, now I see. My instructions on rebuilding the index were not taking
the old style into account. Sorry, I overlooked that!
So, anyone else
Picking up my earlier question at:
http://lists.openstreetmap.org/pipermail/osmosis-dev/2011-July/001092.html
On 22 July 2011 08:22, Shaun McDonald sh...@shaunmcdonald.me.uk wrote:
It is a problem with trailing spaces in MySQL VARCHAR:
http://sql-info.de/mysql/gotchas.html#1_6
Yeah, trailing
12 matches
Mail list logo
