cadastre layer always added on top when opening cadastrapp

[landryb]

that's a difference in behaviour with what we have in mapfishapp, and i'm pretty sure this was specified: if the cadastre layer is already present in the map (eg same url/ WMS/WMTS mode), right now ms2-cadastrapp adds it inconditionally on top.

That's annoying if you've built a map with other layers above the cadastre layer, which are now hidden behind the duplicate cadastre layer.

That also generates useless requests.. in mapfishapp we had an heuristic to avoid loading again the layer if it was already present in the context.

@catmorales @MaelREBOUX ?

[MaelREBOUX]

Hello @landryb

Need investiguation / confirmation but for me you need to clearly separate 2 concepts :

• thematic parcels layer
• applicative parcels layer for cadastrapp

See the requirements : https://docs.georchestra.org/cadastrapp/latest/guide_installation/couches_applicatives.html#publication-des-couches-applicatives

[landryb]

i'm pretty sure i have all this right in the config:

• cadastre.wms.url points at mapproxy, which generates a tiled layer from a layergroup in geoserver - that layer is used to display the cadastre layer all the time cadastrapp is loaded, and that's the one that is being loaded a second time by opening the cadastrapp addon, even if the service url and the layer name are the same.
• parcelle.wms.url points at the plot layer directly in geoserver, and is used to render plots when generating BPs
• cadastre.wfs.url is used to query plots by ID or geometry (point/line/polygon), ms2-cadastrapp queries geoserver via service=WFS&outputFormat=json and puts this info in a temporary (hidden?) layer, which is sometimes below the tiled layer (cf #169)

[landryb]

@pierrejego thinks that the check to add or not the layer is done on the internal layer id - eg here the layer with id __CADASTRAPP_RASTER_LAYER__ is updated or added if not present in the map. @offtherailz does this ring a bell to you ?

previously in mfapp, the check was done on the layer url/name, which is what we expect here. I don't want to have to fiddle with the json stored in the db to set an internal layer id to some arcane constant, if that's the case...