Modèle ETL : Travailler avec des fichiers locaux bien connus

bharold

À l'extrémité simple du continuum des modèles ETL se trouve le format le plus courant de tous - CSV, ou valeurs séparées par des virgules, et son proche cousin, la feuille de calcul Excel. De vastes quantités de données circulent sous ces formats - facilement partagés, lisibles par l'humain - quoi ne pas aimer dans ArcGIS ? Eh bien, ces choses !

• Pas de schéma propre intégré au format
• Les noms de colonnes ne sont souvent pas valides dans ArcGIS
• Les champs texte avec des valeurs numériques sont traités comme numériques
• La largeur des champs texte est supposée être de 8000 (CSV) ou 255 (Excel) octets
• Les champs entiers peuvent être traités comme des flottants en double précision
• Les valeurs nulles peuvent être codées avec zéro ou une autre valeur improbable
• La géométrie est souvent codée dans un format non pris en charge pour la création de classes d'entités

Prenez ce jeu de données populaire provenant de data.gov, miroir du portail open data de Washington :

D'abord, les données sous forme de carte :

Washington EV Population

Voici maintenant le fichier CSV source :

Problèmes de données CSV ou Excel

En rouge, je souligne certaines de ces violations habituelles suspectes. Les noms de colonnes contiennent des espaces ou des métacaractères, les codes postaux USPS peuvent avoir des zéros initiaux donc doivent être du texte, des zéros ont été utilisés pour coder les valeurs nulles dans les colonnes Electric Range et Base MSRP, Vehicle Location est au format WKT et 2020 Census Tract contient de grands entiers et un nom commençant par un chiffre.

Le jeu de données concerné est dynamique - il est régulièrement mis à jour - donc si vous êtes intéressé à l'utiliser, ou n'importe lequel des milliers similaires - vous voudrez automatiser la gestion de ces problèmes avec du géotraitement.

D'abord, un peu de recherche ! Dans le téléchargement du blog se trouve un outil script que j'ai utilisé pour scanner le fichier CSV afin d'obtenir les largeurs maximales des données, voici le code :

 

tbl = arcpy.GetParameterAsText(0)
d = arcpy.da.Describe(tbl)
flds = [f.name for f in d['fields'] if f.type == 'String']
mDict = {f:0 for f in flds}
with arcpy.da.SearchCursor(tbl,flds) as cursor:
    for row in cursor:
        for f in flds:
            if row[flds.index(f)]:
                mDict[f] = max(mDict[f],len(row[flds.index(f)]))
for k in mDict.keys():
    arcpy.AddMessage(f"""Le champ '{k}' dans la table d'entrée '{tbl}' a une largeur maximale de données '{mDict[k]}'""")

 

Cela donne :

Largeurs maximales des champs texte

 En ignorant la colonne Postal Code, dont la connaissance locale me dit qu'elle fait 5 caractères de large, je peux maintenant voir les largeurs requises par champ texte.

Je suis maintenant en mesure de concevoir un schéma qui gère correctement le fichier concerné. J'ai choisi ModelBuilder pour conserver mon traitement car il peut envelopper les fonctions principales de géotraitement et Python que je prévois d'utiliser. Le modèle final est celui-ci, que nous allons parcourir.

Modèle EVPopulation

La première étape consiste à imposer un schéma conçu. Cela se fait en utilisant le contrôle Field Map dans Export Table, copiant essentiellement les données dans une table en mémoire selon le schéma souhaité. Le contrôle Field Map vous permet de renommer, caster et même construire des champs très flexiblement.

Dans ce cas, il n'y a qu'un seul champ source pour chaque champ de sortie, donc l'Action est toujours First, et seules les propriétés du champ sont manipulées.

Field Map

En aval d'Export Table, la classe d'entités de sortie est créée en utilisant la table en mémoire comme modèle, les lignes (toujours sans géométrie) y sont ajoutées, puis la géométrie est créée à partir de la colonne WKT et les deux champs avec des nulls codés par zéro sont corrigés avec les outils Calculate Field (notez le traitement conditionnel). Enfin, le champ Vehicle Location est supprimé car superflu.

Avons-nous terminé ? Non ! La meilleure pratique est l'automatisation complète, et ces données proviennent du web.

L'URL utilisée pour le téléchargement du fichier n'est pas valide comme entrée Text File pour le géotraitement comme le modèle le souhaite. Il y a aussi un risque qu'un utilisateur utilise un fichier CSV d'entrée avec un nom différent de Electric_Vehicle_Population_Data.csv, ce qui déclencherait le field map dans Export Table à revenir au traitement par défaut des champs, annulant tout notre travail de conception du schéma.

Pour gérer à la fois l'entrée des données web et l'entrée avec un nom de fichier cohérent, le modèle EVPopulation est enveloppé dans un modèle parent, URL2EVPopulation :

URL2EVPopulationTéléchargement Web

D'abord un outil modèle Calculate Value télécharge les données actuelles vers un fichier nommé de façon cohérente et de type paramètre Text File, puis le modèle EVPopulation est appelé pour traiter les données. Voyez comment un simple extrait Python s'occupe de l'automatisation ? 😉

Même maintenant, nous avons automatisé la gestion des fichiers CSV ! J'ai un peu étendu le concept de "fichiers locaux bien connus" en allant chercher les données sur le web, mais aujourd'hui les fichiers sur internet sont locaux. Je peux planifier ou exécuter manuellement URL2EVPopulation quand je veux.

Les modèles et l'outil script sont dans le téléchargement du blog.