Re: [postgis-users] Patch for casting geometry to geography
I've added this patch as item #799 on OSGEO.
I understand the philosophy of failing loudly; in many cases it is the right
thing to do. However the longitude values I described are not truly errors,
and arise from what I think is legitimate use of spatial reference system
EPSG:4326. For anyone who is trying to migrate from geometries to geographies,
I think a more forgiving casting function will be a huge advantage. For this
reason, I hope the change will be accepted.
Steve Marshall
-Original Message-
From: postgis-users-boun...@postgis.refractions.net
[mailto:postgis-users-boun...@postgis.refractions.net] On Behalf Of Paul Ramsey
Sent: Friday, January 21, 2011 12:03 PM
To: PostGIS Users Discussion; PostGIS Development Discussion
Subject: Re: [postgis-users] Patch for casting geometry to geography
Note, I originally intended to do a lot of this kind of quiet
helpfulness but -devel persuaded me not to, on the principle that it
was better to fail noisily ("can't deal with these coordinates!") than
to screw up silently (incorrectly "fixing" things that shouldn't be
fixed).
P
On Thu, Jan 20, 2011 at 3:07 PM, Paragon Corporation wrote:
> Steve,
>
> It would help if you posted this issue as a bug ticket and then attach the
> patch to it.
> http://trac.osgeo.org/postgis/newticket
>
> That way it will get on our list on items.
>
>
>
> Since it doesn't require an external function addition, I think it can be
> slated for PostGIS 1.5.3
>
> Thanks,
> Regina
> http://www.postgis.us
>
>
> -Original Message-
> From: postgis-users-boun...@postgis.refractions.net
> [mailto:postgis-users-boun...@postgis.refractions.net] On Behalf Of
> Marshall, Steve
> Sent: Thursday, January 20, 2011 3:29 PM
> To: postgis-users@postgis.refractions.net
> Subject: [postgis-users] Patch for casting geometry to geography
>
> Related to an earlier post by Radu Ilie, I have a patch for casting from
> geometry to geography that solves his problem. In particular, it will
> transform coordinates into the desired range for geography objects (-90 to
> 90 lat, -180 to 180 lon). The previous version detected this problem, but
> simply issued an error if it occurred.
>
> The attached files add one new external function to the the postgis library
> (lwgeom_force_geodetic) and uses it in the function that casts geometry
> objects to geography objects (Datum geography_in). The logic is a very
> simple clone of the lwgeom_check_geodetic function, except it fixes any
> descrepancies it finds.
>
> I hope this could be included in a future PostGIS release. If necessary, I
> can post this to a different list.
>
> Steve Marshall
>
>
> ___
> postgis-users mailing list
> postgis-users@postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users
>
___
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users
___
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] Patch for casting geometry to geography
http://www.osgeo.org/osgeo_userid On Fri, Jan 21, 2011 at 2:42 PM, Marshall, Steve wrote: > I get an error when I try to post to the URL below: > TICKET_CREATE privileges are required to perform this operation > > Do I need a particular account to post to OSGEO? Can someone either > explain to me how to get the proper credential, or post my patch as a > bug ticket to OSGEO? > > Thanks, > Steve > > > -Original Message- > From: postgis-users-boun...@postgis.refractions.net > [mailto:postgis-users-boun...@postgis.refractions.net] On Behalf Of > Paragon Corporation > Sent: Thursday, January 20, 2011 6:07 PM > To: 'PostGIS Users Discussion' > Subject: Re: [postgis-users] Patch for casting geometry to geography > > Steve, > > It would help if you posted this issue as a bug ticket and then attach > the > patch to it. > http://trac.osgeo.org/postgis/newticket > > That way it will get on our list on items. > > > > Since it doesn't require an external function addition, I think it can > be > slated for PostGIS 1.5.3 > > Thanks, > Regina > http://www.postgis.us > > > -Original Message- > From: postgis-users-boun...@postgis.refractions.net > [mailto:postgis-users-boun...@postgis.refractions.net] On Behalf Of > Marshall, Steve > Sent: Thursday, January 20, 2011 3:29 PM > To: postgis-users@postgis.refractions.net > Subject: [postgis-users] Patch for casting geometry to geography > > Related to an earlier post by Radu Ilie, I have a patch for casting from > geometry to geography that solves his problem. In particular, it will > transform coordinates into the desired range for geography objects (-90 > to > 90 lat, -180 to 180 lon). The previous version detected this problem, > but > simply issued an error if it occurred. > > The attached files add one new external function to the the postgis > library > (lwgeom_force_geodetic) and uses it in the function that casts geometry > objects to geography objects (Datum geography_in). The logic is a very > simple clone of the lwgeom_check_geodetic function, except it fixes any > descrepancies it finds. > > I hope this could be included in a future PostGIS release. If > necessary, I > can post this to a different list. > > Steve Marshall > > > ___ > postgis-users mailing list > postgis-users@postgis.refractions.net > http://postgis.refractions.net/mailman/listinfo/postgis-users > > ___ > postgis-users mailing list > postgis-users@postgis.refractions.net > http://postgis.refractions.net/mailman/listinfo/postgis-users > ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] Patch for casting geometry to geography
I get an error when I try to post to the URL below: TICKET_CREATE privileges are required to perform this operation Do I need a particular account to post to OSGEO? Can someone either explain to me how to get the proper credential, or post my patch as a bug ticket to OSGEO? Thanks, Steve -Original Message- From: postgis-users-boun...@postgis.refractions.net [mailto:postgis-users-boun...@postgis.refractions.net] On Behalf Of Paragon Corporation Sent: Thursday, January 20, 2011 6:07 PM To: 'PostGIS Users Discussion' Subject: Re: [postgis-users] Patch for casting geometry to geography Steve, It would help if you posted this issue as a bug ticket and then attach the patch to it. http://trac.osgeo.org/postgis/newticket That way it will get on our list on items. Since it doesn't require an external function addition, I think it can be slated for PostGIS 1.5.3 Thanks, Regina http://www.postgis.us -Original Message- From: postgis-users-boun...@postgis.refractions.net [mailto:postgis-users-boun...@postgis.refractions.net] On Behalf Of Marshall, Steve Sent: Thursday, January 20, 2011 3:29 PM To: postgis-users@postgis.refractions.net Subject: [postgis-users] Patch for casting geometry to geography Related to an earlier post by Radu Ilie, I have a patch for casting from geometry to geography that solves his problem. In particular, it will transform coordinates into the desired range for geography objects (-90 to 90 lat, -180 to 180 lon). The previous version detected this problem, but simply issued an error if it occurred. The attached files add one new external function to the the postgis library (lwgeom_force_geodetic) and uses it in the function that casts geometry objects to geography objects (Datum geography_in). The logic is a very simple clone of the lwgeom_check_geodetic function, except it fixes any descrepancies it finds. I hope this could be included in a future PostGIS release. If necessary, I can post this to a different list. Steve Marshall ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] migrating tables to postgis
Thank you for all your help. In the end, it turns out to be relatively
simple (as long as you know who to ask...) For anyone interested, here are
the steps I performed to display these tables together in QGIS.
1. Add a geometry column to the table that contains the coordinates, which
is my station inventory table, Table1.
SELECT AddGeometryColumn('Table1','the_geom', 26918,'POINT', 2);
UPDATE Table1 SET the_geom = ST_SetSRID(ST_MakePoint(EASTING,NORTHING),
26918);
2. Add a primary key field (of integer type) to my project data table
(Table2) that will be used as the primary key in QGIS.
ALTER TABLE "Table2" ADD COLUMN id SERIAL PRIMARY KEY;
3. Create a view containing all records in my project data table and the
matching geometry (and a few other fields I need) in the station inventory
table. "DGSID" is the common field between them, which I had to give an
alias to since it had the same name in both tables.
CREATE VIEW "siteview" AS
SELECT
"Table2".*,
"Table1"."DGSID" as dgsid2,
"Table1"."EASTING",
"Table1"."NORTHING",
"Table1"."the_geom"
FROM
public."Table2",
public."Table1"
WHERE
"Table1"."DGSID" = "Table2"."DGSID"
ORDER BY
"Table2"."DGSID" ASC;
4. Manually add a record for the view in the geometry_columns table.
INSERT INTO geometry_columns(f_table_catalog, f_table_schema, f_table_name,
f_geometry_column, coord_dimension, srid, "type")
VALUES ('', 'public', 'siteview', 'the_geom', 2, 26918, 'POINT');
That's it. It's working beautifully. Thanks again.
- John
**
John Callahan, Research Scientist
Delaware Geological Survey, University of Delaware
URL: http://www.dgs.udel.edu
**
On Wed, Jan 19, 2011 at 12:20 PM, MarkW wrote:
> Views are fine in Qgis for me, but in my experience you'll need to manually
> add a record to the GeometryColumns table, and include a suitable unique ID
> field into the view or Qgis will complain.
>
> I think views are what you want based on your description. I think the
> table structure qualifier was because you said "etc" without giving all
> fields from each table, and a one-to-many relationship (or other) wasn't all
> that clear in your first message. My guess. But yeah, it's easier if you
> give the relationship between tables and a few rows of sample data (in, out)
> can't hurt in communicating.
>
> Finally, Etienne's suggestion was better - my impression (from the PostGIS
> in Action book which I recommend by the way!) gives the example of ST_point
> for your purpose and I've had an easier time using it with column names than
> ST_GeomFromText.
>
> Mark
>
>
> On Wed, Jan 19, 2011 at 11:18 AM, John Callahan wrote:
>
>> Thanks for your response Rob. Looks good. I'll give this a try.
>>
>> I cannot merge everything into one table. Our station inventory table
>> contains only the basics/metadata about each station. As other projects
>> arise, they each have their own tables containing data observations for that
>> project only. There are many project tables with all types of data.
>>
>> As an aside, for future questions, what kind of table information would
>> you (the list) need in order to provide support? Would you need column
>> types (string, numeric), or some sample data? Thanks.
>>
>>
>> - John
>>
>> **
>> John Callahan, Research Scientist
>> Delaware Geological Survey, University of Delaware
>> URL: http://www.dgs.udel.edu
>> **
>>
>>
>> On Wed, Jan 19, 2011 at 10:56 AM, wrote:
>>
>>> Hi John:
>>>
>>> Given your stated table structure**, a query like the following should
>>> give you the records you want.
>>>
>>> SELECT t2.*, t1.geometry_column --substitute your newly created geometry
>>> column for "geometry_column"
>>> FROM table2 t2 LEFT JOIN table1 t1 ON(t2.stationid = t1.stationid);
>>>
>>> The "LEFT JOIN" specifies that you want all rows from table2 and just the
>>> matching rows from table1.
>>>
>>> **It's difficult to predict success of any proposed solution without more
>>> info on the structure and content of your two tables.
>>>
>>> Have you considered merging the data into one table, allowing null values
>>> for the table2 attributes? You would then be able to select specific records
>>> without performing a join. If you've already created your table1 geometry
>>> column, you can quickly generate a "master" table or view (don't know if
>>> QGIS will recognize a view--might have to be a table) by:
>>>
>>> CREATE TABLE stations AS --or CREATE VIEW stations AS
>>> SELECT t2.*, t1.*
>>> FROM table2 t2 JOIN table1 t1 ON(t2.stationid = t1.stationid);
>>>
>>> Hope that helps.
>>>
>>> Cheers,
>>> Rob
>>>
>>> --
>>> *From:* postgis-users-boun...@postgis.refractions.net [mailto:
>>> postgis-users-boun...@postgis.refractions.net] *On Behalf Of *John
>>> Callahan
>>> *Sent:* Wednesday, January
Re: [postgis-users] Patch for casting geometry to geography
Note, I originally intended to do a lot of this kind of quiet
helpfulness but -devel persuaded me not to, on the principle that it
was better to fail noisily ("can't deal with these coordinates!") than
to screw up silently (incorrectly "fixing" things that shouldn't be
fixed).
P
On Thu, Jan 20, 2011 at 3:07 PM, Paragon Corporation wrote:
> Steve,
>
> It would help if you posted this issue as a bug ticket and then attach the
> patch to it.
> http://trac.osgeo.org/postgis/newticket
>
> That way it will get on our list on items.
>
>
>
> Since it doesn't require an external function addition, I think it can be
> slated for PostGIS 1.5.3
>
> Thanks,
> Regina
> http://www.postgis.us
>
>
> -Original Message-
> From: postgis-users-boun...@postgis.refractions.net
> [mailto:postgis-users-boun...@postgis.refractions.net] On Behalf Of
> Marshall, Steve
> Sent: Thursday, January 20, 2011 3:29 PM
> To: postgis-users@postgis.refractions.net
> Subject: [postgis-users] Patch for casting geometry to geography
>
> Related to an earlier post by Radu Ilie, I have a patch for casting from
> geometry to geography that solves his problem. In particular, it will
> transform coordinates into the desired range for geography objects (-90 to
> 90 lat, -180 to 180 lon). The previous version detected this problem, but
> simply issued an error if it occurred.
>
> The attached files add one new external function to the the postgis library
> (lwgeom_force_geodetic) and uses it in the function that casts geometry
> objects to geography objects (Datum geography_in). The logic is a very
> simple clone of the lwgeom_check_geodetic function, except it fixes any
> descrepancies it finds.
>
> I hope this could be included in a future PostGIS release. If necessary, I
> can post this to a different list.
>
> Steve Marshall
>
>
> ___
> postgis-users mailing list
> postgis-users@postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users
>
___
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] Problems using ST_Contains to check if a linestring is included in a multilinestring
Hi, Same result on Mac OSX, same PG versions as yours. Seems like a bug, no ? Nicolas On 19 January 2011 13:20, Jochen Woidich wrote: > Hello, > > I'm pretty new to postgis and mailing lists, so please excuse if I'm > breaking any conventions. :) > > I'm trying to use ST_Contains to check if a certain linestring is > included in a multilinestring. This seems to work fine until the > linestring grows. > > This query (http://paste.frubar.net/13291) should imho return true for > both calls, but only the first one equals to true. > > Any hint on what i'm doing wrong? > > PostgreSQL 9.0, PostGIS v1.5.2-3, running on Windows. > ___ > postgis-users mailing list > postgis-users@postgis.refractions.net > http://postgis.refractions.net/mailman/listinfo/postgis-users > ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] Using asKML() with google maps
Hi RH. You can use Geoserver for most advanced features (regions, zoom levels). However AsKML is better for simple and fast mapping solutions. Less code, no painful installations. Your choise. -- Yesid Carrillo Esp SIG On Wed, Jan 19, 2011 at 5:43 PM, R H wrote: > I'm more of a DBA than a GIS developer and I hoping someone can help > understand a few things? > > I'm using asKML() to render some polygons in google maps through a network > link. It's in the preliminary phases and works ok. I have seen several > examples where geoServer is used with google maps to do basically them same > thing. What are the pros and cons of using something like geoServer with > google maps. Opposed to only using google maps? Eventually I would like to > add some tools to interact with the polygon data, is that where the > geoServer would help? > > Thanks in advance, any advice would be helpful... > > ___ > postgis-users mailing list > postgis-users@postgis.refractions.net > http://postgis.refractions.net/mailman/listinfo/postgis-users > > ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] Why use C procedurals for Postgres
I'm on RedHat 5 Enterprise. I have installed PostgreSQL 8.4.2 and Postgis 1.5.2 I have not customized PostgreSQL or Postgis installation. > From: nicklas.a...@jordogskog.no > To: postgis-users@postgis.refractions.net > Date: Fri, 21 Jan 2011 15:13:52 +0100 > Subject: Re: [postgis-users] Why use C procedurals for Postgres > > Hallo > > You should not need do change any security settings that is default in > PostgreSQL to run PostGIS. > But if there is some security setting that that is customized to not > allow C-langage functions there will be problems since PostGIS is > written in C. > > But if you have not customized any security settings in PostgreSQL this > is just a symptom of something els. > > What OS are you running? > > /Nicklas > > > > > On Fri, 2011-01-21 at 13:44 +, Rudy COMMENGE wrote: > > Hello, > > > > I have installed Postgis with PostgreSQL. > > When I try to send postgis.sql to PostgreSQL, I have an error > > notifying C is not trusted. > > So I think I have found a solution : I disable the security with this > > request "UPDATE pg_language SET lanpltrusted=true WHERE lanname='c';" > > > > But this is a security, so is there another solution without disable ? > > If not, why Postgis need to bypass a PostgreSQL security ? > > > > Regards, > > > > RudyWI > > ___ > > postgis-users mailing list > > postgis-users@postgis.refractions.net > > http://postgis.refractions.net/mailman/listinfo/postgis-users > > > ___ > postgis-users mailing list > postgis-users@postgis.refractions.net > http://postgis.refractions.net/mailman/listinfo/postgis-users ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] Why use C procedurals for Postgres
On 21/01/11 13:44, Rudy COMMENGE wrote: Hello, I have installed Postgis with PostgreSQL. When I try to send postgis.sql to PostgreSQL, I have an error notifying C is not trusted. So I think I have found a solution : I disable the security with this request "UPDATE pg_language SET lanpltrusted=true WHERE lanname='c';" But this is a security, so is there another solution without disable ? If not, why Postgis need to bypass a PostgreSQL security ? Regards, RudyWI Hi Rudy, Only the PostgreSQL super-user can install C functions into the database, and for good reason. A C function can execute any code in the context of the database, and so your change above has opened up a big security hole in your database - I strongly recommend you change it back. Note that once you've installed PostGIS as the database super-user, you can always use ALTER TABLE...OWNER... to change the ownership of your tables back to your normal (non-super) user. HTH, Mark. -- Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS Sirius Corporation plc - control through freedom http://www.siriusit.co.uk t: +44 870 608 0063 Sirius Labs: http://www.siriusit.co.uk/labs ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] Why use C procedurals for Postgres
Hallo You should not need do change any security settings that is default in PostgreSQL to run PostGIS. But if there is some security setting that that is customized to not allow C-langage functions there will be problems since PostGIS is written in C. But if you have not customized any security settings in PostgreSQL this is just a symptom of something els. What OS are you running? /Nicklas On Fri, 2011-01-21 at 13:44 +, Rudy COMMENGE wrote: > Hello, > > I have installed Postgis with PostgreSQL. > When I try to send postgis.sql to PostgreSQL, I have an error > notifying C is not trusted. > So I think I have found a solution : I disable the security with this > request "UPDATE pg_language SET lanpltrusted=true WHERE lanname='c';" > > But this is a security, so is there another solution without disable ? > If not, why Postgis need to bypass a PostgreSQL security ? > > Regards, > > RudyWI > ___ > postgis-users mailing list > postgis-users@postgis.refractions.net > http://postgis.refractions.net/mailman/listinfo/postgis-users ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
[postgis-users] Why use C procedurals for Postgres
Hello, I have installed Postgis with PostgreSQL. When I try to send postgis.sql to PostgreSQL, I have an error notifying C is not trusted. So I think I have found a solution : I disable the security with this request "UPDATE pg_language SET lanpltrusted=true WHERE lanname='c';" But this is a security, so is there another solution without disable ? If not, why Postgis need to bypass a PostgreSQL security ? Regards, RudyWI ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
