GiST Concurrency Project : IMPORTANT

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

GiST Concurrency Project : IMPORTANT

Paul Ramsey
PostGIS'ers,

Oleg and Teodor are ready to attack GiST concurrency, so the time has
come for all enterprise PostGIS users to dig deep and help fund this
project.

http://archives.postgresql.org/pgsql-hackers/2005-06/msg00294.php

Refractions Research will contribute $2000 towards this development
project, and will serve as a central bundling area for all funds
contributed towards this project. As such, we will provide invoices that
can be provided to accounts payable departments and cash cheques on
North American banks to get the money oversees to Oleg and Teodor. No,
we will not assess any commisions for this: we want to see this done.

GiST concurrency will allow more granular locking for spatial table
updates, inserts and deletes, and will provide improved performance for
all users with multi-user systems doing data management. We in the
PostGIS project have done all we can to get the most out of the existing
GiST structure, but now we have to help the experts make GiST even better.

Please contact me on or off list, whatever you are comfortable with. I
hope that everyone who needs this functionality can find $1-5K to
contribute towards getting this done for 8.1.

Thanks,

Paul
_______________________________________________
postgis-users mailing list
[hidden email]
http://postgis.refractions.net/mailman/listinfo/postgis-users
Reply | Threaded
Open this post in threaded view
|

Re: GiST Concurrency Project : IMPORTANT

Paul Ramsey

Just an update. There are 700 people on this mailing list currently.  
As of this morning, I have received zero (0) responses on this.

An explanation of why this is important: currently, when doing an  
update or delete to a stable with a GiST index (any indexed PostGIS  
table) PostgreSQL must obtain a FULL TABLE LOCK. That means only one  
update can go in at a time. That means that if you are querying a  
table at the same time someone is updating it, things slow down.  
Basically it means in terms of handling concurrent data  
modifications, GiST tables (PostGIS tables) are an order of magnitude  
less effective than b-tree tables (non-spatial tables). We have found  
that with just two (2) developers working on a large spatial  
database, it is possible for them to step on each others toes by  
doing large updates on spatial tables. One starts an update, and  
suddenly the other finds some of her queries that use that table are  
blocking and delaying. Eventually, if you use PostGIS for tasks that  
involve data modification, you *will* run into this problem.

This is a huge opportunity to improve the core on which PostGIS is  
built. If you are thinking "we don't need this now, and if we need it  
later we will come up with the money and have it done then", you are  
making strategic error. Right now, there is an opportunity to pool  
your funds with others and pay a lot less for very high end  
functionality: later, there may not be a pool.  Right now, there are  
experienced, brilliant developers ready to start on the work, and  
when you need the functionality, it will be there: later, they may  
not be available, and even if they are it will take them months to  
complete the work.  Later, will you be able to afford the delay?

This is not a sales pitch, this is a customer pitch. Like you, we are  
a heavy *user* of PostGIS, that is why we are willing to put up our  
own money for this improvement. If you need invoices for accounting  
purposes, we can act as a middle man. If you do not, then by all  
means, contact Oleg and Teodor directly. But as a community, we are  
really coming up short if we cannot make this one happen.

Paul

On 7-Jun-05, at 7:56 PM, Paul Ramsey wrote:

> PostGIS'ers,
>
> Oleg and Teodor are ready to attack GiST concurrency, so the time  
> has come for all enterprise PostGIS users to dig deep and help fund  
> this project.
>
> http://archives.postgresql.org/pgsql-hackers/2005-06/msg00294.php
>
> Refractions Research will contribute $2000 towards this development  
> project, and will serve as a central bundling area for all funds  
> contributed towards this project. As such, we will provide invoices  
> that can be provided to accounts payable departments and cash  
> cheques on North American banks to get the money oversees to Oleg  
> and Teodor. No, we will not assess any commisions for this: we want  
> to see this done.
>
> GiST concurrency will allow more granular locking for spatial table  
> updates, inserts and deletes, and will provide improved performance  
> for all users with multi-user systems doing data management. We in  
> the PostGIS project have done all we can to get the most out of the  
> existing GiST structure, but now we have to help the experts make  
> GiST even better.
>
> Please contact me on or off list, whatever you are comfortable  
> with. I hope that everyone who needs this functionality can find  
> $1-5K to contribute towards getting this done for 8.1.

_______________________________________________
postgis-users mailing list
[hidden email]
http://postgis.refractions.net/mailman/listinfo/postgis-users
Reply | Threaded
Open this post in threaded view
|

RE: GiST Concurrency Project : IMPORTANT

Gregory S. Williamson
In reply to this post by Paul Ramsey
I am all in favor of this, and am trying to get the company which employs my labor time to commit some resources to this ... don't be discouraged by a lack of immediate response, please. It's just that, uhm, bean counters can be notoriously hard to persuade even if the utility and cost effectiveness of the solution is clear to those of who use these tools.

If only the DBA, Chief Information Officer and other such titles carried more weight !

Greg WIlliamson
DBA
GLobeXplorer LLC
-----Original Message-----
From: [hidden email] on behalf of Paul Ramsey
Sent: Fri 6/10/2005 4:48 AM
To: PostGIS Users Discussion
Cc:
Subject: Re: [postgis-users] GiST Concurrency Project : IMPORTANT

Just an update. There are 700 people on this mailing list currently.  
As of this morning, I have received zero (0) responses on this.

An explanation of why this is important: currently, when doing an  
update or delete to a stable with a GiST index (any indexed PostGIS  
table) PostgreSQL must obtain a FULL TABLE LOCK. That means only one  
update can go in at a time. That means that if you are querying a  
table at the same time someone is updating it, things slow down.  
Basically it means in terms of handling concurrent data  
modifications, GiST tables (PostGIS tables) are an order of magnitude  
less effective than b-tree tables (non-spatial tables). We have found  
that with just two (2) developers working on a large spatial  
database, it is possible for them to step on each others toes by  
doing large updates on spatial tables. One starts an update, and  
suddenly the other finds some of her queries that use that table are  
blocking and delaying. Eventually, if you use PostGIS for tasks that  
involve data modification, you *will* run into this problem.

This is a huge opportunity to improve the core on which PostGIS is  
built. If you are thinking "we don't need this now, and if we need it  
later we will come up with the money and have it done then", you are  
making strategic error. Right now, there is an opportunity to pool  
your funds with others and pay a lot less for very high end  
functionality: later, there may not be a pool.  Right now, there are  
experienced, brilliant developers ready to start on the work, and  
when you need the functionality, it will be there: later, they may  
not be available, and even if they are it will take them months to  
complete the work.  Later, will you be able to afford the delay?

This is not a sales pitch, this is a customer pitch. Like you, we are  
a heavy *user* of PostGIS, that is why we are willing to put up our  
own money for this improvement. If you need invoices for accounting  
purposes, we can act as a middle man. If you do not, then by all  
means, contact Oleg and Teodor directly. But as a community, we are  
really coming up short if we cannot make this one happen.

Paul

On 7-Jun-05, at 7:56 PM, Paul Ramsey wrote:

> PostGIS'ers,
>
> Oleg and Teodor are ready to attack GiST concurrency, so the time  
> has come for all enterprise PostGIS users to dig deep and help fund  
> this project.
>
> http://archives.postgresql.org/pgsql-hackers/2005-06/msg00294.php
>
> Refractions Research will contribute $2000 towards this development  
> project, and will serve as a central bundling area for all funds  
> contributed towards this project. As such, we will provide invoices  
> that can be provided to accounts payable departments and cash  
> cheques on North American banks to get the money oversees to Oleg  
> and Teodor. No, we will not assess any commisions for this: we want  
> to see this done.
>
> GiST concurrency will allow more granular locking for spatial table  
> updates, inserts and deletes, and will provide improved performance  
> for all users with multi-user systems doing data management. We in  
> the PostGIS project have done all we can to get the most out of the  
> existing GiST structure, but now we have to help the experts make  
> GiST even better.
>
> Please contact me on or off list, whatever you are comfortable  
> with. I hope that everyone who needs this functionality can find  
> $1-5K to contribute towards getting this done for 8.1.

_______________________________________________
postgis-users mailing list
[hidden email]
http://postgis.refractions.net/mailman/listinfo/postgis-users

!DSPAM:42a97e08126587556341591!





_______________________________________________
postgis-users mailing list
[hidden email]
http://postgis.refractions.net/mailman/listinfo/postgis-users
Reply | Threaded
Open this post in threaded view
|

INSERT geom Problem

Levert Donovan
Hello,
This is the continuation of the message Postgis
Problem , I continued on the problem and I discover
where is the problem.

It is a problem from INSERT and the AddGeometryColumn.

this INSERT works fine :
INSERT INTO "popplace"
("unique_key","name","the_geom") VALUES
('128','pari',GeometryFromText('POINT(0 0
0)',27582));

But this INSERT doesn't work :
INSERT INTO "popplace"
("unique_key","name","the_geom") VALUES
('124','London','SRID=27582;0101000000000000A053984241000000C0789A3141');

Do you what is the format of
'SRID=27582;0101000000000000A053984241000000C0789A3141',
how can I convert this to GeometryFromText() function
?

Best Regards.
Donovan LEVERT


       

       
               
___________________________________________________________________________
Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger
Téléchargez cette version sur http://fr.messenger.yahoo.com
_______________________________________________
postgis-users mailing list
[hidden email]
http://postgis.refractions.net/mailman/listinfo/postgis-users
Reply | Threaded
Open this post in threaded view
|

Re: INSERT geom Problem

Mike Leahy
Levert,

I think you can cast the text as geometry as follows:

INSERT INTO "popplace"
("unique_key","name","the_geom") VALUES
('124','London','SRID=27582;0101000000000000A053984241000000C0789A3141'::geometry);


Mike

Levert Donovan wrote:

>Hello,
>This is the continuation of the message Postgis
>Problem , I continued on the problem and I discover
>where is the problem.
>
>It is a problem from INSERT and the AddGeometryColumn.
>
>this INSERT works fine :
>INSERT INTO "popplace"
>("unique_key","name","the_geom") VALUES
>('128','pari',GeometryFromText('POINT(0 0
>0)',27582));
>
>But this INSERT doesn't work :
>INSERT INTO "popplace"
>("unique_key","name","the_geom") VALUES
>('124','London','SRID=27582;0101000000000000A053984241000000C0789A3141');
>
>Do you what is the format of
>'SRID=27582;0101000000000000A053984241000000C0789A3141',
>how can I convert this to GeometryFromText() function
>?
>
>Best Regards.
>Donovan LEVERT
>
>
>
>
>
>
>___________________________________________________________________________
>Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger
>Téléchargez cette version sur http://fr.messenger.yahoo.com
>_______________________________________________
>postgis-users mailing list
>[hidden email]
>http://postgis.refractions.net/mailman/listinfo/postgis-users
>
>  
>

_______________________________________________
postgis-users mailing list
[hidden email]
http://postgis.refractions.net/mailman/listinfo/postgis-users
Reply | Threaded
Open this post in threaded view
|

Re: GiST Concurrency Project : IMPORTANT

Paul Ramsey
In reply to this post by Paul Ramsey
Further update. I have received a number of statements of "interest in
principle" and one PayPal donation, but no official major corporate
contributions yet (aside from Refractions own $2000).

In the next two weeks, I will prepare a short prospectus for
presentation to managers and accountants for those who need one.

On the PayPal front: I have checked with Oleg, and PayPal is not
available in Russia (it only takes a few bad apples, I guess) so direct
donations via that facility are out. For those who want to make a minor
donation via PayPal, you can send contributions to my account
([hidden email]) and I will bundle them and do a direct deposit
into Oleg's bank account with the rest of the funds when the project is
complete. As with the larger "corporate" contributions, I can arrange
for receipts or invoices for PayPal contributions if desired.

Yours,

Paul

Paul Ramsey wrote:

> Just an update. There are 700 people on this mailing list currently.  As
> of this morning, I have received zero (0) responses on this.
>
> An explanation of why this is important: currently, when doing an  
> update or delete to a stable with a GiST index (any indexed PostGIS  
> table) PostgreSQL must obtain a FULL TABLE LOCK. That means only one  
> update can go in at a time. That means that if you are querying a  table
> at the same time someone is updating it, things slow down.  Basically it
> means in terms of handling concurrent data  modifications, GiST tables
> (PostGIS tables) are an order of magnitude  less effective than b-tree
> tables (non-spatial tables). We have found  that with just two (2)
> developers working on a large spatial  database, it is possible for them
> to step on each others toes by  doing large updates on spatial tables.
> One starts an update, and  suddenly the other finds some of her queries
> that use that table are  blocking and delaying. Eventually, if you use
> PostGIS for tasks that  involve data modification, you *will* run into
> this problem.
>
> This is a huge opportunity to improve the core on which PostGIS is  
> built. If you are thinking "we don't need this now, and if we need it  
> later we will come up with the money and have it done then", you are  
> making strategic error. Right now, there is an opportunity to pool  your
> funds with others and pay a lot less for very high end  functionality:
> later, there may not be a pool.  Right now, there are  experienced,
> brilliant developers ready to start on the work, and  when you need the
> functionality, it will be there: later, they may  not be available, and
> even if they are it will take them months to  complete the work.  Later,
> will you be able to afford the delay?
>
> This is not a sales pitch, this is a customer pitch. Like you, we are  a
> heavy *user* of PostGIS, that is why we are willing to put up our  own
> money for this improvement. If you need invoices for accounting  
> purposes, we can act as a middle man. If you do not, then by all  means,
> contact Oleg and Teodor directly. But as a community, we are  really
> coming up short if we cannot make this one happen.
>
> Paul
>
> On 7-Jun-05, at 7:56 PM, Paul Ramsey wrote:
>
>> PostGIS'ers,
>>
>> Oleg and Teodor are ready to attack GiST concurrency, so the time  has
>> come for all enterprise PostGIS users to dig deep and help fund  this
>> project.
>>
>> http://archives.postgresql.org/pgsql-hackers/2005-06/msg00294.php
>>
>> Refractions Research will contribute $2000 towards this development  
>> project, and will serve as a central bundling area for all funds  
>> contributed towards this project. As such, we will provide invoices  
>> that can be provided to accounts payable departments and cash  cheques
>> on North American banks to get the money oversees to Oleg  and Teodor.
>> No, we will not assess any commisions for this: we want  to see this
>> done.
>>
>> GiST concurrency will allow more granular locking for spatial table  
>> updates, inserts and deletes, and will provide improved performance  
>> for all users with multi-user systems doing data management. We in  
>> the PostGIS project have done all we can to get the most out of the  
>> existing GiST structure, but now we have to help the experts make  
>> GiST even better.
>>
>> Please contact me on or off list, whatever you are comfortable  with.
>> I hope that everyone who needs this functionality can find  $1-5K to
>> contribute towards getting this done for 8.1.
>
>
> _______________________________________________
> postgis-users mailing list
> [hidden email]
> http://postgis.refractions.net/mailman/listinfo/postgis-users

_______________________________________________
postgis-users mailing list
[hidden email]
http://postgis.refractions.net/mailman/listinfo/postgis-users
Reply | Threaded
Open this post in threaded view
|

Re: INSERT geom Problem

Mike Leahy
In reply to this post by Levert Donovan
Donovan,

If you cast as type 'geometry' instead of 'point', it should work fine...if you
try the following, you'll see that this produces a point geometry:

db=# select
astext('SRID=27582;0101000000000000A053984241000000C0789A3141'::geometry);
            astext
------------------------------
 POINT(2437287.25 1153656.75)
(1 row)

It should work in your insert statement without any trouble...I tried it with a
table of my own that restricts the geometry column to point geometry only, and I
got no error (using PostGIS 1.0).

Mike

P.S. You'll want to make sure you reply to the list...

Quoting Levert Donovan <[hidden email]>:

> Hello,
>
> Thank you for the response,
> I modified the request with POINT geometry, but I have
> an error :
>
> INSERT INTO "popplace"
> ("unique_key","name","the_geom") VALUES
> ('128','test','SRID=27582;0101000000000000A053984241000000C0789A3141'::POINT);
>
> ERROR:  invalid input syntax for type point:
> "SRID=27582;0101000000000000A053984241000000C0789A3141"
>
>
> Best Regards,
> Donovan LEVERT.
>
>
>
>
> --- Mike Leahy <[hidden email]> a écrit :
>
> > Levert,
> >
> > I think you can cast the text as geometry as
> > follows:
> >
> > INSERT INTO "popplace"
> > ("unique_key","name","the_geom") VALUES
> >
>
('124','London','SRID=27582;0101000000000000A053984241000000C0789A3141'::geometry);

> >
> >
> > Mike
> >
> > Levert Donovan wrote:
> >
> > >Hello,
> > >This is the continuation of the message Postgis
> > >Problem , I continued on the problem and I discover
> > >where is the problem.
> > >
> > >It is a problem from INSERT and the
> > AddGeometryColumn.
> > >
> > >this INSERT works fine :
> > >INSERT INTO "popplace"
> > >("unique_key","name","the_geom") VALUES
> > >('128','pari',GeometryFromText('POINT(0 0
> > >0)',27582));
> > >
> > >But this INSERT doesn't work :
> > >INSERT INTO "popplace"
> > >("unique_key","name","the_geom") VALUES
> >
> >('124','London','SRID=27582;0101000000000000A053984241000000C0789A3141');
> > >
> > >Do you what is the format of
> >
> >'SRID=27582;0101000000000000A053984241000000C0789A3141',
> > >how can I convert this to GeometryFromText()
> > function
> > >?
> > >
> > >Best Regards.
> > >Donovan LEVERT
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >___________________________________________________________________________
> >
> > >Appel audio GRATUIT partout dans le monde avec le
> > nouveau Yahoo! Messenger
> > >Téléchargez cette version sur
> > http://fr.messenger.yahoo.com
> > >_______________________________________________
> > >postgis-users mailing list
> > >[hidden email]
> >
> >http://postgis.refractions.net/mailman/listinfo/postgis-users
> > >
> > >  
> > >
> >
> > _______________________________________________
> > postgis-users mailing list
> > [hidden email]
> >
> http://postgis.refractions.net/mailman/listinfo/postgis-users
> >
>
>
>
>
>
>
>
> ___________________________________________________________________________
> Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger
> Téléchargez cette version sur http://fr.messenger.yahoo.com
>




----------------------------------------
This mail sent through www.mywaterloo.ca
_______________________________________________
postgis-users mailing list
[hidden email]
http://postgis.refractions.net/mailman/listinfo/postgis-users
Reply | Threaded
Open this post in threaded view
|

Re: INSERT geom Problem

Levert Donovan
Hello,
I don't understand why this INSERT doesn't works, I am
using postgis 1.0 :

INSERT INTO "popplace"
("unique_key","name","the_geom") VALUES
('128','test','SRID=27582;0101000000000000A053984241000000C0789A3141'::geometry);
ERROR:  couldnt parse objects in GEOMETRY


INSERT INTO "popplace"
("unique_key","name","the_geom") VALUES
('128','test','SRID=27582;0101000000000000A053984241000000C0789A3141'::point);
ERROR:  invalid input syntax for type point:
"SRID=27582;0101000000000000A053984241000000C0789A3141"

Best Regards.
Donovan


--- Mike Leahy <[hidden email]> a écrit :

> Donovan,
>
> If you cast as type 'geometry' instead of 'point',
> it should work fine...if you
> try the following, you'll see that this produces a
> point geometry:
>
> db=# select
>
astext('SRID=27582;0101000000000000A053984241000000C0789A3141'::geometry);

>             astext
> ------------------------------
>  POINT(2437287.25 1153656.75)
> (1 row)
>
> It should work in your insert statement without any
> trouble...I tried it with a
> table of my own that restricts the geometry column
> to point geometry only, and I
> got no error (using PostGIS 1.0).
>
> Mike
>
> P.S. You'll want to make sure you reply to the
> list...
>
> Quoting Levert Donovan <[hidden email]>:
>
> > Hello,
> >
> > Thank you for the response,
> > I modified the request with POINT geometry, but I
> have
> > an error :
> >
> > INSERT INTO "popplace"
> > ("unique_key","name","the_geom") VALUES
> >
>
('128','test','SRID=27582;0101000000000000A053984241000000C0789A3141'::POINT);
> >
> > ERROR:  invalid input syntax for type point:
> >
>
"SRID=27582;0101000000000000A053984241000000C0789A3141"

> >
> >
> > Best Regards,
> > Donovan LEVERT.
> >
> >
> >
> >
> > --- Mike Leahy <[hidden email]> a écrit
> :
> >
> > > Levert,
> > >
> > > I think you can cast the text as geometry as
> > > follows:
> > >
> > > INSERT INTO "popplace"
> > > ("unique_key","name","the_geom") VALUES
> > >
> >
>
('124','London','SRID=27582;0101000000000000A053984241000000C0789A3141'::geometry);

> > >
> > >
> > > Mike
> > >
> > > Levert Donovan wrote:
> > >
> > > >Hello,
> > > >This is the continuation of the message Postgis
> > > >Problem , I continued on the problem and I
> discover
> > > >where is the problem.
> > > >
> > > >It is a problem from INSERT and the
> > > AddGeometryColumn.
> > > >
> > > >this INSERT works fine :
> > > >INSERT INTO "popplace"
> > > >("unique_key","name","the_geom") VALUES
> > > >('128','pari',GeometryFromText('POINT(0 0
> > > >0)',27582));
> > > >
> > > >But this INSERT doesn't work :
> > > >INSERT INTO "popplace"
> > > >("unique_key","name","the_geom") VALUES
> > >
> >
>
>('124','London','SRID=27582;0101000000000000A053984241000000C0789A3141');
> > > >
> > > >Do you what is the format of
> > >
> >
>
>'SRID=27582;0101000000000000A053984241000000C0789A3141',
> > > >how can I convert this to GeometryFromText()
> > > function
> > > >?
> > > >
> > > >Best Regards.
> > > >Donovan LEVERT
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> >
>
>___________________________________________________________________________
> > >
> > > >Appel audio GRATUIT partout dans le monde avec
> le
> > > nouveau Yahoo! Messenger
> > > >Téléchargez cette version sur
> > > http://fr.messenger.yahoo.com
> > > >_______________________________________________
> > > >postgis-users mailing list
> > > >[hidden email]
> > >
> >
>
>http://postgis.refractions.net/mailman/listinfo/postgis-users
> > > >
> > > >  
> > > >
> > >
> > > _______________________________________________
> > > postgis-users mailing list
> > > [hidden email]
> > >
> >
>
http://postgis.refractions.net/mailman/listinfo/postgis-users

> > >
> >
> >
> >
> >
> >
> >
> >
> >
>
___________________________________________________________________________

>
> > Appel audio GRATUIT partout dans le monde avec le
> nouveau Yahoo! Messenger
> > Téléchargez cette version sur
> http://fr.messenger.yahoo.com
> >
>
>
>
>
> ----------------------------------------
> This mail sent through www.mywaterloo.ca
> _______________________________________________
> postgis-users mailing list
> [hidden email]
>
http://postgis.refractions.net/mailman/listinfo/postgis-users
>



       

       
               
___________________________________________________________________________
Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger
Téléchargez cette version sur http://fr.messenger.yahoo.com
_______________________________________________
postgis-users mailing list
[hidden email]
http://postgis.refractions.net/mailman/listinfo/postgis-users
Reply | Threaded
Open this post in threaded view
|

Re: INSERT geom Problem

Markus Schaber-7
In reply to this post by Levert Donovan
Hi, Levert,

Levert Donovan wrote:

 > But this INSERT doesn't work :
> INSERT INTO "popplace"
> ("unique_key","name","the_geom") VALUES
> ('124','London','SRID=27582;0101000000000000A053984241000000C0789A3141');
>
> Do you what is the format of
> 'SRID=27582;0101000000000000A053984241000000C0789A3141',
> how can I convert this to GeometryFromText() function
> ?
>
Try setsrid() function:

lwgeom=# select
setsrid('0101000000000000A053984241000000C0789A3141'::geometry,27582);
                      setsrid
----------------------------------------------------
 0101000020BE6B0000000000A053984241000000C0789A3141


Alternatively, produce the Hex-EWKB containing the SRID yourself.

HTH,
Schabi
_______________________________________________
postgis-users mailing list
[hidden email]
http://postgis.refractions.net/mailman/listinfo/postgis-users
Reply | Threaded
Open this post in threaded view
|

Re: INSERT geom Problem

Levert Donovan

> What does "SELECT version()" spit out?
$psql  -U mapuser mapcanada
mapcanada=> SELECT version();
version
---------------------------------------------------------------------------------------------------------
 PostgreSQL 7.4.7 on i686-pc-linux-gnu, compiled by
GCC gcc (GCC) 3.2 20020903 (Red Hat Linux 8.0 3.2-7)
(1 row)

> Try setsrid() function:
> lwgeom=#
>select
>setsrid('0101000000000000A053984241000000C0789A3141'::geometry,27582);

I can't do the SELECT because the INSERT doesn't
works.
select
setsrid('0101000000000000A053984241000000C0789A3141'::geometry,27582);


Best Regards.
Donovan LEVERT

--- Markus Schaber <[hidden email]> a écrit :

> Hi, Levert,
>
> Levert Donovan wrote:
>
>  > But this INSERT doesn't work :
> > INSERT INTO "popplace"
> > ("unique_key","name","the_geom") VALUES
> >
>
('124','London','SRID=27582;0101000000000000A053984241000000C0789A3141');
> >
> > Do you what is the format of
> >
>
'SRID=27582;0101000000000000A053984241000000C0789A3141',
> > how can I convert this to GeometryFromText()
> function
> > ?
> >
> Try setsrid() function:
>
> lwgeom=# select
>
setsrid('0101000000000000A053984241000000C0789A3141'::geometry,27582);

>                       setsrid
> ----------------------------------------------------
>  0101000020BE6B0000000000A053984241000000C0789A3141
>
>
> Alternatively, produce the Hex-EWKB containing the
> SRID yourself.
>
> HTH,
> Schabi
> _______________________________________________
> postgis-users mailing list
> [hidden email]
>
http://postgis.refractions.net/mailman/listinfo/postgis-users
>



       

       
               
___________________________________________________________________________
Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger
Téléchargez cette version sur http://fr.messenger.yahoo.com
_______________________________________________
postgis-users mailing list
[hidden email]
http://postgis.refractions.net/mailman/listinfo/postgis-users
Reply | Threaded
Open this post in threaded view
|

Re: INSERT geom Problem

Markus Schaber-7
Hi, Levert,

Levert Donovan wrote:

> $psql  -U mapuser mapcanada
> mapcanada=> SELECT version();
> version
> ---------------------------------------------------------------------------------------------------------
>  PostgreSQL 7.4.7 on i686-pc-linux-gnu, compiled by
> GCC gcc (GCC) 3.2 20020903 (Red Hat Linux 8.0 3.2-7)
> (1 row)

That looks fine.

> I can't do the SELECT because the INSERT doesn't
> works.
> select
> setsrid('0101000000000000A053984241000000C0789A3141'::geometry,27582);

You do not need any INSERT for this SELECT.

Just type "select
setsrid('0101000000000000A053984241000000C0789A3141'::geometry,27582);"
at the psql prompt.

Schabi
_______________________________________________
postgis-users mailing list
[hidden email]
http://postgis.refractions.net/mailman/listinfo/postgis-users
Reply | Threaded
Open this post in threaded view
|

Re: INSERT geom Problem

strk
In reply to this post by Levert Donovan
On Mon, Jun 13, 2005 at 11:07:23AM +0200, Levert Donovan wrote:
> Hello,
> I don't understand why this INSERT doesn't works, I am
> using postgis 1.0 :
>
> INSERT INTO "popplace"
> ("unique_key","name","the_geom") VALUES
> ('128','test','SRID=27582;0101000000000000A053984241000000C0789A3141'::geometry);
> ERROR:  couldnt parse objects in GEOMETRY

SELECT postgis_version() ?
1.x uses HEXEWKB (what I see in your query) as canonical input,
0.x uses EWKT instead.
--strk;
_______________________________________________
postgis-users mailing list
[hidden email]
http://postgis.refractions.net/mailman/listinfo/postgis-users
Reply | Threaded
Open this post in threaded view
|

Re: INSERT geom Problem

Levert Donovan
In reply to this post by Markus Schaber-7
Hello,
I have make a mistake, I have not using Postis 1.0 but
Postgis 0.9.1.

mapcanada=> SELECT postgis_full_version();
                                       
postgis_full_version                    
-----------------------------------------------------------------------------------------------------
 POSTGIS="0.9.1" GEOS="1.0.0" PROJ="Rel. 4.4.8, 3 May
2004" USE_STATS DBPROC="0.0.1" RELPROC="0.0.1"
(1 row)

I solved the problem with shp2pgsql, I used -w option
for the postgis 0.x

Thank you for your responses.

Best Regards.
Donovan


>Just type "select
setsrid('0101000000000000A053984241000000C0789A3141'::geometry,27582);"
at the psql prompt.
ERROR:  couldnt parse objects in GEOMETRY

--- Markus Schaber <[hidden email]> a écrit :

> Hi, Levert,
>
> Levert Donovan wrote:
>
> > $psql  -U mapuser mapcanada
> > mapcanada=> SELECT version();
> > version
> >
>
---------------------------------------------------------------------------------------------------------

> >  PostgreSQL 7.4.7 on i686-pc-linux-gnu, compiled
> by
> > GCC gcc (GCC) 3.2 20020903 (Red Hat Linux 8.0
> 3.2-7)
> > (1 row)
>
> That looks fine.
>
> > I can't do the SELECT because the INSERT doesn't
> > works.
> > select
> >
>
setsrid('0101000000000000A053984241000000C0789A3141'::geometry,27582);
>
> You do not need any INSERT for this SELECT.
>
> Just type "select
>
setsrid('0101000000000000A053984241000000C0789A3141'::geometry,27582);"
> at the psql prompt.
>
> Schabi
> _______________________________________________
> postgis-users mailing list
> [hidden email]
>
http://postgis.refractions.net/mailman/listinfo/postgis-users
>



       

       
               
___________________________________________________________________________
Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger
Téléchargez cette version sur http://fr.messenger.yahoo.com
_______________________________________________
postgis-users mailing list
[hidden email]
http://postgis.refractions.net/mailman/listinfo/postgis-users