GeoServer Blog

GeoServer 3 Call for Crowdfunding

GeoServer is at a critical turning point and it needs your help to continue its journey as the leading free and open-source platform for geospatial data. With GeoServer 3 we are transforming the way you interact with geospatial data—making it faster, more intuitive, and more secure.

This major upgrade, led by Camptocamp, GeoSolutions, and GeoCat, will deliver:

  • Future-Proof Performance: A modernized core for compatibility with the latest data management and deployment technologies.

  • Enhanced Image Processing: Faster, smoother handling of spatial imagery and larger datasets.

  • Improved Security and Compliance: Meet regulatory standards and protect your data with the latest security enhancements.

  • Streamlined User Experience: Easier navigation, integrating new services, and empowering users at all levels.

The scope of this work is beyond routine updates or maintenance since the transition to GeoServer 3 requires extensive redevelopment of core systems as well as implementing modern security practices and also thorough testing and validation across all GeoServer extensions.

The consortium members - Camptocamp, GeoSolutions, and GeoCat- have a long-standing history of supporting and contributing to GeoServer and are fully committed to the success of this migration. However, this is a major effort that cannot be completed without community support.

By supporting this crowdfunding campaign, you are investing in the future of GeoServer and helping to sustain the innovative, open-source geospatial community.

Why GeoServer 3

As the digital landscape evolves, staying up-to-date with the latest technology is no longer optional — it’s essential. GeoServer 3 is being developed to address crucial challenges and ensure that GeoServer remains a reliable and secure platform for the future. Several key factors make this upgrade critical right now:

  • Regulatory Compliance: New regulations, including the CISA known exploited vulnerabilities list, demand that systems be fully patched to ensure operational readiness. Without the latest updates, GeoServer risks falling short of these standards, which is why migrating to Spring 6 is essential.

  • End of Support for Spring 5: By January 2025, Spring 5 will no longer receive security updates, leaving systems vulnerable. As GeoServer operates as middleware between web services and essential data layers, this upgrade to Spring 6 is crucial to maintaining secure connections and protecting data from potential breaches.

  • Security Enhancements: Upgrading to Spring 6 enables OAuth2 protocols for secure authentication, especially critical for large-scale or enterprise-level use. These advancements will help organizations meet evolving security requirements and protect sensitive geospatial data.

  • Switching to JDK 17: This upgrade also marks GeoServer’s transition to JDK 17, which brings improvements in performance, security, and long-term support. Keeping GeoServer aligned with the latest Java versions ensures compatibility with modern deployment technologies Tomcat 10 and Jakarta and future-proofs the platform.

  • Improved Image Processing: GeoServer 3 will replace the outdated Java Advanced Imaging (JAI) library with the more modern and flexible ImageN toolkit. This switch will significantly enhance image processing capabilities, enabling faster handling of large spatial datasets and improving Java compatibility.

  • Future-Proof Technology Stack: With the migration to Spring 6 and the shift to JDK 17, GeoServer 3 ensures long-term viability. Addressing the entire GeoServer stack, including enterprise components GeoFence and Cloud Native GeoServer, allows organizations to seamlessly adopt modern infrastructure and deployment models without compromising performance or security.

With this work, GeoServer is moving into a more secure, high-performing future—ready to tackle the evolving needs of the geospatial community. For more information on the work to be performed and its phases, please visit this document.

Crowdfunding structure

The crowdfunding will be structured in two phases to ensure success:

  1. Commitment Phase: Sponsors and community members will pledge their financial support during this phase, but no funds will be collected. The goal is to reach a predefined target that covers the full scope of work necessary for the migration.

  2. Funding Activation: Once the target is reached, the crowdfunding will be activated, and sponsors will be invoiced for their pledged amounts. This ensures there is enough financial backing to complete the migration without risking underfunding.

This structured approach ensures that GeoServer 3 is fully funded before any work begins, preventing the risk of an incomplete migration. This guarantees that the project will have the necessary resources to be completed in its entirety.

This structure forms a multi-party agreement:

  • Consortium: Three companies are forming a consortium (Camptocamp, GeoSolutions, and GeoCat) providing expertise, a proven track record, and capacity. These companies are also taking on responsibility for project management, estimating, and importantly risk.

  • Supporters: We are seeking organisations to pledge their support via funding during the commitment phase. No funds will be collected until we reach the target established below for the full scope of work necessary.

  • Community: We ask that our community step forward to match the contributions above with both financial contributions and in-kind development and testing.

Crowdfunding target

The financial target is ambitious, 550,000.00 €. CamptoCamp, GeoCat and GeoSolutions have generously stepped up and will provide 50,000.00€ each, which means the current funding goal starts at 400,000.00 €. Here below you will find the live updated situation as far as committed funding is concerned.

How to participate

If you are ready to support GeoServer 3, please, fill this online form or contact us at gs3-funding@googlegroups.com to express your interest and pledge your support.

Together, we can secure the future of GeoServer for years to come.

GeoServer 3 Crowdfunding

Read More

Using Value Comparison Operators in GeoServer Filters

GeoSpatial Techno is a startup focused on geospatial information that is providing e-learning courses to enhance the knowledge of geospatial information users, students, and other startups. The main approach of this startup is providing quality, valid specialized training in the field of geospatial information.

( YouTube | LinkedIn | Facebook | X )


Value Comparison Operators in GeoServer Filters

In this session, we want to talk about the various types of filters, with a particular focus on “Value comparison operators in GeoServer” comprehensively. If you want to access the complete tutorial, click on the link.

Introduction

Filtering allows the selection of features that satisfy a specific set of conditions. Filters can be used in several contexts in GeoServer:

  • In WMS requests, select which features should be displayed on a map
  • In WFS requests, specify the features to be returned
  • In SLD documents, apply different symbolizations to features on a thematic map

Note. This video was recorded on GeoServer 2.22.4, which is not the most up-to-date version. Currently, versions 2.24.x and 2.25.x are supported. To ensure you have the latest release, please visit this link and avoid using older versions of GeoServer.

Comparison operators

In GeoServer, the Web Feature Service (WFS) filtering utilizes a set of comparison operators to facilitate the querying of geospatial features. These operators allow users to create precise filters based on attribute values, enabling robust spatial queries. The main comparison operators available include: Binary comparison operators and Value comparison operators.

The value comparison operators are:

  • PropertyIsLike
  • PropertyIsNull
  • PropertyIsBetween

PropertyIsLike

The PropertyIsLike operator is used to compare a string property value with a text pattern. It includes the and elements to specify the property name and pattern respectively. The pattern can contain a sequence of regular characters and three special pattern characters.

These characters are defined by the attributes of the element:

  • WildCard: It specifies the pattern character that matches any sequence of zero or more string characters
  • SingleChar: It specifies the pattern character that matches any single string character
  • EscapeChar: It specifies the escape character which can be used to escape the pattern character

Geoserver supports the PropertyIsLike operator within filter expressions for querying spatial data. Here are some examples of how you can use this filter in an XML request to filter the States layer by the State_Name attribute:

  • Navigate to the Demos page, then select Demo requests.
  • From the Request section, select the WFS_getFeature1.0.xml request.
  • The address will be filled in automatically, in the URL section.

Use the following block codes to replace line 26:

<PropertyIsLike wildCard="*" singleChar="_" escapeChar="\">
  <PropertyName>STATE_NAME</PropertyName>
  <Literal>North*</Literal>
</PropertyIsLike>	
  • Now, we will explain some elements:
    • The first fifteen lines include explanations in the form of comments.
    • Line 16 describes the XML version and the GetFeature operation of the WFS service being used.
    • Line 17 specifies the default output format for the WFS service as “gml2.” Additionally, GeoServer supports several other commonly used formats such as “gml3, shapefile, geojson, and csv.”
    • Lines 18 to 23 define the start of the XML request and declare the namespaces used in the request.
    • Line 24 specifies the type name of the feature to be queried. In this case, it requests features of the “topp:states”.
    • Lines 25 to 30 define the filter criteria for the query. On these lines, we use the PropertyIsLike filter, to retrieve all states that start with the word North.
  • Press the Submit button to see the implemented changes.

  • Note. For GeoServer 2.25.2 the Demo Request page has been improved to show response Headers, and provide the option to pretty print XML output.

Now, we are looking for the States with four-letter names, where the letter o appears at both the beginning and the end. This requires using a singleChar as a different mode of the “LIKE” operator that you see on the screen:

<ogc:Filter>
  <PropertyIsLike wildCard="*" singleChar="_" escapeChar="\">
    <PropertyName>STATE_NAME</PropertyName>
    <Literal>O__o</Literal>
  </PropertyIsLike>
</ogc:Filter>

Press the Submit button to see the implemented changes. As you can see, a state called Ohio was found that meets the conditions in this example.

To show the escapeChar mode, modify the names ‘Montana’ and ‘Minnesota’ to Monta*na and Minnesota* in QGIS. This will allow you to filter out special characters, such as asterisks or underscores, that you have used. Now, use the codes displayed on the screen:

<ogc:Filter>
  <PropertyIsLike wildCard="*" singleChar="_" escapeChar="\">
    <PropertyName>STATE_NAME</PropertyName>
    <Literal>*ta\**</Literal>
  </PropertyIsLike>
</ogc:Filter>

Press the Submit button to see the implemented changes. Note that, If the escapeChar is not used, the correct result may not be visible in the output; because the underscore is a special character.

You have the flexibility to modify the wildCard, singleChar, and escapeChar attributes based on your requirements. This allows for a more proper filtering experience. So, feel free to customize them and make the most of your filtering capabilities!

PropertyIsNull

This operator, allows you to query for features where a specific property or attribute, has a null value. In other words, it is used to filter the features based on the absence of a value in a particular property. In this example, the query is looking for features in the topp:states layer, where the STATE_NAME attribute is null.

As an example of using this filter in a WFS getFeature request, use the following block codes to replace lines 26 to 29:

<PropertyIsNull>
  <PropertyName>STATE_NAME</PropertyName>
</PropertyIsNull>

Press the Submit button. As you can see, there is no value returned in the output as a null value.

PropertyIsBetween

The PropertyIsBetween operator is a helpful tool that allows you to determine whether a particular property of a feature, is within a defined range of values. As an example of using this operator, select the WFS_getFeatureBetween1.1.xml request from the Request section.

Now the filters block code is as follows:

<ogc:Filter>
  <ogc:PropertyIsBetween>
    <ogc:PropertyName>topp:LAND_KM</ogc:PropertyName>
    <ogc:LowerBoundary><ogc:Literal>100000</ogc:Literal></ogc:LowerBoundary>
    <ogc:UpperBoundary><ogc:Literal>150000</ogc:Literal></ogc:UpperBoundary>
  </ogc:PropertyIsBetween>
</ogc:Filter>

Press the Submit button.

Remember that PropertyIsBetween like other operators, is case-sensitive and the property name is specified as the first parameter to the operator. The minimum and maximum values of the range are specified as the second and third parameters, respectively.


In this session, we took a brief journey through the various types of filters, with a particular focus on “Value comparison operators in GeoServer”. If you want to access the complete tutorial, click on the link.

Read More

GeoServer 2.24.5 Release

GeoServer 2.24.5 release is now available with downloads (bin, war, windows), along with docs and extensions.

This is a maintenance release of GeoServer providing existing installations with minor updates and bug fixes. GeoServer 2.24.5 is made in conjunction with GeoTools 30.5, and GeoWebCache 1.24.5.

Thanks to Andrea Aime for making this release.

Release notes

Improvement:

  • GEOS-11336 security-keycloak: upgrade keycloak version
  • GEOS-11443 REST API does not take effect immediately due to 10 minute authentication cache
  • GEOS-11463 WMS vector dimension validation should query only one feature and only for dimension attribute
  • GEOS-11502 Permit resize on user/group/role palette textbox to allow for extra long role names

Bug:

  • GEOS-11446 [INSPIRE] Incorrect behavior for unsupported languages
  • GEOS-11453 Failure to look-up default value of custom dimensions on vector layers
  • GEOS-11462 500 error thrown when double adding a user to a group via REST with JDBC user/group services
  • GEOS-11484 DirectRasterRenderer is not respecting advancedProjectionHandling and continuosMapWrapping format_options
  • GEOS-11493 Azure blob store may not get environment parameters from property file

Task:

  • GEOS-11464 Update Jackson 2 libs from 2.17.1 to 2.17.2

For the complete list see 2.24.5 release notes.

Community Updates

Community module development:

  • GEOS-11111 Open search for EO community module: STAC search page has wrong self link

Community modules are shared as source code to encourage collaboration. If a topic being explored is of interest to you, please contact the module developer to offer assistance.

About GeoServer 2.24 Series

Additional information on GeoServer 2.24 series:

Release notes: ( 2.24.5 | 2.24.4 | 2.24.3 | 2.24.2 | 2.24.1 | 2.24.0 | 2.24-RC )

Read More

Using Binary Comparison Operators in GeoServer Filters

GeoSpatial Techno is a startup focused on geospatial information that is providing e-learning courses to enhance the knowledge of geospatial information users, students, and other startups. The main approach of this startup is providing quality, valid specialized training in the field of geospatial information.

( YouTube | LinkedIn | Facebook | X )


Binary Comparison Operators in GeoServer Filters

In this session, we want to talk about the various types of filters, with a particular focus on “Binary comparison operators in GeoServer” comprehensively. If you want to access the complete tutorial, click on the link.

Introduction

Filtering allows the selection of features that satisfy a specific set of conditions. Filters can be used in several contexts in GeoServer:

  • In WMS requests, select which features should be displayed on a map
  • In WFS requests, specify the features to be returned
  • In SLD documents, apply different symbolizations to features on a thematic map

Note. This video was recorded on GeoServer 2.22.4, which is not the most up-to-date version. Currently, versions 2.24.x and 2.25.x are supported. To ensure you have the latest release, please visit this link and avoid using older versions of GeoServer.

Supported filter languages

Data filtering in GeoServer follows the OGC Filter Encoding Specification, which provides a standard XML schema for encoding spatial, attribute, and temporal filters in GIS. This allows for customized queries to retrieve specific data from databases and web services while ensuring interoperability among GIS applications. GeoServer supports filters in both Filter Encoding Language and Common Query Language.

Filter Encoding Language

The Filter Encoding language, defined by OGC standards, utilizes an XML-based syntax to select specific features, similar to the “WHERE” clause in SQL. A filter consists of a condition formed by Predicate elements and Logical operators, employing comparison and spatial operators to evaluate relationships between feature properties. In this session, we will explore various types of binary comparison operators, while the next sessions will cover spatial operators.

Common Query Language

Common Query Language (CQL) is a Text-based language used in GeoServer for constructing filters and queries on geospatial data. It provides flexible and powerful options for filtering and retrieving specific subsets of data from GeoServer layers. In the upcoming sessions, we will dive into a detailed exploration of CQL/ECQL, covering its various operations and practical usage.

Comparison operators

These operators are part of Filter Encoding operators and are used in attribute-based queries to filter and retrieve specific features or data, based on their non-spatial attributes. The comparison operators include: binary comparison operators and value comparison operators.

The binary comparison operators are:

  • PropertyIsEqualTo
  • PropertyIsNotEqualTo
  • PropertyIsLessThan
  • PropertyIsLessThanOrEqualTo
  • PropertyIsGreaterThan
  • PropertyIsGreaterThanOrEqualTo

These operators contain two filter expressions to be compared. The first operand is often a <PropertyName>, but both operands may be any expression, function or literal value. Binary comparison operator elements may include an optional matchCase attribute, with the true or false value. The default value is true, but the comparisons do not check the case if the attribute has a false value.

Note. String comparison operators are case-sensitive.

PropertyIsEqualTo

PropertyIsNotEqualTo is a common type of filter used in GeoServer, which allows you to retrieve features from a data source based on the values of one or more properties. As an example of using this filter in WFS getFeature request:

  • Navigate to the Demos page, then select Demo requests.
  • From the Request section, select the WFS_getFeature1.0.xml request.
  • The address will be filled in automatically, in the URL section.

Use the following block codes to replace line 26:

<PropertyIsEqualTo>
  <PropertyName>STATE_NAME</PropertyName>
  <Literal>Delaware</Literal>
</PropertyIsEqualTo>	
  • Now, we will explain some elements:
    • The first fifteen lines include explanations in the form of comments.
    • Line 16 describes the XML version and the GetFeature operation of the WFS service being used.
    • Line 17 specifies the default output format for the WFS service as “gml2.” Additionally, GeoServer supports several other commonly used formats such as “gml3, shapefile, geojson, and csv.”
    • Lines 18 to 23 define the start of the XML request and declare the namespaces used in the request.
    • Line 24 specifies the type name of the feature to be queried. In this case, it requests features of the “topp:states”.
    • Lines 25 to 30 define the filter criteria for the query. On these lines, we use the PropertyIsEqualTo filter, to retrieve all features where the state name attribute is equal to Delaware.
  • Press the Submit button to see the implemented changes.

  • Note. For GeoServer 2.25.2 the Demo Request page has been improved to show response Headers, and provide the option to pretty print XML output.

PropertyIsNotEqualTo

PropertyIsNotEqualTo is another common type of filter used in GeoServer, which allows you to retrieve features from a data source based on properties that don’t match a specified value. As an example of using this filter in a WFS getFeature request, use the following block codes to replace lines 26 to 29:

<PropertyIsNotEqualTo matchCase="false">
  <PropertyName>STATE_NAME</PropertyName>
  <Literal>delAwarE</Literal>
</PropertyIsNotEqualTo>

Note. The matchCase attribute in WFS_getFeature 1.1 and 2.0 versions, can be set to “false” to specify a case-insensitive comparison.

Press the Submit button.

In this example, we used the <PropertyIsNotEqualTo> filter to retrieve all features where the STATE_NAME attribute, is not equal to Delaware.

PropertyIsLessThan

The PropertyIsLessThan filter is used to filter features, based on a comparison of a numeric property with a given value. It returns all features where the specified property is less than the specified value.

An example of using this filter in a WFS getFeature request is:

outputFormat="shape-zip"
<wfs:Query typeName="topp:states">
    <wfs:PropertyName>topp:STATE_NAME</wfs:PropertyName> 
    <wfs:PropertyName>topp:LAND_KM</wfs:PropertyName>
<ogc:Filter>
  <PropertyIsLessThan>
    <PropertyName>STATE_FIPS</PropertyName>
    <Literal>18</Literal>
  </PropertyIsLessThan>
</ogc:Filter>

Press the Submit button.

In this example, we used the <PropertyIsLessThan> filter to get all features in a shapefile format where the value of the STATE_FIPS attribute is less than 18. The query only retrieves the STATE_NAME and LAND_KM fields, instead of all the attributes.


In this session, we took a brief journey through the various types of filters, with a particular focus on “Binary comparison operators in GeoServer”. If you want to access the complete tutorial, simply click on the link.

Read More

GeoServer User Forum replaces mailing list

GeoServer is updating our communication channels!

We know people do not like signing up for mailing lists, Twitter has been Xed out, and it is time to move on.

GeoServer User Forum

Welcome to the GeoServer User forum:

  • This forum is open to the public, we are pleased to meet you and hope you enjoy using GeoServer.
  • Hosted by Open Source Geospatial Foundation
  • All project communication including this forum are subject to our code of conduct
  • This is one of many options for community support and communication.

Sign in

Taking part is easy (sign-in with credentials you already have):

  1. Login to discourse.osgeo.org:

    • Login “with LDAP” to use your OSGeo UserID (also used for other osgeo services).

      The button appears greyed out, but this is only poor styling choice. The button is enabled and works.

    • Use “Log in with GitHub” to use GitHub credentials.

    • More options are added over time.

    Discourse Login

  2. You may also use “Sign Up” if you want to create an account just for use with the Forum.

    Discourse Signup

  3. Unsubscribe from geoserver-users email list.

    We will continue to operate the geoserver-user list for the month of August, and then do a final synchronization of any outstanding email messages to complete the migration.

  4. Navigate to the category GeoSever / User to enjoy the forum.

    Discourse Signup

  5. Use New Topic to start a new conversation.

    Only the GeoServer / user subcategory allows new topics. If the New Topic button is disabled you may be looking at the GeoServer top-level category.

  6. To test please send introduce yourself we are looking forward to meeting you.

Use as a mailing list replacement

If you enjoy the out-of-band timezone friendly mailing list experience - Discourse allows you to subscribe to notifications, and use email to post and reply to topics.

  1. Sign-in to Discourse as above.

  2. From your profile preferences, use the email tab to adjust email settings.

    IMPORTANT: Email is only sent when you are not logged in to the discourse website!

    Discourse Email Preferences

  3. Navigate to GeoSever User category, and use the bell to change notifications to Watching.

    Discourse Notifications

  4. If you wish to update any email rules the new mailing is user.geoserver.discourse.osgeo.org

  5. You can send email to geoserver-user@discourse.osgeo.org to start a new topic.

    To test please send an email to introduce yourself (rather than a test message).

Mastadon and other socials

GeoServer is occasionally active on social media:

If you enjoy social media we would love some assistance reposting and highlighting our community activity. Contact us on your preferred social media platform to help out.

GeoServer Mastadon

Read More