-
-
Notifications
You must be signed in to change notification settings - Fork 35
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
high call rate style
function on RLayerVectorTile
, hits performance badly
#12
Comments
style
function on RLayerVectorTile
call ratestyle
function on RLayerVectorTile
, hits performance badly
If your function returns a different style for every feature used, you have no way to improve the performance - whether you use rlayers or you use directly OpenLayers. In this case you have 2 choices: either reduce the number of features or use clustering. |
You got it - the function returns 3 different styles depending on the feature type. One of those types makes for 99% of the features rendered... what cache parameters are you making mention of, Do you mean I should build a cache layer depending on the 'feature' and 'resolution' parameters sent to the function, or is there a mechanism offered by rlayers/openlayers? Unfortunately clustering does not seem to be an option for our use case (but I'll look into it more). Thanks for such a fast response btw 🚀 edit: I just noticed |
@vgrafe if one feature type represents 99% of the features, your best option, performance-wise, would be to move these features to a separate vector layer with a single fixed style |
Makes sense. Thank you for the help! |
Hi!
I set up a
RLayerVectorTile
in myRMap
that uses MVT format, and pullpbf
files from my server. That layer has a lot of features... this leads the function passed to thestyle
prop to be called thousands of times, over 10-20 seconds. This causes the render to freeze at times.Is there a way to manage the performance on client side to address this scenario? or should my team look into providing more tilesets with less features each?
Thanks!
The text was updated successfully, but these errors were encountered: