[Geoserver-users] Null Extent versions over 1.3.1

Hi
I am having a problem using any version above 1.3.1a. I am using exactly the
same data in a postgis database and I get the error when adding a new
feature type and fetching the bounding box.
The FeatureType polylines has a NULL extent.
HINT: the dataset is empty or has no default geometry attribute.
The geometry_columns is correct (i think) displaying:
36606;"''";"public";"polylines";"the_geom";2;27700;"MULTILINESTRING"

I can add in a POINT defined table ok but both MULTILINESTRING and
MULTIPOLYGON tables produce the error. I have tried also removing the SRID
or using 4326 with no luck.
Does anyone have any ideas?

On a semi related matter I cannot seem to downgrade geoserver in my tomcat
installation without first uninstalling tomcat and reinstalling. I get a
whole page error when I goto the stores page.

--
View this message in context: http://www.nabble.com/Null-Extent-versions-over-1.3.1-tf2544946.html#a7091353
Sent from the GeoServer - User mailing list archive at Nabble.com.

Tomcat sometimes keeps libraries in its shared/lib directory. So there might be some old geotools or geoserver jars in there that are conflicting and causing your errors when you downgrade.

The only change that I can remember to the postgis datastore (there are probably more, maybe someone else on the list knows) is that it does not rely on OIDs any more. I'm not sure if that would be giving you the null extents problem. Usually this is a case of the wrong projection.
Do you have data in the table? (I'm assuming so).

Brent Owens
(The Open Planning Project)

Phatbloke wrote:

Hi
I am having a problem using any version above 1.3.1a. I am using exactly the
same data in a postgis database and I get the error when adding a new
feature type and fetching the bounding box. The FeatureType polylines has a NULL extent. HINT: the dataset is empty or has no default geometry attribute. The geometry_columns is correct (i think) displaying:
36606;"''";"public";"polylines";"the_geom";2;27700;"MULTILINESTRING"

I can add in a POINT defined table ok but both MULTILINESTRING and
MULTIPOLYGON tables produce the error. I have tried also removing the SRID
or using 4326 with no luck.
Does anyone have any ideas?

On a semi related matter I cannot seem to downgrade geoserver in my tomcat
installation without first uninstalling tomcat and reinstalling. I get a
whole page error when I goto the stores page.

Hi

Yeah the data is there, I have tried different projections with no luck
either both defining it in the geometry_columns table or leaving it as -1
and defining it in geoserver. It might have something to do with how i am
importing the data. I am using Mapinfo and converting the TAB files to Shape
files then using the PostGIS shp2sql prog to convert the shape files into
SQL inserts. Do you think that might be an issue? Can you recomend another
way to get from mapinfo TAB files to PostGIS?

Thanks

Jason

Brent Owens wrote:

Tomcat sometimes keeps libraries in its shared/lib directory. So there
might be some old geotools or geoserver jars in there that are
conflicting and causing your errors when you downgrade.

The only change that I can remember to the postgis datastore (there are
probably more, maybe someone else on the list knows) is that it does not
rely on OIDs any more. I'm not sure if that would be giving you the null
extents problem. Usually this is a case of the wrong projection.
Do you have data in the table? (I'm assuming so).

Brent Owens
(The Open Planning Project)

Phatbloke wrote:

Hi
I am having a problem using any version above 1.3.1a. I am using exactly
the
same data in a postgis database and I get the error when adding a new
feature type and fetching the bounding box.
The FeatureType polylines has a NULL extent.
HINT: the dataset is empty or has no default geometry attribute.
The geometry_columns is correct (i think) displaying:
36606;"''";"public";"polylines";"the_geom";2;27700;"MULTILINESTRING"

I can add in a POINT defined table ok but both MULTILINESTRING and
MULTIPOLYGON tables produce the error. I have tried also removing the
SRID
or using 4326 with no luck.
Does anyone have any ideas?

On a semi related matter I cannot seem to downgrade geoserver in my
tomcat
installation without first uninstalling tomcat and reinstalling. I get a
whole page error when I goto the stores page.

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job
easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

--
View this message in context: http://www.nabble.com/Null-Extent-versions-over-1.3.1-tf2544946.html#a7200905
Sent from the GeoServer - User mailing list archive at Nabble.com.

Hi

I have a bit of an update on this matter but still cannot solve it.
Basically I need to split my line strings from Mapinfo before inserting into
PostGIS. If I use ogr2ogr I always get a "violates check constraint" error
when inserting the polylines although when I use shp2pgsql I get no errors
but obviously poorly formatted entries.
I think some are linestrings and some multiline strings maybe.
has anyone else had these problems when importing from Mapinfo to PostGIS

Thanks

Phatbloke wrote:

Hi

Yeah the data is there, I have tried different projections with no luck
either both defining it in the geometry_columns table or leaving it as -1
and defining it in geoserver. It might have something to do with how i am
importing the data. I am using Mapinfo and converting the TAB files to
Shape files then using the PostGIS shp2sql prog to convert the shape files
into SQL inserts. Do you think that might be an issue? Can you recomend
another way to get from mapinfo TAB files to PostGIS?

Thanks

Jason

Brent Owens wrote:

Tomcat sometimes keeps libraries in its shared/lib directory. So there
might be some old geotools or geoserver jars in there that are
conflicting and causing your errors when you downgrade.

The only change that I can remember to the postgis datastore (there are
probably more, maybe someone else on the list knows) is that it does not
rely on OIDs any more. I'm not sure if that would be giving you the null
extents problem. Usually this is a case of the wrong projection.
Do you have data in the table? (I'm assuming so).

Brent Owens
(The Open Planning Project)

Phatbloke wrote:

Hi
I am having a problem using any version above 1.3.1a. I am using exactly
the
same data in a postgis database and I get the error when adding a new
feature type and fetching the bounding box.
The FeatureType polylines has a NULL extent.
HINT: the dataset is empty or has no default geometry attribute.
The geometry_columns is correct (i think) displaying:
36606;"''";"public";"polylines";"the_geom";2;27700;"MULTILINESTRING"

I can add in a POINT defined table ok but both MULTILINESTRING and
MULTIPOLYGON tables produce the error. I have tried also removing the
SRID
or using 4326 with no luck.
Does anyone have any ideas?

On a semi related matter I cannot seem to downgrade geoserver in my
tomcat
installation without first uninstalling tomcat and reinstalling. I get a
whole page error when I goto the stores page.

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job
easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache
Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

--
View this message in context: http://www.nabble.com/Null-Extent-versions-over-1.3.1-tf2544946.html#a7377587
Sent from the GeoServer - User mailing list archive at Nabble.com.

Phatbloke ha scritto:

Hi

I have a bit of an update on this matter but still cannot solve it.
Basically I need to split my line strings from Mapinfo before inserting into
PostGIS. If I use ogr2ogr I always get a "violates check constraint" error
when inserting the polylines although when I use shp2pgsql I get no errors
but obviously poorly formatted entries. I think some are linestrings and some multiline strings maybe. has anyone else had these problems when importing from Mapinfo to PostGIS

Never tried to do so, but anyways, can you provide us with the shapefile
you're trying to import, I would like to test it against my geoserver and postgis install and see if I can reproduce and fix the issue.

Cheers
Andrea Aime

phatbloke@anonymised.com ha scritto:

Hi

Thanks for your help. Please find attached a zip of the polylines I am having troubles with. The shape files are generated from a Mapinfo TAB using the universal translator. I am also having problems with the polygons but hopefully it might be the same problem.
I have been importing these with shp2pgsql provided with postgis.

Ah, some more feedback on your issue. I've confirmed there was an error
during bbox computation, and fixed it, so now bbox computation is ok,
but unfortunately broken data is still there, and it will make:
* wms map building very slow because of exception logging
* wfs operations not working at all.

The following query:

select astext(the_geom), NumGeometries(the_geom), NumPoints(the_geom)
from errpoly where NumGeometries(the_geom) = 2 and NumPoints(the_geom) = 1

extracts some (but not all) of the broken data... as you can see, there
are quite a bit of multilinestrings that have a single point inside.
According to the OGC simple feature specification, this is incorrect.

I guess you could write a script that cleans the data once in postgis,
but you would have to do it parsing geometries as wkt text (hint,
split strings on (), and then throw away coordinate sets that do not
contain a , since these are made of single points)...

Cheers
Andrea Aime