Suite

Regrouper plus de 40 000 points à partir du fichier de formes et remplir Google Maps/Webapp ?

Regrouper plus de 40 000 points à partir du fichier de formes et remplir Google Maps/Webapp ?


Je viens de commencer un nouveau travail d'application Web Python/Django lié aux SIG (et je suis totalement nouveau dans les SIG). Voici ma tâche et ce que j'ai trouvé jusqu'à présent, et je suis coincé quant à savoir quelle est la meilleure façon ou la façon standard mondiale de faire les choses.

  • Nous construisons une application Web où un utilisateur peut télécharger un fichier de formes, prendre les enregistrements et les points du fichier, puis les remplir sur une carte.

    1. Télécharger un fichier de formes
    2. Analyse du fichier de formes à l'aide de la bibliothèque pyshp - cela semble OK
    3. Je suis capable de lire les formes (coordonnées) et les enregistrements (valeur pour chaque champ sur chaque forme)
    4. Maintenant, disons, par exemple, que j'ai environ 40 000+ coordonnées, chacune d'entre elles contenant des enregistrements de terrain
    5. Je devrai remplir ces 40 000 points sur Google Maps - ces points doivent être représentés avec un marqueur, et les enregistrements de terrain peuvent être représentés avec une carte thermique (selon le champ sur lequel l'utilisateur choisit de le filtrer)
    6. Le chargement de 40 000 points sur Google Maps n'aurait certainement pas de sens car cela ralentirait le côté client.

Que puis-je faire pour que cela soit rapide ou que cela fonctionne ?

En pensant à regrouper les coordonnées proches dans une grille, et pas seulement cela, chaque coordonnée a un enregistrement de champ et nous devons les regrouper d'une manière ou d'une autre (?) Quelques options que j'ai examinées sont :-

  1. Utilisez http://google-maps-utility-library-v3.googlecode.com/svn/trunk/markerclusterer/docs/reference.html, cela accélérerait les choses… mais le serveur enverra toujours 40 000 points, ce qui peut ne pas travailler à un point où nous devons charger plus de 40 000 points pour chaque section différente sur la carte
  2. Je cherchais comment nous pouvons atteindre http://www.gdal.org/grid_tutorial.html en utilisant http://www.gdal.org/gdal_grid.html - Je n'ai pas réussi à faire fonctionner la génération .tiff encore
  3. Aussi pour obtenir des données de grille, j'ai trouvé http://docs.scipy.org/doc/scipy/reference/generated/scipy.interpolate.griddata.html - bien que je ne pense pas que cela le fasse réellement
  4. Il se trouve que je viens d'en apprendre davantage sur GeoDjango et https://github.com/biodiv/anycluster, et je l'examine pour voir si cela devrait être quelque chose que je devrais utiliser
  5. et je continue toujours mes recherches

Je ne sais pas s'il existe une norme mondiale, cela ressemble à un problème commun que beaucoup de gens ont peut-être rencontré. Je ne connais probablement pas les termes de jargon à rechercher.


Les deux termes de cartographie Web SIG que vous décrivez sont en effet le regroupement, puis l'indexation spatiale. Le clustering est généralement effectué côté client tandis que l'indexation est effectuée côté serveur, généralement à l'aide d'une géodatabase, avec un moteur de rendu de carte côté serveur au milieu.

Dans KML, il existe une fonctionnalité relativement nouvelle appelée "Régions" qui essaie de gérer le côté affichage des choses. Il a été conçu à l'origine pour GoogleEarth, mais je pense qu'il peut également fonctionner avec GoogleMaps : https://developers.google.com/kml/documentation/regions?csw=1

Si vous recherchez des personnes affichant des données marines AIS, vous trouverez également des exemples de regroupement côté client dans GoogleMaps. En voici une bonne : effectuez un zoom arrière, puis explorez différentes régions. Vous pouvez consulter la source de la page : http://www.shinemicro.com/marine_traffic.asp

Voici un sujet connexe avec une stratégie utilisant OpenLayers et GoogleMaps : Comment afficher plusieurs points d'un KML avec les mêmes coordonnées dans OpenLayers ?

Toutes les stratégies ci-dessus forceront toujours vos utilisateurs à télécharger probablement environ 2 Mo de données ponctuelles en fonction de la taille de l'enregistrement.

Vous avez mentionné GeoDjango qui vous conduirait à utiliser une vraie géodatabase et un serveur cartographique. Il y aurait une courbe d'apprentissage abrupte et beaucoup plus de création d'applications, mais en fin de compte, cela fonctionnera mieux que toute autre approche.

Je testerais d'abord les 40 000 points dans un KML et je verrais à quel point c'est mauvais. De cette façon, vous disposez d'un point de référence pour comparer d'autres solutions. Essayez également de le charger dans GoogleEarth juste pour comparer la façon dont GE le gère par rapport à GMaps.

Une partie de votre décision doit être basée sur le caractère central de cette fonction pour votre application. S'il s'agit d'une partie plus petite d'une application plus grande, il ne vaut peut-être pas la peine de développer la meilleure solution possible pour cette partie. Si tout est construit autour de cette fonction, vous finirez probablement par utiliser GeoDjango ou similaire.