12 Changelog

In the following paragraphs we've listed an aggregated result of changes specific to this version of Oskari. Following the links below you can access full notes of different components.

• Oskari frontend release notes
• Oskari server release notes
• Migration guide

12.1 Frontend release notes

For a full list of changes see: https://github.com/oskariorg/oskari-frontend/milestone/60?closed=1

12.1.1 MyFeatures functionality 1.0

The myfeatures functionality is now considered production ready and can be used as a replacement for myplaces and userlayer functionalities, enabling end-users to maintain their own geographic data on the service. The functionality has been tuned to make the functionality more user-friendly such as:

• Improved feature editor functionality with support for:
  • Additional field types
  • Number and boolean fields
  • Localized field labels
  • Fixes to hidden fields
  • Localization and help text improvements
• Added geometry validation to prevent saving self-intersecting geometries
• Disabled input fields while drawing features
• Improved feature editor usability and layout
• Feature being edited is now highlighted
• Fixed issues when adding feature outside the layers original coverage area
• Data source field is now shown to other users (embedded maps) as "user provided", but enabled ways for applications to control the override the message or style the message (even hide it): https://github.com/oskariorg/oskari-frontend/pull/3018
• Added support for GeoJSON and files without ZIP packaging as an import options https://github.com/oskariorg/oskari-frontend/pull/3003

12.1.2 Administration improvements

• Layer coverage information is now better presented with user-interface for selecting between coverage from metadata or the layer capabilities (https://github.com/oskariorg/oskari-frontend/pull/2992) and the metadata coverage area is immediately updated hen saving when metadata id is available.
• Layer URL-field improvements (https://github.com/oskariorg/oskari-frontend/pull/2990):
  • copy to clipboard button added
  • parameters moved from the JSON-tab to URL-field with a nicer user-interface
  • automatic removal with notification for reserved parameters (service, version, request that admins regularly paste to URL, but are also added by the code/values are selected with different fields/based on the operation requested from the service)
• Improved layer permission management by grouping system and other roles (https://github.com/oskariorg/oskari-frontend/pull/2986)
• Announcements admin user-interface now incidates announcements imported from RSS-feeds and disables fields that are not controllable by the admin due to importing announcements.
• Metadata id is now trimmed to prevent accidental white spaces

12.1.3 Other changes

• Added warning messages when feature limits may affect results/service has more vector features that are shown on the map/results limited by max features configuration etc (https://github.com/oskariorg/oskari-frontend/pull/3000)
• Metadata flyout is now resizeable by end-users
• Search results can now include an url related to that result. The link is now shown to the user when the search result is clicked (https://github.com/oskariorg/oskari-frontend/pull/2993). The localization can be overridden in an application.
• Added localizations for reverse geocoding results for TerrainElevationSearchChannel (https://github.com/oskariorg/oskari-frontend/pull/3004)
• Added localization for "Year" variable identifier for statistical data to match the parameter used some statistical data providers
• Added publiccode.yml (https://github.com/oskariorg/oskari-frontend/pull/2985, https://github.com/oskariorg/oskari-frontend/pull/2989)
• Made an effort for preventing device zoom when pinching with 3 fingers on map (https://github.com/oskariorg/oskari-frontend/pull/3036, https://github.com/oskariorg/oskari-frontend/pull/3037)
• Reduced noise in developer console when an embedded maps starts with not all the bells and whistles included (https://github.com/oskariorg/oskari-frontend/pull/3045, https://github.com/oskariorg/oskari-frontend/pull/3046)
• Generic admin-bundle for managing appsetups rewritten from jQuery to React-based implementation (https://github.com/oskariorg/oskari-frontend/pull/3002)
• User Guide functionality migrated to React (https://github.com/oskariorg/oskari-frontend/pull/3012)

12.1.4 Tooling changes

Minimum node-version updated to 22 as some dependencies require it. Initial testing shows that Node 24 and 26 should work as well.

12.1.5 Library updates

• Migrated from styled-components 5 to 6
• Upgraded Ant Design from v5 to v6
• Upgraded to React 19
• openlayers 10.8 -> 10.10
• ol-mapbox-style 13.4.0 -> 13.4.3
• cesium 1.139.1 -> 1.450.0
• olcs 2.22.1 -> 2.23.1
• babel/core-js/eslint etc updates

12.2 Migration guide

12.2.1 Enabling myfeatures functionality

The myfeatures functionality is a replacement for user-generated geographic data provided by myplaces and userlayer functionalities. All 3 functionalities will be supported by Oskari 3.4.x, but myplaces and userlayer functionalities are considered deprecated and are being dropped from Oskari 4.0 as myfeatures combines the functionality of the other two (allow user to import features from file and draw/modify features on the map).

The myfeatures functionality can be enabled in an application like most other functionalities: migrating any appsetups for users (default and user-specific appsetups) by adding the myfeatures bundle to the appsetups in the database and including the frontend code by importing the bundle in main.js (https://oskari.org/documentation/docs/3.3.0/8-Configuration-instructions#How-to-modify-app-setups).

Changes for:

• sample-application: https://github.com/oskariorg/sample-application/pull/53
• sample-server-extension: https://github.com/oskariorg/sample-server-extension/pull/77

Also add the maven module for the application like done on this commit https://github.com/oskariorg/sample-server-extension/commit/4cb2db5d77d68b4bc961f21c785b06bb6be6c4cd:

<dependency>
    <groupId>org.oskari</groupId>
    <artifactId>control-myfeatures</artifactId>
</dependency>

In addition the functionality uses a new Flyway-migration module myfeatures that needs to be added to the oskari-ext.properties configuration in db.additional.modules=...,myfeatures. The Flyway-module adds the database tables that is used by the functionality and can be configured to partition the feature table for scalability. For enabling partitioning add this to oskari-ext.properties (Sensible value for most users would probably be in the range of 16-64. See https://github.com/oskariorg/oskari-server/pull/1267 for details):

myfeatures.numPartitions={number of partitions to use}

Note that the partitioning configuration needs to be set when the Flyway-migration module is enabled as the partitioning commands are part of that module. If you forget to do it, you should replicate the migration code for partitioning in an application specific migration to re-run the migration. If you are migrating from 3.3.0, you can also remove myplaces, userlayer from db.additional.modules=...,myplaces, userlayer in oskari-ext.properties. Otherwise, you can remove them after the migration modules have been fully run and you have upgraded your application to an Oskari 3.4 based version.

See https://github.com/oskariorg/oskari-server/pull/1267 for more details. Note that you can just enable myfeatures without disabling myplaces or userlayer and without migrating previous data and have all three functionalities enabled at the same time, but the user-interface re-uses some icons and naming so it will be confusing for users with such combination (however, it could be useful for testing).

12.2.2 Data migrations from myplaces/userlayers

New flyway-modules added that will migrate the content from my places and userlayers to myfeatures: myfeatures_myplaces and myfeatures_userlayer. See details: https://github.com/oskariorg/oskari-server/pull/1264

The modules can be configured as usual for applications to migrate the content on oskari-ext.properties configuration by adding one or both in db.additional.modules=...,myfeatures_myplaces, myfeatures_userlayer. As the migrations take some time, depending on the amount of data users have uploaded (can be hours), you can either disable access to the service for users when you start the migration (resulting in downtime) or to prevent downtime, do a staged upgrade with multiple/gradual updates of the application if you have multiple Oskari instances running in parallel/clustered system:

1. Update your application to an Oskari 3.4 based version and remove the frontend funtionality of myplaces/userlayers:

This will remove the user-interface that allow users to generate more content/modify the existing ones. Remove bundles myplaces3 (myplaces) and myplacesimport (userlayers) from your application by modifying main.js and/or delete rows referencing the bundles in the database table oskari_appsetup_bundles. If you only change main.js the developer console will show warnings that it tried to start a bundle that is not included in the application, but the warning is harmless.

2. Restart one of your instances and include the Flyway-modules for myfeatures_myplaces and/or myfeatures_userlayer (oskari-ext.properties configuration for db.additional.modules) so migrations start running while the other parallel instances continue to serve users with the functionalities to add/edit data removed.

Note that you can use the same installed app and just enable the migrating modules, but you only want to do it for one server instance so any other instances can run, serve users and not interfere with the migration process. This way users can't add new features while the migrations are running, but can continue to use the system for viewing the map etc. The migrations track which layers have been migrated to the new format, so if some failure happens or server is shutdown during migration etc, the migrations can continue from where they were after an unexpected stop.

3. Update all of the instances to a version that includes the new myfeatures functionality for the frontend (myfeatures bundle).

This allows users to add features with the new functionality by adding the necessary user-interface to manage the data.

12.2.3 RSS feed as annoucement source

Can be configured in oskari-ext.properties:

oskari.scheduler.job.AnnouncementsRssImport.url=https://your-rss-feed-org/feed
## Runs every 5 minutes by default (even without the config)
oskari.scheduler.job.AnnouncementsRssImport.cronLine=0 0/5 * * * ?

See https://github.com/oskariorg/oskari-server/pull/1266 for more details.

12.3 Server release notes

For a full list of changes see: https://github.com/oskariorg/oskari-server/milestone/58?closed=1

12.3.1 MyFeatures functionality 1.0

The functionality combining the functionalities of myplaces and userlayer that allow user-generated geographic data is now considered production ready. See MigrationGuide for details on replacing functionality and migrating user data.

• Registered the myfeatures bundle so applications can use it as part of an appsetup.
• Added configurable table partitioning for myfeatures_feature to improve scalability (See MigrationGuide for details).
• Added migration tooling for moving data from myplaces and userlayers into myfeatures and migrating references to layers in for example embedded maps.
• myfeatures uploads now support direct file uploads without ZIP packaging (through shared code this applies to the to-be-removed userlayers functionality as well).
• Added support for importing KMZ files.
• GeoJSON handling (import/export) now defaults to longitude/latitude coordinate ordering.

12.3.2 Other changes

• Added an indicator to GetWFSFeatures and GetWFSVectorTile responses when additional features are available beyond the current response. This enables the frontend to signal if there would have been more features available on a service that can be shown.
• MVT feature IDs are now derived from source feature IDs instead of tile-specific counters, resulting in more stable identifiers across tiles (improved handling for features that extend to multiple tiles).
• Content-Type header comparisons now ignore charset information, improving compatibility with external services and APIs.
• SearchChannels can now add contentURL to a search result, enabling clients to link directly to related content and fixed an issue with result sorting.
• Added support for reading metadataURL from OGC API Features layers for automatic parsing of metadata id.
• Refactored CSWISORecordParser for metadata parsing from CSW service to improve maintainability.
• Metadata identifiers are now trimmed automatically to avoid issues caused by leading or trailing whitespace.
• Information for layer coverage bbox has been improved to help debugging issues using the admin user-interface (both capabilities and metadata coverage bbox is included).
• Coverage information from metadata catalogue is now updated when a layer is updated by admin (when metadata id is present). Previously it was only updated through scheduled updates (by default nightly).
• Announcements now support an RSS feed as source of announcements (See MigrationGuide for details)
• Added opt-in telemetry functionality to GetAppSetup for collecting usage information by an external/customizable filter/valve.
• Migration added for userguide bundle database config to remove the defaulted config (used by the sample-server-extension) that does not work with the new React-based userguide functionality.

12.3.3 Library updates:

• JUnit 5.14.3 -> 6.0.3
• Log4J 2.25.3 -> 2.25.4
• Tomcat 10.1.52 -> 10.1.59
• Jsoup 1.22.1 -> 1.23.1
• GeoTools 34.2 -> 34.5
• Jackson 2.21.1 -> 2.22.3
• Postgres JDBC 42.7.11 -> 42.7.13
• Spring framework 6.2.17 -> 6.2.19
• Spring security 6.5.9 -> 6.5.11
• Spring session 3.5.5 -> 3.5.7
• Log4j 2.25.4 -> 2.26.1
• slf4j 2.0.17 -> 2.0.18
• Added Micrometer version override for 1.16.7 (Resilience4j uses older one by default).