Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[MAP] Traitement d'un grand nombre de géométries complexes #2243

Open
mvergez opened this issue Jan 5, 2023 · 4 comments
Open

[MAP] Traitement d'un grand nombre de géométries complexes #2243

mvergez opened this issue Jan 5, 2023 · 4 comments

Comments

@mvergez
Copy link
Contributor

mvergez commented Jan 5, 2023

Bonjour !

Contexte

Dans le cadre d'une prestation pour l'UMS Patrinat sur gn_module_monitoring, nous avons dû réimplémenter côté frontend la liste et la carte car le nombre potentiellement important d'objets à traiter poussait à paginer côté serveur. La carte présente donc uniquement les objets présents dans la liste. Or, il est beaucoup plus utile de disposer de toutes les géométries.
Cela soulève la problématique cartographique suivante : comment renvoyer un grand nombre de géométries côté front ? Sachant que ces géométries peuvent être complexes.

Quelques pistes

  • Avec potentiellement 9000 géométries complexes, un geojson même zippé pourrait être lourd.
  • Pour donner une idée : un geojson de 4500 géométries complexes (zones humides), avait été évalué à ~45Mo (qui peut être réduit à 20Mo avec seulement l'id comme properties, qui peut tomber à 10Mo en gzippant) :
    • Nous avions donc utilisé le format geobuf/pbf qui avait réduit le geojson à 4Mo (sans gzip). Puis un traitement via vectorGrid de Leaflet permettait de réduire la complexité des géométries en fonction du zoom
  • L'utilisation du format geobuf/pbf de mapbox : https://github.com/mapbox/geobuf ne semble finalement pas être une bonne idée car le dépôt n'a pas été mis à jour depuis plus de 2 ans et le format serait supporté uniquement par mapbox
  • A voir si l'utilisation du format MVT (mapbox) est une bonne idée
  • Quelques fonctions sont disponibles dans PostGis mais attention à la version car, pour rappel, GeoNature supporte toujours PostgreSQL 10 qui est livré avec postgis 2 et donc ne contient pas toutes les fonctions de Postgis 3, si je retranscris bien les propos d'@amandine-sahl et @camillemonchicourt.
  • Quelques librairies permettent de simplifier grandement le geojson telles que https://github.com/simonhuwiler/brokJSON_js mais, idem que précédemment, à voir si actif ou pas.
  • Implémenter un genre de vector tiles maison ? Qui renvoie uniquement des géométries simplifiées en fonction du zoom et de la bbox ? Semble complexe

Cette issue a été écrite dans le dépôt de GeoNature car peut concerner tous les autres modules (accueil, occtax, synthèse, validation et peut-être d'autres !)

Merci d'avance pour vos retours !

@camillemonchicourt
Copy link
Member

Il st aussi possible de simplifier les objets linéaires et vectoriels directement dans la BDD (en stockant les géométries simplifiés ou n les simplifiant à la volée) avec la fonction ST_simplify.
C'est ce qui est fait dans le Dashboard : PnX-SI/gn_module_dashboard#9 (comment)

On peut imaginer une simplification en fonction du niveau de zoom mais c'est complexe et nécessite de recharger des géométries différentes en fonction du niveau de zoom.
On peut aussi imaginer que des géométries simplifiées soient acceptables et suffisantes dans les pages de recherche, à tous niveaux de zoom, et n'afficher les géométries précises que quand on est sur la fiche détail de l'objet.

Sinon, on va aussi ajouter la compression des objets par défaut dans le template de conf Apache.

Les tuiles vectorielles sont aussi une piste envisagée à étudier, même si on veut faire attention à pas alourdir et complexifier trop l'eco-système de GeoNature en lui ajoutant un serveur cartographique.

A creuser.

Voir aussi - #560

@gildeluermoz
Copy link
Contributor

Dans ce genre de situation, les géometries sont souvent dupliquées : plusieurs observations pour une seule et même géométrie (par exemple une commune ou un espace protégé, ou un site visité). D'où le poids catastrophique de ce genre de geojson.
Est-ce que techniquement, coté front, il serait possible de faire un lien entre un geojson et un json ?
La requête retournerait un geojson avec toutes les géometries différentes (par un select distinct), chaque geométries ayant un id_geom. Elle retournerait aussi un json comportant les infos de chacune des obs avec pour chacune d'elle le id_geom mais du coup pas la géométrie elle même.
Le front se chargeant de faire la relation entre l'obs et sa géométrie via le id_geom.

Est-ce que ce mécanisme n'est pas déjà en place pour l'atlas avec les mailles ?

@camillemonchicourt
Copy link
Member

@gildeluermoz, en l'occurrence dans le cas évoqué par @mvergez, ce sont bien des points ou des polygones avec des géométries distinctes.

Mais le cas que tu évoques est en effet bien présent aussi, dans la Synthèse notamment.

Et justement la solution que tu évoques est ce qui a été développé il y a quelques temps par @cecchi-a et @ch-cbna, a été repris récemment avec @TheoLechemia et est déjà mergé dans la branche develop pour être disponible dans la prochaine version 2.12.0 : https://github.com/PnX-SI/GeoNature/blob/changelog-2120/docs/CHANGELOG.md

2 choses détaillées dans ces tickets :

@gildeluermoz
Copy link
Contributor

Ha oui si toutes les geom sont différentes, c'est imparable...
Super nouvelle ces aggréations de géométries. Dans certaines instances avec beaucoup de rattachement des obs à des geom, parfois grandes et complexes, ça peut vraiment améliorer la réactivité de l'interface. 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants