Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enabling end-users to save styling for vector layers #296

Closed
ZakarFin opened this issue Mar 9, 2023 · 3 comments
Closed

Enabling end-users to save styling for vector layers #296

ZakarFin opened this issue Mar 9, 2023 · 3 comments

Comments

@ZakarFin
Copy link
Member

ZakarFin commented Mar 9, 2023

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).

@jampukka
Copy link
Member

jampukka commented Mar 9, 2023

Seems really nice for published maps.

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?

@ZakarFin
Copy link
Member Author

ZakarFin commented Mar 10, 2023

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).

@ZakarFin
Copy link
Member Author

This was included in version 2.11

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants