Geometry appears empty

View: New views
8 Messages — Rating Filter:   Alert me  

Geometry appears empty

by geoffi :: Rate this Message:

| View Threaded | Show Only this Message

I have translated some polygon data into a PostGIS table using FME. The translation was successful with no errors reported. All the records appear in the PostGIS table (using the pgAdminIII application) except for about 90% of the geometries (see image below).



However, using the FME Universal Viewer all records are displayed with their correct geometry as I would expect.

What is causing the Geometry column in the table to appear empty?
Is there a setting in PostGIS to force the data to be visible in the pgAdminIII application?

Attempts to generate a WMS from this table using GeoServer only displays those records that appear to have geometry.

Performing a similar exercise using point geometries, there was no problem.

Re: Geometry appears empty

by Tim Bowden :: Rate this Message:

| View Threaded | Show Only this Message

Geoff,

This earlier thread may be of interest:
http://postgis.refractions.net/pipermail/postgis-users/2008-March/018814.html

It deals with limitations of pgadmin and postgis.

If the geometries really are null, are you also able to try loading the
data with ogr2ogr to see if you get the same result?   Are you sure you
don't have any invalid geometries?  I don't know how FME handles these.

HTH,
Tim Bowden
On Tue, 2008-07-01 at 17:12 -0700, geoffi wrote:

> I have translated some polygon data into a PostGIS table using FME. The
> translation was successful with no errors reported. All the records appear
> in the PostGIS table (using the pgAdminIII application) except for about 90%
> of the geometries (see image below).
>
> http://www.nabble.com/file/p18227858/table.jpg 
>
> However, using the FME Universal Viewer all records are displayed with their
> correct geometry as I would expect.
>
> What is causing the Geometry column in the table to appear empty?
> Is there a setting in PostGIS to force the data to be visible in the
> pgAdminIII application?
>
> Attempts to generate a WMS from this table using GeoServer only displays
> those records that appear to have geometry.
>
> Performing a similar exercise using point geometries, there was no problem.
>
--
vim is a good example of an IDE done properly.  emacs is an example of
an IDE done poorly.  Anything that involves little pictures is a
mis-umderstanding of what an IDE should be.

_______________________________________________
postgis-users mailing list
postgis-users@...
http://postgis.refractions.net/mailman/listinfo/postgis-users

Re: Geometry appears empty

by geoffi :: Rate this Message:

| View Threaded | Show Only this Message

Hi Tim,

First of all I can confirm that the geometries are not null by:
   a) select count(*) from <my_table> where geom is null;
       This returns a count of 0.
   b) the FME Universal Viewer successfully displays all the geometries successfully. Features can be graphically selected and their attributes interrogated.

The link you gave seems to imply that pgAdminIII may not be the tool to use to verify geometry columns. It also mentions a possible limitation for the number of verticies hitting a limit of 1365. I will need to check my geometries if this is the same in my case.

In the meantime, I've also used the psql command line interface to check the records with the same results as per the pgAdminIII. Can you recommend another tool I can use to report the geometry data?

As mentioned in the original post, my final step is to publish a WMS via GeoServer. Only those geometries that "appear" to be populated come through in the WMS. While this may be a GeoServer issue, it is still reporting the same information that "appears" in PostGIS.

Any other thoughts?




Tim Bowden wrote:
Geoff,

This earlier thread may be of interest:
http://postgis.refractions.net/pipermail/postgis-users/2008-March/018814.html

It deals with limitations of pgadmin and postgis.

If the geometries really are null, are you also able to try loading the
data with ogr2ogr to see if you get the same result?   Are you sure you
don't have any invalid geometries?  I don't know how FME handles these.

HTH,
Tim Bowden
On Tue, 2008-07-01 at 17:12 -0700, geoffi wrote:
> I have translated some polygon data into a PostGIS table using FME. The
> translation was successful with no errors reported. All the records appear
> in the PostGIS table (using the pgAdminIII application) except for about 90%
> of the geometries (see image below).
>
> http://www.nabble.com/file/p18227858/table.jpg 
>
> However, using the FME Universal Viewer all records are displayed with their
> correct geometry as I would expect.
>
> What is causing the Geometry column in the table to appear empty?
> Is there a setting in PostGIS to force the data to be visible in the
> pgAdminIII application?
>
> Attempts to generate a WMS from this table using GeoServer only displays
> those records that appear to have geometry.
>
> Performing a similar exercise using point geometries, there was no problem.
>
--
vim is a good example of an IDE done properly.  emacs is an example of
an IDE done poorly.  Anything that involves little pictures is a
mis-umderstanding of what an IDE should be.

_______________________________________________
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users

Re: Geometry appears empty

by Tim Bowden :: Rate this Message:

| View Threaded | Show Only this Message


On Tue, 2008-07-01 at 20:28 -0700, geoffi wrote:
> Hi Tim,
>
> First of all I can confirm that the geometries are not null by:
>    a) select count(*) from <my_table> where geom is null;
>        This returns a count of 0.
>    b) the FME Universal Viewer successfully displays all the geometries
> successfully. Features can be graphically selected and their attributes
> interrogated.

Ok, so you're saying there is geometry data is in postgis for each
record?  You seem to be negating this further down.

>
> The link you gave seems to imply that pgAdminIII may not be the tool to use
> to verify geometry columns. It also mentions a possible limitation for the
> number of verticies hitting a limit of 1365. I will need to check my
> geometries if this is the same in my case.
>

This limitation is just PgAdminIII's ability to view the data.  It does
not affect what's in the DB.  I'd be  surprised if there isn't a fix on
the way for PgAdminIII as this has been around for a while now.

> In the meantime, I've also used the psql command line interface to check the
> records with the same results as per the pgAdminIII. Can you recommend
> another tool I can use to report the geometry data?
>

Prefer psql over PgAdmin myself (can't seem to break the cli habit).
There should be no issues with using psql.  Are you saying some records
don't contain geometry data (as per original PgAdmin view) or you got no
null geom records?  Little confused now.

> As mentioned in the original post, my final step is to publish a WMS via
> GeoServer. Only those geometries that "appear" to be populated come through
> in the WMS. While this may be a GeoServer issue, it is still reporting the
> same information that "appears" in PostGIS.
>
> Any other thoughts?
>
Check the validity of your geoms.
select count(*) from <table> where not ST_IsValid(the_geom);
(or whatever your geom column is called).

Regards,
Tim Bowden

>
>
>
>
> Tim Bowden wrote:
> >
> > Geoff,
> >
> > This earlier thread may be of interest:
> > http://postgis.refractions.net/pipermail/postgis-users/2008-March/018814.html
> >
> > It deals with limitations of pgadmin and postgis.
> >
> > If the geometries really are null, are you also able to try loading the
> > data with ogr2ogr to see if you get the same result?   Are you sure you
> > don't have any invalid geometries?  I don't know how FME handles these.
> >
> > HTH,
> > Tim Bowden
> > On Tue, 2008-07-01 at 17:12 -0700, geoffi wrote:
> >> I have translated some polygon data into a PostGIS table using FME. The
> >> translation was successful with no errors reported. All the records
> >> appear
> >> in the PostGIS table (using the pgAdminIII application) except for about
> >> 90%
> >> of the geometries (see image below).
> >>
> >> http://www.nabble.com/file/p18227858/table.jpg 
> >>
> >> However, using the FME Universal Viewer all records are displayed with
> >> their
> >> correct geometry as I would expect.
> >>
> >> What is causing the Geometry column in the table to appear empty?
> >> Is there a setting in PostGIS to force the data to be visible in the
> >> pgAdminIII application?
> >>
> >> Attempts to generate a WMS from this table using GeoServer only displays
> >> those records that appear to have geometry.
> >>
> >> Performing a similar exercise using point geometries, there was no
> >> problem.
> >>
> > --
> > vim is a good example of an IDE done properly.  emacs is an example of
> > an IDE done poorly.  Anything that involves little pictures is a
> > mis-umderstanding of what an IDE should be.
> >
> > _______________________________________________
> > postgis-users mailing list
> > postgis-users@...
> > http://postgis.refractions.net/mailman/listinfo/postgis-users
> >
> >
>
--
vim is a good example of an IDE done properly.  emacs is an example of
an IDE done poorly.  Anything that involves little pictures is a
mis-umderstanding of what an IDE should be.

_______________________________________________
postgis-users mailing list
postgis-users@...
http://postgis.refractions.net/mailman/listinfo/postgis-users

Re: Geometry appears empty

by geoffi :: Rate this Message:

| View Threaded | Show Only this Message

Hi Tim,

OK to clarify...
 I have 694 records in my table, all have geometry based on the query:
    select count(*) from gen_poly
    where ST_IsValid(geom);

       count
       -------
          694
      (1 row)

When viewed in pgAdminIII only a handfull "appear" to have actual data in the geom column (see original post). This is also the result when queried using psql. The rest "appear" to be null.

FME proves that all 694 geometries exist and can display and interrogate them.

Pushing the data out as a WMS via GeoServer only displays the handfull that can be "seen" in psql and pgAdminIII.

So, we've established that all geometries are valid, but only some can be seen using the Postgres tools or GeoServer. FME can see ALL the geometries!



Tim Bowden wrote:
On Tue, 2008-07-01 at 20:28 -0700, geoffi wrote:
> Hi Tim,
>
> First of all I can confirm that the geometries are not null by:
>    a) select count(*) from <my_table> where geom is null;
>        This returns a count of 0.
>    b) the FME Universal Viewer successfully displays all the geometries
> successfully. Features can be graphically selected and their attributes
> interrogated.

Ok, so you're saying there is geometry data is in postgis for each
record?  You seem to be negating this further down.

>
> The link you gave seems to imply that pgAdminIII may not be the tool to use
> to verify geometry columns. It also mentions a possible limitation for the
> number of verticies hitting a limit of 1365. I will need to check my
> geometries if this is the same in my case.
>

This limitation is just PgAdminIII's ability to view the data.  It does
not affect what's in the DB.  I'd be  surprised if there isn't a fix on
the way for PgAdminIII as this has been around for a while now.

> In the meantime, I've also used the psql command line interface to check the
> records with the same results as per the pgAdminIII. Can you recommend
> another tool I can use to report the geometry data?
>

Prefer psql over PgAdmin myself (can't seem to break the cli habit).
There should be no issues with using psql.  Are you saying some records
don't contain geometry data (as per original PgAdmin view) or you got no
null geom records?  Little confused now.

> As mentioned in the original post, my final step is to publish a WMS via
> GeoServer. Only those geometries that "appear" to be populated come through
> in the WMS. While this may be a GeoServer issue, it is still reporting the
> same information that "appears" in PostGIS.
>
> Any other thoughts?
>
Check the validity of your geoms.
select count(*) from <table> where not ST_IsValid(the_geom);
(or whatever your geom column is called).

Regards,
Tim Bowden
>
>
>
>
> Tim Bowden wrote:
> >
> > Geoff,
> >
> > This earlier thread may be of interest:
> > http://postgis.refractions.net/pipermail/postgis-users/2008-March/018814.html
> >
> > It deals with limitations of pgadmin and postgis.
> >
> > If the geometries really are null, are you also able to try loading the
> > data with ogr2ogr to see if you get the same result?   Are you sure you
> > don't have any invalid geometries?  I don't know how FME handles these.
> >
> > HTH,
> > Tim Bowden
> > On Tue, 2008-07-01 at 17:12 -0700, geoffi wrote:
> >> I have translated some polygon data into a PostGIS table using FME. The
> >> translation was successful with no errors reported. All the records
> >> appear
> >> in the PostGIS table (using the pgAdminIII application) except for about
> >> 90%
> >> of the geometries (see image below).
> >>
> >> http://www.nabble.com/file/p18227858/table.jpg 
> >>
> >> However, using the FME Universal Viewer all records are displayed with
> >> their
> >> correct geometry as I would expect.
> >>
> >> What is causing the Geometry column in the table to appear empty?
> >> Is there a setting in PostGIS to force the data to be visible in the
> >> pgAdminIII application?
> >>
> >> Attempts to generate a WMS from this table using GeoServer only displays
> >> those records that appear to have geometry.
> >>
> >> Performing a similar exercise using point geometries, there was no
> >> problem.
> >>
> > --
> > vim is a good example of an IDE done properly.  emacs is an example of
> > an IDE done poorly.  Anything that involves little pictures is a
> > mis-umderstanding of what an IDE should be.
> >
> > _______________________________________________
> > postgis-users mailing list
> > postgis-users@postgis.refractions.net
> > http://postgis.refractions.net/mailman/listinfo/postgis-users
> >
> >
>
--
vim is a good example of an IDE done properly.  emacs is an example of
an IDE done poorly.  Anything that involves little pictures is a
mis-umderstanding of what an IDE should be.

_______________________________________________
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users

Re: Geometry appears empty

by Tim Bowden :: Rate this Message:

| View Threaded | Show Only this Message


On Tue, 2008-07-01 at 21:53 -0700, geoffi wrote:

> Hi Tim,
>
> OK to clarify...
>  I have 694 records in my table, all have geometry based on the query:
>     select count(*) from gen_poly
>     where ST_IsValid(geom);
>
>        count
>        -------
>           694
>       (1 row)

Ok, that's confirmed the geometries are there.

>
> When viewed in pgAdminIII only a handfull "appear" to have actual data in
> the geom column (see original post). This is also the result when queried
> using psql. The rest "appear" to be null.
>
psql should be showing the geometries.  What query are you using to see
them?

Using psql try:
SELECT AsText(geom) AS geom from <mytable>;
That should show you the text representations of the geometries and
return 694 rows.

> FME proves that all 694 geometries exist and can display and interrogate
> them.
>
> Pushing the data out as a WMS via GeoServer only displays the handfull that
> can be "seen" in psql and pgAdminIII.
>

Are you sure it is *exactly* the same subset that doesn't get shown in
both geoserver and PgAdmin?

Does geoserver log any errors?  Are you having minscale or maxscale
issues in visualising the data?  Given FME can see the data it is in
there and appears to be doing what it is supposed to do. I'm starting to
think it is an issue with geoserver of some sort.

Regards,
Tim Bowden

> So, we've established that all geometries are valid, but only some can be
> seen using the Postgres tools or GeoServer. FME can see ALL the geometries!
>
>
>
>
> Tim Bowden wrote:
> >
> >
> > On Tue, 2008-07-01 at 20:28 -0700, geoffi wrote:
> >> Hi Tim,
> >>
> >> First of all I can confirm that the geometries are not null by:
> >>    a) select count(*) from <my_table> where geom is null;
> >>        This returns a count of 0.
> >>    b) the FME Universal Viewer successfully displays all the geometries
> >> successfully. Features can be graphically selected and their attributes
> >> interrogated.
> >
> > Ok, so you're saying there is geometry data is in postgis for each
> > record?  You seem to be negating this further down.
> >
> >>
> >> The link you gave seems to imply that pgAdminIII may not be the tool to
> >> use
> >> to verify geometry columns. It also mentions a possible limitation for
> >> the
> >> number of verticies hitting a limit of 1365. I will need to check my
> >> geometries if this is the same in my case.
> >>
> >
> > This limitation is just PgAdminIII's ability to view the data.  It does
> > not affect what's in the DB.  I'd be  surprised if there isn't a fix on
> > the way for PgAdminIII as this has been around for a while now.
> >
> >> In the meantime, I've also used the psql command line interface to check
> >> the
> >> records with the same results as per the pgAdminIII. Can you recommend
> >> another tool I can use to report the geometry data?
> >>
> >
> > Prefer psql over PgAdmin myself (can't seem to break the cli habit).
> > There should be no issues with using psql.  Are you saying some records
> > don't contain geometry data (as per original PgAdmin view) or you got no
> > null geom records?  Little confused now.
> >
> >> As mentioned in the original post, my final step is to publish a WMS via
> >> GeoServer. Only those geometries that "appear" to be populated come
> >> through
> >> in the WMS. While this may be a GeoServer issue, it is still reporting
> >> the
> >> same information that "appears" in PostGIS.
> >>
> >> Any other thoughts?
> >>
> > Check the validity of your geoms.
> > select count(*) from <table> where not ST_IsValid(the_geom);
> > (or whatever your geom column is called).
> >
> > Regards,
> > Tim Bowden
> >>
> >>
> >>
> >>
> >> Tim Bowden wrote:
> >> >
> >> > Geoff,
> >> >
> >> > This earlier thread may be of interest:
> >> >
> >> http://postgis.refractions.net/pipermail/postgis-users/2008-March/018814.html
> >> >
> >> > It deals with limitations of pgadmin and postgis.
> >> >
> >> > If the geometries really are null, are you also able to try loading the
> >> > data with ogr2ogr to see if you get the same result?   Are you sure you
> >> > don't have any invalid geometries?  I don't know how FME handles these.
> >> >
> >> > HTH,
> >> > Tim Bowden
> >> > On Tue, 2008-07-01 at 17:12 -0700, geoffi wrote:
> >> >> I have translated some polygon data into a PostGIS table using FME.
> >> The
> >> >> translation was successful with no errors reported. All the records
> >> >> appear
> >> >> in the PostGIS table (using the pgAdminIII application) except for
> >> about
> >> >> 90%
> >> >> of the geometries (see image below).
> >> >>
> >> >> http://www.nabble.com/file/p18227858/table.jpg 
> >> >>
> >> >> However, using the FME Universal Viewer all records are displayed with
> >> >> their
> >> >> correct geometry as I would expect.
> >> >>
> >> >> What is causing the Geometry column in the table to appear empty?
> >> >> Is there a setting in PostGIS to force the data to be visible in the
> >> >> pgAdminIII application?
> >> >>
> >> >> Attempts to generate a WMS from this table using GeoServer only
> >> displays
> >> >> those records that appear to have geometry.
> >> >>
> >> >> Performing a similar exercise using point geometries, there was no
> >> >> problem.
> >> >>
> >> > --
> >> > vim is a good example of an IDE done properly.  emacs is an example of
> >> > an IDE done poorly.  Anything that involves little pictures is a
> >> > mis-umderstanding of what an IDE should be.
> >> >
> >> > _______________________________________________
> >> > postgis-users mailing list
> >> > postgis-users@...
> >> > http://postgis.refractions.net/mailman/listinfo/postgis-users
> >> >
> >> >
> >>
> > --
> > vim is a good example of an IDE done properly.  emacs is an example of
> > an IDE done poorly.  Anything that involves little pictures is a
> > mis-umderstanding of what an IDE should be.
> >
> > _______________________________________________
> > postgis-users mailing list
> > postgis-users@...
> > http://postgis.refractions.net/mailman/listinfo/postgis-users
> >
> >
>
--
vim is a good example of an IDE done properly.  emacs is an example of
an IDE done poorly.  Anything that involves little pictures is a
mis-umderstanding of what an IDE should be.

_______________________________________________
postgis-users mailing list
postgis-users@...
http://postgis.refractions.net/mailman/listinfo/postgis-users

Re: Geometry appears empty

by geoffi :: Rate this Message:

| View Threaded | Show Only this Message

Hi Tim,

We may be getting closer...

I played with 2 records as shown in the following picture...



The first record is "good" with a geometry displayed.
The second record is "bad" with no apparent geometry, although FME says it's there.

Using your SQL to pull back the geometry from a "good" record, I get...

    SELECT AsText(geom) AS geom from <mytable>
    where objectid = 1223;

{lots of blank space then}

                        astext

{more blank space then}
-- More  --

I needed to hold the [Return] key down a couple of times, then...

--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
-------------------------------------------------------------------------------
 POLYGON((141.548285513 -31.912637719,141.545762555 -31.913531755,141.546310555
-31.913471761,141.54674956 -31.913504737,141.549265544 -31.913691714,141.5490575
76 -31.915810721,141.548619679 -31.920279747,141.548576682 -31.920711755,141.548
254731 -31.923986732,141.548238728 -31.924155721,141.548155735 -31.924996737,141
.548086712 -31.925530721,141.545391787 -31.925311784,141.545221783 -31.926897754
,141.545194788 -31.92715276,141.544995849 -31.929013758,141.544967838 -31.929266
733,141.544770839 -31.931113736,141.544741881 -31.931379758,141.544550886 -31.93
317074,141.544521928 -31.933439741,141.544332965 -31.935254739,141.544298951 -31
-- More  --

This looks good.

Then using a "bad" record
    SELECT AsText(geom) AS geom from <mytable>
    where objectid = 1224;

I needed to hold the [Return] key down for some considerable time before information starts to appear...

{lots of blank space then}

                        astext

{much much more blank space then}

-- More  --

{even more ------------- and finally...}
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------
 POLYGON((144.197668937 -30.371967948,144.229111829 -30.406941493,144.29063679 -
30.475285756,144.290958811 -30.475642761,144.287176868 -30.478198809,144.3050499
26 -30.498464562,144.31816496 -30.513087375,144.414326182 -30.620141056,144.4942
14172 -30.708857457,144.550416228 -30.770291066,144.590842179 -30.814480786,144.
590236218 -30.814832803,144.589741214 -30.815377824,144.589873209 -30.815524829,
144.646111081 -30.878004698,144.646507042 -30.878444719,144.658429019 -30.891677
615,144.657705033 -30.892580611,144.656548023 -30.891890617,144.654921065 -30.89
1748623,144.652761093 -30.891872651,144.649312163 -30.89238569,144.647124203 -30
.892460693,144.644460222 -30.892488727,144.641851269 -30.892347749,144.640252252
 -30.892446769,144.638794282 -30.892690784,144.638038314 -30.893367777,144.63733
9338 -30.894432787,144.636696359 -30.895713802,144.63613836 -30.89745382,144.635
917368 -30.899169821,144.63622842 -30.900304801,144.636790391 -30.9012468,144.63
8167399 -30.901969793,144.639458367 -30.902353769,144.639935382 -30.902885789,14
-- More  --


So, the geometry is present in both the "good" and "bad" records.
Next, what is GeoServer doing? It's probably over to that forum to find out.

Thanks for your help.

Tim Bowden wrote:
On Tue, 2008-07-01 at 21:53 -0700, geoffi wrote:
> Hi Tim,
>
> OK to clarify...
>  I have 694 records in my table, all have geometry based on the query:
>     select count(*) from gen_poly
>     where ST_IsValid(geom);
>
>        count
>        -------
>           694
>       (1 row)

Ok, that's confirmed the geometries are there.

>
> When viewed in pgAdminIII only a handfull "appear" to have actual data in
> the geom column (see original post). This is also the result when queried
> using psql. The rest "appear" to be null.
>
psql should be showing the geometries.  What query are you using to see
them?

Using psql try:
SELECT AsText(geom) AS geom from <mytable>;
That should show you the text representations of the geometries and
return 694 rows.

> FME proves that all 694 geometries exist and can display and interrogate
> them.
>
> Pushing the data out as a WMS via GeoServer only displays the handfull that
> can be "seen" in psql and pgAdminIII.
>

Are you sure it is *exactly* the same subset that doesn't get shown in
both geoserver and PgAdmin?

Does geoserver log any errors?  Are you having minscale or maxscale
issues in visualising the data?  Given FME can see the data it is in
there and appears to be doing what it is supposed to do. I'm starting to
think it is an issue with geoserver of some sort.

Regards,
Tim Bowden

> So, we've established that all geometries are valid, but only some can be
> seen using the Postgres tools or GeoServer. FME can see ALL the geometries!
>
>
>
>
> Tim Bowden wrote:
> >
> >
> > On Tue, 2008-07-01 at 20:28 -0700, geoffi wrote:
> >> Hi Tim,
> >>
> >> First of all I can confirm that the geometries are not null by:
> >>    a) select count(*) from <my_table> where geom is null;
> >>        This returns a count of 0.
> >>    b) the FME Universal Viewer successfully displays all the geometries
> >> successfully. Features can be graphically selected and their attributes
> >> interrogated.
> >
> > Ok, so you're saying there is geometry data is in postgis for each
> > record?  You seem to be negating this further down.
> >
> >>
> >> The link you gave seems to imply that pgAdminIII may not be the tool to
> >> use
> >> to verify geometry columns. It also mentions a possible limitation for
> >> the
> >> number of verticies hitting a limit of 1365. I will need to check my
> >> geometries if this is the same in my case.
> >>
> >
> > This limitation is just PgAdminIII's ability to view the data.  It does
> > not affect what's in the DB.  I'd be  surprised if there isn't a fix on
> > the way for PgAdminIII as this has been around for a while now.
> >
> >> In the meantime, I've also used the psql command line interface to check
> >> the
> >> records with the same results as per the pgAdminIII. Can you recommend
> >> another tool I can use to report the geometry data?
> >>
> >
> > Prefer psql over PgAdmin myself (can't seem to break the cli habit).
> > There should be no issues with using psql.  Are you saying some records
> > don't contain geometry data (as per original PgAdmin view) or you got no
> > null geom records?  Little confused now.
> >
> >> As mentioned in the original post, my final step is to publish a WMS via
> >> GeoServer. Only those geometries that "appear" to be populated come
> >> through
> >> in the WMS. While this may be a GeoServer issue, it is still reporting
> >> the
> >> same information that "appears" in PostGIS.
> >>
> >> Any other thoughts?
> >>
> > Check the validity of your geoms.
> > select count(*) from <table> where not ST_IsValid(the_geom);
> > (or whatever your geom column is called).
> >
> > Regards,
> > Tim Bowden
> >>
> >>
> >>
> >>
> >> Tim Bowden wrote:
> >> >
> >> > Geoff,
> >> >
> >> > This earlier thread may be of interest:
> >> >
> >> http://postgis.refractions.net/pipermail/postgis-users/2008-March/018814.html
> >> >
> >> > It deals with limitations of pgadmin and postgis.
> >> >
> >> > If the geometries really are null, are you also able to try loading the
> >> > data with ogr2ogr to see if you get the same result?   Are you sure you
> >> > don't have any invalid geometries?  I don't know how FME handles these.
> >> >
> >> > HTH,
> >> > Tim Bowden
> >> > On Tue, 2008-07-01 at 17:12 -0700, geoffi wrote:
> >> >> I have translated some polygon data into a PostGIS table using FME.
> >> The
> >> >> translation was successful with no errors reported. All the records
> >> >> appear
> >> >> in the PostGIS table (using the pgAdminIII application) except for
> >> about
> >> >> 90%
> >> >> of the geometries (see image below).
> >> >>
> >> >> http://www.nabble.com/file/p18227858/table.jpg 
> >> >>
> >> >> However, using the FME Universal Viewer all records are displayed with
> >> >> their
> >> >> correct geometry as I would expect.
> >> >>
> >> >> What is causing the Geometry column in the table to appear empty?
> >> >> Is there a setting in PostGIS to force the data to be visible in the
> >> >> pgAdminIII application?
> >> >>
> >> >> Attempts to generate a WMS from this table using GeoServer only
> >> displays
> >> >> those records that appear to have geometry.
> >> >>
> >> >> Performing a similar exercise using point geometries, there was no
> >> >> problem.
> >> >>
> >> > --
> >> > vim is a good example of an IDE done properly.  emacs is an example of
> >> > an IDE done poorly.  Anything that involves little pictures is a
> >> > mis-umderstanding of what an IDE should be.
> >> >
> >> > _______________________________________________
> >> > postgis-users mailing list
> >> > postgis-users@postgis.refractions.net
> >> > http://postgis.refractions.net/mailman/listinfo/postgis-users
> >> >
> >> >
> >>
> > --
> > vim is a good example of an IDE done properly.  emacs is an example of
> > an IDE done poorly.  Anything that involves little pictures is a
> > mis-umderstanding of what an IDE should be.
> >
> > _______________________________________________
> > postgis-users mailing list
> > postgis-users@postgis.refractions.net
> > http://postgis.refractions.net/mailman/listinfo/postgis-users
> >
> >
>
--
vim is a good example of an IDE done properly.  emacs is an example of
an IDE done poorly.  Anything that involves little pictures is a
mis-umderstanding of what an IDE should be.

_______________________________________________
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users

Re: Geometry appears empty

by Tim Bowden :: Rate this Message:

| View Threaded | Show Only this Message


On Tue, 2008-07-01 at 23:41 -0700, geoffi wrote:

> Hi Tim,
>
> We may be getting closer...
>
> I played with 2 records as shown in the following picture...
>
> http://www.nabble.com/file/p18231274/two_records.jpg 
>
> The first record is "good" with a geometry displayed.
> The second record is "bad" with no apparent geometry, although FME says it's
> there.
>
> Using your SQL to pull back the geometry from a "good" record, I get...
>
>     SELECT AsText(geom) AS geom from <mytable>
>     where objectid = 1223;
>
> {lots of blank space then}

<snip>
The geom column is set to the width of the widest output, hence the
massive line wrap.

>
> So, the geometry is present in both the "good" and "bad" records.
> Next, what is GeoServer doing? It's probably over to that forum to find out.
>
Yes, geoserver mailing list is now the best place.

Regards,
Tim Bowden

> Thanks for your help.
>
>
> Tim Bowden wrote:
> >
> >
> > On Tue, 2008-07-01 at 21:53 -0700, geoffi wrote:
> >> Hi Tim,
> >>
> >> OK to clarify...
> >>  I have 694 records in my table, all have geometry based on the query:
> >>     select count(*) from gen_poly
> >>     where ST_IsValid(geom);
> >>
> >>        count
> >>        -------
> >>           694
> >>       (1 row)
> >
> > Ok, that's confirmed the geometries are there.
> >
> >>
> >> When viewed in pgAdminIII only a handfull "appear" to have actual data in
> >> the geom column (see original post). This is also the result when queried
> >> using psql. The rest "appear" to be null.
> >>
> > psql should be showing the geometries.  What query are you using to see
> > them?
> >
> > Using psql try:
> > SELECT AsText(geom) AS geom from <mytable>;
> > That should show you the text representations of the geometries and
> > return 694 rows.
> >
> >> FME proves that all 694 geometries exist and can display and interrogate
> >> them.
> >>
> >> Pushing the data out as a WMS via GeoServer only displays the handfull
> >> that
> >> can be "seen" in psql and pgAdminIII.
> >>
> >
> > Are you sure it is *exactly* the same subset that doesn't get shown in
> > both geoserver and PgAdmin?
> >
> > Does geoserver log any errors?  Are you having minscale or maxscale
> > issues in visualising the data?  Given FME can see the data it is in
> > there and appears to be doing what it is supposed to do. I'm starting to
> > think it is an issue with geoserver of some sort.
> >
> > Regards,
> > Tim Bowden
> >
> >> So, we've established that all geometries are valid, but only some can be
> >> seen using the Postgres tools or GeoServer. FME can see ALL the
> >> geometries!
> >>
> >>
> >>
> >>
> >> Tim Bowden wrote:
> >> >
> >> >
> >> > On Tue, 2008-07-01 at 20:28 -0700, geoffi wrote:
> >> >> Hi Tim,
> >> >>
> >> >> First of all I can confirm that the geometries are not null by:
> >> >>    a) select count(*) from <my_table> where geom is null;
> >> >>        This returns a count of 0.
> >> >>    b) the FME Universal Viewer successfully displays all the
> >> geometries
> >> >> successfully. Features can be graphically selected and their
> >> attributes
> >> >> interrogated.
> >> >
> >> > Ok, so you're saying there is geometry data is in postgis for each
> >> > record?  You seem to be negating this further down.
> >> >
> >> >>
> >> >> The link you gave seems to imply that pgAdminIII may not be the tool
> >> to
> >> >> use
> >> >> to verify geometry columns. It also mentions a possible limitation for
> >> >> the
> >> >> number of verticies hitting a limit of 1365. I will need to check my
> >> >> geometries if this is the same in my case.
> >> >>
> >> >
> >> > This limitation is just PgAdminIII's ability to view the data.  It does
> >> > not affect what's in the DB.  I'd be  surprised if there isn't a fix on
> >> > the way for PgAdminIII as this has been around for a while now.
> >> >
> >> >> In the meantime, I've also used the psql command line interface to
> >> check
> >> >> the
> >> >> records with the same results as per the pgAdminIII. Can you recommend
> >> >> another tool I can use to report the geometry data?
> >> >>
> >> >
> >> > Prefer psql over PgAdmin myself (can't seem to break the cli habit).
> >> > There should be no issues with using psql.  Are you saying some records
> >> > don't contain geometry data (as per original PgAdmin view) or you got
> >> no
> >> > null geom records?  Little confused now.
> >> >
> >> >> As mentioned in the original post, my final step is to publish a WMS
> >> via
> >> >> GeoServer. Only those geometries that "appear" to be populated come
> >> >> through
> >> >> in the WMS. While this may be a GeoServer issue, it is still reporting
> >> >> the
> >> >> same information that "appears" in PostGIS.
> >> >>
> >> >> Any other thoughts?
> >> >>
> >> > Check the validity of your geoms.
> >> > select count(*) from <table> where not ST_IsValid(the_geom);
> >> > (or whatever your geom column is called).
> >> >
> >> > Regards,
> >> > Tim Bowden
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> Tim Bowden wrote:
> >> >> >
> >> >> > Geoff,
> >> >> >
> >> >> > This earlier thread may be of interest:
> >> >> >
> >> >>
> >> http://postgis.refractions.net/pipermail/postgis-users/2008-March/018814.html
> >> >> >
> >> >> > It deals with limitations of pgadmin and postgis.
> >> >> >
> >> >> > If the geometries really are null, are you also able to try loading
> >> the
> >> >> > data with ogr2ogr to see if you get the same result?   Are you sure
> >> you
> >> >> > don't have any invalid geometries?  I don't know how FME handles
> >> these.
> >> >> >
> >> >> > HTH,
> >> >> > Tim Bowden
> >> >> > On Tue, 2008-07-01 at 17:12 -0700, geoffi wrote:
> >> >> >> I have translated some polygon data into a PostGIS table using FME.
> >> >> The
> >> >> >> translation was successful with no errors reported. All the records
> >> >> >> appear
> >> >> >> in the PostGIS table (using the pgAdminIII application) except for
> >> >> about
> >> >> >> 90%
> >> >> >> of the geometries (see image below).
> >> >> >>
> >> >> >> http://www.nabble.com/file/p18227858/table.jpg 
> >> >> >>
> >> >> >> However, using the FME Universal Viewer all records are displayed
> >> with
> >> >> >> their
> >> >> >> correct geometry as I would expect.
> >> >> >>
> >> >> >> What is causing the Geometry column in the table to appear empty?
> >> >> >> Is there a setting in PostGIS to force the data to be visible in
> >> the
> >> >> >> pgAdminIII application?
> >> >> >>
> >> >> >> Attempts to generate a WMS from this table using GeoServer only
> >> >> displays
> >> >> >> those records that appear to have geometry.
> >> >> >>
> >> >> >> Performing a similar exercise using point geometries, there was no
> >> >> >> problem.
> >> >> >>
> >> >> > --
> >> >> > vim is a good example of an IDE done properly.  emacs is an example
> >> of
> >> >> > an IDE done poorly.  Anything that involves little pictures is a
> >> >> > mis-umderstanding of what an IDE should be.
> >> >> >
> >> >> > _______________________________________________
> >> >> > postgis-users mailing list
> >> >> > postgis-users@...
> >> >> > http://postgis.refractions.net/mailman/listinfo/postgis-users
> >> >> >
> >> >> >
> >> >>
> >> > --
> >> > vim is a good example of an IDE done properly.  emacs is an example of
> >> > an IDE done poorly.  Anything that involves little pictures is a
> >> > mis-umderstanding of what an IDE should be.
> >> >
> >> > _______________________________________________
> >> > postgis-users mailing list
> >> > postgis-users@...
> >> > http://postgis.refractions.net/mailman/listinfo/postgis-users
> >> >
> >> >
> >>
> > --
> > vim is a good example of an IDE done properly.  emacs is an example of
> > an IDE done poorly.  Anything that involves little pictures is a
> > mis-umderstanding of what an IDE should be.
> >
> > _______________________________________________
> > postgis-users mailing list
> > postgis-users@...
> > http://postgis.refractions.net/mailman/listinfo/postgis-users
> >
> >
>
--
vim is a good example of an IDE done properly.  emacs is an example of
an IDE done poorly.  Anything that involves little pictures is a
mis-umderstanding of what an IDE should be.

_______________________________________________
postgis-users mailing list
postgis-users@...
http://postgis.refractions.net/mailman/listinfo/postgis-users