On Thu, Apr 05, 2012 at 09:25:40AM +1000, Evan Martin wrote:
> >70 west, 10 north is in venezuela which is outside the bounds of
> >available NAD27 to NAD83 conversion files. Try (-120 40).
>
> Thanks, Frank. Yes, (-120 40) works. Just to confirm, will PostGIS
> always return the input coordinate
>70 west, 10 north is in venezuela which is outside the bounds of
>available NAD27 to NAD83 conversion files. Try (-120 40).
Thanks, Frank. Yes, (-120 40) works. Just to confirm, will PostGIS
always return the input coordinates now when they're outside the bounds
of the input datum, rather tha
On Mon, Apr 2, 2012 at 7:53 PM, Evan Martin
wrote:
> When trying to transform from NAD27 (SRID 4267) to WGS84 (SRID 4326) some
> points used to fail as of 2.0.0 beta 3 (bug 318). I've just tried 2.0.0 RC 2
> and they now return the input value unchanged, eg.
>
> SELECT ST_AsText(ST_Transform(ST_Ge
ctions.net] On Behalf Of Stephen Crawford
Sent: Tuesday, February 28, 2012 11:51 AM
To: postgis-users@postgis.refractions.net
Subject: Re: [postgis-users] Transform
ScaleX and ScaleY are identical for each tile in the original table, and are all
different in the transformed table, which I guess s
> boun...@postgis.refractions.net] On Behalf Of Stephen Crawford
> Sent: Tuesday, February 28, 2012 11:51 AM
> To: postgis-users@postgis.refractions.net
> Subject: Re: [postgis-users] Transform
>
> ScaleX and ScaleY are identical for each tile in the original table, and are
> all
> diff
ScaleX and ScaleY are identical for each tile in the original table, and
are all different in the transformed table, which I guess should make
sense on a transform?
I actually now think my output problem is in GDAL. I have been
outputting AAIGrids which I then use in geoserver. The values ar
> OK, it seems ST_Transform is working for me, but I'm a bit confused about the
> "raster_columns" table. The original (pre-transform) raster table is a set of
> 187
> tiles. In raster_columns 'scale_x', 'scale_y', 'blocksize_x', 'blocksize_y'
> are all
> defined, and 'same_alignment'=t.
> Then
rre Racine wrote:
So Steve could you fix this problem? Any update?
Pierre
-Original Message-
From: postgis-users-boun...@postgis.refractions.net [mailto:postgis-users-
boun...@postgis.refractions.net] On Behalf Of Stephen Crawford
Sent: Tuesday, February 21, 2012 3:11 PM
To: postgis-users@postgis.r
users-boun...@postgis.refractions.net [mailto:postgis-users-
boun...@postgis.refractions.net] On Behalf Of Stephen Crawford
Sent: Tuesday, February 21, 2012 3:11 PM
To: postgis-users@postgis.refractions.net
Subject: Re: [postgis-users] Transform
Spoke too soon. Now the new table is in the correct projection, but
: postgis-users@postgis.refractions.net
> Subject: Re: [postgis-users] Transform
>
> Spoke too soon. Now the new table is in the correct projection, but almost
> all
> of the data have been changed to "0" (should be a % such as
> 93.25 etc). The original raster is tiled; do
Spoke too soon. Now the new table is in the correct projection, but
almost all of the data have been changed to "0" (should be a % such as
93.25 etc). The original raster is tiled; do I need to do a Union
first, or something else I'm missing?
Thanks,
Steve
On 2/21/2012 2:20 PM, Bborie Park
I saw the note in the docs just as I received your reply. That did the
trick. Thanks.
On 2/21/2012 2:20 PM, Bborie Park wrote:
Steve,
Are you running Windows? If so, I believe there is a known issue with
GDAL not finding the proj.4 DLL. You'll need to set the env variable
PROJSO to the f
Steve,
Are you running Windows? If so, I believe there is a known issue with
GDAL not finding the proj.4 DLL. You'll need to set the env variable
PROJSO to the full path to the DLL.
http://trac.osgeo.org/gdal/wiki/ConfigOptions
-bborie
On 02/21/2012 11:06 AM, Stephen Crawford wrote:
Hi A
-boun...@postgis.refractions.net] On Behalf Of Mars
Sjoden
Sent: Thursday, January 13, 2011 2:12 AM
To: PostGIS Users Discussion
Subject: Re: [postgis-users] Transform WGS84 to UTM
Just a refresher,
WGS84 is a Datum
UTM is a Projection that can use WGS84 as its Datum
On Wed, Jan 12, 2011 at 1:59
Just a refresher,
WGS84 is a Datum
UTM is a Projection that can use WGS84 as its Datum
On Wed, Jan 12, 2011 at 1:59 AM, Birgit Laggner
wrote:
> Hi Lelo,
>
> yes, normally it's very simple. If you know the SRID of the projection you
> want to transform your geometry to, you only have to use
>
>
Hi Lelo,
yes, normally it's very simple. If you know the SRID of the projection
you want to transform your geometry to, you only have to use
ST_Transform(your_geometry_column, new_srid_number)
(see:
http://postgis.refractions.net/documentation/manual-1.5/ST_Transform.html)
If you don't kn
Depending on how you choose to ultimately run this query, if you unwrap
the point by point processing into a loop inside a stored procedure,
then you can set up an auxiliary table that you use to figure out what
UTM zone, and therefore what EPSG, to use for your projection. This is
better than usi
Mark,
Lets say your table is called sometable and is in 4326 projection, then
it would look something like
SELECT ebas.ebaname, distance(ebas.the_geom, pt.the_geom) as
Distance_Metres
FROM ebas
INNER JOIN
(SELECT gid, ST_Transform(the_geom, 32662) As the_geom
FROM sometable WHERE gid = 1)
Might have to do with the proj version you are using adnthe nad shift grid
thingy.
What does
SELECT postgis_full_version();
-Original Message-
From: postgis-users-boun...@postgis.refractions.net
[mailto:postgis-users-boun...@postgis.refractions.net] On Behalf Of toni
hernández
Sent: Mo
Quoting lisek lichu <[EMAIL PROTECTED]>:
You can also add new column in Your table
SELECT
AddGeometryColumn('','table_name','new_column_name','new_SRID','POINT',2);
after that jst do:
UPDATE table_name set new_column_name = Transform(old_geom_column,new_SRID);
after that query You will ha
WOW i didn't know that
Thanks a lot :P
On Wed, Nov 12, 2008 at 18:16, Jean David TECHER
<[EMAIL PROTECTED]>wrote:
> The two options are right but becarefull with the second!
>
> You will have to do something like
>
> ALTER TABLE ADD COLUMN ...
>
> Because of the remarks taken from PostgreSQL do
The two options are right but becarefull with the second!
You will have to do something like
ALTER TABLE ADD COLUMN ...
Because of the remarks taken from PostgreSQL doc
"Adding a column with a non-null default or changing the type of an
existing column will require the entire table to be re
You can also add new column in Your table
SELECT
AddGeometryColumn('','table_name','new_column_name','new_SRID','POINT',2);
after that jst do:
UPDATE table_name set new_column_name = Transform(old_geom_column,new_SRID);
after that query You will have 2 columnt: first with old SRID ald second
wi
Thank you very much Nicolas.
On Wed, Nov 12, 2008 at 8:42 AM, Nicolas Ribot <[EMAIL PROTECTED]> wrote:
> > How can I transform the coordinate system of a table ?
> > I know the SRID is 4326.
> >
> > Thanks a lot
> >
>
> Basically, by using st_transform(geometry, srid) on your table.
> It may be
> How can I transform the coordinate system of a table ?
> I know the SRID is 4326.
>
> Thanks a lot
>
Basically, by using st_transform(geometry, srid) on your table.
It may be a little more complicated if you have SRID constraints on your table.
2 options among several:
1°) Drop the constraint,
EMAIL PROTECTED]
Sent: Friday, October 10, 2008 11:22 AM
To: PostGIS Users Discussion
Subject: Re: [postgis-users] transform - update
lakesetthe_geom=transform(the_geom, 26971)
Thanks to all.
The problem in my case was that I relied on PgAdmin doing my SQL queries
and
it does not display ce
riday, October 10, 2008 10:00 AM
Subject: Re: [postgis-users] transform - update lake
setthe_geom=transform(the_geom, 26971)
I have a table city which contains Multipolygons (SRID=4326) in latitude
and
longitude. To project it to a plane coordinate (SRID=26971), I did:
update lake set t
> I have a table city which contains Multipolygons (SRID=4326) in latitude and
> longitude. To project it to a plane coordinate (SRID=26971), I did:
>
> update lake set the_geom=transform(the_geom, 26971);
>
> It ran without any error. But some of the resulted values in the_geom column
> became
is null;
>
> The sql below returns npoints = 218:
> select gid, npoints(the_geom) from city where polygon_id=35665106;
>
> Thanks,
> CYW
>
> - Original Message - From: "Paul Ramsey" <
> [EMAIL PROTECTED]>
> To: "PostGIS Users Discussion&quo
t; CYW
>
> - Original Message - From: "Paul Ramsey" <[EMAIL PROTECTED]>
> To: "PostGIS Users Discussion"
> Sent: Thursday, October 09, 2008 10:12 PM
> Subject: Re: [postgis-users] TRANSFORM failures with some multiploygons -
> datasample attached
&g
postgis_full_version
POSTGIS="1.3.3" GEOS="3.0.0-CAPI-1.4.1" PROJ="Rel. 4.6.0, 21 Dec 2007"
USE_STATS
- Original Message -
From: "Paul Ramsey" <[EMAIL PROTECTED]>
To: "PostGIS Users Discussion"
Sent: Thursday, October 09, 2008
>> It ran without any error. But some of the resulted values in the_geom
>> column became null or empty.
How did you check this?
select gid from thetable where the_geom is null?
select gid from thetabel where npoints(the_geom) =
P
___
postgis-users mai
I'm not seeing this problem on your polygon. What does
select postgis_full_version()
say?
On Thu, Oct 9, 2008 at 7:56 PM, <[EMAIL PROTECTED]> wrote:
> Hi All,
>
> In debugging the problem below, I found that TRANSFORM would fail with some
> of my city multipolygons.
>
> I would think that the T
Your syntax looks right, all that's missing is whether the def'n for
102010 you are using matching your input coordinates, which we can't
tell, since we don't know what you're using for 102010.
P
On Fri, Sep 5, 2008 at 11:55 AM, Angel Menendez <[EMAIL PROTECTED]> wrote:
> Hi:
> doing that
> int_x
ing an intermediary workspace
table
Hope that helps,
Regina
*From:* [EMAIL PROTECTED] on behalf of
Kevin Neufeld
*Sent:* Wed 7/16/2008 2:24 PM
*To:* PostGIS Users Discussion
*Subject:* Re: [postgis-users] Transform overlap
ad by creating an intermediary workspace
table
Hope that helps,
Regina
*From:* [EMAIL PROTECTED] on behalf of
Kevin Neufeld
*Sent:* Wed 7/16/2008 2:24 PM
*To:* PostGIS Users Discussion
*Subject:* Re: [postgis-users] Transform
Title: Re: [postgis-users] Transform overlapping polygons to
non-overlapping?
Brent, good to see someone else having fun with this issue! We worked
through it a couple of months ago, established a procedure, but had
some continuing issues with robustness and performance with large
datasets
er.
With those follow Kevin's lead by creating an intermediary workspace table
Hope that helps,
Regina
From: [EMAIL PROTECTED] on behalf of Kevin Neufeld
Sent: Wed 7/16/2008 2:24 PM
To: PostGIS Users Discussion
Subject: Re: [postgis-users] Transform overla
tely inside another, it is not considered to
overlap, but they do intersect.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Paragon
Corporation
Sent: Wednesday, July 16, 2008 12:41 PM
To: 'PostGIS Users Discussion'
Subject: RE: [postgis-user
Dylan,
Yes! Clean polygons! I gravitated towards PostGIS due to my large number of
polygons (1.2 million), and I'd like a solution that is scalable beyond that
number. GRASS may be the/an answer; I'll give it a try.
Thanks!
Brent
Dylan Beaudette wrote:
On Wednesday 16 July 2008, Brent Fra
EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On Behalf Of
> > Paragon Corporation
> > Sent: Wednesday, July 16, 2008 12:41 PM
> > To: 'PostGIS Users Discussion'
> > Subject: RE: [postgis-users] Transform overlapping polygons to
> > non-overlapping?
>
Paragon
Corporation
Sent: Wednesday, July 16, 2008 12:41 PM
To: 'PostGIS Users Discussion'
Subject: RE: [postgis-users] Transform overlapping polygons to
non-overlapping?
Brent,
INSERT INTO temp3_lines (the_geom)
SELECT ST_ExteriorRing( ST_GeometryN(the_geom, generate_series(1,
ST_NumGeome
: Wednesday, July 16, 2008 12:41 PM
To: 'PostGIS Users Discussion'
Subject: RE: [postgis-users] Transform overlapping polygons to
non-overlapping?
Brent,
INSERT INTO temp3_lines (the_geom)
SELECT ST_ExteriorRing( ST_GeometryN(the_geom, generate_series(1,
ST_NumGeometries(the_g
--
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Brent
Fraser
Sent: Wednesday, July 16, 2008 12:13 PM
To: PostGIS Users Discussion
Subject: Re: [postgis-users] Transform overlapping polygons to
non-overlapping?
To all,
My quest for non-overlapping polygons continues:
I start
ri 7/11/2008 12:14 PM
*To:* PostGIS Users Discussion
*Subject:* Re: [postgis-users] Transform overlapping polygons to
non-overlapping?
To All,
There doesn't seem to be an obvious answer to the problem given
below (aka cleaning polygons, creating planar polygons, etc). I did
see a not
--
*From:* [EMAIL PROTECTED] on behalf of Brent
Fraser
*Sent:* Fri 7/11/2008 12:14 PM
*To:* PostGIS Users Discussion
*Subject:* Re: [postgis-users] Transform overlapping polygons to
non-overlapping?
To All,
There doesn't seem to be an obvious answer to the problem given below
(a
(r.the_geom, a.the_geom)));
Hope that helps,
Regina
From: [EMAIL PROTECTED] on behalf of Brent Fraser
Sent: Fri 7/11/2008 12:14 PM
To: PostGIS Users Discussion
Subject: Re: [postgis-users] Transform overlapping polygons to non-overlapping?
To All,
There
To All,
There doesn't seem to be an obvious answer to the problem given below (aka cleaning
polygons, creating planar polygons, etc). I did see a note on the PostGIS wiki wishlist
to "Add a geometry cleaner". There is also a suggestion to convert to
linestrings, node, then polygonize (while
On Wed, 2007-06-20 at 15:25 +0200, Lobo wrote:
> Hi,
>
> I have problem executing the following query:
>
> SELECT transform(the_geom,4326) FROM gm_1996;
>
> It results in the following error message:
>
> ERROR: AddToPROJ4SRSCache: couldn't parse proj4 string: '+proj=sterea
> +lat_0= 52.1561605
49 matches
Mail list logo
