Hi,
I also downloaded the extension and managed to install it within the
target database. But when I attempt to enable the target-table, I get
the following error:
HINWEIS: CREATE TABLE erstellt implizit eine Sequenz
»uberschwemmungsgebiete_h
istory_history_id_seq« für die
Ricardo,
Clearly, if you want to search across different tables you need a way to
combine data in a common place. You should not do anything like search
the tables one after the other and combine the results.
Even if you merge all tables into one, you will need some explicit
mechanism (trigger!)
Peter Hopfgartner wrote:
Hi
I tried to upgrade the shapelib version in PostGIS to the current one, as found
in the current shapelib CVS repository.
What I did was:
* copy safileio.c shapefil.h shpopen.c dbfopen.c from shapelib
* add support for dates and include the functions DBFReadSetup
Is there, or are we likely to see a way of calculating ST_Azimuth on the
spheroid?
Is an implementation, overloading ST_Azimuth to accept the GEOGRAPHY type to
be expected?
I suspect the code has already been written, given the existence of
ST_Distance_Spheroid which presumably uses Vincenty's
Dear all,
I'm having a hard time porting a postgis database to another server
(let's call server A the one where the original database resides and
server B the one where I need to replicate the database). I'm trying
it in two different ways:
1. Creating a fresh empty database at server B and
You could try the newest version of pgadmin, 1.12.0 beta3. It lets you
do partial dumps of a database.
Jan
On 08/04/10 13:15, Luís de Sousa wrote:
Dear all,
I'm having a hard time porting a postgis database to another server
(let's call server A the one where the original database resides
El Wednesday 04 August 2010, Luís de Sousa escribió:
1. Creating a fresh empty database at server B and then restoring.
With this process PostGres complains of not having permissions to
create basic types.
Are you executing that restore with a user who has permissions to create basic
types?
Hi Luís,
you may need to do first a backup globals of the entire database cluster
A. (to import users, etc..)
A good practice (I think) is to avoid public schema for data...
Then, for option B, you can backup only data schemas (and use postgis
function to populate geometry_columns at the end)
Hi,
Am Mittwoch, 4. August 2010 13:15:04 schrieb Luís de Sousa:
I'm having a hard time porting a postgis database to another server
I suggest to follow the steps as described in the PostGIS manual for hard
upgrades [1].
Regards,
Frank
[1]
I'm sorry, I don't know german. Can't help you with that.
For what I could understand is that the relation
uberschwemmungsgebiete existiert nicht
doest not exist. Are you sure the table exists?
It should work, my current version works.
If you can translate the error would be nice :P
I'll
Indeed, the code is there, it just needs to be exposed to SQL. Do you
build your own PostGIS Francis? If so you can open a ticket for the
feature and I'll provide a patch there you can apply. If not, it could
be a long wait for PostGIS 2.0 and new features. (several months)
P
On Wed, Aug 4, 2010
Mark Cave-Ayland mark.cave-ayl...@siriusit.co.uk wrote
Subject: Re: [postgis-users] Update to current shapelib
Date: 04.08.2010 11:40
Peter Hopfgartner wrote:
Hi
I tried to upgrade the shapelib version in PostGIS to the current one,
as found in the current shapelib CVS
Uli and Simon,
Thank you very much for your quick response.
I agree in not searching table by table, and merging the results.
I will store the Full Text ts_vector data into one common table. I guess I
will use the TableOID + GID to know excatly where the indexed data came
from.
Thanks again to
Hi Luis,
With option 2, all the errors are about a failure to create objects (postgis
functions spatial_ref_sys entries I assume).
Why is this a problem for you? They already exist so do not need to be
reinstalled, the rest of your database should be installed, so you should have
a fully
14 matches
Mail list logo
