Le 04/01/2012 14:27, Andrea Aime a écrit :
On Wed, Jan 4, 2012 at 11:43 AM, Emmanuel Blondel
<[email protected]> wrote:
Dear all,
I am facing an issue with geometry validation.
I have a PostGIS table for which I tested geometry validity with GEOS
st_isValid(), all geometries are valid. I published this PostGIS table in
Geoserver and I use this layer in a model based on Geotools/JTS, retrieving
the features using WFS Datastore plugin.
- I retrieved the features from WFSDatastore, and before applying any
geo-process, I set a control of geometry validity using the JTS method
isValid(). According to JTS, some geometries are not valid, while they are
valid according to GEOS st_isValid() in PostGIS. I tried to focus on the
issue, and tested one geometry using WKT:
String wkt = "MULTIPOLYGON(((-4931658.38628938
5608697.43804972,-4931658.38629031 5608697.43804656,-4931658.38628939
5608697.43804972,-4931658.38628938 5608697.43804972)),((-4947166.38166375
5555710.74141808,-4947166.38166466 5555710.74141493,-4947166.38166467
5555710.74141491,-4947166.38166467 5555710.74141491,-4947166.38166375
5555710.74141808)))";
GeometryFactory geometryFactory = JTSFactoryFinder.getGeometryFactory( null
);
WKTReader reader = new WKTReader( geometryFactory );
Geometry geom = reader.read(wkt);
System.out.println(geom.isValid());
Getting a geometry from WKT, I can see that both GEOS and JTS return true,
so it seems the issue is related to GeoTools WFSdatastore.
- Hereafter the wkt string of the geometry retrieved from WFS, which indeed
is a bit different.
MULTIPOLYGON (((-4931658.38628938 5608697.43804972, -4931658.38629031
5608697.43804656, -4931658.38628938 5608697.43804972, -4931658.38628938
5608697.43804972)), ((-4947166.38166374 5555710.74141808, -4947166.38166466
5555710.74141493, -4947166.38166467 5555710.74141491, -4947166.38166467
5555710.74141491, -4947166.38166374 5555710.74141808)))
This small difference makes the geometry invalid.
I know that to make valid a geometry, I can apply a buffer, but I would like
to avoid this and know if such issue could be solved in WFSdatastore, so to
ensure that the geometry retrieved from WFS is exactly the same as in the
initial geometry in PostGIS.
==================
Here the versions I am using:
- select postgis_full_version(): "POSTGIS="1.5.3" GEOS="3.3.1-CAPI-1.7.1"
PROJ="Rel. 4.6.1, 21 August 2008" LIBXML="2.7.8" USE_STATS"
- Geoserver 2.1.3
- Geotools library / WFS datastore plugin - version 8.0-M4
I'm wondering where the loss of procision is happening. There could be several
places:
- as the geometry is read from the database in wkb form
- as the geometry is turned into GML
- as the gml is read by the wfs datastore
Did you try manually checking the GML produced by GeoServer?
Also, have you tried changing the number of decimals generated by
Geoserver? It's part of the global settings, equal to 8 by default
Cheers
Andrea
Hello Andea,
I checked the GML (GML2 output format) produced by Geoserver (see attached):
- the one with the default number of decimals (8): coordinates are the
same as the one retrieved using WFS datastore, so we can eliminate the
third place you mentioned.
- the one after setting 9 decimals in the global settings.
Emmanuel
<?xml version="1.0" encoding="UTF-8"?>
<wfs:FeatureCollection xmlns="http://www.opengis.net/wfs"; xmlns:wfs="http://www.opengis.net/wfs"; xmlns:repo="http://opengeo.org/repo"; xmlns:gml="http://www.opengis.net/gml"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://www.opengis.net/wfs http://localhost:8080/geoserver/schemas/wfs/1.0.0/WFS-basic.xsd http://opengeo.org/repo http://localhost:8080/geoserver/wfs?service=WFS&version=1.0.0&request=DescribeFeatureType&typeName=repo%3At_statarea_csquare05_hseez";>
<gml:boundedBy>
<gml:null>unknown</gml:null>
</gml:boundedBy>
<gml:featureMember>
<repo:t_statarea_csquare05_hseez fid="t_statarea_csquare05_hseez.fid--62d25b6f_134a8bb9da0_-14bf">
<repo:the_geom>
<gml:MultiPolygon srsName="http://www.opengis.net/gml/srs/epsg.xml#54012";>
<gml:polygonMember>
<gml:Polygon>
<gml:outerBoundaryIs>
<gml:LinearRing>
<gml:coordinates xmlns:gml="http://www.opengis.net/gml"; decimal="." cs="," ts=" ">
-4931658.38628938,5608697.43804972 -4931658.38629031,5608697.43804656 -4931658.38628938,5608697.43804972 -4931658.38628938,5608697.43804972</gml:coordinates>
</gml:LinearRing>
</gml:outerBoundaryIs>
</gml:Polygon>
</gml:polygonMember>
<gml:polygonMember>
<gml:Polygon>
<gml:outerBoundaryIs>
<gml:LinearRing>
<gml:coordinates xmlns:gml="http://www.opengis.net/gml"; decimal="." cs="," ts=" ">
-4947166.38166374,5555710.74141808 -4947166.38166466,5555710.74141493 -4947166.38166467,5555710.74141491 -4947166.38166467,5555710.74141491 -4947166.38166374,5555710.74141808</gml:coordinates>
</gml:LinearRing>
</gml:outerBoundaryIs>
</gml:Polygon>
</gml:polygonMember>
</gml:MultiPolygon>
</repo:the_geom>
<repo:geocode_1>21.4.W</repo:geocode_1>
<repo:geocode_2>7405:459:2</repo:geocode_2>
<repo:geocode_3>218</repo:geocode_3>
<repo:inter_area>0.001953125</repo:inter_area>
<repo:fa_prob>1.0</repo:fa_prob>
</repo:t_statarea_csquare05_hseez>
</gml:featureMember>
</wfs:FeatureCollection>
<?xml version="1.0" encoding="UTF-8"?>
<wfs:FeatureCollection xmlns="http://www.opengis.net/wfs"; xmlns:wfs="http://www.opengis.net/wfs"; xmlns:repo="http://opengeo.org/repo"; xmlns:gml="http://www.opengis.net/gml"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://www.opengis.net/wfs http://localhost:8080/geoserver/schemas/wfs/1.0.0/WFS-basic.xsd http://opengeo.org/repo http://localhost:8080/geoserver/wfs?service=WFS&version=1.0.0&request=DescribeFeatureType&typeName=repo%3At_statarea_csquare05_hseez";>
<gml:boundedBy>
<gml:null>unknown</gml:null>
</gml:boundedBy>
<gml:featureMember>
<repo:t_statarea_csquare05_hseez fid="t_statarea_csquare05_hseez.fid--62d25b6f_134a8bb9da0_-14c0">
<repo:the_geom>
<gml:MultiPolygon srsName="http://www.opengis.net/gml/srs/epsg.xml#54012";>
<gml:polygonMember>
<gml:Polygon>
<gml:outerBoundaryIs>
<gml:LinearRing>
<gml:coordinates xmlns:gml="http://www.opengis.net/gml"; decimal="." cs="," ts=" ">
-4931658.386289378,5608697.438049718 -4931658.38629031,5608697.438046556 -4931658.386289384,5608697.438049718 -4931658.386289378,5608697.438049718</gml:coordinates>
</gml:LinearRing>
</gml:outerBoundaryIs>
</gml:Polygon>
</gml:polygonMember>
<gml:polygonMember>
<gml:Polygon>
<gml:outerBoundaryIs>
<gml:LinearRing>
<gml:coordinates xmlns:gml="http://www.opengis.net/gml"; decimal="." cs="," ts=" ">
-4947166.381663744,5555710.74141808 -4947166.38166466,5555710.741414928 -4947166.381664664,5555710.741414912 -4947166.381664672,5555710.741414912 -4947166.381663744,5555710.74141808</gml:coordinates>
</gml:LinearRing>
</gml:outerBoundaryIs>
</gml:Polygon>
</gml:polygonMember>
</gml:MultiPolygon>
</repo:the_geom>
<repo:geocode_1>21.4.W</repo:geocode_1>
<repo:geocode_2>7405:459:2</repo:geocode_2>
<repo:geocode_3>218</repo:geocode_3>
<repo:inter_area>0.001953125</repo:inter_area>
<repo:fa_prob>1.0</repo:fa_prob>
</repo:t_statarea_csquare05_hseez>
</gml:featureMember>
</wfs:FeatureCollection>
------------------------------------------------------------------------------
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual
desktops for less than the cost of PCs and save 60% on VDI infrastructure
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
_______________________________________________
Geotools-gt2-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
