Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Jan 15 16:14
    sonarcloud[bot] commented #1401
  • Jan 15 16:14
    kasparia opened #1401
  • Jan 15 07:15
    sonarcloud[bot] commented #1388
  • Jan 15 07:15
    sonarcloud[bot] commented #1388
  • Jan 15 07:15
    kasparia synchronize #1388
  • Jan 14 15:53

    ZakarFin on master

    Remove 'run example' as the map… Url-fragment consistency Fix styling to relevant compone… and 1 more (compare)

  • Jan 14 15:34
    sonarcloud[bot] commented #1388
  • Jan 14 15:34
    sonarcloud[bot] commented #1388
  • Jan 14 15:33
    kasparia synchronize #1388
  • Jan 13 13:55
    ZakarFin commented #664
  • Jan 13 12:39
    ZakarFin closed #235
  • Jan 13 12:39
    ZakarFin commented #235
  • Jan 13 12:13
    mr-lev1 commented #1397
  • Jan 13 12:09
    mr-lev1 commented #1397
  • Jan 13 12:08
    mr-lev1 commented #1397
  • Jan 13 09:40

    ZakarFin on develop

    Change localisations Add search result help text as … Merge pull request #1400 from k… (compare)

  • Jan 13 09:40
    ZakarFin closed #1400
  • Jan 13 09:40
    ZakarFin milestoned #1400
  • Jan 13 09:38

    ZakarFin on develop

    Implement 3D layer options and … Added CESIUM_ION LayerComposing… Merge pull request #1 from oska… and 9 more (compare)

  • Jan 13 09:38
    ZakarFin closed #1397
Sami Mäkinen
@ZakarFin
I mean you can store them as userlayers to the database, save the style JSON that you already have like you want it in some other part of the db, load the userlayer features as geojson to the frontend by some other means than what they are normally loaded with, load the style JSON from wherever you saved it (it can be hardcoded on the apps frontend for example). Then push the features as geojson with the style on the map
like you have probably done to get that styling for them now
Sami Mäkinen
@ZakarFin
Added a note about the mapbox-style problem here with the workaround that I used to get around it on my env: https://github.com/oskariorg/oskari-docs/issues/241#issuecomment-747090677
amilcar-capsus
@amilcar-capsus
Are there any tips and/or documentation for migration to 2.x?
osqq
@osqq
Great, gitter has been jammed and didn't show me those message. But I did finally find a workaround by downgrading to
"ol-mapbox-style": "6.1.1" and using the dev mode. So basically almost same as you said.
osqq
@osqq
Ah actually I found the workaround a bit before that comment. Your way is better I guess, as it just downgrades the one dependency (don’t know what others that possibly includes).
Sami Mäkinen
@ZakarFin
Great! I didn't check what the dependency versions for ol-mapbox-style was for its last version since itself wasn't the problem but good to know that downgrading it works too
Sami Mäkinen
@ZakarFin
@amilcar-capsus You can see migration guide for any release on the oskari-server repository and in addition both oskari-frontend and oskari-server repositories have a ReleaseNotes.md that you can check as well. Here's a link to the mailing list post I sent when 2.0 was released: https://lists.osgeo.org/pipermail/oskari-user/2020-September/000190.html
The migration guide usually just tells you things you have to do (if any) when you upgrade. Release notes gather the info from pull requests and lists most of the things that have changed. For a full change list you can see the PRs for a given milestone (== release)
Sami Mäkinen
@ZakarFin
You can also join the mailing list to get notifications for releases like the one for 2.0 . It's really a low traffic mailing list with me mostly posting stuff on releases. It can be used to ask questions as well but looks like Gitter is the preferred choice for most developers for questions :)
Jani Levonen
@mr-lev1
Hi! Any ideas what could cause this kind of issues; We are working on an migration to a new server environment of our client and have copied all data (db, GeoServer etc.) to the new environment. Oskari is up and running and all is working well except for the WFS layers. The layers are not shown on map (no apparent errors related to it in Jetty logs or in browser console). However, the features are shown if we print the map view as pdf.
The GeoServer (2.17) is running on it's own Tomcat instance and Oskari (1.56.0) is running on Jetty.
Sami Mäkinen
@ZakarFin
Not really. I would check if the browser even tries to call the GetWFSFeatures action route to load the vectors on the frontend
The print functionality gets the selected layer ids as param and loads the vectors itself. As both print and the wfs-proxying code is now part of the oskarimap.war it shouldn't be anything like missing proxy configs or anything like that
Have you changed the Oskari version on the migration or is the codebase the same on the old and the new env?
Wondering if there could be some config you are missing for the frontend if you have updated the Oskari version at the same time
8 replies
amilcar-capsus
@amilcar-capsus
I'm trying to adapt some of my imports on my server extension for testing in 2.1.0, but I'm not sure how to handle the ones involving db, jdbc and Flyway
amilcar-capsus
@amilcar-capsus
I got the following errors when trying to compile:
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.7.0:compile (default-compile) on 
project app-resources: Compilation failure: Compilation failure: 
[ERROR] /opt/oskari/oskari-server/UPT-Server-Extension/app-resources/src/main/java/flyway/example/V1_0_3__initial
_db_content.java:[3,21] package org.oskari.db does not exist
[ERROR] /opt/oskari/oskari-server/UPT-Server-Extension/app-resources/src/main/java/flyway/example/V1_0_3__initial
_db_content.java:[4,44] package org.flywaydb.core.api.migration.jdbc does not exist
[ERROR] /opt/oskari/oskari-server/UPT-Server-Extension/app-resources/src/main/java/flyway/example/V1_0_3__initial
_db_content.java:[8,52] cannot find symbol
[ERROR]   symbol: class JdbcMigration
[ERROR] /opt/oskari/oskari-server/UPT-Server-Extension/app-resources/src/main/java/flyway/example/V1_1_3__add_dow
nload_basket.java:[3,23] cannot find symbol
[ERROR]   symbol:   class FlywayHelper
[ERROR]   location: package org.oskari.util
[ERROR] /opt/oskari/oskari-server/UPT-Server-Extension/app-resources/src/main/java/flyway/example/V1_1_3__add_dow
nload_basket.java:[4,44] package org.flywaydb.core.api.migration.jdbc does not exist
[ERROR] /opt/oskari/oskari-server/UPT-Server-Extension/app-resources/src/main/java/flyway/example/V1_1_3__add_dow
nload_basket.java:[12,53] cannot find symbol
[ERROR]   symbol: class JdbcMigration
[ERROR] /opt/oskari/oskari-server/UPT-Server-Extension/app-resources/src/main/java/flyway/example/V1_1_1__add_uns
d_datasources.java:[3,44] package org.flywaydb.core.api.migration.jdbc does not exist
[ERROR] /opt/oskari/oskari-server/UPT-Server-Extension/app-resources/src/main/java/flyway/example/V1_1_1__add_uns
d_datasources.java:[12,54] cannot find symbol
[ERROR]   symbol: class JdbcMigration
[ERROR] /opt/oskari/oskari-server/UPT-Server-Extension/app-resources/src/main/java/flyway/example/V1_1_2__add_per
mission_for_regionset.java:[3,25] package org.oskari.domain does not exist
[ERROR] /opt/oskari/oskari-server/UPT-Server-Extension/app-resources/src/main/java/flyway/example/V1_1_2__add_per
mission_for_regionset.java:[4,25] package org.oskari.domain does not exist
amilcar-capsus
@amilcar-capsus
I've been trying to narrow down the adjustments needed, but I've come across something I'm not sure how to solve. There's some parts where we use a UserLayer object, and while I'm trying to compile for 2.1.0, the setStyle() method doesn't seem to exist. Here's an example of how we're using it.
tuomo-hautala
@tuomo-hautala
Hi y'all! Just wanted to tell that I got "FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory" -error on Windows 10 (x64) when developing oskari-frontend but seems that this was fixed by updating nodejs. This error occured every second attempt to save changes and rebuild.
Petteri Pesonen
@Pesonet1

Has anyone noticed that channel.getFeatures Oskari RPC method call returns following error:

0: "TypeError"
1: "n.getLayerIds is not a function"

Is this deprecated method, or should it be working? If it is deprecated, is there anymore possibility to get all layer features without custom state logic?

Jani Levonen
@mr-lev1

Hello! I've ran into some trouble with WFS-layers in Oskari. For some reason the GetFeature-requests sent to GeoServer serving the layers have flipped coordinates (we are using EPSG:3879). And because the request contains the crs in the short format, GeoServer does not return any features. In the browser the GetWFSFeatures-actionRoute has the coords in the correct order, but when the GetFeature-request is sent from Oskari, they have flipped.

If we copy the sent request from Oskari's log and either remove the crs definition from the bbox OR change it to the longer urn-format OR flip the coordinate order, the request works.

So, any ideas why the coords are flipped somewhere along the line? Or is there an option in Oskari to start using the long crs format (urn)?

In our setup Oskari (1.56) is running on Jetty and the GeoServer (2.17) is running on Tomcat.

amilcar-capsus
@amilcar-capsus
Hi again. I managed to get the oskari-map.war file compiled after several adjustments for 2.1.0. However, upon moving it to the webapps folder, I get the following on the logs: Pastebin to avoid flooding
Sami Mäkinen
@ZakarFin
Hi @amilcar-capsus You might have conflicting versions of Oskari on your classpath
You can use mvn dependency:tree to check what dependencies are added and by which module. If you unzip the war-file you can probably see multiple versions of some of the oskari jar-files in WEB-INF\lib\
I think most of the previous jars were named with the oskari-prefix. Now there should only be "oskari-utils-2.1.0.jar" that starts with oskari
Sami Mäkinen
@ZakarFin
That got me thinking we might want to prefix the jars just so they are easier to identify on the unzipped folder
@tuomo-hautala There's a workaround in the README for giving more memory for nodejs: https://github.com/oskariorg/sample-application#out-of-memory-error-when-running-webpack
We started seeing this when the 3d-apps were added
Guess they take a lot of memory to transpile
@Pesonet1 I noticed this just before xmas as well as I was rewriting the RPC examples page. It's not deprecated and it should work. Have you debugged it any further?
2 replies
I was going to take a look at it but it would help if you have narrowed down the problem
Sami Mäkinen
@ZakarFin
Anyone I missed from the backlog of messages?
amilcar-capsus
@amilcar-capsus
Ah, okay. I have oskari-utils-2.1.0.jar and oskari-base-1.56.0.jar
Other files have the 'control' and 'service' prefixes
Sami Mäkinen
@ZakarFin
Ok, you probably have somewhere in the applications pom.xmls a reference to 1.56.0 version of service-base in Oskari
So check the pom.xml files on you copy of sample-server-extension
Updating that to 2.1.0 should fix the problem
amilcar-capsus
@amilcar-capsus

I got the following after adjusting the pom file:

[ERROR] /C:/Users/User/Desktop/UPT-Server-Extension/app-specific-code/src/main/java/org/oskari/example/LayersWFSHandler.java:[14,35] package com.vividsolutions.jts.geom does not exist

If I remain at 1.56.0, I don't get this error when compiling

amilcar-capsus
@amilcar-capsus
Nevermind, I think I solved it. Besides, it's a package I was no longer using.
Sami Mäkinen
@ZakarFin
Ok, good. We update the JTS library on the 2.0 and that was one of the changes in the Oskari 2.0 migration guide. JTS had it's own doc for upgrading and we have it linked on our guide
amilcar-capsus
@amilcar-capsus
Trying to upgrade an installation of 1.55.2 to 2.1.0 and logging in, I got the following error on the logs:
2021-01-12 04:44:30,640 WARN  AUDIT - {"msg":"\n### Error querying database.  Cause: org.postgresql.util.PSQLException: ERROR: column \"options\" does not exist\n  Position: 60\n### The error may exist in org/oskari/myplaces/service/mybatis/MyPlaceCategoryMapper.java (best guess)\n### The error may involve org.oskari.myplaces.service.mybatis.MyPlaceCategoryMapper.getByUserId-Inline\n### The error occurred while setting parameters\n### SQL: SELECT id, uuid, \"default\", publisher_name, category_name, options FROM categories WHERE uuid = ?\n### Cause: org.postgresql.util.PSQLException: ERROR: column \"options\" does not exist\n  Position: 60","op":"ERROR","resource":"GENERIC","ip":"189.216.150.226","params":{"action_route":["MyPlacesLayers"],"_":["1610397866776"]},"user":"amilcar_gonzalez"} 
[DEBUG] fi.nls.oskari.util.IOHelper: Opening connection to http://localhost:8082/geoserver/oskari/ows? 
2021-01-12 04:44:30,901 ERROR org.oskari.map.userlayer.service.UserLayerDbServiceMybatisImpl - Failed to get userLayer with uuid: xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxx 
org.apache.ibatis.exceptions.PersistenceException: 
### Error querying database.  Cause: org.postgresql.util.PSQLException: ERROR: column "options" does not exist
  Position: 159
### The error may exist in org/oskari/map/userlayer/service/UserLayerMapper.xml
### The error may involve defaultParameterMap
### The error occurred while setting parameters
### SQL: select           id,         uuid,         layer_name,         layer_desc,         layer_source,         fields,         publisher_name,         wkt,         options         from          user_layer         where uuid = ?
### Cause: org.postgresql.util.PSQLException: ERROR: column "options" does not exist
Jani Levonen
@mr-lev1
Hello! We have some issues with Oskari and WMTS layers. We have a version 1.56 running on Jetty and GeoServer (2.17) on a separate Tomcat. We are able to add WMTS-layers from the GeoServer (or from any external API's also) to Oskari, but none of them are shown on map. The strangest thing is that (according to the console and Jetty logs, at least) nothing is requested when we toggle the layers in Oskari. The capabilities are fetched correctly when the layer is added, but that's it. Any ideas? All non-working layers can be viewed in QGIS, for example (the ones on our GeoServer and also the ones from external API's).
Sami Mäkinen
@ZakarFin
@amilcar-capsus you need to upgrade to 1.56.0 before updating to 2.x
@mr-lev1 is it a public wmts-service? Might be able to test it on demo.oskari.org to see whats happening but no obvious thing comes to mind from that description
1 reply
amilcar-capsus
@amilcar-capsus
Ok. I will try that out. I also tried to deploy my server extension to a clean installation of the jetty bundle on the oskari.org site, and I get the following on the logs:
13 Jan 22:41:58 WARN [geoserver.catalog] - Error while getting feature type, flushing cache and retrying: Schema$
13 Jan 22:41:58 WARN [geoserver.catalog] - Unable to flush 'http://www.oskari.org:user_layer_data_style
java.io.IOException: Schema 'user_layer_data_style' does not exist.
13 Jan 22:41:58 WARN [geoserver.wfs] - Could not build xml schema for type: user_layer_data_style
java.io.IOException: Schema 'user_layer_data_style' does not exist.
The server extension is on 2.x
image.png
I also tried to upload a layer and get that message
The logs show the following:
2021-01-14 12:58:33,712 ERROR org.oskari.control.userlayer.CreateUserLayerHandler - User uuid: asdf-asdf-asdf-asdf-asdf zip: study_area.zip info: {"parser":"shp","cause":"format_failure","files":["study_area.shp","study_area.sbn","study_area.shp.xml","study_area.shx","study_area.dbf","study_area.prj","study_area.cpg","study_area.sbx"],"error":"parser_error"} 
2021-01-14 12:58:33,712 WARN  AUDIT - {"msg":"Failed to read feature collection from source: Invalid ordinate index: 3","op":"ERROR","resource":"USERLAYER","ip":"189.216.149.226","params":{"filename":"study_area.zip"},"user":"admin"} 
2021-01-14 12:58:33,712 ERROR fi.nls.oskari.AjaxController - Couldn't handle action: CreateUserLayer . Message:  Failed to read feature collection from source: Invalid ordinate index: 3 . Parameters:  {action_route=[CreateUserLayer],srs=[EPSG:3857]}
amilcar-capsus
@amilcar-capsus
I did as instructed, migrating to 1.56.0. I uploaded a layer, no problem. Afterwards, I migrated to 2.1.0, and no signs of that first log error (ERROR org.oskari.map.userlayer.service.UserLayerDbServiceMybatisImpl). However, I'm unable to upload that same layer after deleting it, and get the same error just above.