#1071 closed enhancement (fixed)
Ability to load tiger data into PostGIS topology structure
Reported by: | robe | Owned by: | robe |
---|---|---|---|
Priority: | medium | Milestone: | PostGIS 2.0.0 |
Component: | tiger geocoder | Version: | master |
Keywords: | Cc: |
Description
We aren't sure if we'll get to this before PostGIS 2.0.0 is released, but the plan is to load tiger data edges, faces, and nodes (which Leo noted each tlid in edges does have a corresponding start and end node id) into the PostGIS topology structure. This will be both directly useful to many people building topogeometries against tiger data as well as a learning tool since tiger data is freely available.
strk may not like this, but we plan to skirt all his loading functions and go straight to the tables. The main reason is that a lot of people (e.g. local communities building boundaries and so forth where topology is very important use the tiger edges and the tlids (tiger's edge ids). The tiger tlids therefore have significance in meaning to be able to reconcile back easily with tiger data. So we need to maintain these to make it most useful.
Any rate that is the plan. This kind of borders between tiger geocoder and topology since the loader we create will probably piggy back at least a little bit on the tiger geocoder loader.
Change History (3)
comment:1 by , 13 years ago
comment:2 by , 13 years ago
Component: | topology → tiger geocoder |
---|---|
Milestone: | PostGIS Future → PostGIS 2.0.0 |
Resolution: | → fixed |
Status: | new → closed |
I moved this to tiger_geocoder since I am packaging it as part of that module.
This is a preliminary version that only loads specified cities and counties. Will add other loader options later. Committed at r7832 including documentation.
Watch out strk! Now I have the tools to mercilessly test your topology functions.
I like it. I don't think you should be using the standard functions to populate the tables.
Actually, once you're at it, you may proof test insertion into the "edge" table (rather than into the "edge_data" one) whereas the inserts should automatically and transparentely populate the real table (edge is currently a view).
I can't even remember why edge_data was there, probably something to do with foreign key and signed edge identifiers, which may be a non-issue anymore (it was pgsql 7.4 at time of writing)