Book Question about mastering_openlayers3 HOT 2 CLOSED

Hi,

It is more like making the right considerations for your project. Let's
understand what will happen when you define a loader function
https://github.com/openlayers/ol3/blob/v3.15.1/src/ol/source/vectorsource.js#L789
on a vector source. When you change your map's extent:

• OL3 checks, if the extent is already stored in the R-tree of the layer,
  thus the features are already requested.
• If not, it executes the loader function, and stores the current extent in
  the layer's R-tree

So basically, when you pan or zoom your map to a new extent, it request
every new feature, which wasn't requested before.

Let's assume, you are building a Web GIS application, and you would like to
load some of the minor processing functions to the client side (e.g.
feature count, attribute table, some other minor statistics). If you don't
have access to every feature in the given layer, your code will be faulty.

Now let's assume, you're developing a web mapping application. You don't
need every feature, just the ones in the current extent. Furthermore, you
would like to optimize the performance of your application as much as
possible. You define a loading function, which loads features based on the
extent. Your users browse your map, and with every extent change new
features are requested. In the end, the whole layer will be stored in the
memory. If you have a low feature count (e.g. topp:states layer in the demo
WFS server), it won't have an impact on performance. However, if you have a
high feat count (e.g. osm:water_areas), it will have a great impact on user
experience. Loading 28k features took about 1 gig of memory in my benchmark
after a forced garbage collection in Chrome. Furthermore, it took an awful
lot of time to load features with WFS (which can be optimized by requesting
GeoJSON), and slowed down the application on small zoom levels, due to
rendering masses of coordinates.

Conclusions:

Can you benefit from extent based loader functions? Well, maybe you can cut
down you server's traffic a little bit, if your users won't browse your
maps that much.

If you have low feat count, why would you bother with loading functions?
Just load all of them at once.

If you have high feature count, you should make better optimizations.
Features requested from map servers are not scale dependent, and they are
not cacheable. They will be regenerated with every request (server side
computation and access time), and generalized only on the client side. If
you would like to render large amount of features in a timely manner, look
into Mapbox's vector tiles https://github.com/mapbox/vector-tile-spec.
They are stored on the server as regular tiles, thus they are cacheable,
and they are scale dependent. You can generate them with Mapnik
https://github.com/mapbox/mapnik-vector-tile, and use them with OL3
http://openlayers.org/en/v3.15.1/apidoc/ol.source.VectorTile.html out of
the box.

2016-04-15 16:18 GMT+02:00 Willie Maddox [email protected]:

Hello,
56
In your book, on page 56, you say that dynamic loading should be avoided.
Could you explain why in more detail? Maybe provide a few examples?

Thanks,

WM

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#1

from mastering_openlayers3.

Thank you for the detailed explanation! I understand it much better now.

from mastering_openlayers3.