You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently vector layers can have styles defined by an admin, but an end-user can also add or modify styling of vector layers. The difference is that the styles defined by admins are saved to the database while end-user styles are runtime only.
Having runtime only styles means that these styles can't be used in embedded maps etc.
We (National Land Survey) are currently working on changes that allow end-user styles to be saved and used on embedded maps. We are approaching this by migrating the current styles from oskari_maplayer tables options column to a dedicated table on the database. This is the first part of the migration: oskariorg/oskari-server#932
Another change for the frontend part is that layer styles are not included in the layer listing response. The styles would be included in /fetched using the DescribeLayer action route. This also moves us in a direction we want to go with layer listing having only the data that is needed for listing the layers (an old draft pr oskariorg/oskari-server#745 is related to this) while the specific config for a layer would be loaded when needed (layer is added to the map).
This will have some effect on the frontend as there's code that assume everything we need to know about a layer is available on the MapLayerService on the frontend immediately.
Listing of the users saved styles might prove tricky to have a good UI for. Any suggestions are welcome. One option would be that we list layers like for my places on the my data as dropdown (with layers that the user has a saved style for) and selecting a layer would then list the styles the user have saved for that layer. This might be cumbersome if users only have one or two styles per layer. Or just single listing with layers as subheadings on that listing (which might be a long list if the user has custom styles for many layers).
The text was updated successfully, but these errors were encountered:
I don't think it's a problem to just include the users own styles in the same UI as the ones provided by the service. Maybe after 10-15 custom styles one would want some support for organizing the styles for a layer but that seems more like an edge case or a future improvement if someone consistently runs into the issue.
How is editing the styles planned to work? Both for users and admins, as admins probably need another from writing json to options textarea , another textarea perhaps, or textarea per selected style and +/- add/delete buttons for new styles?
The user styles will definitely be included in the style selection in for example selected layers (maybe having a small visual reminder that this is the users own style). But as with any user generated data the content should be accessible through my data as well. One option could be just listing the layers that have styles by the user in mydata and editing would be through the same logic as today (using selected layers).
Currently vector layers can have styles defined by an admin, but an end-user can also add or modify styling of vector layers. The difference is that the styles defined by admins are saved to the database while end-user styles are runtime only.
Having runtime only styles means that these styles can't be used in embedded maps etc.
We (National Land Survey) are currently working on changes that allow end-user styles to be saved and used on embedded maps. We are approaching this by migrating the current styles from
oskari_maplayer
tablesoptions
column to a dedicated table on the database. This is the first part of the migration: oskariorg/oskari-server#932Another change for the frontend part is that layer styles are not included in the layer listing response. The styles would be included in /fetched using the DescribeLayer action route. This also moves us in a direction we want to go with layer listing having only the data that is needed for listing the layers (an old draft pr oskariorg/oskari-server#745 is related to this) while the specific config for a layer would be loaded when needed (layer is added to the map).
This will have some effect on the frontend as there's code that assume everything we need to know about a layer is available on the MapLayerService on the frontend immediately.
Listing of the users saved styles might prove tricky to have a good UI for. Any suggestions are welcome. One option would be that we list layers like for
my places
on the my data as dropdown (with layers that the user has a saved style for) and selecting a layer would then list the styles the user have saved for that layer. This might be cumbersome if users only have one or two styles per layer. Or just single listing with layers as subheadings on that listing (which might be a long list if the user has custom styles for many layers).The text was updated successfully, but these errors were encountered: