Une projection globale de type grille pour créer des cartes thermiques

Je prépare une application où j'ai besoin de créer une grille vectorielle qui sera utilisée pour stocker et afficher une carte thermique. Il a les exigences suivantes:

Peut couvrir la planète entière.
La grande majorité des carrés de la grille n'auront pas de valeurs.
Je ne veux pas avoir à stocker la grille elle-même; Je voudrais le calculer à la volée.
L'échelle des données utilisées avec la grille peut varier considérablement.
Je prévois de vouloir des carrés de grille allant de 1 km à 100 km. (Je sais combien cela sera (~ 510 millions pour 1 km, ~ 51 000 pour 100 km)).
Les valeurs seront accumulées / agrégées pour chaque carré de la grille.
Idéalement, je serais en mesure d'utiliser facilement des cellules de grille plus petites pour calculer les valeurs des plus grandes plutôt que de stocker les valeurs de cellule de grille plus grandes.
Je vais utiliser OpenLayers pour le draper sur OpenStreetMap.
Je vais le stocker dans SpatiaLite ou SQLite, donc de préférence pris en charge par ceux nativement (c'est-à-dire pour SpatiaLite = un CRS pris en charge; ou pour SQLite = un système basé sur des nombres purs).

Ma question est donc la suivante: quelle projection dois-je utiliser pour cette grille?

Aussi - existe-t-il un bon moyen de concevoir cela? Quelqu'un connaît-il une bonne solution potentielle à ce problème ou a-t-il déjà résolu des problèmes similaires? Ou peut me diriger dans une direction utile.

Modifier le cas d'utilisation - en gros, j'agrège des boîtes englobantes de différentes formes et tailles. Ils peuvent être de quelques hectares à des milliers de kilomètres carrés. Ils peuvent également être dans différentes projections.

Vous trouverez ci-dessous une version sur mesure du genre de choses que je souhaite accomplir automatiquement à plus grande échelle. entrez la description de l'image ici

Merci beaucoup.

— SIG-Jonathan
source

En aucun cas nécessairement une réponse complète ou parfaite, mais vous voudrez peut-être Google le Military Grid Reference System ou au moins le US National Grid fgdc.gov/usng pour quelques idées sur la façon dont ces organisations ont géré au moins des défis similaires. Encore une fois, pas nécessairement parfait, mais peut être une bonne référence pour votre travail. J'espère que ça aide.

— John

@John - Merci; J'ai rencontré la grille militaire dans mes propres recherches, mais elle utilise des lettres ainsi que des chiffres, donc je ne suis pas sûr que cela convienne. Le truc USNG semble intéressant mais je ne cherche pas à créer le mien.

— GIS-Jonathan

Certaines informations sur la nature des données et le but de la carte thermique aideront à focaliser les réponses, qui peuvent (et devraient) varier en fonction des propriétés géographiques que vous souhaitez conserver dans les cartes: orientation, relèvement, zone, forme, etc. Étant donné que la reprojection de données spatiales est relativement rapide et facile, cependant, on pourrait être amené à ignorer ces problèmes et à se concentrer plutôt sur des problèmes plus fondamentaux de biais et de précision: que comptez-vous faire à propos du MAUP? Envisagez-vous de tirer des conclusions à partir des données regroupées dans ces cellules de la grille? Pourquoi doit-il s'agir d'une structure de données vectorielles ?

— whuber

Pourriez-vous préciser quelle est la dimensionnalité spatiale des données sous-jacentes? c'est-à-dire que les données sont fondamentalement ponctuelles et uniquement agrégées à la cellule, ou sont-elles réellement superficielles?

— AnserGIS

@whuber - Les données seront utilisées pour une représentation générale auprès des profanes, et non pour toute forme d'analyse spatiale. Ainsi, aucune préférence particulière concernant les propriétés géographiques qui sont conservées / perdues et MAUP n'est pas pertinente car je cherche une généralisation grossière des données. Je n'ai besoin que des carrés de grille pour superposer proprement quelque chose comme des tuiles OSM. Mon désir pour le vecteur est parce que je le stocke dans une base de données et c'est beaucoup plus facile à manipuler.

— GIS-Jonathan

Réponses:

Les tuiles OSM standard sont dans Spherical Mercator (SRID = 3857), il sera donc probablement plus facile de construire votre grille en utilisant la même projection.

Si vous utilisez SM, vous pouvez stocker les données au niveau de zoom le plus élevé pris en charge par OSM, ou au niveau de zoom le plus élevé, vous permettra aux utilisateurs de zoomer. Si la couverture est rare, utilisez une structure de données

XIndex, YIndex, Count

où les index sont les index dans la grille de tuiles au niveau de zoom souhaité, count est le nombre d'entités qui coupent cette tuile et n'incluent pas d'entrées pour les points où count est nul. Ensuite, vous pouvez simplement sélectionner le comptage par index ou, à des niveaux de zoom inférieurs, sélectionner la somme des comptages par plage d'index en sachant que si la requête retourne rien, le compte est nul pour la région donnée.

C'est bien sûr une abstraction, je suppose un niveau logiciel entre celui-ci et votre moteur de rendu de carte thermique. Une description plus détaillée de la façon dont vous allez rendre la carte thermique m'aiderait à donner de meilleurs conseils.

— Russell chez ISC
source

La valeur stockée dans une cellule à partir d'une carte thermique est souvent normalisée par sa zone. Dans ce cas, je préfère suggérer une projection à surface égale afin que vous puissiez facilement agréger à plus grande échelle

— radouxju
source

Envisagez-vous de calculer la densité sur le plan projeté ou sur une surface sphérique et de simplement l'afficher de cette façon? De plus, les données rectangulaires doivent-elles jamais être réparties sur plusieurs cellules de la grille?

— AnserGIS

@AnserGIS - Le calcul se fera sur un plan projeté. Les données rectangulaires peuvent couvrir plusieurs cellules de la grille. Voir aussi l'édition pour plus d'informations.

— GIS-Jonathan

Ceci est une réponse à la façon dont vous pouvez concevoir une carte thermique. Ma suggestion est que vous examiniez le système de cellules de grille de quart de degré . QDGC représente un moyen de faire des carrés de surface (presque) égaux couvrant une zone spécifique pour représenter des qualités spécifiques de la zone couverte. Les carrés eux-mêmes sont basés sur les degrés carrés couvrant la terre. Autour de l'équateur, nous avons 360 lignes longitudinales et du nord au pôle sud, 180 lignes latitudinales. Ensemble, cela nous donne 64800 segments ou tuiles couvrant la terre. La forme des carrés devient plus rectangulaire à mesure que nous arrivons au nord. Aux pôles, ils ne sont pas du tout carrés ou même rectangulaires, mais se retrouvent en triangles allongés.

Les cellules de la grille peuvent être divisées en quatre, et les cellules de la grille résultantes à nouveau divisées en quatre. Le système fournit à l'utilisateur une convention de dénomination prévisible. En calculant les zones pour les différentes cellules de la grille, elles devraient convenir aux présentations dépendantes de la zone. La nomenclature des cellules de grille de quart de degré est récursive.

Des informations plus détaillées et des références à d'autres systèmes sont également disponibles dans un article que j'ai publié il y a quelques années. La norme est utilisée dans plusieurs atlas africains pour l'information environnementale.

Des fichiers de formes pour différents continents et pays sont disponibles en téléchargement sur mon site de blog.

J'ai joué avec l'idée d'étendre la norme, de sorte que les cellules de la grille au-dessus ou au-dessous d'une certaine latitude puissent être divisées en deux, fournissant ainsi un produit de carte plus agréable à regarder lorsqu'il est utilisé.

— ragnvald
source

Merci d'avoir partagé; idée intéressante. Il semble certainement que cela pourrait être utile pour cela. Je suppose que ce ne serait pas trop d'efforts pour le modifier afin qu'il soit purement numérique? c'est-à-dire pas de "E" ou de "N"? Cela permettrait probablement une agrégation plus facile et plus efficace des cellules, en particulier au méridien ou à l'équateur.

— GIS-Jonathan

Une bonne raison de conserver les caractères (texte) est de le rendre lisible par l'homme. Pour une utilisation dans les atlas et les références humaines, il sert bien le but. Il serait bien entendu possible en utilisant par exemple cette représentation: E = 0, W = 1, S = 0, N = 1, A = 1, B = 2, C = 3 et D = 4. Certains extraits de code bien écrits en python ou dans un autre langage de script pertinent devraient être en mesure de «combler» les défis des méridiens / équateurs à peu de frais. Bien sûr, cela dépend du niveau de fonctionnement de votre QDGC et de la taille de l'ensemble de données.

— ragnvald