Pixels vs coordonnées
Quand je pense que les cartes Raster, je pense d'abord aux images satellites. Presque chaque pixel d'une image satellite détaillée d'une zone urbaine peut contenir des informations uniques. Une seule vignette dans une carte Web (généralement une variante de Mercator , appelée " Mercator sphérique " ou " Web Mercator " et prise en charge par Google , Bing , Yahoo, OSM et ESRI) est généralement de 256 x 256 = 65 536 pixels. le niveau de zoom a des tuiles (2 ^ zoom * 2 ^ zoom) . Quand je pense à Vector, je pense à des polygones et des lignes. Par exemple, un fichier de forme détaillant les limites de zonage d'une zone de ville entière (potentiellement des millions de tuiles Raster) pourrait ne comporter que 65 000 formes vectorielles.
Mise à l'échelle précise
Cela ressemble à vous (et probablement à la plupart des lecteurs) connaissez déjà la différence la plus évidente entre les pixels fixes raster et les vecteurs (cartes de coordonnées). Les dessins vectoriels (et les cartes) peuvent évoluer avec un degré de fidélité supérieur à celui des pixels, car les données vectorielles contiennent des motifs de coordonnées (points, polygones, lignes, etc.) pouvant être rendus les uns par rapport aux autres à l’aide de formules simples, alors que le redimensionnement des pixels algorithme de lissage qui se traduit par des artefacts d'image.
Compression d'image vs compression de structure
En pratique, la plupart des images ne possèdent pas des pixels uniques à 100%. Elles peuvent donc être compressées en paquets de données plus petits. De nombreux fichiers vectoriels contiennent des détails excessifs qui ne sont pas nécessaires à de nombreux niveaux de zoom très détaillés. La compression d'image est un processus bien connu et très efficace, et presque toutes les bibliothèques de codage disposent de classes intégrées pour effectuer ce travail. La compression des coordonnées vectorielles, ou "simplification de la géométrie", est un peu moins commune (le SIG en général l'est un peu moins que la manipulation d'image en général). D'après mon expérience, vous passerez près de 0 fois à réfléchir à la compression d'image (il suffit de l'activer ou de l'activer) et beaucoup plus de temps à la compression spatiale. Découvrez l' algorithme Douglas Peucker pour des exemples ou jouez avec QGIS et certains fichiers des limites du recensement.
Rendu côté client vs côté serveur
Finalement, tout ce qui est visualisé sur un ordinateur est rendu en pixels sur l'écran avec une résolution particulière (c'est-à-dire le niveau de zoom). Souvent (surtout sur le Web), le défi consiste à placer ces pixels devant les utilisateurs aussi efficacement que possible. Les fichiers de forme du groupe de recensement des États - Unis Tract & blocsont particulièrement intéressants car ils dépassent la limite des jeux de données vectoriels «trop volumineux» pour être restitués dans un navigateur Web en tant que données vectorielles. En revanche, les comtés américains peuvent à peine être rendus dans les navigateurs modernes sous forme de téléchargement vectoriel. Bien qu'un fichier de formes vectorielles de groupes de blocs de recensement américain soit certainement plus petit qu'un jeu de mosaïques raster couvrant l'ensemble des États-Unis à plusieurs niveaux de zoom, le fichier de formes de groupe de blocs est trop volumineux (près de 1 Go) pour qu'un navigateur Web puisse télécharger ce qui est demandé. Même si le navigateur Web peut télécharger le fichier rapidement, la plupart des navigateurs Web (même à l'aide de Flash) sont assez lents lors du rendu d'un grand nombre de formes. Ainsi, lors de la visualisation de jeux de données vectoriels volumineux, il est souvent préférable de les traduire en images compressées pour les transmettre au navigateur Web.
Quelques exemples pratiques
J'ai répondu à une question similaire il y a quelques jours à propos du rendu de grands ensembles de données dans Google Maps. Vous pouvez voir la question et une analyse détaillée des « meilleures pratiques » telle qu'elle est utilisée par le New York Times et d' autres aujourd'hui ici .
Il y a quelques années, nous avons décidé d'abandonner le rendu vectoriel côté client lourd Flash au profit du rendu vectoriel côté serveur, qui fournit des mosaïques d'images compressées au format HTML et JavaScript pur. Nous avons une galerie de cartes avec plusieurs versions de Html + Raster (mosaïques d'image générées par le serveur) et Flash + Vector (rendu lourd côté client).