Existe-t-il un moyen gratuit ou bon marché de coder un grand nombre d'adresses et de renvoyer ou d'annexer les secteurs de recensement et de bloquer les données?
Il existe un certain nombre de façons de géocoder une adresse et d'obtenir la lat longue, mais j'ai vraiment besoin d'obtenir les données des secteurs de recensement et des blocs.
Réponses:
Ok Ben, voici mes hypothèses:
1) Vous avez déjà vos données (j'avais quelques points d'adresse dans un fichier de formes et j'ai téléchargé des fichiers de formes de secteurs de recensement et de blocs de recensement pour le Missouri).
2) Vous avez déjà géocodé vos points d'adresse et vous êtes à l'aise de projeter les données.
3) Vous êtes à l'aise avec une solution OGR / PostGIS (toutes deux gratuites).
Voici quelques notes d'installation si vous ne disposez pas de ces logiciels: Comment installer PostGRE avec le support PostGIS . (Par BostonGIS. S'il vous plaît, ne vous offusquez pas de leur titre, je pense simplement que c'est le meilleur mode d'emploi.) En outre, voici un , deux et trois sites décrivant comment installer GDAL / OGR avec des liaisons Python.
Mise en garde : Avant d'effectuer l'analyse réelle (c'est-à-dire lesST_Containséléments ci-dessous), vous devez vous assurer que toutes vos couches sont dans la même projection ! Si vous avez des fichiers de formes, il est facile de traduire d'une projection à une autre à l'aide de Quantum GIS (QGIS) ou OGR (ou ArcGIS si vous l'avez). Vous pouvez également effectuer la transformation de projection dans la base de données à l'aide des fonctions PostGIS. Choisissez votre poison ou dites-nous s'il s'agit d'une pierre d'achoppement.
Avec ces données, voici comment j'ai ajouté l'attribut tract et block à certaines données de points d'adresse à l'aide de PostGIS:
J'ai d'abord ogr2ogrimporté les trois fichiers de formes dans PostGIS:
Importez des adresses à l'aide d'ogr2ogr:
ogr2ogr -f "PostGreSQL" PG:"host=127.0.0.1 user=youruser dbname=yourdb password=yourpass" "E:\path_to\addresses.shp" -nln mcdon_addresses -nlt geometry
Importer des secteurs de recensement (Missouri) à l'aide d'ogr2ogr: le spMoWestsuffixe implique que j'ai déjà traduit mes données en pieds ouest du Missouri State Plane.
ogr2ogr -f "PostGreSQL" PG:"host=127.0.0.1 user=youruser dbname=yourdb password=yourpass" "E:\path_to\st_tract10_spMoWest.shp" -nln mo_tracts_2010 -nlt geometry
Importer des données de blocs (Missouri): Celui-ci a pris un certain temps. En fait, mon ordinateur n'arrêtait pas de planter et j'ai dû y mettre un ventilateur! Oh aussi, ogr2ogrne donnera aucune rétroaction, alors ne soyez pas percutant; assurez-vous de l'attendre et il finira par finir.
ogr2ogr -f "PostGreSQL" PG:"host=127.0.0.1 user=youruser dbname=yourdb password=yourpass" "E:\path_to\st_block10_spMoWest.shp" -nln mo_blocks_2010 -nlt geometry
Une fois les importations de données terminées, lancez PgAdmin III (l'interface graphique PostGREs), parcourez votre base de données et lancez quelques commandes de maintenance rapide pour que PostGREsql s'exécute plus rapidement en utilisant ces nouvelles données:
vacuum mcdon_addresses;
vacuum mo_tracts_2010;
vacuum mo_blocks_2010;
Ensuite, j'étais curieux de savoir combien de points d'adresse bruts j'ai importés, j'ai donc fait un rapide COUNT(*). J'ai l'habitude de faire un décompte au début d'une tâche comme celle-ci pour me donner un pied à terre pour les "contrôles de santé mentale" plus tard.
SELECT COUNT(*) FROM mcdon_addresses;
-- 11979
Dans la phase suivante, j'ai créé deux nouvelles tables, en ajoutant progressivement les attributs de tracts, puis les attributs de blocs, à ma table de points d'adresse d'origine. Comme vous le verrez, la ST_Containsfonction PostGIS a fait le gros du travail, créant dans chaque cas une nouvelle table de points, chacun gagnant les attributs des tracts et des blocs de polygones dans lesquels il tombait.
Remarque! Par souci de concision, je ne prends qu'une poignée de champs de chaque table. Vous voudrez probablement presque tout. Je dis presque parce que parce que vous devrez omettre le ogr_fidchamp (peut-être même d'autres?) Des tables que vous combinez, sinon PostGRE se plaindra que les deux champs portent le même nom.
(PS, j'ai fait un peu de surveillance ici tout en comprenant cela: http://postgis.net/docs/manual-1.4/ch04.html )
Créez une nouvelle table de points d'adresse avec des attributs de tracts: Notez que je préfixe chaque colonne de sortie avec un indice révélant dans quelle table elle a commencé (j'expliquerai pourquoi ci-dessous).
CREATE TABLE mcdon_addresses_wtract AS
SELECT
a.wkb_geometry,
a.route AS addr_route,
a.box AS addr_box,
a.new_add AS addr_new_add,
a.prefix AS addr_prefix,
a.rdname AS addr_rdname,
a.road_name AS addr_road_name,
a.city AS addr_city,
a.state AS addr_state,
a.zip AS addr_zip,
t.statefp10 AS tr_statefp10,
t.countyfp10 AS tr_countyfp10,
t.tractce10 AS tr_tractce10,
t.name10 AS tr_name10,
t.pop90 AS tr_pop90,
t.white90 AS tr_white90,
t.black90 AS tr_black90,
t.asian90 AS tr_asian90,
t.amind90 AS tr_amind90,
t.other90 AS tr_other90,
t.hisp90 AS tr_hisp90
FROM
mcdon_addresses AS a,
mo_tracts_2010 AS t
WHERE
ST_Contains(t.wkb_geometry, a.wkb_geometry);
Maintenez la table pour que PostGRE continue de fonctionner correctement:
vacuum mcdon_addresses_wtract;
Maintenant, j'avais deux questions ..
Le ST_Contains a-t-il réellement fonctionné? ..et .. Le nombre d'adresses renvoyées est-il logique compte tenu des entrées de données que j'ai utilisées?
J'ai pu répondre aux deux en utilisant la même requête:
select count(*) from mcdon_addresses_wtract;
-- returns 11848
Une réflexion rapide sur les pertes: tout d'abord, j'ai vérifié dans ArcGIS (vous pouvez également le faire dans QGIS) et il a renvoyé le même nombre. Alors, pourquoi la différence? Tout d'abord, certaines adresses sont tombées en dehors du Missouri, et je n'ai comparé que par rapport à un polygone de tracts du Missouri. Deuxièmement, après une analyse plus approfondie, il semble qu'il y ait eu quelques exemples de mauvaise numérisation dans les données des adresses. Plus précisément, bon nombre des points non capturés ST_Containsavaient des champs d'attributs vides, ce qui est un bon signe que quelque chose s'est mal passé pendant la numérisation; cela signifie également qu'il ne s'agissait de toute façon pas de données utilisables. À ce stade, je suis à l'aise avec les différences, car je pouvais raisonnablement revenir en arrière et améliorer les données, ce qui permet une analyse plus propre.
Pour passer à l'étape suivante, l'ajout de la table d'adresses / secteurs aux attributs des données de blocs a été ajouté. De même, je l'ai fait en créant une nouvelle table, en préfixant une fois de plus chaque champ de sortie pour indiquer la table dont il provient (le préfixe est assez important, vous verrez):
CREATE TABLE mcdon_addr_trct_and_blk AS
SELECT
a.*,
b.pop90 AS blk_pop90,
b.white90 AS blk_white90,
b.black90 AS blk_black90,
b.asian90 AS blk_asian90,
b.amind90 AS blk_amind90,
b.other90 AS blk_other90,
b.hisp90 AS blk_hisp90
FROM
mcdon_addresses_wtract AS a,
mo_blocks_2010 AS b
WHERE
ST_Contains(b.wkb_geometry, a.wkb_geometry);
Bien sûr, maintenez le tableau:
vacuum mcdon_addr_trct_and_blk;
La raison pour laquelle j'ai préfixé chaque champ de sortie était parce que si je ne le faisais pas, certains champs auraient le même nom, et il serait impossible de les distinguer les uns des autres dans le produit final (aussi .. PostGREs peut-être se plaignait à mi-chemin de cela, mais depuis que je renommais, je ne lui ai pas laissé la chance). Considérez, par exemple, les deux champs suivants des deux étapes ci-dessus. Vous pouvez voir pourquoi je les ai renommés ..
t.pop90 AS tr_pop90 -- would have been simply pop90
b.pop90 AS blk_pop90 -- also would have been pop90 !
Maintenant que nous avons une adresse avec un ensemble de données de tracts et de blocs, avons-nous toujours le même nombre de points?
select count(*) from mcdon_addr_trct_and_blk;
-- 11848 (thumbs up!)
Oui! Si vous le souhaitez, vous pouvez continuer et supprimer le premier tableau que nous avons créé mcdon_addresses_wtract,. Nous n'en avons plus besoin pour l'analyse.
En dernier lieu, vous souhaiterez peut -être exporter vos données à partir de PostGRE dans un fichier de formes ESRI afin de pouvoir les visualiser avec d'autres programmes, comme ArcGIS (il convient de noter que QGIS peut lire les données PostGIS sans problème). Si vous êtes intéressé, voici comment effectuer la conversion à l'aide d'ogr2ogr:
ogr2ogr -f "ESRI Shapefile" "E:\path_to\addr_trct_blk.shp" PG:"host=127.0.0.1 user=youruser dbname=yourdb password=yourpass" "mcdon_addr_trct_and_blk"
Enfin, lorsque vous exécutez cette commande, vous obtiendrez probablement des avertissements comme celui-ci:
Avertissement 6: Nom de champ normalisé / blanchi: 'tr_statefp10' à 'tr_statefp'
Cela signifie simplement que OGR a dû raccourcir ce nom de champ, car le nom de champ dans un fichier de formes ne peut être que très long.
Bien sûr, ce n'est qu'une des nombreuses façons d'accomplir ce travail.
La FCC dispose d'une API: http://www.fcc.gov/developer/census-block-conversions-api