Hi,
I'm currently working on Geoserver/Geotools source code to make them handle
organization specific SRS definition. I have few general questions regarding
the way Geoserver/Geotools handle SRS.
In Geoserver if I choose the "Leave declared SRS" option it means :
* Geoserver will look in an internal geotools database/module for a SRS
matching the one declared in the PostGis database
* Geoserver will reproject BBOX using this SRS definition
Right ?
However when Geoserver launches a spatial query to the PostGis database
using Geotools i'm well under the impression that the source SRS for
features reprojection will actually be the one defined in the PostGis
database. (By using feature.content the database schema will be gathered and
hence the PostGis SRS definition). As a result it seems the bursawolf for
the reprojection are missing ...
Generally speaking, shouldnt the declared SRS be the one used for
reprojection features ?
Thanx in advance
Manu
--
View this message in context: http://www.nabble.com/declared-SRS---Postgis-SRS-WKT-tp18867264p18867264.html
Sent from the GeoServer - User mailing list archive at Nabble.com.
Emmanuel Séguin ha scritto:
Hi,
I'm currently working on Geoserver/Geotools source code to make them handle
organization specific SRS definition. I have few general questions regarding
the way Geoserver/Geotools handle SRS.
In Geoserver if I choose the "Leave declared SRS" option it means :
* Geoserver will look in an internal geotools database/module for a SRS
matching the one declared in the PostGis database
* Geoserver will reproject BBOX using this SRS definition
Right ?
Nope. With leave the declared SRS is used only for the capabilities
documents, but the native one will be used for everything else.
What you're explaining above is "reproject".
However when Geoserver launches a spatial query to the PostGis database
using Geotools i'm well under the impression that the source SRS for
features reprojection will actually be the one defined in the PostGis
database. (By using feature.content the database schema will be gathered and
hence the PostGis SRS definition). As a result it seems the bursawolf for
the reprojection are missing ...
Generally speaking, shouldnt the declared SRS be the one used for
reprojection features ?
If you do any query against Postgis in an SRS other than the one
embedded in the geometries an exception will be thrown.
The filters are reprojected in memory before hitting the datastore
if my memory serves me right, but I'm not sure which SRS is used
as the target, it should be native one if you're using "leave",
if you want to impose your own, you should use "force"
Hope this helps
Cheers
Andrea
Andrea Aime-4 wrote:
Emmanuel Séguin ha scritto:
Hi,
I'm currently working on Geoserver/Geotools source code to make them
handle
organization specific SRS definition. I have few general questions
regarding
the way Geoserver/Geotools handle SRS.
In Geoserver if I choose the "Leave declared SRS" option it means :
* Geoserver will look in an internal geotools database/module for a SRS
matching the one declared in the PostGis database
* Geoserver will reproject BBOX using this SRS definition
Right ?
Nope. With leave the declared SRS is used only for the capabilities
documents, but the native one will be used for everything else.
What you're explaining above is "reproject".
Oooops i'm sorry i meant "Force declared SRS" option 
Yeah and reprojection is an approximative english translation for a french
word => I think it should be "transform". What I meant by "reproject" was
to transform the bbox coordinates in an other system that its own.
So if leave the "force declared srs" i'm under the impression that the
target SRS for the BBOX transformation (projection change) will be the one
declared into Geoserver database/module and not the one in the postgis
database.
However when Geoserver launches a spatial query to the PostGis database
using Geotools i'm well under the impression that the source SRS for
features reprojection will actually be the one defined in the PostGis
database. (By using feature.content the database schema will be gathered
and
hence the PostGis SRS definition). As a result it seems the bursawolf for
the reprojection are missing ...
Generally speaking, shouldnt the declared SRS be the one used for
reprojection features ?
If you do any query against Postgis in an SRS other than the one
embedded in the geometries an exception will be thrown.
The filters are reprojected in memory before hitting the datastore
if my memory serves me right, but I'm not sure which SRS is used
as the target, it should be native one if you're using "leave",
if you want to impose your own, you should use "force"
Allright i try again
Let's say i've changed the EPSG system definitions in the Geoserver
internal database.
As an example why not consider i've changed the EPSG:2154 false_easting
parameter in the Geoserver internal database. Let's say now i've got a
table in my a postgis with a geometry column in EPSG:2154, wich is defined
in the spatial_ref_sys table with the unchanged false_easting parameter.
When i load the feature in Geoserver, i got my declared SRS with the
modified parameter and native SRS with the unmodified one. So i choose the
"Force declared SRS" option
Now that everything is loaded i try and get a wmsc tile with a BBOX in
EPSG:27572. The BBOX is transformed properly using my declared SRS
(false_easting modified). Using the transformed BBOX now in EPSG:2154 the
database table is queried and a resultset obtained.
My problem is that it seems that each feature in the resultset got in its
content attribute the native schema of the postgis database and hence the
EPSG:2154 definition with the unmodified false_easting parameter.
I'm just wondering if that's the usual behaviour of Geoserver.
Thanx for your time
Manu
Hope this helps
Cheers
Andrea
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's
challenge
Build the coolest Linux based applications with Moblin SDK & win great
prizes
Grand prize is a trip for two to an Open Source event anywhere in the
world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
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/declared-SRS---Postgis-SRS-WKT-tp18867264p18868213.html
Sent from the GeoServer - User mailing list archive at Nabble.com.
Emmanuel Séguin ha scritto:
...snip...
Nope. With leave the declared SRS is used only for the capabilities
documents, but the native one will be used for everything else.
What you're explaining above is "reproject".
Oooops i'm sorry i meant "Force declared SRS" option
Yeah and reprojection is an approximative english translation for a french
word => I think it should be "transform". What I meant by "reproject" was
to transform the bbox coordinates in an other system that its own.
We use the term reproject as well.
So if leave the "force declared srs" i'm under the impression that the
target SRS for the BBOX transformation (projection change) will be the one
declared into Geoserver database/module and not the one in the postgis
database.
It should be, yes. The transformation will occur in memory before the
datastore is even reached.
If you use "leave" instead, the transformation should occur using
the postgis declared wkt.
Allright i try again
Let's say i've changed the EPSG system definitions in the Geoserver
internal database. As an example why not consider i've changed the EPSG:2154 false_easting
parameter in the Geoserver internal database. Let's say now i've got a
table in my a postgis with a geometry column in EPSG:2154, wich is defined
in the spatial_ref_sys table with the unchanged false_easting parameter.
When i load the feature in Geoserver, i got my declared SRS with the
modified parameter and native SRS with the unmodified one. So i choose the
"Force declared SRS" option
Now that everything is loaded i try and get a wmsc tile with a BBOX in
EPSG:27572. The BBOX is transformed properly using my declared SRS
(false_easting modified). Using the transformed BBOX now in EPSG:2154 the
database table is queried and a resultset obtained.
My problem is that it seems that each feature in the resultset got in its
content attribute the native schema of the postgis database and hence the
EPSG:2154 definition with the unmodified false_easting parameter.
Mumble, this should not be happening unless there is a problem
with the force coordinate reader. Doh, actually there is, I've fixed this issue some days ago in GeoTools:
http://jira.codehaus.org/browse/GEOT-1938
But afaik the issue was happening only on the 1.7.x branch.
Which version of GeoServer are you using?
Cheers
Andrea