GeoServer 1.5.0-beta2 released

We have released our second beta version of GeoServer 1.5.0. It contains many bug fixes and improvements. You can find the download here. Another useful feature it has is the ability to add coverages outside of your data directory.

Our next round of releases before the official 1.5.0 release are going to contain several larger changes that should clean up the UI and also introduce a suite of useful coverage tools, such as a Pyramid Builder and an Image Mosaic tool. This beta release will help us figure out what users want and need for the official release. So please try it out and give us lots of feedback either on our mailing list or on this blog.


  1. David Haskiya
    Posted January 31, 2007 at 10:26 am | Permalink

    Any plans to include cascading WMS in the 1.5 release?

  2. Jesse
    Posted January 31, 2007 at 3:47 pm | Permalink

    I have downloaded and begun testing the beta2 version of GeoServer 1.5.0 and had a question regarding the WFS output of the sample data (typename=topp:tasmania_roads).
    Although the srsName attribute indicates the data is using EPSG:4326, the actual data for the LineStrings are ordered longitude first and then latitude second for each point in the gml:coordinates tag.
    However, the database provided by states that the order for EPSG:4326 should be latitude and then longitude. Also, the examples shown at (using GML 3.1.1) indicate an ordering specifically of latitude and then longitude in that order when using the common WGS84 or “EPSG:4326” reference system.

    When trying to parse arbitrary GML (version 2 or 3) with an srsName of “EPSG:4326” how is it possible to know if the first coordinate is latitude or longitude? It seems as though the output by GeoServer from the WFS does not match what the expected output should be. I have not been able to find more information about this on the GeoServer site and wondered if this issue has been resolved elsewhere.

  3. Posted January 31, 2007 at 5:22 pm | Permalink

    No plans for cascading WMS, at least not for 1.5. But possibly in the future. If it is something that people would like to have, bring it up on our mailing list and start some discussion. People will gladly join in.

  4. Posted January 31, 2007 at 5:34 pm | Permalink

    Hi Jesse,
    The issue is that most services that use or produce WGS84 data flip the axes to match X and Y. It has been brought up in the past to maybe follow the “standard”, but in practice no one else does and it would cause more problems if we switched. It is a valid concern though and hopefully some day this issue can get sorted out.

  5. Jesse
    Posted January 31, 2007 at 6:10 pm | Permalink

    Thanks for the quick response Brent. It seems as though most products that implement WFS do indeed output GML with longitude first and latitude second as you mention. However, the convention for GeoRSS seems to be latitude first and then longitude second for those examples that use the “GML” version of GeoRSS. This makes it difficult to parse a gml:Point because there is no programmatic way to know which axis should come first when using EPSG:4326. It seems as though the most useful solution from someone wanting to use a WFS would be to have the GML include one EPSG code to indicate lon/lot ordering and have another EPSG code to indicate lat/lon ordering. A quick google search came up with a link to a web page that suggested such a code did exist but I have not seen many references to this code:–Geotools-devel–Re:-Blocking-Issue-affecting-CRS,-features-and-streaming-renderer.-p4477021.html
    Do you know if there is any effort from the OGC/EPSG community or from GeoServer to use two separate codes that differentiate the axis ordering so that those who wish to ingest GML can do so in an effective way?

Download GeoServer