-
Notifications
You must be signed in to change notification settings - Fork 48
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
Feature/additional vector layer styling (#878) #953
Conversation
@jacobwod , @Hallbergs. This is blocking updating Kungsbackas public map. If possible, Kungsbacka would like to have this fix in 3.8 version. |
Me, Jacob, and Per discussed this in a meeting yesterday. Some kind of solution will probably be presented in 3.8. |
Let me know if there is anything I can fix. |
@@ -133,6 +158,10 @@ class VectorLayerForm extends React.Component { | |||
return new Date().getTime().toString(); | |||
} | |||
|
|||
function rgba_to_string(c) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please use camelCase for consistency. rgbaToString
@@ -144,6 +173,8 @@ class VectorLayerForm extends React.Component { | |||
if (fieldName === "date") value = create_date(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please use camelCase for consistency. createDate
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @jesade-vbg,
Thanks for reviewing!
"create_date" is used in other *layerform.jsx and in search and edit.jsx so i suggest we leave it as is, for consinstency ;-).
I changed "rgba_to_string" to "rgbaToString" as you suggested in previous comment. Pushed it to github.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great! Sorry I was'nt paying attention to where create_date was placed. Admin is a diffrent story.
I'll check it out with our current SLD styling locally, to ensure everything works out fine with current solutions too. (Hopefully later today.) If so, it'll be ready to merge. |
Looks like a good commit @perosoderstrom! I'll take a closer look tomorrow. |
Hi @perosoderstrom. So the styling is correct if I supply SLD or point out an SLD file in Admin UI. If I however remove them, I don't get the default OL-styling (the blue polygons), but rather something like this: That's the case with empty settings (or as empty as they can be - I can't remove some of these…). |
- Since createStyle is now a class method, there's no need to use .call() or .apply(). Changed how it's invoked. - Removed getStyle() as it was only called once, in the constructor. We can instead just use the value that resists in this.style. - Even better: there's no need to save the value in this.style, as it is only used in once place (again, the constructor). Hence, line 115 now is simplified. - As createStyle() is invoked only once and _without_ parameters, there is no need to have the parameters in method definition (see line 306). Removing them would lead to further simplification inside createStyle. - What's even more interesting is that we have a lot of unused code in createStyle. E.g. everything that has to do with 'feature' is never invoked, as we never provide any 'feature' to the method. - The entire comment with generateLegend() should be removed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Apart from the behavior above, I've commited some changes (that don't fix the problem in my previous comment).
You can see the changes in VectorLayer.js:
- Since createStyle is now a class method, there's no need to use .call() or .apply(). Changed how it's invoked.
- Removed getStyle() as it was only called once, in the constructor. We can instead just use the value that resists in this.style.
- Even better: there's no need to save the value in this.style, as it is only used in once place (again, the constructor). Hence, line 115 now is simplified.
- As createStyle() is invoked only once and without parameters, there is no need to have the parameters in method definition (see line 306). Removing them would lead to further simplification inside createStyle.
- What's even more interesting is that we have a lot of unused code in createStyle. E.g. everything that has to do with 'feature' is never invoked, as we never provide any 'feature' to the method.
- The entire comment with generateLegend() should be removed.
Hi @jacobwod, |
Hi @perosoderstrom. I would prefer the following chain of events:
|
I'm not quite sure what you mean with "custom config from Admin UI". In current PR it is implemented as But instead of falling back to previous Hajk default it will use OpenLayers default. Will that be OK? |
I think we talk about different "previous" versions here. To me, "previous" is the state it was in prior this PR. (While I think that you refer to the previous implementation of custom styling, that has been removed when I implemented styling with SLD, right?) If so: yes, it's fine to just fall back to OpenLayers' defaults, if no custom nor SLD styling is set. |
- Removed unused generateLegend code - Use OpenLayers default vector style if neither SLD nor OpenLayers style is specified in admin - Fixed icon scale (that has never worked)
@jesade-vbg What's your opinion on this: Hajk/new-client/src/models/layers/VectorLayer.js Lines 18 to 20 in 0ab97c5
Is it really needed when
|
same-origin is the default behavior of hfetch, so the three lines can be removed. |
I took a look at the code and corrected one minor thing (see previous comment). Unfortunately, there's something going on in this branch that leads to total freeze upon app load. Please the video below where I compare Skarminspelning.2022-03-01.kl.11.05.53.movI'd be great if someone could confirm, ping @Hallbergs @jesade-vbg. I have two WFS layers in this map config, both styled by SLD. When I do the same test using a map config without WFS layers, there is no freeze. So it's clearly related to Update: happens on both Safari and Firefox. |
It is probably these settings that are missing in map config. It does not fallback to correct values if not specified in config.
|
Thanks for pointing it out - it reminded my to merge latest Anyway, the problem persists. And I'm on the same map config as you can see in the video, only switching branches. The settings you refer are in |
Just tested with a fresh clone. |
We've located the issue. If the vector layer added contains alot of features, we block the thread when we try to parse them. See this line. We could get around this by doing this in a worker, but we're not sure thats a valid solution since we're still fetching all the data just to create a legend graphic (we're talking several MBs of unneccesary data). Hmm... |
A possible soultion could be to do a |
The problem is the legend generation. Unfortunately, it results in two separate problems: A. Everything is loadedTo generate the legend, the code does basically this:
This algorithm's weakness lies in the first point: the entire dataset is retrived from server. In your case, @perosoderstrom, where the dataset is small, you don't see the delay. In our case, where we get all buildings, step 1 leads to 13 Mb being downloaded, while step 2 has to parse 103605 features. That's what causes the freeze. B. Generated legend differs from SLD stylingSince the algorithm for legend generation is invoked even when SLD styling is used, we can get "funny" results, like those in the screenshot below: |
At a second thought, |
A thought. |
Well, in that case the algoritm isn't particularly clever. A simple I propose that everything related to the |
- See discussion in #953. - Main take aways: a) it loads all features which can lead to enormous data transfers, just to get the first element; b) it parses all features, which can lead to hang-ups, but only cares for the first feature; c) it only generetes legend for the first feature which will lead to misleading legends for layers with mulitple geometry types.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just pushed a change where legend generation is removed. This should be a good compromise for everyone.
Restores previous vector layer styling.
See issue #878