The coordinates you get from extent do not look like WGS84 (lat/lon) which is
EPSG code 4326. Are they UTC zone 33N (which covers Austria?). If the
original projection is incorrect this would explain the inf results from
ST_TRANSFORM.
Phil
>
>From: Jan Peter
Rene,
There is no single answer to this as it depends on your usage, type of
data, etc. You can get some pointers here
http://postgis.refractions.net/docs/ch06.html#id2636014
Also a search on the mailing list will give you some information on what to
change, some messages are a bit old but they
Rene,
You're best asking the PostgreSQL Performance (pgsql-performance)
mailing list.
http://www.postgresql.org/community/lists/
If you have any spatial-specific questions (a query is running slower
than expected), then definitely post here.
-bborie
On 11/06/2011 10:16 AM, René Fournier w
Sorry for posting in a reply last time:
Dear all,
I am a bit stuck: I just encountered that some of my PostGIS datasets were
defined as EPSG:31259 in the geometry_colums table, but the geometry data was
actually EPSG:4326. Now I wanted to project this data from 4326 to 31259 via:
CREATE TABLE t
Dear all,
I am a bit stuck: I just encountered that some of my PostGIS datasets were
defined as EPSG:31259 in the geometry_colums table, but the geometry data was
actually EPSG:4326. Now I wanted to project this data from 4326 to 31259 via:
CREATE TABLE table_31259 AS
SELECT
table_4326.id,
ST_
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/06/2011 12:40 PM, Sandro Santilli wrote:
> Ivan, maybe tracking history of a PostGIS topology would be an interesting
> use case for you. It'd require tracking multiple tables at once, so that
> "restore" operations are also performed on all tabl
Apparently the gdal Python binding is not able to determine the pixeltype of
the raster...
Does gdalinfo can?
> -Original Message-
> From: postgis-users-boun...@postgis.refractions.net [mailto:postgis-users-
> boun...@postgis.refractions.net] On Behalf Of elliott
> Sent: Monday, November
Hi,
I have tried to load an HDF4 formatted MODIS temperature file with the
raster2pgsql.py script and getting the following error. I have built
GDAL with the HDF4 format and it seems to recognize the file but the
loader is having the following problem:
/usr/local/pgsql/bin/raster2pgsql.py -
>> Now, trying to import it with:
>>
>>shp2pgsql -s EPSG:26191 -I -D morocco.shp morocco> morocco.sql
>>psql -U my_database< morocco.sql
>
> Hi Stefan,
>
> The SRID argument to shp2pgsql should just be a plain numeric field, and not
> have the EPSG prefix in front of it,
On 07/11/11 14:07, Stefan Schwarzer wrote:
Now, trying to import it with:
shp2pgsql -s EPSG:26191 -I -D morocco.shp morocco> morocco.sql
psql -U my_database< morocco.sql
Hi Stefan,
The SRID argument to shp2pgsql should just be a plain numeric field, and
not have the E
On 7 November 2011 15:07, Stefan Schwarzer wrote:
> Hi there,
>
> I am somewhat fighting with the projection of my file.
>
> I have a file for Morocco, which, after ArcMap, has the following projection:
>
> Projected Coordinate System: zone1
> Projection: Lambert_Conformal_Con
Hi there,
I am somewhat fighting with the projection of my file.
I have a file for Morocco, which, after ArcMap, has the following projection:
Projected Coordinate System: zone1
Projection: Lambert_Conformal_Conic
False_Easting: 50.
False_Northi
12 matches
Mail list logo
