[Geoserver-users] The way we use GeoServer

GeoServer GeoServer User
1

Hi,

I write you this email as a member of Alcer.
The project we are working on uses GeoServer and is now in its validation period.
The client is a french national institution and the server will be available over the Internet.
So we think that it is a good moment to make a report on how we use GeoServer.

The base version of GeoServer is 1.4, the data are stored in Oracle Locator 10g (SDO_GEOMETRY)
and the outputs produced by GeoServer are in PNG and PDF.

Our goal is to give you back all the modifications, corrections or evolutions we realized.
We would like to see those contribution integrated as much as possible on the Géoserver trunk in a next release, of course, if they are accepted by the community.

Sooner we have created some bug reports but, by now, we are not sure that it will be the easiest way
to provide you what we have made. So all your propositions will be welcome on the best way to do that!

The modifications made on the code are listed below (in a list of what we think reusable
and in a list of what we think specific).

Reusable modifications :
1 - correction for a multi-threading problem in the ConnectionPool (see GEOT-1003)
2 - add the DB schema names in the SQLEncoder (see GEOT-1005)
3 - add the management of a J2EE/JNDI connection pool (see GEOT-489 and GEOS-778)
4 - correction of a possible JDBC connection loss in StreamingRenderer (see GEOT-1004)
5 - add the encoding of MultiPoints in Oracle/SQL (gtype=2005)
6 - add the management of a ‘getScale’ function in the SLD
7 - detection of a loss of performance : because of some ‘complex SLD’ there are some layers are rendered with no geometries (ie : the geometry column does not appear in the SQL query so there is no rendering and the query loads the whole table !). Those cases are detected in StreamingRenderer and the processing is skipped.
8 - correction of a drawing bug on PDF rendering : in PDF, a line with a depth less than 1 can be rendered.
9 - SVG rendering improvement for rasteur outputs
10 - correction of a memory retention problem in FeatureListenerManager
11 - add the possibility to change the output resolution with PDF outputs
12 - add an 8 bit palette management with PNG outputs
13 - add the management of a global rotation of the output (tested on both PNG and PDF)

Specific modifications :
14 - add the drawing of a geographic grid on the PDF outputs
15 - add the management of specific raster data
16 - add the management of a specific “easy-to-read” XML format for the WFS answers
17 - add the management of some specific WMS key-value pairs to produce the PDF outputs
18 - add a workaround to prevent some string values like ‘6E490’ to be parsed as Double in WMS queries with filters
19 - add a specific log level for the project
20 - add a workaround to prevent the encoding of some SQL queries with empty columns

As a conclusion, working with GeoServer is a good experience. We are very impressed by the amount
of job done by the community and we hope that our contribution will help.

Best regards,

Raphaël Gaquer
IT engineer
http://www.alcer.com

2

Alcer (Raphael Gaquer) ha scritto:

Hi,

I write you this email as a member of Alcer.
The project we are working on uses GeoServer and is now in its validation period.
The client is a french national institution and the server will be available over the Internet.
So we think that it is a good moment to make a report on how we use GeoServer.

The base version of GeoServer is 1.4, the data are stored in Oracle Locator 10g (SDO_GEOMETRY)
and the outputs produced by GeoServer are in PNG and PDF.

Our goal is to give you back all the modifications, corrections or evolutions we realized.
We would like to see those contribution integrated as much as possible on the Géoserver trunk in a next release, of course, if they are accepted by the community.

Raphael, this is really great :slight_smile:

Sooner we have created some bug reports but, by now, we are not sure that it will be the easiest way
to provide you what we have made. So all your propositions will be welcome on the best way to do that!

Single patches would be useful (svn diff, separate for each fix).

The modifications made on the code are listed below (in a list of what we think reusable
and in a list of what we think specific).

Reusable modifications :
1 - correction for a multi-threading problem in the ConnectionPool (see GEOT-1003)

Sigh, never seen 1003, and I already fixed it with GEOT-1271 (on 2.3.x and trunk, but not on 2.2.x).
Unfortunately, there are two problems here:
* Geoserver 1.4 is dead, no more releases will be issued out of it,
   and so is Geotools 2.2.x. If you want patches to be accepted,
   you need to open them against trunk or 2.3.x
* James McGill is no longer a contributor, so nobody ever noticed
   your patches (I'm sending a mail on gt2 so that we remove non
   active contributors as default targets).
So long story short, all your patches have been totally ignored :frowning:
I'm reassigning the ones I haven't already fixed to me, but I won't
be able to fix them only on Geoserver 1.5.x onwards.

On trunk I should land the new connection pooling subsystem tomorrow, which will be a complete overhaul and will provide the ability to use various connection pool providers.
See:
http://geotools.codehaus.org/Connection+pool+subsystem+upgrade

2 - add the DB schema names in the SQLEncoder (see GEOT-1005)

Nice

3 - add the management of a J2EE/JNDI connection pool (see GEOT-489 and GEOS-778)

Covered by the connection pooling upgrade

4 - correction of a possible JDBC connection loss in StreamingRenderer (see GEOT-1004)

Nice

5 - add the encoding of MultiPoints in Oracle/SQL (gtype=2005)
6 - add the management of a 'getScale' function in the SLD
7 - detection of a loss of performance : because of some 'complex SLD' there are some layers are rendered with no geometries (ie : the geometry column does not appear in the SQL query so there is no rendering and the query loads the whole table !). Those cases are detected in StreamingRenderer and the processing is skipped.

How can you render something without the geometries?

8 - correction of a drawing bug on PDF rendering : in PDF, a line with a depth less than 1 can be rendered.
9 - SVG rendering improvement for rasteur outputs
10 - correction of a memory retention problem in FeatureListenerManager
11 - add the possibility to change the output resolution with PDF outputs
12 - add an 8 bit palette management with PNG outputs

Already done in Geoserver 1.5.1 and we have newer patches on 1.5.x
to handle optimal palette computation as well. But I'd like to see your
solution as well.

13 - add the management of a global rotation of the output (tested on both PNG and PDF)

Specific modifications :
14 - add the drawing of a geographic grid on the PDF outputs
15 - add the management of specific raster data
16 - add the management of a specific "easy-to-read" XML format for the WFS answers
17 - add the management of some specific WMS key-value pairs to produce the PDF outputs
18 - add a workaround to prevent some string values like '6E490' to be parsed as Double in WMS queries with filters
19 - add a specific log level for the project
20 - add a workaround to prevent the encoding of some SQL queries with empty columns

Good stuff. What we need to handle this, is that you open an issue for
each one of these changes, with a patch attached.

As a conclusion, working with GeoServer is a good experience. We are very impressed by the amount
of job done by the community and we hope that our contribution will help.

Many thanks for all this work, and we're glad GeoServer worked for you.
In the future, a better way to handle this kind of patches would be to
have them reported into jira issues promptly, and report them as Geoserve issues, even if they are gt2 ones, because that increases a lot
the likeliness those will be addressed. If the issue turns out to be
a gt2 one, we'll open another issue agaist gt2, and link the two (so
that we have good tracking).

Cheers
Andrea

3

Good stuff.

We especially need more Oracle users with your attitude!

Am curious too about the no-geometry stuff. FYI I created a special datastore "geometryless" to handle the cases of no geometry, and X,Y or Lat/Lon columns, which are very common in real business data. Let me know if there are specific cases you have, I'm looking to move the module into supported land and someone to review documentation on configuration.

2 - add the DB schema names in the SQLEncoder (see GEOT-1005)
    
Nice

I didnt see this either - because it wasnt against the jdbc module...

i created a duplicate with a patch at GEOT-1228