oskariorg/oskari-docs

Oskari documentation and Node.js app running oskari.org

oskari-docs's Issues

Admin-functionality to be more user-friendly

This is a roadmap item. Responsible party is NLS Finland.

SSO/user recognition on embedded map

This is a roadmap item. Responsible party is NLS Finland.

There's need to recognize the user using an embedded map and show more layers/functionalities on the embedded map based on that. The easy way would be to add simple login functionality on the embedded map, but this would require the user to login both to the site using the embedded map AND to the map (usually with different credentials). A more elegant way should be implemented to enable user recognition.

SOS-service support

Initial support for Sensor Observation Services in Oskari: http://www.opengeospatial.org/standards/sos

Responsible party: NLS Finland. Schedule Q3-Q4/2017

Buffer problem with initial database (works with an older backup database)

Hello again,

As title says, if I use the default databse Oskari initializes, buffer doesn't work even when I change projection to EPSG:3857. For some reason it tries to create the buffers according to degrees I think (creates an ellipsoid around a point).

During July I got the buffer tool to work when I changed the projection (and also marked the issue solved here) and then decided to create a backup of the database. Now the buffer tool works with the backup version regardless of projection type (even with the initial 4326, buffers are drawn correctly) and I actually have no idea why it works with the backup version but not with the default one.

If you want to check what the database looks like or want to test it, I uploaded it here as .sql file inside a .zip file.

oskariDBbackup.zip

Scandic letters shown wrong with imported Shapefiles

AH-3554
Shapefile and .dpf define ISO-8859-1 as default. The wanted encoding can be defined in the .cpg file for the shapefile. Geoserver WFS uses .cst file to define the encoding for exports.

Adding temporary map layers at runtime

This is a roadmap item. Responsible party is NLS Finland.

Metadata Search returns dataset and service metadata records. For the time being, a map layer can be added from metadata search results only if the layer has been preconfigured into the Oskari portal as a map layer.

The goal is to enable Users to temporarily view and overlay layers even if it has not been configured into the Oskari portal. Administrators could have an option to read layer information into the Map layer administration tool, which would make it easy to permanently add map layers leveraging service metadata. It should be investigated, which API types the temporary viewing can support with moderate effort. Minimum requirement is WMS layer, to be investigated are WMTS and ESRI rest. Also, a discussion is needed whether adding temporary layers will have e.g. a tool button in the toolbar, and whether users could save their temporary map layers as e.g. "My layers".

Affected functionalities

• Metadata search
• Map layer administration
• Main map
• Optionally My data

Thematic maps functionality rewrite

Responsible party: NLS Finland. Schedule Q1/2017

The current thematic maps functionality in Oskari is based on and tightly coupled with one data source: Sotkanet provided by National institute for Health and Welfare (of Finland). The code for presenting the statistical data and the user interface expects only two dimensions (gender and year). This limits the reuse of the statistical data functionality since one needs to have the exact same data dimensions and server API for any statistical data.

The rewrite has been in the works for some time already and delivers an adapter/plugin architecture on the server-side to read in statistical data from multiple data sources. It also allows more flexibility for the data dimensions. The map layers used for visualizing the statistical data is also restructured to use the same logic as the rest of the layers in Oskari which allows for more customization and using external mapping services in addition to local ones.

PROPOSAL: Map legend must not close on full screen mode

Map legend must not close on full screen mode

GetGeoLocatorSearchResult and Reverse Geocoding

Hello,

I'm not sure if this is an issue or not but I cannot for the life of me figure out how to get the reverse geocoding part to work i.e. searching with lat and lon instead of a search term.

Your documentation (http://www.oskari.org/documentation/backend/actionroutes/getGeoLocatorSearchResult) says that the action can be used without "term" but if it is empty, the error "{"error":"Search string was null"}" comes up even with lat and lon present.
Cannot get it to work with https://kartta.paikkatietoikkuna.fi/ either. I can get the normal searching to work with good results with Paikkatietoikkuna on Oskari on localhost but would've liked to use the reverse geocoding as well.

Library updates

This is a roadmap item. Responsible party is NLS Finland.

The current WFS-backend (transport) uses CometD-library for websocket-communication. The version for the library is heavily coupled with Jetty 8. We should update atleast CometD and Jetty to later versions. If more libraries can be updated at the same time the better. We should also try to reduce the number of libraries we use for the same kinds of tasks (like XML-parsing).

Improvements to WMS-T Time Series tool

This is a roadmap item. Responsible party is NLS Finland.

Time Series tool needs to be updated with more functionality, such as

• ability to automatically adjust time slider scale according to frequency of observations
• automatic update of capabilities with regard to availability of new observations
• ability to show Time Series in Embedded maps
• enable Administrator to adjust parameters e.g. animation frequency per layer
• support for WMS 1.1.1

Affected functionalities

• Time Series module
• Embedded map
• Administration tools

Wishlist: Nicer way to check RPC-compatibility

This is a wishlist item. Might happen on future versions.

The current way of checking compatibility can be done like this:

channel.onReady(function() {
    //channel is now ready and listening.
    channel.log('Map is now listening');
    var expectedOskariVersion = '1.36.0';
    channel.isSupported(expectedOskariVersion, function(blnSupported) {
        if(blnSupported) {
            channel.log('Client is supported and Oskari version is ' + expectedOskariVersion);
        } else {
            channel.log('Oskari-instance is not the one we expect (' + expectedOskariVersion + ') or client not supported');
            // getInfo can be used to get the current Oskari version
            channel.getInfo(function(oskariInfo) {
                channel.log('Current Oskari-instance reports version as: ', oskariInfo);
            });
        }
    });
    channel.isSupported(function(blnSupported) {
        if(!blnSupported) {
            channel.log('Oskari reported client version (' + OskariRPC.VERSION + ') is not supported.' +
            'The client might work, but some features are not compatible.');
        } else {
            channel.log('Client is supported by Oskari.');
        }
    });
});

The RPC-client could do some behind-the-scenes queries before onReady is called to make the information available like this:

channel.onReady(function(info) {
    //channel is now ready and listening.
    channel.log('Map is now listening');
    var expectedOskariVersion = '1.36.0';
    if(!info.supported)
        channel.log('Oskari reported client version (' + OskariRPC.VERSION + ') is not supported.' +
        'The client might work, but some features are not compatible.');
    } else {
        if(info.version === expectedOskariVersion) {
            channel.log('Client is supported and Oskari version is ' + expectedOskariVersion);
        } else {
            channel.log('Oskari-instance is not the one we expect (' + expectedOskariVersion + ')');
            channel.log('Current Oskari-instance reports version as: ', info);
        }
    }
});

TJS support

This is a roadmap item. Responsible party is NLS Finland.

We should add at least initial support for Table Join Service.

User Registration improvements

This is a roadmap item. Responsible party is NLS Finland.

More details will be added later.

test issue

GeoServer initializer database settings

The oskari-server/webapp-setup module uses GeoServer REST API to initialize stores/layers for Oskari user content. The stores are always initialized with host as localhost and port as 5432 for the database address.

As a workaround for instances that have non-localhost database you can run the setup once to create initial stores, edit the db config in GeoServer admin UI and run the setup again to create the layers. Would be nice if the host/port would be set correctly on the first go.

My Places - problems with changing / editing location

Problems changing point location in My Data functionality: it should take the scale in which the point has been added into account, now the edit option zooms "too close" and you can not change the location easily (e.g. you are adding points in European level, but you put accidentaly your point into Finland and it should be in Sweden ==> and this results to the fact that you have to zoom out quite a bit and drag the point where you want it).

Also you have to remember to push the Save-button in the attribute dialog (which also gets in the way of the point so you easily shut down the dialog).

When testing changing location with ELF-map service, the saving does not seem to work at all.

Also when editing the point, there is no "refresh"-button and My Data Layer does not show unless you refresh the whole map service and retrieve your layer again from the Map Layers list.

Preconditions for saving drawn map figures

AH-3565
Issue with preconditions for saving drawn map figures

Line Tool:
-The precondition for saving a drawn Line figure should be 2 points or finished figure (double click)
->Currently can be saved with 1 point (form opens)

Area Tool:
-The precondition for saving a drawn Area figure should be 3 points or finished figure (double click)
->Currently can be saved with 1 point (form doesn't open)

Wishlist: Have an option to display coordinates in DMS with N, S, E or W

Today DMS (degree, minutes, seconds) coordinates are displayed without North, South, East or West, instead, + means north and east and - means south and west. This is very strange to use for us living south of equator or west of Prime Meridian. When writing coordinates to many GPS (like Garmin) you do pick N for north and W for west and do not use + or -.
Coordinatetool should have an option to choose to display coordinates with N, S, E or W so
64°53'23", -20°-12'-32" can be: N64°53'23", W20°12'32" (some prefer postfix presentation, i.e N and W in the end).
Same when in Degree-minutes format
64°53,3833', -20°-12,5333' can be: N64°53,3833', W20°12,5333'

Using + and - with DMS and DM can be very confusing, because -20°12'32" is different from -20°-12'-32" but in public mind it is often the same.

Open map services with HTTPS support should not be proxied by default

To improve performance and scalability, open WMS/WMTS/ArcGIS-layers should not be unnecessarily proxied through Oskari Server. Currently layers are always proxied if SSL/TLS (HTTPS) is enabled in Oskari instance. To allow direct access to HTTPS enabled map services from the frontend should proxying be disabled if all of the following conditions are met:

• layer url starts with https://
• layer doesn't have authentication configured
• forceProxy attribute is not set or is false for the layer

This has already been implemented and a pull request is being prepared by NLSFI.

Scale ratio in print tool / map window

Is it possible to have scale ratio info also in print tool and at the same time also in the map window? Like 1:250 000 (This was suggested in Oskari Joint Development Forum)

GeoTools and GeoServer upgrade (requires Java 8)

This is a roadmap item. Responsible party is NLS Finland.

The current GeoTools version included in Oskari is 14.2.
The current GeoServer version included in Oskari is 2.7.1.1.

These components should be updated to get the latest features and security updates, but latest versions on both also require Java 8 which in turn will make Java 8 a requirement for Oskari.

Published maps show maplayer names in one or two rows depending on browser

AH-3559

In published maps, if the layer names are long, the layer list shows selectable map layer names in one or two rows depending on the browser in use (chrome/firefox/ie).

Possibly implement option for the user to edit the aspects of the map layer window (width/lenght).

Frontend code versioning for RPC

This is a roadmap item. Responsible party is NLS Finland.

Initial support for more graceful version negotiation. Mainly for clients connecting with RPC. Currently any RPC-clients will receive the latest Oskari code immediately when a new version is updated to the Oskari instance hosting the embedded map. As there might be backwards-incompatible changes the software built on RPC might break at the same time.

We should add support for a version parameter for the embedded map url (iframe src) that could be used to request a specific version of the frontend code of Oskari. Naturally it's the responsibility of the administrator of each Oskari instance which versions are supported and for how long, but Oskari should enable this kind of functionality. This way an older version of the client code could be used by the RPC-clients to make the migration process more flexible when versions are updated.

Drawn figures are left on the map after closing the save-form by icon

AH-3564
In Oskari maps which allow user to draw and save figures on the map layer (line/area tool), there is an issue with closing the save-form by the icon.

The buttons "Cancel" and "Save" work as intended but the closing X-icon in the top corner of the form window currently only closes the form, which causes the drawn figure to remain on the map.

The icon should be removed or linked to "cancel" functionality.

Autocomplete suggestions support for the search functionality

This is a roadmap item. Responsible party is NLS Finland.

The search channel API in Oskari should introduce a new function to get autocompletion results for a search channel. The autocompletion functionality should be optional and disabled by default. Search channels may implement the function.

The autocompletion function in search service needs to check that the user has access to each channel and compile the results from channels that are available in the instance like with normal searches. There should be a quick timeout for the autocompletion results implemented on the search service level.

The actionroute used by search functionalities should provide XHR endpoint to expose the search service results for autocompletion. A simple parameter can be used to toggle between actual search and autocompletion results.

The front-end default search UI should be enhanced to provide autocompletion when it's available in the search channels available in the instance.

Layer capabilities caching when service is down

Layer capabilities that are being cached are not validated in any way. In case the response is for example HTML it's stored into the database as is without any error handling.

3D-mapmodule

This is a roadmap item. Responsible party is NLS Finland.

Initial implementation for mapmodule supporting 3d. Propably using Cesium or ol3cesium as the implementation.

Click-events on top of map Crosshair

AH-3580
There is currently issue with Click-events, which are done on top of the map Crosshair.
Might affect touch-screen users.

"Analysis Layer Union" -analysis shows "Buffers and sectors"

As title says, when choosing the analysis "Analysis Layer Union", Oskari (and demo) shows the options for "Buffers and sectors" rather than the correct one.

my places not working with dynamic bundles like a map publisher and my data

ISSUE: When map publisher and my data is set into dynamic bundles for roles admin/user, then my places not showing.

SLD editor: WMS preview shows objects in wrong units

AH-3087
In the editor-view, if the size of a point is defined as 'meters', it is still shown as 'pixels' in the WMS Preview.

Jetty Bundle analysis tool - Buffer problem

Hello!

Today I tried to see how well the analysis (beta) version works with the prebuilt Jetty Bundle. At http://www.paikkatietoikkuna.fi/web/fi/kartta it works like it should but with the premade Jetty I had a critical issue with the buffer tool (same happens with http://demo.oskari.org/).

Issue: I create a line and try to add 1 meter buffer to it with the analysis tool. For some reason, the buffer turns out to be huge ( 50-100km). I'm guessing somewhere in the source code, the buffer has a wrong multiplier.

Metadata search condition 'Responsible party' not working for some GeoNetwork datasets

AH-3633
Metadata search condition 'Responsible party' is currently not working for some datasets through CSW api query to GeoNetwork instance

Example ELF showcase:

1. Geo Product Finder -> Show search options -> Responsible party
2. Select: "National geographic institute of Spain (IGN)"
3. No results are found.

Custom SLDs are sometimes listed twice in maplayer admin

The available custom styles for a WFS-layer are duplicated when the result (layer listing) from capabilities returns. It's a minor inconvenience, but nothing that breaks the functionality so labeling as enhancement.

1. Add a WFS-layer with custom style
2. Start adding a new WFS-layer

• the custom sld list shows the previously added custom style

3. Add an URL to add the WFS-layer from and click Get Info
4. Once the layers are listed check the custom SLD listing

• the custom SLD list shows the previously added custom style twice

Issues about roadmap and other from GH to front page

Pop-up-infobox partially positioned outside map area

Sometimes the info box is positioned so that it is partially or completely outside the visible map area. The problem may be alleviated by the user (developer) by taking the click position into account and choosing an approriate position (top, right, bottom, left) for the box. This approach has two problems:

1. Corner positions are not supported (top-right etc.)
2. When the bottom position is chosen, the (possible) map marker is hidden behind the info box

Info box should be positioned automatically so (in relation to the chosen point) that it completely fits inside the visible map area.

Suggested implementation
There should be two modes for positioning a info box: manual and automatic.

In manual mode, the user (developer) may choose whether the info box is oriented top, right, bottom or left from the chosen point.

In automatic mode, Oskari.org ui calculates an appropriate position for the info box so that the box fits inside the current map area. Likewise, the position of the arrow connecting the box to a map marker is calculated automatically.

User stories
User clicks on a map marker situated in the lower left corner of the map view.
Result: Info box opens above and right from the map marker. An arrow is pointing from the info boxes lower left corner to the map marker.

Goals
Improved usability for the info box, as the user does not need to drag the map so as to actually see the info box.

Oskari 2.0 architecture improvements

Responsible party: NLS Finland. Schedule Q2-Q3/2017

Involves e.g. code restructuring, version negotiation for RPC, minification improvements. More details: http://www.oskari.org/documentation/oskari2/index

New visualizations for thematic maps tool

This is a roadmap issue. Responsible party is NLS Finland in collaboration with Statistics Finland.

Visualizations like:

• Bar chart visualization for statistical data
• Proportional/gradual dot symbol map

Size error on download of jetty-oskari-bundle

Hi guys

I have been trying in vain to download the jetty bundle from the Oskari home. I get a size mismatch about halfway through the download.

I have tried Firefox with DownthemAll, as well as without, and have also tried IE.

Any help on this will be greatly appreciated.

Pieter

Multi-projection support in single Oskari instance

This is a roadmap item. Responsible party is NLS Finland.

The goal is to improve the support for multiple projections in functionalities that are part of the Oskari core-repositories. Either support input/output with proper projection support or validate the projection information and handle as an error if not possible to support it.

Currently it is possible to configure an Oskari server-instance with a single native EPSG projection, e.g. national systems like the Finnish ETRS-TM35FIN (EPSG::3067) or global systems like Web Mercator (EPSG::3857) or WGS84 lat/lon (EPSG::4326).

While the front-end can mostly cope with different projections some of the server-functionalities make the assumption that the native projection is used by the frontend. Examples include but are not limited to the publisher functionality (restricted mostly by having a single publish template for the whole system including projection config for the frontend), my places functionality, WFS-T server-side functionality.

A simple Change projection -functionality has been developed for the European Location Framework (ELF) Showcase Application (https://demo.locationframework.eu). However, most of the Oskari functionality is available only in the default or native projection set in the instance.

Affected functionalities include, but are not limited to the following:

• Main geoportal map and all map tools
• Embedded map and all map tools
• Map publisher
• Search
• My Data
• Thematic maps
• Portal and Map layers administration tools

Implications for Oskari modules

Hardcoding or assumming a certain projection should not be allowed in Oskari. If modules handle coordinates or projection information, the current setting should be passed from the frontend or appsetup that is being used. Functionalities should cope with both geographic and projected coordinates. If this is not possible, the functionality should gracefully decline to handle the non-supported projection types.

This kind of projection handling should be listed as a requirement for Oskari functionality in the core-repositories. Community-repository can have more relaxed requirements for this.

Search field for admin bundles

I suggest, could add "search field" for A:MAP LAYER and LAYER RIGHTS. Lists are so longs and it is very difficult find right layer. CTRL+F is not user friendly.

Combination of myplaces and userlayers functionalities

This is a roadmap item. Responsible party is NLS Finland.

The goal is to make myplaces more flexible with feature attributes (like userlayers functionality) and migrate all userlayers to myplaces features. This would allow upload of userlayer to be another way to create myplaces. We wouldn't need separate tools/code for these and it would be more user-friendly.

WCS-service support

Initial support for Web Coverage Services in Oskari: http://www.opengeospatial.org/standards/wcs

Responsible party: NLS Finland. Schedule Q3-Q4/2017

'Show coverage area' -function shows only one bounding box for metadata

'Show coverage area' function currently shows only one bounding box on the map, regardless of the amount of bounding boxes defined for the metadata.

Cleaning up the frontend repository

This is a roadmap item. Responsible party: NLS Finland.

All the code in the oskari-frontend repository should have documentation, work with the latest version and to be generic enough to be considered usable outside the application they were developed for. To achieve this some of the bundles will be moved from the repository to a "community" repository that will have more relaxed requirements.

This will also require flyway-scripts for the server for changing pats references for the frontend code (bundle-references) and instructions for users how to use the code outside the official repository.

Cannot removed WFS-layers properly

Cannot removed WFS-layers properly. WFS-layer not disappear from portti_wfs_layers -table and also sld style mappings are still in portti_wfs_layers_style -table.

Dropping support for Liferay wrapper

Responsible party: NLS Finland. Schedule Q2/2017

The Liferay wrapper for Oskari (https://github.com/nls-oskari/oskari-liferay) was originally created as a way of using the oskari-server as part of a portlet in a Liferay portal. This has been used in Paikkatietoikkuna.fi which uses an old version of Liferay. As paikkatietoikkuna.fi will be migrating from Liferay to the webapp implementation of oskari-server the repository won't be updated as part of a release after the migration. For this reason it's better to remove it from the official Oskari repository than leaving it as outdated/deprecated repository. If there's another sponsor to keep updating the wrapper it can be preserved, but if not I would like to see it removed after it's not used by paikkatietoikkuna.fi anymore. The estimated time for the end of support is at end of the first half of 2017.

Metadata boundaries which cross the International Date Line are shown wrong

AH-3635

In the Arctic SDI Geoportal:
1.When searching Metadata with the string "arctic"
2. Multiple results are found, for which the boundaries cross the International Date Line.
3. These boundaries are shown wrong (possibly OpenLayers problem).

Possible fixes:

• http://gis.stackexchange.com/questions/7064/the-international-date-line-wrap-around
• http://gis.stackexchange.com/questions/83425/splitting-linestrings-on-the-dateline-with-openlayers/83772#83772

Additional support for OpenLayers 3+

This is a roadmap item. Responsible party is NLS Finland.

Currently the functionalities enabled in embedded maps support OpenLayers 3 as the mapping library. We should add OL3-support for more functionalities to enable using it on the the main/geoportal view as well.