Re: [postgis-users] Infinite loop in st_intersects - because of incorrect data out of st_transform?
On Thu, May 26, 2011 at 11:46:34AM -0700, Paul Ramsey wrote: > Like so? > > http://trac.osgeo.org/postgis/attachment/ticket/987/inf2.patch A few points: 1: GEOS-driven ST_IsValid raises a NOTICE containing the reason, home-made version should do the same. 2: I see you're not handling nan, just infinite. Is that intentional ? 3: GEOS-3.2 also survive the inf/nans in GEOSValid, why checkin for 3.3+ ? 4: Expecting the error in tickets.sql makes the whole test file pass or fail based on the version of GEOS you built postgis against. --strk; () Free GIS & Flash consultant/developer /\ http://strk.keybit.net/services.html ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] polygon of sphere
Hi Mike, Look at "case" in your SQL, might meet your needs & if the ST_contains()/ST_covers() function reuslt is cached in a select statement, which I think it is now, will be reasonably effective. http://www.postgresql.org/docs/9.0/interactive/plpgsql-control-structures.html select case when ST_contains(poly, point) then point_name else 'sorry, nothing matches' end as my_name, case when ST_contains(poly, point) then point_desc else 'there is no description' end as my_desc, ... HTH, Brent Wood --- On Fri, 5/27/11, Michael Welter wrote: From: Michael Welter Subject: Re: [postgis-users] polygon of sphere To: "PostGIS Users Discussion" Date: Friday, May 27, 2011, 7:16 AM Thanks, Paul, I have a database of country borders. If the point lies within a particular border then the query will return country-specific information. If the point doesn't lie within a border then I would like to return some default information. Mike On May 26, 2011, at 12:42 PM, Paul Ramsey wrote: > Nope, there isn't. In fact, such a thing will give us the shakes as > our code for determining in/out status of an object depends on first > being able to generate one point that is definitively outside the > containing area. Maybe there is some other way to skin your cat, what > is the higher level problem you are trying to solve? > > P. > > On Thu, May 26, 2011 at 11:05 AM, Michael Welter wrote: >> Hello, >> >> Using type GEOGRAPHY, is there a polygon such that ST_COVERS(Polygon,Point) >> returns true for every point? Something like -180˚ to +180˚ longitude and >> -90˚ to +90˚ latitude? >> >> Thanks, >> >> ___ >> 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 ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] polygon of sphere
Two things: First, at the application level, if you don't get a result from ST_Intersects() then you know you want to return your default information. Second, performance issue. Given the complexity of county boundaries and the fact that big countries (russia, I'm looking at you) are going to pop out of the index condition quite frequently, and the fact that point-in-polygon in geography is still pretty slow, and the fact that you can split cross-date-line countries into multiple polygons relatively easily and the fact that no countries actually surround the poles (I'm not counting antarctica here), you might find that doing this in geometry works better. The intersection test is way faster there, and as long as you aren't calculating distances, the simple true/false results are going to be (mostly mostly) correct. P. On Thu, May 26, 2011 at 12:16 PM, Michael Welter wrote: > Thanks, Paul, > > I have a database of country borders. If the point lies within a particular > border then the query will return country-specific information. If the point > doesn't lie within a border then I would like to return some default > information. > > Mike > > On May 26, 2011, at 12:42 PM, Paul Ramsey wrote: > >> Nope, there isn't. In fact, such a thing will give us the shakes as >> our code for determining in/out status of an object depends on first >> being able to generate one point that is definitively outside the >> containing area. Maybe there is some other way to skin your cat, what >> is the higher level problem you are trying to solve? >> >> P. >> >> On Thu, May 26, 2011 at 11:05 AM, Michael Welter wrote: >>> Hello, >>> >>> Using type GEOGRAPHY, is there a polygon such that ST_COVERS(Polygon,Point) >>> returns true for every point? Something like -180˚ to +180˚ longitude and >>> -90˚ to +90˚ latitude? >>> >>> Thanks, >>> >>> ___ >>> 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 > ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] polygon of sphere
Thanks, Paul, I have a database of country borders. If the point lies within a particular border then the query will return country-specific information. If the point doesn't lie within a border then I would like to return some default information. Mike On May 26, 2011, at 12:42 PM, Paul Ramsey wrote: > Nope, there isn't. In fact, such a thing will give us the shakes as > our code for determining in/out status of an object depends on first > being able to generate one point that is definitively outside the > containing area. Maybe there is some other way to skin your cat, what > is the higher level problem you are trying to solve? > > P. > > On Thu, May 26, 2011 at 11:05 AM, Michael Welter wrote: >> Hello, >> >> Using type GEOGRAPHY, is there a polygon such that ST_COVERS(Polygon,Point) >> returns true for every point? Something like -180˚ to +180˚ longitude and >> -90˚ to +90˚ latitude? >> >> Thanks, >> >> ___ >> 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] New to PostGIS - Simple Question
On 5/26/2011 2:30 PM, SixDegrees wrote:
I'm quite new to GIS in general and PostGIS/Postgres in particular. I have to
write a C/C++ routine to dredge values out of an existing PostGIS-enabled
database. For the most part, this seems straightforward, but I can't figure
out how to access the members of types stored as points.
I'm aware of the ST_X() and ST_Y() SQL functions, but it using these seems
to require two queries. Is it possible to extract the point type into a
C/C++ struct/class with one call to the DB and process the results, or do I
have to make two calls for each point? I can't seem to find a PostGIS API;
does such a thing exist?
A short example would be much appreciated, if possible.
Thank you.
How about something like (untested):
#include
int main(int argc, char **argv)
{
PGconn *dbH;
char *sql;
int res;
char *dbconnect = "host=localhost user=postgres dbname=mydatabase";
dbH = PQconnectdb(dbconnect);
if (PQstatus(dbH) != CONNECTION_OK) {
//die with message
}
sql = "select st_x(the_geom), st_y(the_geom) from points";
res = PQexec(dbH, sql);
if (PQresultStatus(res) != PGRES_TUPLES_OK) {
// message no tuples
}
else {
nRows = PQntuples(res);
for (i=0; ihttp://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] New to PostGIS - Simple Question
I cant help with a C abstraction, of course there will be such a thing, but a single query to get both lat and long of a point is: SELECT ST_X(the_geom), ST_Y(the_geom) FROM mypoints -- or SELECT ST_ASTEXT(the_geom) FROM mypoints -- and parse the returned "POINT(long lat)" P. SixDegrees wrote: I'm quite new to GIS in general and PostGIS/Postgres in particular. I have to write a C/C++ routine to dredge values out of an existing PostGIS-enabled database. For the most part, this seems straightforward, but I can't figure out how to access the members of types stored as points. I'm aware of the ST_X() and ST_Y() SQL functions, but it using these seems to require two queries. Is it possible to extract the point type into a C/C++ struct/class with one call to the DB and process the results, or do I have to make two calls for each point? I can't seem to find a PostGIS API; does such a thing exist? A short example would be much appreciated, if possible. Thank you. ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] Infinite loop in st_intersects - because of incorrect data out of st_transform?
Like so?
http://trac.osgeo.org/postgis/attachment/ticket/987/inf2.patch
On Thu, May 26, 2011 at 11:35 AM, Paul Ramsey wrote:
> I think I'd like to do option (b), leave in the deep check for Inf and
> put upper level checks for Inf in the IsValid* calls. I've put all the
> above code in checks for GEOS_VERSION < 33 so that it'll go dark as we
> move forward. Sound OK?
>
> p.
>
> On Thu, May 26, 2011 at 10:42 AM, Sandro Santilli wrote:
>> On Thu, May 26, 2011 at 07:26:25PM +0200, Sandro Santilli wrote:
>>> On Thu, May 26, 2011 at 09:51:12AM -0700, Paul Ramsey wrote:
>>> > On Thu, May 26, 2011 at 9:44 AM, Sandro Santilli wrote:
>>> > > On Thu, May 26, 2011 at 09:26:15AM -0700, Paul Ramsey wrote:
>>> > > > Erm, do old versions of IsValid still catch Inf geometries safely?
>>> > >
>>> > > If you have an HEXWKB I can give it a quick try against 3.1.0
>>> >
>>> > 010320E61001000500737979F3DDCC2CC0F92154F9E7534540F07FF07F8F806E993F7E55C0304B29FFEA8554400634E8D1DD424540B5FEE6A37FCD4540737979F3DDCC2CC0F92154F9E7534540
>>>
>>> 3.1.0 was unsupported.
>>> 3.1.2 entered the infinite loop on ST_IsValid.
>>
>> 3.2.3 is good:
>>
>> POSTGIS="2.0.0SVN" GEOS="3.2.3-CAPI-1.6.3" PROJ="Rel. 4.7.1, 23 September
>> 2009" LIBXML="2.7.6" USE_STATS
>> strk=# select
>> st_isvalid('010320E61001000500737979F3DDCC2CC0F92154F9E7534540F07FF07F8F806E993F7E55C0304B29FFEA8554400634E8D1DD424540B5FEE6A37FCD4540737979F3DDCC2CC0F92154F9E7534540'::geometry);
>> NOTICE: Invalid Coordinate at or near point inf inf
>> f
>>
>> --strk;
>>
>> () Free GIS & Flash consultant/developer
>> /\ http://strk.keybit.net/services.html
>> ___
>> 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] polygon of sphere
Nope, there isn't. In fact, such a thing will give us the shakes as our code for determining in/out status of an object depends on first being able to generate one point that is definitively outside the containing area. Maybe there is some other way to skin your cat, what is the higher level problem you are trying to solve? P. On Thu, May 26, 2011 at 11:05 AM, Michael Welter wrote: > Hello, > > Using type GEOGRAPHY, is there a polygon such that ST_COVERS(Polygon,Point) > returns true for every point? Something like -180˚ to +180˚ longitude and > -90˚ to +90˚ latitude? > > Thanks, > > ___ > 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] New to PostGIS - Simple Question
I think he's asking for select st_x(pointcol) as x, st_y(pointcol) as y from his_table; hth charles On May 26, 2011, at 2:40 PM, Paul Ramsey wrote: > If you have byte-level chops then the most efficient call would be to > ask for ST_AsBinary(geom) and then handle the well-known-binary byte > array on your end. There's some WKB example code in the source repo, > and also in the MapServer PostGIS connector. But it's a pretty easy > format. > > P. > > On Thu, May 26, 2011 at 11:30 AM, SixDegrees wrote: >> >> I'm quite new to GIS in general and PostGIS/Postgres in particular. I have to >> write a C/C++ routine to dredge values out of an existing PostGIS-enabled >> database. For the most part, this seems straightforward, but I can't figure >> out how to access the members of types stored as points. >> >> I'm aware of the ST_X() and ST_Y() SQL functions, but it using these seems >> to require two queries. Is it possible to extract the point type into a >> C/C++ struct/class with one call to the DB and process the results, or do I >> have to make two calls for each point? I can't seem to find a PostGIS API; >> does such a thing exist? >> >> A short example would be much appreciated, if possible. >> >> Thank you. >> -- >> View this message in context: >> http://old.nabble.com/New-to-PostGIS---Simple-Question-tp31710695p31710695.html >> Sent from the PostGIS - User mailing list archive at Nabble.com. >> >> ___ >> 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] New to PostGIS - Simple Question
If you have byte-level chops then the most efficient call would be to ask for ST_AsBinary(geom) and then handle the well-known-binary byte array on your end. There's some WKB example code in the source repo, and also in the MapServer PostGIS connector. But it's a pretty easy format. P. On Thu, May 26, 2011 at 11:30 AM, SixDegrees wrote: > > I'm quite new to GIS in general and PostGIS/Postgres in particular. I have to > write a C/C++ routine to dredge values out of an existing PostGIS-enabled > database. For the most part, this seems straightforward, but I can't figure > out how to access the members of types stored as points. > > I'm aware of the ST_X() and ST_Y() SQL functions, but it using these seems > to require two queries. Is it possible to extract the point type into a > C/C++ struct/class with one call to the DB and process the results, or do I > have to make two calls for each point? I can't seem to find a PostGIS API; > does such a thing exist? > > A short example would be much appreciated, if possible. > > Thank you. > -- > View this message in context: > http://old.nabble.com/New-to-PostGIS---Simple-Question-tp31710695p31710695.html > Sent from the PostGIS - User mailing list archive at Nabble.com. > > ___ > 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] Infinite loop in st_intersects - because of incorrect data out of st_transform?
I think I'd like to do option (b), leave in the deep check for Inf and
put upper level checks for Inf in the IsValid* calls. I've put all the
above code in checks for GEOS_VERSION < 33 so that it'll go dark as we
move forward. Sound OK?
p.
On Thu, May 26, 2011 at 10:42 AM, Sandro Santilli wrote:
> On Thu, May 26, 2011 at 07:26:25PM +0200, Sandro Santilli wrote:
>> On Thu, May 26, 2011 at 09:51:12AM -0700, Paul Ramsey wrote:
>> > On Thu, May 26, 2011 at 9:44 AM, Sandro Santilli wrote:
>> > > On Thu, May 26, 2011 at 09:26:15AM -0700, Paul Ramsey wrote:
>> > > > Erm, do old versions of IsValid still catch Inf geometries safely?
>> > >
>> > > If you have an HEXWKB I can give it a quick try against 3.1.0
>> >
>> > 010320E61001000500737979F3DDCC2CC0F92154F9E7534540F07FF07F8F806E993F7E55C0304B29FFEA8554400634E8D1DD424540B5FEE6A37FCD4540737979F3DDCC2CC0F92154F9E7534540
>>
>> 3.1.0 was unsupported.
>> 3.1.2 entered the infinite loop on ST_IsValid.
>
> 3.2.3 is good:
>
> POSTGIS="2.0.0SVN" GEOS="3.2.3-CAPI-1.6.3" PROJ="Rel. 4.7.1, 23 September
> 2009" LIBXML="2.7.6" USE_STATS
> strk=# select
> st_isvalid('010320E61001000500737979F3DDCC2CC0F92154F9E7534540F07FF07F8F806E993F7E55C0304B29FFEA8554400634E8D1DD424540B5FEE6A37FCD4540737979F3DDCC2CC0F92154F9E7534540'::geometry);
> NOTICE: Invalid Coordinate at or near point inf inf
> f
>
> --strk;
>
> () Free GIS & Flash consultant/developer
> /\ http://strk.keybit.net/services.html
> ___
> 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] New to PostGIS - Simple Question
I'm quite new to GIS in general and PostGIS/Postgres in particular. I have to write a C/C++ routine to dredge values out of an existing PostGIS-enabled database. For the most part, this seems straightforward, but I can't figure out how to access the members of types stored as points. I'm aware of the ST_X() and ST_Y() SQL functions, but it using these seems to require two queries. Is it possible to extract the point type into a C/C++ struct/class with one call to the DB and process the results, or do I have to make two calls for each point? I can't seem to find a PostGIS API; does such a thing exist? A short example would be much appreciated, if possible. Thank you. -- View this message in context: http://old.nabble.com/New-to-PostGIS---Simple-Question-tp31710695p31710695.html Sent from the PostGIS - User mailing list archive at Nabble.com. ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
[postgis-users] polygon of sphere
Hello, Using type GEOGRAPHY, is there a polygon such that ST_COVERS(Polygon,Point) returns true for every point? Something like -180˚ to +180˚ longitude and -90˚ to +90˚ latitude? Thanks, ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] Infinite loop in st_intersects - because of incorrect data out of st_transform?
On Thu, May 26, 2011 at 07:26:25PM +0200, Sandro Santilli wrote:
> On Thu, May 26, 2011 at 09:51:12AM -0700, Paul Ramsey wrote:
> > On Thu, May 26, 2011 at 9:44 AM, Sandro Santilli wrote:
> > > On Thu, May 26, 2011 at 09:26:15AM -0700, Paul Ramsey wrote:
> > > > Erm, do old versions of IsValid still catch Inf geometries safely?
> > >
> > > If you have an HEXWKB I can give it a quick try against 3.1.0
> >
> > 010320E61001000500737979F3DDCC2CC0F92154F9E7534540F07FF07F8F806E993F7E55C0304B29FFEA8554400634E8D1DD424540B5FEE6A37FCD4540737979F3DDCC2CC0F92154F9E7534540
>
> 3.1.0 was unsupported.
> 3.1.2 entered the infinite loop on ST_IsValid.
3.2.3 is good:
POSTGIS="2.0.0SVN" GEOS="3.2.3-CAPI-1.6.3" PROJ="Rel. 4.7.1, 23 September 2009"
LIBXML="2.7.6" USE_STATS
strk=# select
st_isvalid('010320E61001000500737979F3DDCC2CC0F92154F9E7534540F07FF07F8F806E993F7E55C0304B29FFEA8554400634E8D1DD424540B5FEE6A37FCD4540737979F3DDCC2CC0F92154F9E7534540'::geometry);
NOTICE: Invalid Coordinate at or near point inf inf
f
--strk;
() Free GIS & Flash consultant/developer
/\ http://strk.keybit.net/services.html
___
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] Infinite loop in st_intersects - because of incorrect data out of st_transform?
On Thu, May 26, 2011 at 09:51:12AM -0700, Paul Ramsey wrote: > On Thu, May 26, 2011 at 9:44 AM, Sandro Santilli wrote: > > On Thu, May 26, 2011 at 09:26:15AM -0700, Paul Ramsey wrote: > > > Erm, do old versions of IsValid still catch Inf geometries safely? > > > > If you have an HEXWKB I can give it a quick try against 3.1.0 > > 010320E61001000500737979F3DDCC2CC0F92154F9E7534540F07FF07F8F806E993F7E55C0304B29FFEA8554400634E8D1DD424540B5FEE6A37FCD4540737979F3DDCC2CC0F92154F9E7534540 3.1.0 was unsupported. 3.1.2 entered the infinite loop on ST_IsValid. --strk; () Free GIS & Flash consultant/developer /\ http://strk.keybit.net/services.html ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] Infinite loop in st_intersects - because of incorrect data out of st_transform?
010320E61001000500737979F3DDCC2CC0F92154F9E7534540F07FF07F8F806E993F7E55C0304B29FFEA8554400634E8D1DD424540B5FEE6A37FCD4540737979F3DDCC2CC0F92154F9E7534540 On Thu, May 26, 2011 at 9:44 AM, Sandro Santilli wrote: > On Thu, May 26, 2011 at 09:26:15AM -0700, Paul Ramsey wrote: >> Erm, do old versions of IsValid still catch Inf geometries safely? > > Not sure, worth testing. > If you have an HEXWKB I can give it a quick try against 3.1.0 > > --strk; > > () Free GIS & Flash consultant/developer > /\ http://strk.keybit.net/services.html > ___ > 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] Infinite loop in st_intersects - because of incorrect data out of st_transform?
On Thu, May 26, 2011 at 09:26:15AM -0700, Paul Ramsey wrote: > Erm, do old versions of IsValid still catch Inf geometries safely? Not sure, worth testing. If you have an HEXWKB I can give it a quick try against 3.1.0 --strk; () Free GIS & Flash consultant/developer /\ http://strk.keybit.net/services.html ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] Infinite loop in st_intersects - because of incorrect data out of st_transform?
Erm, do old versions of IsValid still catch Inf geometries safely? On Thu, May 26, 2011 at 9:05 AM, Sandro Santilli wrote: > On Thu, May 26, 2011 at 08:12:19AM -0700, Paul Ramsey wrote: >> OK then either >> (a) we test for Inf boxes at the head of each GEOS function we care >> about protecting (and not IsValid* functions) >> (b) we put a pre-test in the IsValid* functions to check for Inf boxes >> Preferences? > > I like (a) more, done by a function, and only if GEOS version is < 3.3.0. > > This is because we might one day have the current ST_MakeValid function > move down to GEOS and also handle inf/nan somehow. > > --strk; > > () Free GIS & Flash consultant/developer > /\ http://strk.keybit.net/services.html > ___ > 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] Infinite loop in st_intersects - because of incorrect data out of st_transform?
On Thu, May 26, 2011 at 08:12:19AM -0700, Paul Ramsey wrote: > OK then either > (a) we test for Inf boxes at the head of each GEOS function we care > about protecting (and not IsValid* functions) > (b) we put a pre-test in the IsValid* functions to check for Inf boxes > Preferences? I like (a) more, done by a function, and only if GEOS version is < 3.3.0. This is because we might one day have the current ST_MakeValid function move down to GEOS and also handle inf/nan somehow. --strk; () Free GIS & Flash consultant/developer /\ http://strk.keybit.net/services.html ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] Infinite loop in st_intersects - because of incorrect data out of st_transform?
With the disclaimer of not having looked at the code, I like (b). I assume you mean that in the path of isvalid*, we pick up the same check and return the proper thing. But we still keep the check you put in with your patch, so that if we enter them some other way, or if the test in isvalid* goes wrong for some reason, we'll still get the exception. I like the general idea of doing it deep down to make sure there's no codepath being missed. //Magnus On Thu, May 26, 2011 at 17:12, Paul Ramsey wrote: > OK then either > (a) we test for Inf boxes at the head of each GEOS function we care > about protecting (and not IsValid* functions) > (b) we put a pre-test in the IsValid* functions to check for Inf boxes > Preferences? > P. > > On Thu, May 26, 2011 at 7:21 AM, Magnus Hagander wrote: >> On Thu, May 26, 2011 at 16:20, Sandro Santilli wrote: >>> On Thu, May 26, 2011 at 04:16:59PM +0200, Magnus Hagander wrote: On Thu, May 26, 2011 at 16:15, Sandro Santilli wrote: > On Thu, May 26, 2011 at 04:09:27PM +0200, Magnus Hagander wrote: >> Hi! >> >> Yup, it does appear to solve the problem for at least my limited test >> case. I now get: >> ERROR: Infinite coordinate value found in geometry. >> CONTEXT: SQL function "st_intersects" statement 1 >> >> as expected. >> >> Glad to see you found a better place :-) > > Could you please also try ST_IsValid, ST_IsValidReason and > ST_IsValidDetail against the table containing the offensive > geometry ? It's not actually in a table, the offensive geometry was generated by the app as the other side. Tha tmakes it even easier to check - both cases return: ERROR: Infinite coordinate value found in geometry. >>> >>> My point is that ST_IsValid and friends should return validity information, >>> not throw an exception. By throwing an exception you don't get any other >>> result, so can't check the validity of multiple geometries at once. >> >> In that case, the patch is wrong, because it does return an exception. >> >> >> -- >> Magnus Hagander >> Me: http://www.hagander.net/ >> Work: http://www.redpill-linpro.com/ >> ___ >> 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 > -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] Infinite loop in st_intersects - because of incorrect data out of st_transform?
OK then either (a) we test for Inf boxes at the head of each GEOS function we care about protecting (and not IsValid* functions) (b) we put a pre-test in the IsValid* functions to check for Inf boxes Preferences? P. On Thu, May 26, 2011 at 7:21 AM, Magnus Hagander wrote: > On Thu, May 26, 2011 at 16:20, Sandro Santilli wrote: >> On Thu, May 26, 2011 at 04:16:59PM +0200, Magnus Hagander wrote: >>> On Thu, May 26, 2011 at 16:15, Sandro Santilli wrote: >>> > On Thu, May 26, 2011 at 04:09:27PM +0200, Magnus Hagander wrote: >>> >> Hi! >>> >> >>> >> Yup, it does appear to solve the problem for at least my limited test >>> >> case. I now get: >>> >> ERROR: Infinite coordinate value found in geometry. >>> >> CONTEXT: SQL function "st_intersects" statement 1 >>> >> >>> >> as expected. >>> >> >>> >> Glad to see you found a better place :-) >>> > >>> > Could you please also try ST_IsValid, ST_IsValidReason and >>> > ST_IsValidDetail against the table containing the offensive >>> > geometry ? >>> >>> It's not actually in a table, the offensive geometry was generated by >>> the app as the other side. Tha tmakes it even easier to check - both >>> cases return: >>> >>> ERROR: Infinite coordinate value found in geometry. >> >> My point is that ST_IsValid and friends should return validity information, >> not throw an exception. By throwing an exception you don't get any other >> result, so can't check the validity of multiple geometries at once. > > In that case, the patch is wrong, because it does return an exception. > > > -- > Magnus Hagander > Me: http://www.hagander.net/ > Work: http://www.redpill-linpro.com/ > ___ > 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] Infinite loop in st_intersects - because of incorrect data out of st_transform?
On Thu, May 26, 2011 at 16:20, Sandro Santilli wrote: > On Thu, May 26, 2011 at 04:16:59PM +0200, Magnus Hagander wrote: >> On Thu, May 26, 2011 at 16:15, Sandro Santilli wrote: >> > On Thu, May 26, 2011 at 04:09:27PM +0200, Magnus Hagander wrote: >> >> Hi! >> >> >> >> Yup, it does appear to solve the problem for at least my limited test >> >> case. I now get: >> >> ERROR: Infinite coordinate value found in geometry. >> >> CONTEXT: SQL function "st_intersects" statement 1 >> >> >> >> as expected. >> >> >> >> Glad to see you found a better place :-) >> > >> > Could you please also try ST_IsValid, ST_IsValidReason and >> > ST_IsValidDetail against the table containing the offensive >> > geometry ? >> >> It's not actually in a table, the offensive geometry was generated by >> the app as the other side. Tha tmakes it even easier to check - both >> cases return: >> >> ERROR: Infinite coordinate value found in geometry. > > My point is that ST_IsValid and friends should return validity information, > not throw an exception. By throwing an exception you don't get any other > result, so can't check the validity of multiple geometries at once. In that case, the patch is wrong, because it does return an exception. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] Infinite loop in st_intersects - because of incorrect data out of st_transform?
On Thu, May 26, 2011 at 04:16:59PM +0200, Magnus Hagander wrote: > On Thu, May 26, 2011 at 16:15, Sandro Santilli wrote: > > On Thu, May 26, 2011 at 04:09:27PM +0200, Magnus Hagander wrote: > >> Hi! > >> > >> Yup, it does appear to solve the problem for at least my limited test > >> case. I now get: > >> ERROR: Infinite coordinate value found in geometry. > >> CONTEXT: SQL function "st_intersects" statement 1 > >> > >> as expected. > >> > >> Glad to see you found a better place :-) > > > > Could you please also try ST_IsValid, ST_IsValidReason and > > ST_IsValidDetail against the table containing the offensive > > geometry ? > > It's not actually in a table, the offensive geometry was generated by > the app as the other side. Tha tmakes it even easier to check - both > cases return: > > ERROR: Infinite coordinate value found in geometry. My point is that ST_IsValid and friends should return validity information, not throw an exception. By throwing an exception you don't get any other result, so can't check the validity of multiple geometries at once. --strk; () Free GIS & Flash consultant/developer /\ http://strk.keybit.net/services.html ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] Infinite loop in st_intersects - because of incorrect data out of st_transform?
On Thu, May 26, 2011 at 16:15, Sandro Santilli wrote: > On Thu, May 26, 2011 at 04:09:27PM +0200, Magnus Hagander wrote: >> Hi! >> >> Yup, it does appear to solve the problem for at least my limited test >> case. I now get: >> ERROR: Infinite coordinate value found in geometry. >> CONTEXT: SQL function "st_intersects" statement 1 >> >> as expected. >> >> Glad to see you found a better place :-) > > Could you please also try ST_IsValid, ST_IsValidReason and > ST_IsValidDetail against the table containing the offensive > geometry ? It's not actually in a table, the offensive geometry was generated by the app as the other side. Tha tmakes it even easier to check - both cases return: ERROR: Infinite coordinate value found in geometry. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] Infinite loop in st_intersects - because of incorrect data out of st_transform?
On Thu, May 26, 2011 at 04:09:27PM +0200, Magnus Hagander wrote: > Hi! > > Yup, it does appear to solve the problem for at least my limited test > case. I now get: > ERROR: Infinite coordinate value found in geometry. > CONTEXT: SQL function "st_intersects" statement 1 > > as expected. > > Glad to see you found a better place :-) Could you please also try ST_IsValid, ST_IsValidReason and ST_IsValidDetail against the table containing the offensive geometry ? --strk; () Free GIS & Flash consultant/developer /\ http://strk.keybit.net/services.html ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] Infinite loop in st_intersects - because of incorrect data out of st_transform?
Hi!
Yup, it does appear to solve the problem for at least my limited test
case. I now get:
ERROR: Infinite coordinate value found in geometry.
CONTEXT: SQL function "st_intersects" statement 1
as expected.
Glad to see you found a better place :-)
//Magnus
On Wed, May 25, 2011 at 21:11, Paul Ramsey wrote:
> Magnus,
> We've decided to go with Inf testing, but I've move the test lower
> down into the GEOS handling code so it applies to all GEOS operations,
> not just Intersects().
>
> http://trac.osgeo.org/postgis/ticket/987
>
> See if that still works for you, hopefully it should (just tested with
> your test geometry)
>
> P.
>
> On Mon, Feb 28, 2011 at 7:18 AM, Magnus Hagander wrote:
>> Hi!
>>
>> Running the following query locks up postgis completely (in
>> geos::algorithm::RobustDeterminant):
>>
>> SELECT st_intersects(somegeometry,
>> '010320E61001000500737979F3DDCC2CC0F92154F9E7534540F07FF07F8F806E993F7E55C0304B29FFEA8554400634E8D1DD424540B5FEE6A37FCD4540737979F3DDCC2CC0F92154F9E7534540'::geometry)
>>
>> I believe this is because there are infinite values in that geometry:
>>
>> # select
>> ST_AsText('010320E61001000500737979F3DDCC2CC0F92154F9E7534540F07FF07F8F806E993F7E55C0304B29FFEA8554400634E8D1DD424540B5FEE6A37FCD4540737979F3DDCC2CC0F92154F9E7534540'::geometry);
>>
>> st_astext
>> ---
>> POLYGON((-14.4001308522972 42.6555167828373,inf inf,-85.9726317957995
>> 82.0924680617579,42.5223944076352 43.6054577711015,-14.4001308522972
>> 42.6555167828373))
>> (1 row)
>>
>>
>> ISTM that this should either be rejected as an invalid geometry, or at
>> least not hang
>>
>>
>> Now, this geometry actually comes back as the result of st_transform,
>> which suggests to me that there is *also* a bug in st_transform, which
>> should never output an invalid geometry. It is the result of:
>>
>> st_transform('010320CD0B0100050099E6673CA2FC2DC1AD7BF5ED45CC534199E6673CA2FC2DC1D7BDFAF6D28960415A06E670D7E94B41D7BDFAF6D28960415A06E670D7E94B41AD7BF5ED45CC534199E6673CA2FC2DC1AD7BF5ED45CC5341',
>> 4326)
>>
>> And that geometry is valid before it goes into st_transform, from what
>> I can tell:
>> # select
>> st_astext('010320CD0B0100050099E6673CA2FC2DC1AD7BF5ED45CC534199E6673CA2FC2DC1D7BDFAF6D28960415A06E670D7E94B41D7BDFAF6D28960415A06E670D7E94B41AD7BF5ED45CC534199E6673CA2FC2DC1AD7BF5ED45CC5341'::geometry);
>>
>> st_astext
>>
>> --
>> --
>> POLYGON((-982609.1179802 5189911.7181081,-982609.1179802
>> 8670871.7181081,3658670.8820198 8670871.7181081,3658670.8820198
>> 5189911.
>> 7181081,-982609.1179802 5189911.7181081))
>> (1 row)
>>
>>
>>
>> To me this looks like bugs "below" postgis - it's certainly below the
>> PostgreSQL level that I know well :-) Not sure if it can be worked
>> around/fixed at the postgis level or if it needs to be done in the
>> lower level libraries, but either way it shouldn't behave this way :-)
>>
>> --
>> Magnus Hagander
>> Me: http://www.hagander.net/
>> Work: http://www.redpill-linpro.com/
>> ___
>> postgis-users mailing list
>> postgis-users@postgis.refractions.net
>> http://postgis.refractions.net/mailman/listinfo/postgis-users
>>
>
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
___
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] long geometries aren't display on pgAdmin (Windows 7, 64bit)
Hi,
It's just PgAdmin not displaying properly, there is actually a value in
the geom column. Try SELECT ST_IsValid(the_geom) or similar and you'll
find the geometry is actually there, only not displayed by pgAdmin.
--
Barend Köbben (Senior Lecturer)
ITC - University of Twente, Faculty of Geo-Information
Science and Earth Observation
PO Box 217, 7500AE Enschede (The Netherlands)
+31-(0)53 4874 253
On 26-05-11 09:41, "toni hernández" wrote:
>hi,
>
>I already tried with psql without any luck. ;-(
>
>Let me explain the issue again with one example.
>When I load a sql, like the one below, on pgAdmin, authomatically the
>geometry disappears from the screen.
>But only when the geometry is 'too' long.
>
>The insert seems to work fine but only for the columns rec_num and
>data_value. The_Geom column is always empty, even when executing the SQL
>file from psql.
>Example:
>
>SET CLIENT_ENCODING TO UTF8;
>SET STANDARD_CONFORMING_STRINGS TO ON;
>BEGIN;
>CREATE TABLE "kirklees" (gid serial PRIMARY KEY,
>"rec_num" numeric,
>"data_value" numeric);
>SELECT AddGeometryColumn('','kirklees','the_geom','-1','MULTIPOLYGON',2);
>INSERT INTO "kirklees" ("rec_num","data_value",the_geom) VALUES
>('1','1','01060001000103000100D30350141941
>3094184150141941A0921841100E1941A09218
>41100E194130941841800C194130941841
>800C1941C0951841100E1941C0951841100E194100
>0050971841800C194150971841800C1941709A
>1841F00A1941709A1841F00A1941009C184100
>00D0071941009C1841D0071941909D1841B00419
>...
>
>Yves Jacolin wrote:
>> Le jeudi 26 mai 2011 08:28:32, toni hernández a écrit :
>>
>>> Hi,
>>>
>>> I amb holding a postgresql+postgis course on www.unigis.es
>>> Some of our students have experienced some problems when importing shp.
>>> These students are running postgresql 32 bit on a Windows7 64 bit
>>>platform.
>>> I have run the same import with a windows 7, 64bit but haven't
>>> encountered any problems.
>>>
>>> The shp2pgsql seems to be working fine (the output looks good) but when
>>> loading the SQL file from pgAdmin some geometries aren't displayed.
>>> I think the longest geometries (not very long indeed) are the ones that
>>> are not displayed.
>>>
>>> Any ideas about what's happening?
>>>
>>> thanks in advance.
>>>
>>
>> Hi Toni,
>>
>> I am not sure to have understood your issue, but I know that PgAdmin
>>have some
>> difficulties to display values of geometry field. If you check it via
>>psql you'll
>> see that all geometry values are in the table.
>>
>> Y.
>>
>___
>postgis-users mailing list
>postgis-users@postgis.refractions.net
>http://postgis.refractions.net/mailman/listinfo/postgis-users
Faculty of Geo-Information Science and Earth Observation (ITC)
University of Twente
Chamber of Commerce: 50130536
E-mail disclaimer
The information in this e-mail, including any attachments, is intended for the
addressee only. If you are not the intended recipient, you are hereby notified
that any disclosure, copying, distribution or action in relation to the content
of this information is strictly prohibited. If you have received this e-mail by
mistake, please delete the message and any attachment and inform the sender by
return e-mail. ITC accepts no liability for any error or omission in the
message content or for damage of any kind that may arise as a result of e-mail
transmission.
___
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] AddGeometryColumn
Vittoriano,
Try it
without the empty '' for the schema (or specify the schema - probably
'public'),
and
the SRID should be an integer.
SELECT AddGeometryColumn('particelle','the_geom',3003,'MULTIPOLYGON',2);
might work.
(Assuming that you have loaded the postgis.sql functions into your database
first?)
cheers
Ben
On 26/05/2011, at 4:37 PM, vittoriano.aure...@libero.it wrote:
> PostgreSQL 9.0
> PostGIS 1.5
>
>
> what is my problem?
>
>
> SET CLIENT_ENCODING TO UTF8;
> SET STANDARD_CONFORMING_STRINGS TO ON;
> BEGIN;
> CREATE TABLE "particelle" (gid serial PRIMARY KEY,
> "comune" varchar(4),
> "sezione" varchar(1),
> "foglio" varchar(4),
> "allegato" varchar(1),
> "sviluppo" varchar(1),
> "numero" varchar(9),
> "livello" varchar(11));
> SELECT AddGeometryColumn('','particelle','the_geom','3003','MULTIPOLYGON',2);
>
>
>
> NOTICE: CREATE TABLE will create implicit sequence "particelle_gid_seq" for
> serial column "particelle.gid"
> NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index
> "particelle_pkey" for table "particelle"
> ERROR: function addgeometrycolumn(unknown, unknown, unknown, unknown,
> unknown, integer) does not exist
> LINE 12: SELECT AddGeometryColumn('','particelle','the_geom','3003','...
>^
> HINT: No function matches the given name and argument types. You might need
> to add explicit type casts.
>
> ** Error **
>
> ERROR: function addgeometrycolumn(unknown, unknown, unknown, unknown,
> unknown,
> integer) does not exist
> SQL state: 42883
> Hint: No function matches the given name and argument types. You might need
> to
> add explicit type casts.
> Character: 289
>
>
> best regards
>
>
> Vittoriano Aurelio
> ___
> 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] AddGeometryColumn
On Thu, May 26, 2011 at 10:37:49AM +0200, vittoriano.aure...@libero.it wrote:
> PostgreSQL 9.0
> PostGIS 1.5
>
> what is my problem?
> LINE 12: SELECT AddGeometryColumn('','particelle','the_geom','3003','...
> ^
The function was renamed to ST_AddGeometryColumn.
You can get the old name using the postgis/legacy.sql but you'd
better change the script to use the new syntax.
--strk;
() Free GIS & Flash consultant/developer
/\ http://strk.keybit.net/services.html
___
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users
[postgis-users] AddGeometryColumn
PostgreSQL 9.0
PostGIS 1.5
what is my problem?
SET CLIENT_ENCODING TO UTF8;
SET STANDARD_CONFORMING_STRINGS TO ON;
BEGIN;
CREATE TABLE "particelle" (gid serial PRIMARY KEY,
"comune" varchar(4),
"sezione" varchar(1),
"foglio" varchar(4),
"allegato" varchar(1),
"sviluppo" varchar(1),
"numero" varchar(9),
"livello" varchar(11));
SELECT AddGeometryColumn('','particelle','the_geom','3003','MULTIPOLYGON',2);
NOTICE: CREATE TABLE will create implicit sequence "particelle_gid_seq" for
serial column "particelle.gid"
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index
"particelle_pkey" for table "particelle"
ERROR: function addgeometrycolumn(unknown, unknown, unknown, unknown,
unknown, integer) does not exist
LINE 12: SELECT AddGeometryColumn('','particelle','the_geom','3003','...
^
HINT: No function matches the given name and argument types. You might need
to add explicit type casts.
** Error **
ERROR: function addgeometrycolumn(unknown, unknown, unknown, unknown, unknown,
integer) does not exist
SQL state: 42883
Hint: No function matches the given name and argument types. You might need to
add explicit type casts.
Character: 289
best regards
Vittoriano Aurelio
___
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] long geometries aren't display on pgAdmin (Windows 7, 64bit)
hi,
I already tried with psql without any luck. ;-(
Let me explain the issue again with one example.
When I load a sql, like the one below, on pgAdmin, authomatically the
geometry disappears from the screen.
But only when the geometry is 'too' long.
The insert seems to work fine but only for the columns rec_num and
data_value. The_Geom column is always empty, even when executing the SQL
file from psql.
Example:
SET CLIENT_ENCODING TO UTF8;
SET STANDARD_CONFORMING_STRINGS TO ON;
BEGIN;
CREATE TABLE "kirklees" (gid serial PRIMARY KEY,
"rec_num" numeric,
"data_value" numeric);
SELECT AddGeometryColumn('','kirklees','the_geom','-1','MULTIPOLYGON',2);
INSERT INTO "kirklees" ("rec_num","data_value",the_geom) VALUES
('1','1','01060001000103000100D303501419413094184150141941A0921841100E1941A0921841100E194130941841800C194130941841800C1941C0951841100E1941C0951841100E194150971841800C194150971841800C1941709A1841F00A1941709A1841F00A1941009C1841D0071941009C1841D0071941909D1841B00419
...
Yves Jacolin wrote:
Le jeudi 26 mai 2011 08:28:32, toni hernández a écrit :
Hi,
I amb holding a postgresql+postgis course on www.unigis.es
Some of our students have experienced some problems when importing shp.
These students are running postgresql 32 bit on a Windows7 64 bit platform.
I have run the same import with a windows 7, 64bit but haven't
encountered any problems.
The shp2pgsql seems to be working fine (the output looks good) but when
loading the SQL file from pgAdmin some geometries aren't displayed.
I think the longest geometries (not very long indeed) are the ones that
are not displayed.
Any ideas about what's happening?
thanks in advance.
Hi Toni,
I am not sure to have understood your issue, but I know that PgAdmin have some
difficulties to display values of geometry field. If you check it via psql you'll
see that all geometry values are in the table.
Y.
___
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] long geometries aren't display on pgAdmin (Windows 7, 64bit)
On Thu, May 26, 2011 at 08:28:32AM +0200, toni hernández wrote: > These students are running postgresql 32 bit on a Windows7 64 bit platform. Teach quality. They'll stop. --strk(pop philosopher); () Free GIS & Flash consultant/developer /\ http://strk.keybit.net/services.html ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] long geometries aren't display on pgAdmin (Windows 7, 64bit)
Le jeudi 26 mai 2011 08:28:32, toni hernández a écrit : > Hi, > > I amb holding a postgresql+postgis course on www.unigis.es > Some of our students have experienced some problems when importing shp. > These students are running postgresql 32 bit on a Windows7 64 bit platform. > I have run the same import with a windows 7, 64bit but haven't > encountered any problems. > > The shp2pgsql seems to be working fine (the output looks good) but when > loading the SQL file from pgAdmin some geometries aren't displayed. > I think the longest geometries (not very long indeed) are the ones that > are not displayed. > > Any ideas about what's happening? > > thanks in advance. Hi Toni, I am not sure to have understood your issue, but I know that PgAdmin have some difficulties to display values of geometry field. If you check it via psql you'll see that all geometry values are in the table. Y. -- Responsable Formation et Support Camptocamp France SAS Savoie Technolac, BP 352 73377 Le Bourget du Lac, Cedex Tel (France) : +33 4 79 26 57 98 Tel (Suisse) : +41 21 619 1031 Mob. : +33 6 18 75 42 21 Fax : 04 79 70 15 81 Mail : yves.jaco...@camptocamp.com http://www.camptocamp.com ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
