magrit
magrit copied to clipboard
Problème avec Lambert 93
Exemple 1
- un nouveau projet
- Sélection d'un fond de carte d'exemple (world_countries_data)
- dans le menu des projections, choisir plus d'options, lambert 93, reprojetter, confirmer,
- cela fonctionne parfaitement
Exemple 2
- un nouveau projet
- Sélection d'un fond de carte d'exemple (world_countries_data)
- choisir lambert93
- et cela patine, même en laissant longtemps cela ne fonctionne pas
Bug confirmed
Actually, I have a fix for this issue.
In fact, when we select "Lambert 93" in the "more options" menu (example 1), we use a projection managed by d3, using the bounds of the lambert-93 projection as the default zoom if there is no target layer (well, a little wider than the bounds of lambert-93 actually).
When we select "Lambert 93" directly in the dropdown menu (example 2), we use a d3 projection created by us from the proj.4 definition of lambert 93 (and, more importantly, we try to use the bounds of the only layer, here the whole world because there is no target layer, as default zoom). In my case it doesn't lag too much and it reprojects the map but it displays a background with many (if not only) artifacts.
I'm not going to push this fix right away because for now it has a negative effect on the performance (i.e. using the projection we are crafting from the proj 4 string is faster because we dont use any "clip-path" contrary to the d3 one) and the bug only appears if there is no target layer or if the target layer is (way) larger than the bounds of the Lambert-93 projection.
I think one day we should discuss (@riatelab) what we should do about all the CRS that define bounds and do not apply globally. Should we inform the user if its layers are outside these bounds (or not in them at all) ? Should we cut out what is represented outside these bounds? For example here, for lambert 93, the bug only occurs when using data that exceeds these bounds.
Not relevant anymore.