1

I'm currently implementing a web map application (OpenLayers 5.3, Tomcat 8/GeoServer 2.14.0, Apache)

There is a rising number of vector layers coming from different external WFS services. Using WMS service is not enough, application is supposed to do more than just showing the data.

For almost every vector layer, I make as many "sublayers" as the number of values an attribute (1 in general, sometimes 2...) can have.

The idea is to limit as much loading time as possible but allowing availability of a lot of data (and "subdata").

=> instead of displaying a map with a legend, you can imagine a legend (it already uses a LayerSwitcher) in which there would be a checkbox for each item (or even subitems) in the legend (if you follow my thoughts) because it needs features that can be used for all kinds of topographic processing, not just images.

So, my question is :

Could OOP be of any help by subclassing OpenLayers objects (ol.source.Vector, ol.layer.Vector), by using "design patterns", polymorphism ? The idea is to have a much cleaner code, easily maintainable. And if yes, should I use new ECMA standard ("class" word, etc...) or stick to the "old" school OOP JavaScript ?

2

Composition is better indeed. And that's what I've finally done.

In fact, I've used the "Builder" design pattern ("Gang of 4") so I can create single layers, or group of "sublayers". What I call a "sublayer" is a layer "shrinked" by a filter (field value) and giving it a style

This way of working also gives the possibility to lower the amount of data to load from the web, some WFS layers can be big...

To improve loading time, I play with the zoom : needless to load all features particularly at small zooms and starting to load them only at a bigger zoom improves general behaviour. This is almost mandatory for very big WFS layers.

Also, to keep client device memory at a low level, I clear the layer source once I zoom in and reload the features (automatic), with less features of course. More network requests but fewer features... That relieves the client device memory.

ol.loadingstrategy.bbox doesn't do that automatically.

I do that in map.on('moveend'...) event and test map.getview().getZoom() and map.getView().getCenter(). If zoom is smaller or center has moved => clear the layer source and reload (reload is automatic)

0

If I understand properly you want to manage your layers at the level of their polygons (or geometry, if you will). In other words -- as far as I understood -- you want to instrument better OL's Vector source/layer objects; you want to give them more methods.

That being the case, packaging those extra functionalities in a class sounds about right, but I would not inherit from OL classes. I would compose a class with them. I don't see the need to actually "modify who" those objects are (OL' Vectors), but to improve the way they share information, and a nice handler/manager here would do it.

Composing gives you the advantage of having a good-go very soon, gives you more flexibility to change/add/update the overall objects capabilities and even to change the base library in the future (say you want Leaflet, for example). Nevermind about polymorphism...avoid that trap. At this point, you can use whatever ECMA version fits better your project.

Composition vs inheritance:

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.