[Geoserver-devel] bbox reprojection

GeoServer GeoServer Developer
1

Is reprojection fully supported in GeoServer 1.5.3?

I have a problem to understand how to retrieve coordinate systems information inside a DataStore I'm currently developing.
For example, I have a WMS request containing a BoundingBox similar to this:
   <BoundingBox srsName="http://www.opengis.net/gml/srs/epsg.xml#26592&quot;&gt;
        <gml:coord>
            <gml:X>2323959.032931422</gml:X>
            <gml:Y>4857652.7863893</gml:Y>
        </gml:coord>
        <gml:coord>
            <gml:X>2324107.6488483767</gml:X>
            <gml:Y>4857713.686043279</gml:Y>
        </gml:coord>
    </BoundingBox>

My data is stored in EPSG:23032. To apply the bbox filter to the data I'd need to reproject the bbox from EPSG:26592 to EPSG:23032, but, due to my poor knowledge of GeoTools/GeoServer architecture, I'm not able to figure out how my datastore can retrieve the bbox EPSG (in the example EPSG:26592).

Is this possible? Can someone give me any suggestion on this subject?

Thanks,
Mauro Bartolomeoli

2

Hi Mauro,

Yes reprojection is fully supported in 1.5.3 given that the epsg codes
you are using are "known" to GeoServer.

As for where to find the information about which coordinate system is
being requested, this should be available on the org.geotools.data.Query
interface. See Query#getCoordinateSystem().

However this is a bit of a problem in GeoServer / Geotools because 1.
Its not always set properly by GEoServer, and 2. Its not always
respected by the datastores.

Its kind of a chicken and the egg problem. Some of the datastores in
geotools are of poorer quality and less maintained then others. This
means that GeoServer cannot realistically rely on the datastore to do
the reprojection. So GeoServer takes the stance of doing all the
projection itself... and usually just queries the datastore for data in
its native crs.

Or at least this is what I understand. Those more familiar with the
rendering subsystem (like Andrea) can probably give you a more
definitive answer.

-Justin

Mauro Bartolomeoli wrote:

Is reprojection fully supported in GeoServer 1.5.3?

I have a problem to understand how to retrieve coordinate systems
information inside a DataStore I'm currently developing.
For example, I have a WMS request containing a BoundingBox similar to this:
   <BoundingBox srsName="http://www.opengis.net/gml/srs/epsg.xml#26592&quot;&gt;
        <gml:coord>
            <gml:X>2323959.032931422</gml:X>
            <gml:Y>4857652.7863893</gml:Y>
        </gml:coord>
        <gml:coord>
            <gml:X>2324107.6488483767</gml:X>
            <gml:Y>4857713.686043279</gml:Y>
        </gml:coord>
    </BoundingBox>

My data is stored in EPSG:23032. To apply the bbox filter to the data
I'd need to reproject the bbox from EPSG:26592 to EPSG:23032, but, due
to my poor knowledge of GeoTools/GeoServer architecture, I'm not able to
figure out how my datastore can retrieve the bbox EPSG (in the example
EPSG:26592).

Is this possible? Can someone give me any suggestion on this subject?

Thanks,
Mauro Bartolomeoli

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

!DSPAM:4007,46cf0cd3173972090977483!

--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org

3

Justin Deoliveira wrote:

Its kind of a chicken and the egg problem. Some of the datastores in
geotools are of poorer quality and less maintained then others. This
means that GeoServer cannot realistically rely on the datastore to do
the reprojection. So GeoServer takes the stance of doing all the
projection itself... and usually just queries the datastore for data in
its native crs.
  

The renderer seems to have sanity checks built in; it asks the the data in the correct projection (using Query). And then it checks the answer; if the answer is not in the requested CoordinateReferenceSystem it wraps it up in a ReprojectingFeatureCollection before use.

I really better make some conformance tests; right now all the DataStores could be "working" and we still would not know.

Jody

4

I really better make some conformance tests; right now all the
DataStores could be "working" and we still would not know.

Agreed. Without some sort of conformance test GeoServer is forced to
dodge the api and do its own reprojection.

Jody

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

!DSPAM:4007,46cf201d201355219720167!

--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org

5

Justin Deoliveira ha scritto:

Hi Mauro,

Yes reprojection is fully supported in 1.5.3 given that the epsg codes
you are using are "known" to GeoServer.

As for where to find the information about which coordinate system is
being requested, this should be available on the org.geotools.data.Query
interface. See Query#getCoordinateSystem().

However this is a bit of a problem in GeoServer / Geotools because 1.
Its not always set properly by GEoServer, and 2. Its not always
respected by the datastores.

Its kind of a chicken and the egg problem. Some of the datastores in
geotools are of poorer quality and less maintained then others. This
means that GeoServer cannot realistically rely on the datastore to do
the reprojection. So GeoServer takes the stance of doing all the
projection itself... and usually just queries the datastore for data in
its native crs.

Or at least this is what I understand. Those more familiar with the
rendering subsystem (like Andrea) can probably give you a more
definitive answer.

Hmm... I'll need to double check this, but I fear the CRS information
attached to a bbox is lost in the filter parsing code, and I don't
remember any code in GeoServer that morphs filters so that geometries
and bboxes used for reference are turned into the native datastore
CRS.

So, my hunch is that the bboxes will get thru as plain geometries
with no CRS information, and no trasformation will be done on the
query side, but I may be wrong.
In any case, again I think there is no datastore capable of dealing
with queries whose reference geometries are expressed in a CRS
other than the featuretype native one, so the cure would be to
implement a visitor that takes the original filter with geometric
predicates and turns them into the data native CRS, if any is
available. Before that of course the filter parsers would have
to be fixed to add the CRS information somewhere in the filter
themselves.

Cheers
Andrea

6

Andrea Aime wrote:

Justin Deoliveira ha scritto:

Hi Mauro,

Yes reprojection is fully supported in 1.5.3 given that the epsg codes
you are using are "known" to GeoServer.

As for where to find the information about which coordinate system is
being requested, this should be available on the org.geotools.data.Query
interface. See Query#getCoordinateSystem().

However this is a bit of a problem in GeoServer / Geotools because 1.
Its not always set properly by GEoServer, and 2. Its not always
respected by the datastores.

Its kind of a chicken and the egg problem. Some of the datastores in
geotools are of poorer quality and less maintained then others. This
means that GeoServer cannot realistically rely on the datastore to do
the reprojection. So GeoServer takes the stance of doing all the
projection itself... and usually just queries the datastore for data in
its native crs.

Or at least this is what I understand. Those more familiar with the
rendering subsystem (like Andrea) can probably give you a more
definitive answer.

Hmm... I'll need to double check this, but I fear the CRS information
attached to a bbox is lost in the filter parsing code, and I don't
remember any code in GeoServer that morphs filters so that geometries
and bboxes used for reference are turned into the native datastore
CRS.

Hmm.... this is what I fear too.

In any case, again I think there is no datastore capable of dealing
with queries whose reference geometries are expressed in a CRS
other than the featuretype native one,

If this is the situation... maybe it's not a terrible fault if my datastore doesn't support it too.

so the cure would be to
implement a visitor that takes the original filter with geometric
predicates and turns them into the data native CRS, if any is
available. Before that of course the filter parsers would have
to be fixed to add the CRS information somewhere in the filter
themselves.

Do you think this could be done in a near future?
My users are requesting the capability to have data in several coordinate systems and show them in a single map.
I'd like to "promise" them that sometimes in the next months we can add this feature to GeoServer.

Thanks,
Mauro

7

Mauro Bartolomeoli ha scritto:
...

so the cure would be to
implement a visitor that takes the original filter with geometric
predicates and turns them into the data native CRS, if any is
available. Before that of course the filter parsers would have
to be fixed to add the CRS information somewhere in the filter
themselves.

Do you think this could be done in a near future?
My users are requesting the capability to have data in several coordinate systems and show them in a single map.
I'd like to "promise" them that sometimes in the next months we can add this feature to GeoServer.

This you already have, the streaming renderer back projects the map
envelope in whatever native CRS each feature source is before doing
the query.
What I was referring to was the ability to do the same with WFS filter
queries, which is more complex because geometry filtering predicates
can be anywhere in the filter tree (and besides, the filter parser has
to be patched as well). I don't know if we'll have
the time to work on this one, but if you want to do it yourself we
can try to assist you in the coding (drop on the IRC channel, we hang there).
Cheers
Andrea

8

Andrea Aime wrote:

Mauro Bartolomeoli ha scritto:
...

so the cure would be to
implement a visitor that takes the original filter with geometric
predicates and turns them into the data native CRS, if any is
available. Before that of course the filter parsers would have
to be fixed to add the CRS information somewhere in the filter
themselves.

Do you think this could be done in a near future?
My users are requesting the capability to have data in several coordinate systems and show them in a single map.
I'd like to "promise" them that sometimes in the next months we can add this feature to GeoServer.

This you already have, the streaming renderer back projects the map
envelope in whatever native CRS each feature source is before doing
the query.

Ok, perfect, I'm going to do a little more testing on WMS, then. If I'd need WFS too, I'll be back.

Thanks,
Mauro