oskariorg / oskari-docs Goto Github PK
View Code? Open in Web Editor NEWOskari documentation and Node.js app running oskari.org
Home Page: http://www.oskari.org
License: Other
Oskari documentation and Node.js app running oskari.org
Home Page: http://www.oskari.org
License: Other
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
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.
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.
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.
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.
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.
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.
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
'Show coverage area' function currently shows only one bounding box on the map, regardless of the amount of bounding boxes defined for the metadata.
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.
This is a roadmap item. Responsible party is NLS Finland.
This is a roadmap item. Responsible party is NLS Finland.
More details will be added later.
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.
Initial support for Web Coverage Services in Oskari: http://www.opengeospatial.org/standards/wcs
Responsible party: NLS Finland. Schedule Q3-Q4/2017
This is a roadmap item. Responsible party is NLS Finland.
Initial implementation for mapmodule supporting 3d. Propably using Cesium or ol3cesium as the implementation.
This is a roadmap item. Responsible party is NLS Finland.
Time Series tool needs to be updated with more functionality, such as
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.
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).
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:
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.
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".
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.
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.
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).
Map legend must not close on full screen mode
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.
Initial support for Sensor Observation Services in Oskari: http://www.opengeospatial.org/standards/sos
Responsible party: NLS Finland. Schedule Q3-Q4/2017
AH-3633
Metadata search condition 'Responsible party' is currently not working for some datasets through CSW api query to GeoNetwork instance
Example ELF showcase:
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.
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.
ISSUE: When map publisher and my data is set into dynamic bundles for roles admin/user, then my places not showing.
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.
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.
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:
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.
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:
This has already been implemented and a pull request is being prepared by NLSFI.
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.
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.
This is a roadmap item. Responsible party is NLS Finland.
We should add at least initial support for Table Join Service.
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.
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)
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)
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.
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.
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.
AH-3580
There is currently issue with Click-events, which are done on top of the map Crosshair.
Might affect touch-screen users.
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); } } });
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.
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.
This is a roadmap issue. Responsible party is NLS Finland in collaboration with Statistics Finland.
Visualizations like:
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.