Suite

Fusionner des DEM ou d'autres jeux de données raster et découper le jeu de données raster en ligne vectorielle ?


J'ai deux DEM à partir desquels je vais créer un ombrage et je veux finalement qu'un ombrage soit coupé à une limite de comté. Je rencontre cependant quelques problèmes.

Lorsque j'essaie de fusionner les deux ombrages créés à partir des DEM, ArcMap se bloque. Lorsque j'essaie de fusionner les deux DEM, ArcMap se bloque. Je suppose que si je parvenais à fusionner les DEM, l'ombrage créé provoquerait également le blocage d'ArcMap.

J'utilise l'outil PLTS Merge Raster Datasets, car pour une raison quelconque, l'outil Spatial Analyst Raster Calculator n'apparaît pas comme sélectionnable.

Une fois que je suis capable de faire cela et d'obtenir un ombrage des deux DEM, existe-t-il une fonction spécifique pour utiliser la ligne de comté (qui est un vecteur fc) pour découper le jeu de données raster?


Je n'ai jamais utilisé les outils PLTS, et l'aide ne donne pas vraiment beaucoup d'informations sur le fonctionnement de la fusion des jeux de données raster, mais l'outil de géotraitement Mosaic to New Raster, dans la boîte à outils de gestion des données sous Jeu de données raster, devrait fonctionner correctement, et ne nécessite pas de licence ArcInfo ou Spatial Analyst.

Pour découper votre mosaïque résultante sans Spatial Analyst, utilisez l'outil de géotraitement Découper, également dans Gestion des données sous Traitement raster, et utilisez l'entité de ligne de comté comme étendue en sortie. Si vous avez sélectionné l'entité de comté et activez l'option "Utiliser les entités d'entrée pour la géométrie de découpage", elle sera découpée à la frontière réelle. Si vous ne sélectionnez pas l'entité, le raster sera découpé dans le cadre de délimitation de l'entité.


En fait, vous pouvez trouver une alternative dans le progiciel GDAL FOSS. En supposant que les fichiers raster sont dans un format que GDAL peut lire, vous pouvez les traiter en suivant les étapes suivantes :

  1. créer un raster virtuel à l'aide gdalbuildvrt util, en créant un raster virtuel, vous pouvez économiser de l'espace disque et du temps de traitement
  2. utiliser util gdalwrap pour couper la trame en utilisant préparé ligne de coupe dans n'importe quel format pris en charge par OGR

Pour plus d'informations, vous pouvez consulter cette page http://linfiniti.com/2009/09/clipping-rasters-with-gdal-using-polygons/, vous pouvez également trouver des outils GDAL/OGR et d'autres FOSS pour le système d'exploitation Windows dans OSGEO4w distribution binaire.


Pour découper votre ombrage, utilisez Extraire par masque (en supposant que vous ayez Spatial Analyst) et spécifiez votre classe d'entités de comté en tant que "données de masque d'entité".


Concernant les plantages… Cela peut être lié ou non à votre problème spécifique. Chaque fois qu'il semble que je fais les choses correctement et qu'ArcGIS se bloque inexplicablement, mes deux premières actions sont :

  • assurez-vous que je suis connecté en tant qu'administrateur sur l'ordinateur.
  • exporter mes données depuis ArcGIS (en gros, il suffit de les réenregistrer).

Bien sûr, vérifiez bien que votre Spatial Analyst et toute autre extension liée au workflow sont activés. Remarque : Je lance des licences ArcInfo complètes et je ne connais pas le comportement dans ArcView ou ArcEditor.


Un mot : GlobalMapper Vos cauchemars de traitement raster seront terminés, le tout pour 350 $. Ce que vous essayez d'accomplir, c'est du gâteau dans GM.

ÉDITER:

Voici comment découper un raster sur un polygone vectoriel dans GlobalMapper (ver. 13.2 utilisé ici) :

  1. Chargez votre raster et votre polygone vectoriel dans GlobalMapper

  2. Sélectionnez le polygone à l'aide de l'outil Infos sur l'entité, puis désactivez-le dans le Centre de contrôle de superposition (sinon il sera inclus dans votre exportation) :

  3. Allez au format Fichier|Raster/Image ou Fichier|Exporter le format Grille d'élévation (je vais faire Raster/Image)

  4. Sélectionnez votre format d'exportation dans la liste déroulante. Ensuite, dans l'option Exporter, dans l'onglet Exporter les limites, sélectionnez Recadrer vers la ou les entité(s) de la zone sélectionnée(s) :

  5. Continuez l'exportation, vous obtiendrez un raster avec l'étendue de votre polygone de découpage.


Leçon 3. Activité : Tracer des données raster spatiales en Python

Tout au long de ces chapitres, l'un des principaux objectifs a été d'ouvrir, de modifier et de tracer toutes les formes de données spatiales. Les chapitres ont couvert un large éventail de ces types de données, y compris tous les types de données vectorielles, données d'altitude, données d'imagerie, et plus encore ! Vous avez utilisé une combinaison de plusieurs bibliothèques pour ouvrir et tracer des données spatiales, y compris pandas, géopandas, matplotlib, terrien, et divers autres. Souvent, l'analyse de la Terre combinera des données vectorielles et raster pour effectuer une analyse plus significative sur une question de recherche. Regrouper ces différents types de données peut être difficile, mais aussi très instructif.


Comment pouvez-vous supprimer les artefacts de bord DEM dans ArcGIS ?

Comme vous pouvez le voir, il y a des artefacts de carrelage clairs à partir de l'analyse DEM d'origine, à cause de cela, mon modèle de direction de flux est en train de se soulever à mesure que la direction de flux interprétée change le long de ce bord de carrelage, comme on le voit ici : https://imgur.com/a /60PXwXn

Quelle est la source des tuiles DEM ? Je commence par vérifier si les tuiles ont des valeurs équivalentes pour les régions qui se chevauchent. Ouvrez simplement la calculatrice raster et soustrayez l'une de l'autre. Le résultat doit être un raster dont la seule valeur est zéro. Si vous obtenez autre chose, le problème vient des données elles-mêmes.

Cela ressemble à un problème de capteur/traitement pour moi, dans deux directions différentes. Je n'imagine pas que les tuiles ne feraient que 7 ou 8 pixels de large.

La façon de gérer cela dépend de l'importance des données d'origine pour vous. Une simple moyenne mobile le lisserait pour permettre une direction de flux - ici un filtre moyen de 25x25 pixels.

Mais si vous souhaitez conserver la résolution DEM d'origine, vous devrez faire preuve de plus de créativité pour identifier le modèle original d'erreur de capteur/de traitement et le compenser. Cela fait un moment que je n'ai pas fait cela (il utilisait PCA, mais il y a de nombreuses années), donc je ne prétendrai pas connaître les outils actuels.


Méthodes

Concept de zones climatiques locales

La typologie LCZ a été adoptée comme description de base des zones urbaines mondiales en types reconnaissables qui sont formellement définis comme « des régions de couverture de surface uniforme, de structure, de matériaux et d'activité humaine qui s'étendent sur des centaines de mètres à plusieurs kilomètres à l'échelle horizontale », excluent « noms de classe et définitions spécifiques à la culture ou à la région », et se caractérisent par « un régime de température caractéristique à hauteur d'écran qui est le plus apparent sur les surfaces sèches, les nuits calmes et claires et dans les zones de simple relief » 27 . Il existe 17 types de LCZ, dont 10 sont considérés comme « urbains » (Fig. 1), et tous sont associés à des paramètres caractéristiques de la canopée urbaine (UCP, Tableau 1). Dans la présente étude, deux classes LCZ « urbaines » ne sont pas considérées : LCZ 7 (lowweight lowrise) se référant à des habitations informelles peu présentes dans le CONUS, et LCZ 9 (pauvrement construit) caractérisée par une forte abondance d'occupation du sol naturelle qui se comporte ainsi thermiquement comme couverture naturelle du sol.

Définitions des zones climatiques locales urbaines (1–10) et naturelles (A–G) (adaptées du tableau 2 de Stewart et Oke 27 , couleurs LCZ par défaut selon Bechtel et al. 31 ).

Une procédure de cartographie LCZ automatisée (hors ligne) a été suggérée par Bechtel et al. 31 et adopté par le projet WUDAPT pour créer des cartes LCZ cohérentes des villes du monde. Pour faciliter l'extension de la couverture des cartes LCZ, Demuzere et al. 32,34 a introduit le concept de transférabilité des zones de formation (TA) étiquetées 32 et l'utilisation de l'environnement de cloud computing Earth Engine de Google 33 , qui permet d'étendre l'approche WUDAPT par défaut à l'échelle continentale (par exemple, l'Europe 34 ). Dans cette approche, les trois opérations clés du protocole WUDAPT d'origine restent inchangées : (1) le prétraitement des données d'observation de la Terre en tant que caractéristiques d'entrée pour le classificateur aléatoire, (2) la numérisation et le prétraitement des zones d'entraînement appropriées, et (3) la application de l' algorithme de classification et de l' évaluation de l' exactitude 45 . Ces étapes sont décrites plus en détail ci-dessous.

Des données d'entrée

Données d'observation de la Terre

Le flux de travail WUDAPT par défaut utilise généralement un certain nombre de tuiles Landsat 8 (L8) comme entrée du classificateur de forêt aléatoire 31 . Nous adoptons ici l'approche de Demuzere et al. 34, en utilisant 41 caractéristiques d'entrée à partir d'une variété de capteurs et de périodes de temps. Les composites moyens L8 (2016-2018) sont réalisés pour l'année entière et le semestre été/hiver, et incluent le bleu (B2), le vert (B3), le rouge (B4), le proche infrarouge (B5), l'infrarouge à ondes courtes (B6 et B7) et les bandes infrarouges thermiques (B10 et B11). En outre, un certain nombre d'indices spectraux sont dérivés (sous forme de composites couvrant la période 2016-2018) : l'indice de végétation par différence normalisée minimum et maximum (NDVI), l'indice de composition biophysique (BCI 46 ) en utilisant les coefficients de transformation Tasseled Cap de DeVries et al. 47 , l'indice moyen de différence normalisée de BAreness (NDBAI 48 ), l'indice moyen amélioré de terre bâtie et nue (EBBI 49 ), l'indice moyen de différence normalisée de l'eau (NDWI 50 ), l'indice moyen de différence normalisée construit (NDBI 51 ) et l'indice urbain de différence normalisée (NDUI 52 ). L'imagerie radar à synthèse d'ouverture (SAR) (2016-2018) est également incluse, car cette caractéristique s'est révélée auparavant être la clé 32,34,53 . Dans la lignée de Demuzere et al. 32,34, cette étude utilise la rétrodiffusion à simple copolarisation Sentinel-1 VV filtrée par le mode d'acquisition interférométrique à large fauchée et les orbites ascendante et descendante, composites en une seule image (ci-après dénommée S1). À partir du composite de rétrodiffusion S1, une entropie et une image C de Geary (une mesure locale d'association spatiale 54 ) sont calculées, en utilisant respectivement un noyau carré de 5x5 pixels et un noyau de voisinage spatial 9x9. Enfin, d'autres ensembles de données sont inclus, tels que le produit Global Forest Canopy Height (GFCH 55 ), le modèle numérique de terrain (DTM) GTOPO30 et la pente et l'aspect dérivés du Earth Resources Observation and Science (EROS) Center de l'US Geological Survey, l'ALOS Ensemble de données de modèle de surface numérique mondial (DSM) 3D mondial 56,57 et un modèle d'élévation numérique (DEM) en soustrayant le DTM du DSM. Notez que l'ensemble complet des fonctionnalités est traité sur une résolution de 100 mètres, suivant la résolution de cartographie par défaut suggérée par Bechtel et al. 31 . Le lecteur est renvoyé à Demuzere et al. 34 pour plus de détails.

Données d'entraînement

Les données d'AT sont généralement créées par des experts urbains 31 , une procédure qui prend du temps, à la fois en raison de la nature intrinsèque de la tâche (c'est-à-dire de l'étendue et de l'hétérogénéité des zones urbaines) et de la capacité de l'expert urbain à identifier et numériser les TA de manière cohérente 58 ,59 . Ici, des AT experts sont utilisés dans neuf villes américaines : Phoenix et Las Vegas 60 , Salt Lake City 61 , Chicago et New York 62,63 , Houston, Washington D.C., Philadelphie et Los Angeles. Les AT d'experts de ces villes sont complétées par des polygones couvrant les classes LCZ E (roche nue ou pavée) et F (sol nu ou sable) pour capturer pleinement la signature spectrale des régions désertiques chaudes dans les parties sud-ouest de CONUS.

Une limitation de la procédure d'assistance technique experte est que les données sont collectées dans seulement 9 villes (en raison de la procédure exigeante en temps décrite ci-dessus). Pour pallier cette limitation, des données de formation supplémentaires sont créées sur la base d'une plateforme de crowdsourcing : MTurk (https://www.mturk.com). MTurk est hautement évolutif et permet de collecter un grand nombre d'AT urbaines et naturelles à travers CONUS. Le processus suivant a été utilisé pour collecter les AT MTurk. Premièrement, la participation à MTurk est limitée aux travailleurs titulaires d'une qualification de maîtrise (c'est-à-dire aux utilisateurs qui ont démontré de hautes performances sur MTurk lors de tâches précédentes) provenant de pays anglophones (pour éviter toute confusion dans les instructions). On montre aux travailleurs de MTurk un tutoriel et on leur demande de classer une image satellite (500 sur 500 m) d'une zone urbaine ou naturelle. Pour chaque image satellite (https://www.google.com/earth), les utilisateurs voient également les images Google Street View correspondantes (https://www.google.com/streetview/) dans la zone de 500 sur 500 m. Sur la base des images satellite et Street View, les travailleurs de MTurk sont invités à classer la zone comme une seule LCZ. Les emplacements sont sélectionnés sur la base de : (1) Sites de surveillance de la qualité de l'air de l'Agence de protection de l'environnement des États-Unis (qui sont situés dans toutes les grandes régions métropolitaines) et (2) un supplément d'emplacements choisis manuellement pour les ZLC qui ont été sous-échantillonnées (à partir des 60 plus grandes zones urbaines Zones), pour s'assurer qu'un large éventail d'environnements bâtis et naturels est inclus. Pour chaque emplacement, les réponses sont obtenues d'au moins dix travailleurs MTurk uniques uniquement lorsqu'au moins 70 % des travailleurs MTurk sont d'accord sur la classification (définie comme la même LCZ ou une LCZ proche), les AT MTurk sont inclus dans la formation finale. base de données.

Trois approches différentes (utilisant des TA dans les neuf villes « expertes ») sont utilisées pour comparer la cohérence entre les TA EX et MTurk en fonction du degré de chevauchement spatial des polygones TA : (1) correspondance complète où le TA MTurk tombe complètement dans le EX TA, (2) correspondance par centroïde où le centroïde du MTurk TA est dans l'EX TA, et (3) correspondance par intersection où le MTurk TA et EX TA se croisent à un certain point dans l'espace. En utilisant chaque approche, nous avons évalué dans quelle mesure les AT EX et MTurk représentent la même LCZ. Le pourcentage de correspondance était de 100 % (n [nombre de polygones appariés] = 8) pour l'approche de correspondance complète, 87 % (n = 69) pour la correspondance par centroïde et 65 % (n = 141) pour la correspondance par intersection ( Tableau supplémentaire S1). Bien que des différences se produisent, le degré de cohérence est en fait plus élevé par rapport aux résultats de HUMINEX (HUMan INfluence EXperiment 58,59 ), qui a indiqué de grandes différences entre les ensembles de zones d'entraînement de plusieurs « experts », conduisant néanmoins à de fortes améliorations de la précision globale lorsqu'il est utilisé tous ensemble. La combinaison de données d'experts et de crowdsourcing est donc une approche raisonnable pour diversifier les données de formation pour développer des modèles de classification LCZ.

Comme étape finale de prétraitement TA, la surface des grands polygones est réduite à un rayon d'environ 300 m, selon Demuzere et al. 32,34 . Ces grands polygones représentent généralement des zones homogènes telles que des plans d'eau et des forêts 58,59 , une caractéristique qui n'est ni nécessaire ni souhaitée, car cela conduit à des données d'apprentissage plus déséquilibrées et à une inefficacité de calcul du classificateur. De plus, en raison du déséquilibre de l'échantillon MTurk TA (Fig. 2), la quantité de toutes les classes MTurk non-LCZ 6 (lowrise ouverte) est multipliée par cinq, en échantillonnant au hasard cinq petits polygones (100 x 100 m) de chaque polygone MTurk d'origine (boîtes noires sur la figure 2), à l'exclusion des polygones LCZ 6. Il en résulte un ensemble d'entraînement plus équilibré composé de 13 216 polygones (10 323 MTurk et 2 893 EX TA, Fig. 2).

Nombre de domaines de formation experts (EX) et Amazon Mechanical Turk (MTurk) utilisés dans la classification CONUS LCZ. Les cases noires font référence à la quantité d'AT d'origine MTurk déséquilibrés.

Procédure de classification, évaluation de la qualité et post-traitement

En tant qu'étape finale du protocole de classification LCZ de WUDAPT, l'algorithme de forêt aléatoire 64 est appliqué, en utilisant les données d'observation de la Terre et les TA étiquetés 30,31 comme entrées. La précision des cartes résultantes est ensuite évaluée de deux manières, via (1) un « échantillonnage aléatoire » basé sur des pixels et (2) une procédure de « retenue de ville » basée sur des polygones.

La procédure d'échantillonnage aléatoire est basée sur la procédure de validation croisée automatisée WUDAPT par défaut décrite dans Bechtel et al. 45 et est exécuté comme décrit dans Demuzere et al. 34 . Dix pixels sont échantillonnés au hasard à partir de chaque TA (résultant en un total de 132 160 pixels). À partir du pool de pixels TA résultant, 50 % sont sélectionnés comme ensemble d'apprentissage et les 50 % restants comme ensemble de test sur la base d'un échantillonnage aléatoire stratifié (de type LCZ). Cet exercice est ensuite répété 25 fois, ce qui nous permet de fournir des intervalles de confiance autour des mesures de précision décrites plus en détail ci-dessous.

Cette stratégie pourrait conduire à une évaluation de la précision biaisée en raison de la corrélation spatiale potentielle dans les échantillons de train et de test. Par conséquent, une deuxième approche est appliquée conformément à la méthodologie utilisée dans Demuzere et al. 32 . Dans cette procédure d'attente de ville basée sur des polygones, les AT de toutes les villes sauf une sont utilisées pour former le classificateur, tandis que les AT restantes de la ville en attente sont utilisées pour l'évaluation de la précision. Ceci est ensuite répété pour les neuf villes d'AT expertes. Comme les informations pour la formation sont indépendantes de celles utilisées pour les tests, aucun bootstrap n'est effectué. La variabilité autour de la précision est, dans ce cas, fournie par la qualité variable de la cartographie pour les différentes villes cibles. Cette approche city hold out est équivalente aux expériences d'apprentissage croisé ou de transférabilité de modèle dans d'autres études récentes 62,65,66,67 .

Pour les deux approches d'évaluation de la qualité, les mesures de précision suivantes sont utilisées : précision globale (OA), précision globale pour les classes LCZ urbaines uniquement (OAvous), précision globale des classes LCZ construites et naturelles uniquement (OAbu), une précision pondérée (OAw) et la métrique par classe F1 32,34,58,68,69,70 . La précision globale indique le pourcentage de pixels correctement classés. OAvous reflète le pourcentage de pixels classés des classes LCZ urbaines uniquement, et OAbu est la précision globale des classes LCZ construites et naturelles uniquement, sans tenir compte de leur différenciation interne. La précision pondérée (OAw) est obtenu en appliquant des poids à la matrice de confusion et tient compte de la (dis)similarité entre les types LCZ 58,70 . Par exemple, LCZ 1 est le plus similaire aux autres types urbains compacts (LCZ 2 et 3), laissant ces paires avec des poids plus élevés par rapport à, par exemple, une paire de classes LCZ urbaine et naturelle. Cela pénalise davantage la confusion entre types dissemblables que la confusion entre classes similaires. Enfin, la précision par classe est évaluée à l'aide de la métrique F1, qui est une moyenne harmonique de la précision de l'utilisateur et du producteur 68,69.

Selon Bechtel et al. 31 , l'échelle idéale de classification diffère de l'échelle définie par le concept LCZ. Plus précisément, la résolution optimale pour une classification basée sur les pixels doit être systématiquement supérieure à l'échelle LCZ préférée (centaines de mètres à kilomètres) 27 , pour tenir compte des formes non régulières et rectangulaires des patchs. Par conséquent, les pixels individuels ne constituent pas une LCZ et doivent être supprimés. Dans le workflow WUDAPT classique, la granularité est réduite par un filtre de post-classification majoritaire avec un rayon par défaut de 300 m. Celui-ci présente cependant plusieurs défauts. Premièrement, il ne tient pas compte de la distance, c'est-à-dire que le pixel central est pondéré aussi important qu'un pixel à la frontière du masque de filtre. Deuxièmement, il ne tient pas compte des différences dans la taille typique des parcelles entre les classes et, par conséquent, les caractéristiques linéaires comme les rivières ont tendance à être supprimées. Enfin, il produit des artefacts. Par conséquent, une approche de filtrage différente a été choisie ici. Pour chaque classe, la vraisemblance a été définie par convolution du masque d'appartenance binaire dérivé de la carte initiale (1 si le pixel est affecté à la classe je, 0 sinon) avec un noyau gaussien avec écart type σje et taille du noyau > = 2 σje, résultant en une carte de vraisemblance par classe. Par la suite, la classe avec la probabilité la plus élevée a été choisie pour chaque pixel. Étant donné que les correctifs typiques diffèrent en taille entre les LCZ, σje des valeurs de 100 m pour LCZ 1, 250 m pour LCZ 8 et 10 et 150 m pour toutes les classes urbaines restantes ont été choisies. Pour les classes naturelles, 25 m ont été retenus pour l'eau et 75 m pour toutes les autres classes. Étant donné que ces chiffres ont été dérivés par des experts, ils introduisent a priori connaissance de la procédure et méritent une enquête plus approfondie et un ajustement à l'avenir. En particulier, optimale σje sont supposées différer entre les villes et les continents.

Paramètre de canopée urbaine et données de population

Le schéma LCZ est considéré comme une classification universelle, qui fournit non seulement une plate-forme commune pour l'échange de connaissances et une voie pour modéliser les applications dans les villes avec peu d'infrastructure de données, mais fournit également une description numérique des paramètres de la canopée urbaine (UCP) qui sont essentiels dans les processus écosystémiques urbains 71 . Ces UCP, entre autres, comprennent l'empreinte du bâtiment (BF), la hauteur moyenne du bâtiment (BH), la surface imperméable (ISA), le facteur de vue du ciel (SVF) et le flux de chaleur anthropique (AHF). Les plages UCP spécifiques à la classe, globalement génériques, sont fournies dans le tableau 1 et sont particulièrement utiles dans les zones où ces informations ne sont pas disponibles/incomplètes et/ou disponibles à de faibles résolutions spatiales/temporelles 30,34. CONUS dispose de tels ensembles de données, ce qui nous permet 1) d'évaluer la carte LCZ avec ces ensembles de données indépendants et 2) d'affiner potentiellement les plages UCP génériques existantes fournies par Stewart et Oke 27 . Comme indiqué ci-dessus, la typologie LCZ est principalement une description de la couverture terrestre, mais certains des types peuvent être liés à l'utilisation des terres et à la population. Par exemple, les gratte-ciel compacts (LCZ 1) et les hauteurs moyennes (LCZ 2) sont généralement associés aux quartiers commerciaux du centre-ville dans la plupart des villes américaines, bien qu'ils comprennent également de grands immeubles résidentiels. Les bâtiments compacts de faible hauteur (LCZ 3) sont généralement associés à des quartiers densément occupés à proximité des centres-villes, dont beaucoup ont été construits au début du XXe siècle. Des types ouverts de toutes hauteurs (LCZ 4-6) peuvent être reliés aux zones résidentielles suburbaines. Enfin, les types grande taille basse (LCZ 8) et industrie lourde (LCZ 10) sont associés respectivement aux unités de stockage et aux grandes installations émettrices. En d'autres termes, on peut s'attendre à ce que chaque type soit associé à des populations différentes. Pour évaluer les LCZ sur la base de cette proposition, les types de LCZ sont également comparés aux chiffres de la population résidente.

Empreintes de bâtiments

L'équipe Bing Maps de Microsoft a publié un ensemble de données de construction vectorielle à l'échelle nationale en 2018 72 . Cet ensemble de données est généré à partir d'images aériennes disponibles pour Bing Maps à l'aide de méthodes d'apprentissage en profondeur pour la classification d'objets. Cet ensemble de données comprend plus de 125 millions de polygones d'empreinte de bâtiment dans les 50 États américains au format vectoriel GeoJSON. L'ensemble de données est distribué séparément pour chaque état et a une précision de 99,3 % et une précision de rappel des pixels de 93,5 %. Étant donné que les couches vectorielles sont très difficiles pour l'analyse à grande échelle, Heris et al. 73,74 ont converti l'ensemble de données au format raster avec une résolution spatiale de 30 m conformément à la grille du National Land-Cover Dataset (NLCD) 29 , fournissant six variables récapitulatives de l'empreinte du bâtiment pour chaque cellule. Notre étude utilise la couverture d'empreinte totale par cellule de grille, avec des valeurs allant de 0 m 2 (0 %, aucun bâtiment) à 900 m 2 (100 %, entièrement construit).

Hauteur du bâtiment

A notre connaissance, il n'existe actuellement aucune hauteur de bâtiment accessible au public, récente et de qualité (BH, m) qui couvre la zone continentale des États-Unis. Par conséquent, la hauteur des bâtiments est tirée de Falcone 75 , qui fournit une cartographie catégorique des hauteurs moyennes estimées des bâtiments, par groupe d'îlots de recensement pour la zone continentale des États-Unis. Les données ont été dérivées de la NASA Shuttle Radar Topography Mission, qui a collecté des données radar de « premier retour » (haut de la canopée et bâtiments) à une résolution de 30 m en février 2000. Les caractéristiques non urbaines ont été filtrées, de sorte que les valeurs de hauteur se réfèrent à hauteurs d'objets où le développement urbain est présent, par exemple, les bâtiments et autres structures artificielles (stades, tours, monuments). En raison des difficultés à cartographier les hauteurs exactes des bâtiments, les informations ont été regroupées sur 216 291 groupes d'îlots de recensement à travers le CONUS. À leur tour, les valeurs de hauteur de bloc ont été classées en six groupes en fonction de leur distribution statistique et ont été classées en « faible », « faible-moyen », « moyen », « moyen-élevé », « élevé » et « très élevé ». En utilisant les hauteurs et les emprises des bâtiments pour 85 166 bâtiments à San Francisco (représentatifs pour 2010), la qualité des données a été évaluée (corrélation de 0,8), et la moyenne et l'écart type (SD) des hauteurs réelles ont été calculés pour les groupes de blocs où la hauteur réelle du bâtiment les données étaient disponibles. Cette procédure a donné les valeurs de hauteur moyenne (SD) suivantes : « Faible » : trop peu d'observations pour être significatives, « Faible-Moyen » : 11,5 m (3,2 m), « Moyen » : 13,1 m (3,1 m), « Moyen -Haut' : 16,3 m (4,4 m), 'Haut' : 21,7 m (8,2 m) et 'Très haut' : 35,3 m (14,2 m).

La procédure décrite ci-dessus indique clairement que cet ensemble de données sert de proxy de premier ordre pour les données réelles de hauteur de bâtiment. Les données ont été prises en l'an 2000, ce qui ne correspond pas à l'année 2017 représentative de cette carte CONUS LCZ. En tant que tel, l'analyse comparative de la carte LCZ par rapport à cet ensemble de données sur la hauteur des bâtiments néglige une augmentation nette de 6,7% des terres urbaines développées, dérivée de la différence entre les classes de couverture terrestre développées NLCD 2016 et 2001 76 . De plus, les 75 hauteurs de bâtiments de Falcone sont catégoriques et reflètent la variabilité observée à San Francisco, qui n'est pas nécessairement représentative de toutes les autres zones urbaines du CONUS. L'empreinte spatiale est définie par des groupes d'îlots de recensement, dont la forme et l'échelle varient, car leur objectif initial est d'échantillonner la population. L'impact de ces limitations est évalué à l'aide d'ensembles de données plus récents, à haute résolution et disponibles gratuitement dans les régions métropolitaines d'Austin, Boston, Des Moines, Los Angeles et New York, couvrant plus de 5 millions de bâtiments (tableau supplémentaire S2).

Surface imperméable

La surface imperméable est tirée du produit 29,77 de la National Land-Cover Database (NLCD) 2016 , qui fournit le pourcentage de chaque pixel de 30 m couvert par la surface imperméable développée (plage de 0 à 100 %). Ces auteurs ont créé l'ensemble de données en quatre étapes : (1) développement de données d'entraînement à l'aide de produits d'éclairage nocturne, (2) modélisation de surface imperméable à l'aide de modèles d'arbre de régression et d'imagerie Landsat, (3) comparaison des sorties du modèle initial pour éliminer les fausses estimations dues à une réflectance élevée des zones non urbaines et de conserver les valeurs imperméables de 2011 inchangées de 2011 à 2016, et (4) l'édition finale et la génération de produits (voir la section 6.1 dans Yang et al. 29 pour plus de détails).

Facteur de vue du ciel

Des informations sur le facteur de vue du ciel (SVF) sont disponibles pour 22 villes américaines (Atlanta, Baltimore, Boston, Buffalo, Cleveland, Denver, El Paso, Fresno, Las Vegas, Miami, Orlando, Philadelphie, Portland, Richmond, Salt Lake City, San Diego, San Francisco, San Jose, Seattle, Tampa, Tuscon et Washington DC) et sont obtenues à partir d'images Google Street View (GSV) qui sont examinées à l'aide d'une approche d'apprentissage en profondeur 78,79. Un échantillon complet des emplacements GSV dans chaque ville est récupéré via l'API Google Maps pour tous les emplacements, un cube d'images est téléchargé sous la forme de six images de champ de vision à 90 degrés orientées vers le haut, le bas, le nord, l'est, le sud , et à l'ouest. Les images sont segmentées par un réseau neuronal convolutif qui a été affiné avec des images GSV à 90 degrés de villes du monde entier pour produire six classes : ciel, arbres, bâtiments, surfaces imperméables et perméables et objets non permanents 79 . Ici, seul le SVF est utilisé, qui est obtenu en projetant la moitié supérieure segmentée du cube d'image dans un fish-eye hémisphérique pour calculer le SVF en utilisant des pixels du ciel et non du ciel 80 . Les images GSV sont intrinsèquement biaisées vers les emplacements de rue, et donc sous-échantillonnent grandement les espaces ouverts, y compris les parcs, les terrains de golf, les arrière-cours et les zones naturelles en général 78 . L'analyse comparative avec des données SVF (plages entre 0 et 100 %) n'est donc effectuée que pour les classes LCZ urbaines dans le domaine CONUS.

Flux de chaleur anthropique

Flux thermique anthropique moyen annuel (AHF, hm −2 ) les données sont fournies par Dong et al. 81 , qui sont disponibles dans le monde entier à une résolution spatiale de 30 secondes d'arc. Ce produit comprend quatre composants de chauffage : les pertes d'énergie, le chauffage des secteurs commercial, résidentiel et des transports, le chauffage des secteurs industriel et agricole et le chauffage du métabolisme humain.

Population

Les chiffres de population résidente représentatifs pour 2015 sont fournis par la grille de population mondiale des établissements humains mondiaux (GHS-POP) 82,83 . Ces données sont désagrégées des unités administratives ou de recensement GPWv4 84 du CIESIN en cellules de grille avec une résolution de 250 m, une manipulation qui est informée par la distribution et la densité des bâtiments tels que cartographiés dans l'ensemble de données Global Human Settlement Layer 3,5,83 . Pour d'autres ensembles de données démographiques mondiales et continentales, et leur aptitude à l'emploi, le lecteur est renvoyé à Leyk et al. 85 .


La norme National Imagery Transmission Format (NITF) est un format raster défini par le NITF Standards Technical Board. Le Joint Interoperability Test Command (JITC) certifie les systèmes mettant en œuvre le format NITF pour la conformité avec la norme. Le module NITF/NSIF fournit une prise en charge conforme JITC pour le format de fichier NITF et il est requis pour la prise en charge conforme NITF dans ENVI. Le module ENVI 5.0 NITF/NSIF a été testé par le JITC et a été certifié au niveau de complexité 7 pour NITF 2.1 et au niveau de complexité 6 pour NITF 2.0 (le plus élevé pour chaque format). ENVI 5.1 est conforme à ces normes.

Contactez le JITC pour obtenir des informations détaillées sur le programme de certification NITF, y compris les pannes fonctionnelles en lecture/écriture et les anomalies de test.

Le module NITF/NSIF nécessite une licence distincte. Veuillez contacter votre représentant commercial.

Un ensemble de données NITF valide fournit un en-tête principal identifiant le fichier en tant qu'ensemble de données NITF et décrivant le contenu du fichier. L'en-tête est généralement suivi d'un ou plusieurs segments de données. Chaque segment de données se compose d'un sous-en-tête de segment identifiant le type et les propriétés des données, suivi des données elles-mêmes.

Voir les rubriques suivantes :

En-tête principal

Un jeu de données NITF peut contenir tout ou partie des types de segments disponibles pour cette version, mais chaque jeu de données NITF doit contenir un en-tête principal. L'en-tête NITF principal décrit l'intégralité du fichier, y compris les informations d'origine, les informations de sécurité, la version et la taille du fichier, ainsi que le nombre et le type de tous les segments de données contenus dans l'ensemble de données NITF.

Segments de sécurité

Le format NITF a été conçu pour contenir des informations jugées sensibles, il inclut donc des données d'en-tête décrivant l'état de toute information qui n'est pas accessible au grand public. L'en-tête du fichier principal contient des informations de sécurité décrivant le niveau de sécurité de l'ensemble de données NITF, et chaque segment contient également des informations de sécurité dans son sous-en-tête, car la confidentialité des données dans un fichier peut varier. Le niveau de sécurité de l'ensemble du fichier (T = Top Secret, S = Secret, C = Confidentiel, R = Restreint, U = Non classé) est le même ou supérieur à celui du segment le plus restreint du fichier. NITF 2.0 utilise les mêmes champs que NITF 1.1 pour contenir des informations de sécurité, tandis que NITF 2.1 a déprécié certains champs d'informations de sécurité et ajouté de nouveaux champs.

Ces changements sont décrits dans le tableau suivant. Pour une description détaillée de ces champs de sécurité, consultez les spécifications NITF pour déterminer quelles métadonnées sont pertinentes pour la version de votre fichier NITF.

Champs de sécurité NITF 1.1/2.0

Instructions de libération
Type de déclassement
Date de déclassement
Exemption de déclassement
Rétrograder
Date de rétrogradation
Texte de classification
Type d'autorité de classification

Autorité de classification
Raison du classement
Date de la source de sécurité

Lors de la conversion entre les formats NITF, les champs de sécurité seront mappés conformément à l'annexe G de la Pratiques de mise en œuvre de la norme nationale de format de transmission d'images (IPON), Coordination Draft Version 0.3A, 14 janvier 2005.

Segments d'images

Image segments contain raster data, typically image data, intended for display or analysis. Each image segment contains a single image consisting of one or more bands of data (NITF 2.0 allows one, three, or four bands of data in an image, and NITF 2.1 allows up to 999 bands).

All bands within an image segment must have the same data type, dimensions, storage order, and map information, although these characteristics can vary across different image segments. Each image segment may contain specific display instructions, including color lookup tables for single-band images and default display bands for multi-band images.

Images can be stored in integer data types in NITF 2.0 and in integer and real data types in NITF 2.1. Images can also be compressed using a variety of algorithms including JPEG DCT, Vector Quantization, Bi-level, JPEG 2000 NPJE (NITF 2.1 only), and JPEG 2000 EPJE (NITF 2.1 only). Images can be broken into blocks, providing an orderly set of subimages (or subarrays). Additional information describing the collection, intended use, wavelengths, and comments can also be stored with the image.

Masks

Mask information stored in image segments identifies pixels that are invalid or not intended to be displayed, and should therefore not be displayed.

Images that are rotated or have gaps can also contain a mask indicating which portions of the image should not be used for display or analysis. Two types of image masks are used in NITF files:

  • Blocked image masks are used to mask entire blocks of image data.
  • Transparent pixel masks are used for masking individual pixels or groups of pixels within an image block.

When an image segment containing masked blocks or pixels is displayed, pixels from images or graphics underneath the image segment show through and are displayed even though they would ordinarily be obscured. If a transparent pixel occurs with nothing displayed under it, or if for any other reason there is no display information for a pixel, the background color specified in the main file header is displayed.

Graphic/Symbol Segments

Symbol segments can contain Computer Graphics Metafile (CGM), bitmap, or object elements, while label segments contain graphical text elements. The CGM format allows direct control of all display elements contained in the graphic including color, size, and orientation of objects. CGM graphics can contain complex lines and polygons, as well as displayable text. Multiple annotations can be combined in a single CGM, so symbol segments with CGM graphics may actually contain multiple sets of graphical primitives.

NITF 2.1 files can contain graphic segments with CGM graphic and graphical text elements, while NITF 2.0 files contain two segment types for the same purpose: symbol segments and label segments. Both the NITF 2.0 symbol segment and the NITF 2.1 graphic segment can contain CGM graphics.

The NITF 2.1 graphic segment can only contain CGM graphics, but NITF 2.0 symbol segments can contain other graphical display elements as well. Symbol segments can contain bitmaps (color-mapped bitmaps to be displayed on the composite) or objects (graphics from a limited set of graphical primitives, including lines, arrows, circles, and rectangles).

For NITF 2.1, the bitmap and object symbol types as well as the label segment have been deprecated. Bitmaps are stored in image segments instead of symbols, and object symbols and labels have been removed in favor of the more general and powerful CGM.

Label Segments

Label segments, available only in NITF 2.0, contain displayable text intended to be drawn with the NITF display. In addition to this text, a label segment includes display instructions such as font, color, size, and a background color to display behind the text.

There are many required CGM elements to draw the data contained in a NITF 2.0 label segment. Element details are described in the MIL-STD-2301A specification.

Annotation Segments

NITF 2.0 symbol and label segments, as well as NITF 2.1/NSIF 1.0 graphics segments, are collectively referred to as annotation segments, as illustrated in the following diagram.

Image, text, and extension segments are available in every version of NITF, while label and symbol segments can occur only in NITF 2.0 datasets. Graphic segments occur only in NITF 2.1 datasets.

Because of the similarity between the symbol segments and label segments in NITF 2.0 files, and the graphic segments in NITF 2.1 files, ENVI combines these segments into a single conceptual type (annotation segments). Annotation segments can contain symbol, label, or graphic segments, and they might include text, ellipses, polylines, bitmaps, and other objects. Annotation segments do not exist in any NITF file, and they are not mentioned in the NITF specification documents. They are a simplification used to reduce the overall number of segment types.

Annotation segments and image segments both carry information intended to be displayed graphically, and both are referred to as displayable segments.

Annotation Objects

Because CGM graphics can display multiple graphical elements, each annotation segment must store multiple displayable features, referred to as annotation objects. NITF 2.0 and 2.1 annotation segments can contain multiple CGM annotation objects. Each NITF 2.0 annotation segment can only contain one non-CGM label, bitmap, or object symbol annotation object. The type of object determines which fields will be filled in the annotation object.

Text Segments

Text segments consist of textual information that is not intended for graphical display. Examples are notes explaining target information, or US Message Text Format (USMTF) notes for other users.

Data Extension Segments

Data Extension Segments (DESes) contain data that cannot be stored in the other NITF segments. An example is the NCDRD Attitude Data DES, CSATTA. A list of unclassified, registered DESes is available at the JITC web site.

ENVI only supports NITF Commercial Dataset Requirements Document (NCDRD) DESes. You cannot edit, create, or delete NCDRD DESes through the Metadata Editor.

If a NITF file contains valid supported DESes, they are automatically saved in the output file. When opening a NITF image, ENVI will not read the DES user-defined subheader if the input data format does not mirror the format in the accompanying XML definition file. When writing a NITF file that contains a DES with no corresponding XML file, ENVI passes through this unknown DES in NITF 2.1 and NSIF 1.0 files only. ENVI does not support unknown DESes in NITF 2.0 files. Also see Data Extension Segments.

Display Levels

The NITF format supports multiple image, graphical, and displayable text elements. A NITF dataset can contain all displayable segments (image, graphic/symbol, and label), allowing for raw imagery plus ancillary information. Each displayable segment contains information controlling the location of the display element in the composite. Each segment also contains a display level that determines which elements should be displayed on top of others, obscuring the lower-level displayable elements from view without corrupting the hidden portion of those lower-level displayable elements.

Wavelength Information

Wavelength information can be stored in several different ways in a NITF image segment. The BANDSB TRE contains the most information, followed by the BANDSA TRE, and the band subcategory settings contain the least information. ENVI will attempt to read wavelength information from a NITF file from each of those locations, in order, until wavelength information is found. If no information is present in any of these locations, the file is opened without wavelength information.

Les références

For more detailed information about the NITF/NSIF format and its components, see the technical specifications on the Reference Library for NITFS Users web site.


Discussion

This study provides one of the first landscape-scale efforts to explore spatial patterns and landscape drivers of dynamic surface-water connections between depressional wetlands and streams in the PPR. These VC wetlands were found to connect to streams predominately through merging with and being subsumed by other wetland features. Both small (2–10) and large (>100) wetland clusters (or complexes of surficially connected or consolidated wetlands) were common across the study area. The consolidation of wetlands was particularly common around lake features, many of which occur in open, flat basins in which excess water can result in 100% to almost 600% increases in surface-water extent (Vanderhoof and Alexander 2015) (Fig. 6). Initial rises in lake levels may merge wetlands with lakes, but wetlands may still retain wetland vegetation and function. However, as lake levels continue to rise, merged wetlands are completely subsumed by lakes and no longer function as independent depressional wetlands (Mortsch 1998). Features were observed to expand and contract in response to variable wetness conditions, connecting and disconnecting lakes, streams and wetlands. Previous work in the PPR documented variability in wetland-to-wetland and wetland-to-stream connectivity as surface water merges in low relief areas and/or wetlands fill and spill (Leibowitz and Vining 2003 Kahara et al. 2009 Shaw et al. 2013 Vanderhoof et al. 2016), and sought to predict connectivity based on storage capacity and spill point elevation (Huang et al. 2011b), temporal changes in surface-water extent (Rover et al. 2011), and wetland vegetation and water chemistry (Cook and Hauer 2007). This study sought to move from the prediction of connections for individual wetlands to explaining variability in the abundance of such surface-water connections on a landscape scale.

The probability of hydrologic connectivity has been most commonly linked to the proximity or distance between depressional wetlands and streams (Tiner 2003 Kahara et al. 2009 Lang et al. 2012). Yet this study found that substantial variation in the mean Euclidean and flowpath distance to stream for VC and NCO wetlands between ecoregions makes it extremely problematic to identify VC wetlands based on distance alone. For example within 400 m of a stream on the Des Moines Lobe, 78% of the VC wetlands were connected, while the Drift Plains had only 52% of the VC wetlands connected at that same distance. Consequently while mean distance to stream emerged as an important variable in explaining the abundance of SI and NCO variables, it was not ranked as important in explaining the abundance of VC wetlands. Instead, for VC wetlands, wetland arrangement (wetland to wetland distance), as well as the temporal dynamics of surface-water expansion, also need to be considered. Additionally, in landscapes with little relief, flowpath distance from a fixed spill point to a fixed stream entry point may be less relevant. Surface flows connecting wetlands to streams in this area may not follow a single, theoretical flowpath, but instead are likely to expand and spread across the flat surface as excess water accumulates in a catchment.

The variables considered in the models represent several different factors in determining landscape-scale connectivity including (1) wetland abundance, (2) wetland arrangement (distance variables), (3) the availability of surface water connections (stream and lake abundance, surface water extent), and (4) potential influences on water accumulation and flow (topography and land use variables). However, across the PPR, variability within and between these variables is intrinsically tied to variability in landscape age (since last glacial retreat) and corresponding drainage development across the region (Ahnert 1996). The last maximum glacial extent (the Wisconsin glacier) diverged around the Lowlands ecoregion, leaving the older landscape (>20,000 BP) with a well-developed drainage network (Clayton and Moran 1982). In contrast, the Wisconsin glacier retreated from the Missouri Coteau and Drift Plains ecoregions by 11,300 BP, meaning the drainage system is still developing in these ecoregions. In ecoregions with low drainage development, surface water is being stored in glacially formed depressions (Winter and Rosenberry 1998 Stokes et al. 2007), resulting in an inverse relationship between stream density and surface-water extent (Table 10). The drainage network in the PPR is also increasingly modified with the expansion of ditch networks and tile drainage in association with agricultural activities (McCauley et al. 2015). Ditches, pipes and field tiles can increase connectivity between waterbody features, however, both filling wetlands with soil and lowering the water table through increased water withdrawal can decrease expected surface-water connectivity (DeLaney 1995 Blann et al. 2009 McCauley et al. 2015). Our finding regarding the importance of predicted anthropogenic drainage may be related to the relation between land use and wetland connectivity and wetland loss (Miller et al. 2009 Van Meter and Basu 2015). These potential interrelations merit further study.

It is critical to note that the aim of this analysis was not to document all surface-water connections, recognizing limitations of our input datasets, but instead, to characterize spatial patterns for a subset of wetlands that merge with a stream over a wide range of wetness conditions and a relatively large study area. A complete analysis of wetland-to-stream connectivity would also need to consider narrow and temporary (e.g., in response to rain events and peak snow melt conditions) surface connections, groundwater connections, as well as chemical and biological connections (U.S. EPA 2015). This analysis allowed us to identify regionally relevant parameters that can provide a preliminary means to explain variability in the abundance of wetlands that affect streamflow and are subject to regulatory programs. Patterns in VC wetland abundance, for example, demonstrate that wetland abundance and arrangement in combination with expanding surface-water extent provides important opportunities for wetlands to merge with streams, a finding consistent with related literature. Limitations of this study are potential bias due to unmeasured variables and the glacial history of the landscape, which may complicate efforts to apply these variables to different ecoregions.

Further, patterns in the mechanism of connection show that in addition to SI wetlands, depressional wetlands and open waters can play critical roles in moving surface water across the landscape. These findings are particularly relevant to floodplains, permafrost landscapes and formerly glaciated landscapes that often exhibit low topographic gradients, low rates of infiltration, and low stream density. Runoff events in these landscapes rarely satisfy the threshold surface storage volume so that excess surface water (precipitation inputs exceeding soil infiltration and evapotranspiration) tends to accumulate instead of leaving the watershed as stream discharge (Hamilton et al. 2004 Yao et al. 2007 Aragón et al. 2011 Kuppel et al. 2015), leading to wetland consolidation and surface-water connections.


4. Challenges of measuring population exposure to SLR

This review found numerous challenges in the literature when measuring population exposure to SLR and related impacts. The estimates are based on gridded datasets that include DEMs, flooding and extreme sea-levels, and population distribution. Hinkel et al (2014), Lichter et al (2011), and Mondal and Tatem (2012) have shown that estimates of land and population exposure to SLR and coastal flooding vary significantly according to which datasets are employed. Final estimates depend on the input data, and decisions about key parameters such as time horizons, warming scenarios, and ecological or socioeconomic processes and feedbacks including adaptation measures assumed. Four main challenges are discussed here based on our review and analysis.

First, estimates of populations exposed to SLR rely on elevation data to define zones of inundation or potential hazard parameters (Small and Nicholls 2003, Ericson et al 2006, Mcgranahan et al 2007, Lichter et al 2011). Global DEM datasets include GLOBE which combines six gridded DEMs and five cartographic sources the US Geological Survey GTOPO30 which combines eight raster and vector sources of topographic information and the Shuttle Radar Topography Mission (SRTM) elevation data with a vertical resolution of 1 m and spatial resolution of approximately 90 m at the equator (Mcgranahan et al 2007, Lichter et al 2011, Brown et al 2018). Any DEM has vertical and horizontal uncertainties (Wolff et al 2016). For example, while there are enhanced versions of SRTM data (see Mondal and Tatem 2012, Kulp and Strauss 2019), SRTM datasets have uncertainties in urban and forested areas where radar technologies capture infrastructure or tree elevation as opposed to ground elevation (Dasgupta et al 2011, Marzeion and Levermann 2014). Global mean error in SRTM's 1–20 m elevation band has been found to be 1.9 m (and 3.7 m in the US) (Kulp and Strauss 2019). Choice of DEM also has significant effects on estimates. Hinkel et al (2014) found the estimated number of people flooded according to the GLOBE elevation model to be double that calculated using the SRTM elevation model, and Kulp and Strauss (2019) found that using CoastalDEM instead of SRTM resulted in estimates of population exposure to extreme coastal water level that were three or more times higher. Improvements in elevation datasets are required to enable accurate estimates of land area exposure (Gesch 2009).

Second, estimating coastal floodplains and potential coastal flooding requires datasets on extreme sea levels. A significant limitation of flood analysis at all scales is limited availability of accurate datasets (Gesch 2009, Mondal and Tatem 2012, Neumann et al 2015). In their analysis of coastal flood exposure, Muis et al (2017) found that correcting vertical data of sea-level extremes and land elevation for two sea-level datasets—DINAS-COAST Extreme Sea Levels (DCESL) dataset and the GTSR dataset—resulted in an increase of 16% and 20% respectively in flood exposed land, and 39% and 60% respectively for exposed populations. Moreover, there are other drivers of flooding including storm intensity, and climate change affects frequencies, magnitudes, and tracks of storms thereby yielding low confidence in how storm surges and extreme sea levels may alter over time (Marzeion and Levermann 2014, Brown et al 2018, Knutson et al 2019). Hazard parameters must be set within models, but it is not always clear which hazard parameters to select, or whether to select extremes or means.

Third, estimates of population exposure to SLR require population distribution datasets. Key datasets are the Gridded Population of the World (GPW), the Global Rural Urban Mapping Project (GRUMP), and LandScan Global Population database, all of which are developed from census data. Census data are available by census accounting units, with uncertainty in the spatial distribution of populations within each unit. GPW was the first global and widely available dataset that transformed census data to a grid it emphasises input data rather than modelling distributions (Nicholls et al 2008a). GRUMP combines population data with census units, allocating people into urban or rural areas to coincide with UN estimates and using an urban extent assessment derived mostly from the night-time lights dataset of the US National Oceanic and Atmospheric Administration (NOAA) (Mcgranahan et al 2007, CIESIN, IFPRI, World Bank and CIAT 2011, Mondal and Tatem 2012). LandScan disaggregates census data within administrative boundaries based on weightings derived from land cover data, proximity to roads, slope, and populated areas (Bhaduri et al 2007, Mondal and Tatem 2012). As always, all these datasets have limitations. Spatially detailed census data are often not available for low-income countries some census data are over 10 years old informal settlements and undocumented people might not be accounted for in census data and datasets that use night-time lights as a proxy for population can miss smaller coastal settlements with limited development and where electricity supply is intermittent or unavailable (Dugoua et al 2017). Different datasets produce differing population distributions. An analysis of variation in estimates of populations in LECZ as derived from LandScan and GRUMP found that eight of the top ten locations with the largest differences in estimates were small low-lying island countries or territories, including for example Tuvalu (Mondal and Tatem 2012). Consequently, the limited spatial resolution of census data means there is uncertainty as to the location of populations relative to SLR and its related hazards (Small and Nicholls 2003, Foley 2018).

Finally, many studies set specified levels of future GMSLR based on different emission and warming pathways over the coming decades, centuries, and millennia (e.g. Pfeffer et al 2008, Brown et al 2016, Clark et al 2016, Mengel et al 2016). Debates regarding GMSLR estimates and forecasts relate to spatial variations, temporal uncertainties, rates of ice mass loss especially from Greenland and Antarctica, ocean dynamics, emission scenarios, and changes in gravity associated with water mass redistribution, leading to significant regional variations from the global mean (Clark et al 2016, Jevrejeva et al 2016, Mengel et al 2016, Geisler and Currens 2017). Subsidence and isostatic uplift further affect local sea level projections (Hinkel et al 2014, Erkens et al 2015, Brown and Nicholls 2015). There are temporal uncertainties in forecasting GMSLR associated with projected rates (e.g. Bindoff et al 2007, Solomon et al 2007) natural, multi-decadal oscillations (Sérazin et al 2016) and the pace of ice mass loss from the Greenland and Antarctica ice sheets (Tol et al 2006, Hansen 2007, Pfeffer et al 2008, Nicholls et al 2011, Jevrejeva et al 2016). Thus, future GMSLR is uncertain, something that many studies address by using higher and lower bounds of GMSLR in their analyses (IPCC 2019, c.f. Marzeion and Levermann 2014).

In summary, reliability of the estimates of both current and future population exposure to GMSLR and related hazards depend on the reliability of input datasets, with precision not always reflecting accuracy. Global quantitative estimates rely on global datasets, yet there are widely acknowledged challenges in estimating land elevation, extreme sea levels, population distribution, and GMSLR scenarios. These problems are amplified for studies seeking to estimate population exposure to GMSLR in the future. For example, the uncertainties in current population distribution estimates mean that future estimates also have large uncertainties.


The Shp2Vec Tool

The Shp2Vec (shape file to vector data) tool is in the SDKEnvironment SDK dossier. This tool takes vector shape data and creates the BGL files used by Prepar3D. The vector shape data is in standard ESRI shape file format. This format includes three file types, .shp (shape data), shx (shape index data), and .dbf (database file containing attributes of the shape data). The ESRI shapefile is a public domain format for the interchange of GIS (geographical information system) data. The wide availability of tools which support the shapefile format and the fact that the format is publicly documented made it the logical choice as the input to the Shp2Vec tool.

The Shp2Vec tool is command line driven, and takes the following parameters:

Le chemin points to the folder containing all the shape data. Use a single period to specify the current folder. All shape files in the specified folder, but not any sub-folder, are examined by the tool if the filename contains the chaîne de caractères as part of the filename. The first three characters of a file can be anything, but all the remaining characters, except the extension, must be identical to the string. As a convention, the first three characters are set to FLX for airport boundaries, HPX for hydro polygons, and so on (see the table below for a full list), and then the common string is set to the quad numbers. The quad numbers can be located in the Base File Information grid (for example, Hong Kong SAR is in the quad 78 24). The Shp2Vec tool then simply looks for files with the quad string present in the name. For example, if you look at the filenames in the SDKEnvironment SDKVector ExamplesExample1SourceData folder you will see that they all have 7824 as the common string. This means that entering the following line will process all the shape files:

Of course, other file naming conventions could be used. The default behavior of the tool is to provide replacement data for the quad cell. The flag -ADDTOCELLS is optional, and simply indicates the new data should be merged with existing data, and not replace it.

Performing a task with the Shp2Vec tool, such as replacing vector data, or perhaps using surfaces to exclude autogen or land classifications, or to flatten an area to use as an airport boundary, the following general process should be followed:

  1. Use a shape file editor to create the vector data, or surface shapes, that are the basis of the change. A shape file editor is ne pas provided as part of the SDK. There should be one flavor of data per shapefile. Whereas most vector types only require 2D co-ordinates, ensure that vector data for AirportBounds and WaterPolys is 3D (that is, includes elevation data).
  2. Create a single folder with the shapefiles in it, named according to a convention but fitting the format described above. Each shapefile consists of a .dbf, a .shx, and a .shp file.
  3. Add to the folder one of the proprietary XML files supplied with the SDK for each flavor of data. These XML files provide information to the tool. It is very important to point out that they should not be edited, the GUIDs and values in them are hard-coded in Prepar3D, and there is no value in altering the content of these files. However, it is important to rename them within the folder to match the naming of the shape files. So for example, the XML file FLX7824.XML is named to match the airport boundary data of Hong Kong SAR airport contained in the FLX7824 shapefile.
  4. The .dbf file can be edited in a shapefile editor or dbf editor. Usually these edits take the form of replacing GUIDs to match the task you wish to complete. Notice that the columns of the .dbf file exactly match the data definitions in the XML file.
  5. Run the Shp2Vec giving your folder as input.

The table below links to typical XML files, which are all used in Shp2Vec Example 1, except the exclusions vector data, which is used in Shp2Vec Example 2.

The .dbf file contains two columns, UUID and GUID. Enter the following GUIDs in the GUID column to achieve flattening, or Autogen or land class exclusions. Airport boundaries are one example of the use of Flatten + MaskClassMap + ExcludeAutogen.

The .dbf file for exclusion polygons have a GUID column, and there are three options for what to enter here:

1. Exclude all vector data by using a null GUID (all zeros).

2. Exclude general classes of features that have an attribute block (for example, all roads or all water polygons) by using one of the GUIDs from the Vector Attributes table. Note that some of the entries affect vector autogen associated with the excluded feature.

3. Exclude specific types of shapes (for example, only one lane gravel roads or only golf course polygons) by using one of the GUIDs listed in Vector Shape Properties GUIDs.

Remarques
  • The Shp2Vec tool does not process vector data that crosses 180 degrees Latitude, or the Poles.
  • The clip levels are the defaults used by Prepar3D Les données. Clip level 11 is QMID level 11. Setting higher clip levels will create more detailed data, but at the expense of size and performance. Note the use of clip level 15 for freeways.

Vector Attributes

The following table gives the GUIDs that apply for each type of vector data. Refer to the example XML files on how they are used.

F = traffic moves de reference node (one direction, cars drive away from vertex 0 towards vertex N).

T = traffic moves towards reference node.

Remarques
  • The unique IDs that are marked as "does not go into the simulation", are used to troubleshoot issues with the data creation process.
  • The texture GUIDs (noted in the Attribute Block column) reference into in the Scenery Configuration File.

Shp2Vec Sample 1: Hong Kong SAR Area

Le Vector Examples/Example1/SourceData folder includes all the files for all the types of vector data present around Hong Kong SAR. To run the sample type the following in the command line, after navigating to the SDKTerrain dossier.

The BGL file will be written to the same folder as the data, an example of the output is in the Vector Examples/Example1/Output dossier. The command-line output will give some statistics when the tool runs correctly, for example the output from running the tool with the above example data is shown below:

Shp2Vec Sample 2: Excluding and Replacing around Hong Kong SAR (VHHH).

Le Vector Examples/Example2/SourceData folder includes a sample excluding and then replacing AirportBounds geometry around Hong Kong SAR. To run the sample type the following in the command line, after navigating to the SDKTerrain dossier.

Note the importance of the -ADDTOCELLS flag to add this data to the existing vector data. In the TmfViewer tool, the new airport boundary is shown in the following image.


Use GIS software to query spatial data.

Spatial data updates are accessed, read, interpreted and edited to ensure they are in an acceptable format to meet functional requirements .

Entities and attributes are used to display spatial information that will assist in the delivery of spatial information services .

Entity and attribute queries of spatial data are used to generate summary results.

Results from queries are used to present spatial data graphically according to organisational guidelines .

Entity and attribute queries are applied when using univariate statistics to explore the dataset.

Routine spatial data problems or irregularities are solved in the course of the activity or via consultation with relevant personnel .

Keyboard and computer hardware equipment are used to meet functional requirements on speed and accuracy and according to OHS requirements .

Solve problems using GIS software.

Existing spatial and aspatial data is adjusted to integrate with new data to meet documentation and reporting requirements and to add to personal learning and organisational intelligence.

Geospatial techniques on appropriate software are used to combine spatial layers data to solve problems, highlight selected data features and improve the visual aspect and understanding of the project.

Spatial overlay techniques are used to solve problems and generate results pertaining to the spatial project as specified by relevant personnel.

Cartographic integrity is tested and validated to solve accuracy and quality problems.

Produce reports based on basic spatial analysis.

Map or plans are integrated into project reports.

Results, summary statistics and graphs from a mapping application are incorporated into a project.

Legal and ethical requirements are adhered to according to organisational guidelines.

Spatial dataset to be archived is manipulated where necessary to ensure completeness.

Metadata is created according to accepted industry standards.

New and existing spatial data is stored and archival details are recorded according to organisational guidelines.


Merging DEMs or other raster datasets and clipping Raster dataset to vector line? - Systèmes d'information géographique

GIS Methods

For GIS analysis of the trails and hikes in Rocky Mountain National Park, the software package ArcGIS from ESRI was utilized. This allowed for convenient spatial analysis, map genernation, and information storage for this entire endeavor.

Traitement de l'information

After all of the data needed was identified and collected, data procressing could begin. The beginning layers included a Rocky Mountain National Park (RMNP) boundary shapefile, bounding quads shapefiles, RMNP trails and trailhead shapefiles, lakes and ponds shapefiles, streams and rivers shapefiles, roads shapefile, cities shapefile, counties shapefile, elk and bighorn sheep winter ranges shapefiles, and a digital elevation model (DEM) grid. The first step in data processing was to define the study area was by including all bounding quads that contain some part of Rocky Mountain National Park. Additionally, a trail segment was digitized representing the well known Keyhole route to the summit of Long's Peak.

Trail Digitization

Then, a common projection was chosen for the project. A projection is the conversion of a spherical object to a flat surface (Theobald, 2007). The UTM North American Datum 1983 projection with the GCS 1983 North American coordinate system was chosen because UTM (Universal Transverse Mercator) projection is broken in to a grid of 60 zones each 6° wide with 0.5° of overlap and stretching from 80°N to 80°S which allows for a maximum error of 1 per 2,500 for each zone (Theobald, 2007). This projection is best used for small areas, such as Rocky Mountain National Park, because minimizes distortion shape and angles while distorting area (Monmonier and de Blij, 1996). This is known as conformality. This project&rsquos zone of interest is 13N. Most of the data was already in this common projection but each layer was checked to confirm. Any data that was not already in UTM North American Datum 1983 Zone 13N was converted by changing the projection in properties table.

Next, a shapefile was created from XY data giving the coordinates for place names of mountain summits and waterfalls. A spatial reference had to be defined for the new shape file so that it could be projected along with the rest of the data and the projection was defined as UTM North American Datum 1983 Zone 13N, the common projection for the project. The data was then verified by overlaying the place names over a DRG quad to make certain the points lined up.

Then, a file geodatabase structure was conceived and a working file system was defined. The file geodatabase system was chosen to ensure adequate memory capacity. File geodatabases have 1 TB of file space which allows for large data storage, faster query performance, and the ability to operate across different operating systems (Theobald, 2007). File geodatabases have a hierarchial file organization starting with the feature data set, which defines the spatial extent and projection of the geodatabase (Theobald, 2007). The feature dataset also contains the feature classes, which are points, lines, or polygons that share the same type of geometry (Theobald, 2007). Any raster data such as grids are stored outside feature datasets but still within the file geodatabase. There are also relationship classes that store relationships between features so behavior can be modeled, however none were used in this project (Theobald, 2007). This project had two file geodatabases. The first stored all raw and processed data including all of the hikes derived from combining individual trail segments through data analysis and the base map. The second file geodatabase stored the updated trail dataset as well as the zonal statistics tables and summarized hike tables.

Within the trail dataset, a field called shape_length contained a value that represented the flat-line length of the trail segment. In order to obtain a more realitic length for each segment, the elevation differences in the trail were accounted for. To achieve this, the surface length tool under 3D Analyst in Arc Toolbox was used. This created an additional field in the trails data table called surface_length.

All of the trail vector data was converted to raster format at this time for future data analysis using the ployline to raster conversion tool in Arc Toolbox. Before the conversion however, three fields had to be added. The first field was called raster_ndx, which was populated with a value of one. This value was then used to assign a value of one to each of the raster cells during future raster conversion. The next field was called difficulty_index. This field was left null and would be used to store the trail difficulty ratings that would be calculated later. The last field was called hike_id, which was a join field for summary values that would also be calculated later.

The data including trails, roads, rivers and streams, lakes and ponds, cites and counties, and the place name data could then be clipped to include only points, lines, or raster cells within the coordinate bounds of the RMNP boundary. This used several different tools from the ArcToolbox including the feature clip and raster clip.

At this point, data analysis could begin. First, a hillshade of the DEM was constructed using the Surface Analyst function in ArcGIS and the other map layers were layered with transparency on top of the hillshade to create a relief-looking map.

Then, zonal statistics were performed on the trail segment rasters. Zonal statistics provides summary statistics for each zone in a zone layer and only integer raster data can be input as a zone layer (Theobald, 2007). The parameters of interest were maximum elevation, minimum elevation, and mean elevation.

To be able to join and relate tables there must be a common table field, most commonly a name or number ID (Theobald, 2007). In this case, a field called seg_oid was added to the attribute table for the trail raster data and was populated with the corresponding object id from the trails dataset. The individual zonal statistics tables for each trail segment were then merged using merge tool in Arc Toolbox. This table was then joined to the updated trails dataset, which provided original trail information with the three added fields, raster_ndx still with just a value of one, and the other two still null, and the zonal statistics for each trail segment contained in the trails dataset.

Using the field calculator, the Trail Difficulty Rating (TDR) was derived using the following equation:

At this point, the difficulty_index field was populated with the results of the field calculation. This leaves the hike_id field still null.

The next step in spatial analysis of the trails in RMNP using data queries to select trail segments based on different criteria to create theme hikes for potential patrons. To this point, all trail data were composed of a network of separate trail segments. To create meaningful information from the compiled trail data, the concept of a hike was formulated. A hike was defined as any trail segments that connected a trailhead to a specific destination. These hikes included hikes to lakes, hikes to waterfalls, hikes to mountain summits, hikes through wildlife habitat, hikes to historic sites, and family oriented hikes. To identify destinations for hikes locational selection queries were performed to selct trail segments within: 10m of a lake or pond, 25m of a waterfall, 100m of a summit, 100m of a historic site or structure, 100m of bighorn sheep winter range, and trails with a centriod within a polygon defined by elk winter range. The winter ranges for the two wildlife species were used because the animals tend to group in the winter and migrate to lower elevations. These factors would lead to a better chance of seeing wildlife and not having to hike as far to see them.

From the results from each of the preceding queries, adjacent trial segments leading back to a trailhead were also selected and were exported as one new shapefile. Finally, the hike_id field was populated with a name for these combined trail segments. The TDRs were then summerized on the hike_id field, creating a new table for each hike that contained hike_id, the summed difficulty_index, and trail length in miles. These summary tables were joined to each hike dataset on the hike_id field. Each joined table was then imported into the first file geodatabase.

Finally, map creation could begin. First a base map was generated that included the hillshade and base data including summits and waterfalls, which were derived from the place name data, roads, streams, lakes and ponds, park boundary, trails, as well as cities and counties.

A map was then created for each individual hike theme. These maps highlighted hike paths corresponding to the appropriate theme and were color-coded according to their TDR.

We believe that the maps created here will have utility among potential RMNP patrons. Thier ability to plan more enjoyable excursions into RMNP will be enhanced through the use of our analysis. The structure of this website allows would-be RMNP hikers to match their skill level and destination interest to a hike cutomized to their needs. It is our hope that more people will, through the use of this website and the analysis within, get outside and enjoy all of the beauty and breath-taking wonder nature has to offer in our great system of national parks, especially, Rocky Mountain National Park.