The current Maplibre protocol implementation has some flaws that this PR tries to address.
From my understanding, the current comtCache object is overriden each time a new root comt source url is accessed, meaning that having two maps instanciated from the same global maplibre object and showing two different comt files would have their tile caches overwriten each time the other map would request a tile.
It's currently not possible to choose the name the protocol will be added with.
A comt source must be added within the vector source tiles array property, and cannot be added with the url property.
The tileFetchStrategy check for BATCHED or SINGLE was included inside the custom protocol function, which adds an avoidable overhead. The check is now moved in the provider constructor.
The current Maplibre protocol implementation has some flaws that this PR tries to address.
From my understanding, the current comtCache object is overriden each time a new root
comt
source url is accessed, meaning that having two maps instanciated from the same globalmaplibre
object and showing two differentcomt
files would have their tile caches overwriten each time the other map would request a tile.It's currently not possible to choose the name the protocol will be added with.
A
comt
source must be added within the vector sourcetiles
array property, and cannot be added with theurl
property.The
tileFetchStrategy
check forBATCHED
orSINGLE
was included inside the custom protocol function, which adds an avoidable overhead. The check is now moved in the provider constructor.Previously:
Now:
Previously possible:
Now also possible
I would happily discuss the propositions made and the implementation details.