[postgis-users] PostGIS and TIGER/GML

[Paul Ramsey]

Joshua Lieberman wrote:

> Not sure we have met, but I've been messing about in OGC for a few
> years and, following a company transition (Syncline to Traverse +
> EoGeo), I am becoming very involved in the use of open-source
> software. I have also benefitted greatly from the materials published
> out of the recent open-source / MapServer Users meeting and am now
> regretting that I was unable to attend.

There's always next year! Make sure you have free time in June/July 2005
:) Refractions will be there in spades, and have some excellent goodies
to show off.

> It was necessary, however, to simplify the TIGER/GML data
> considerably in order to serve it up.

This is what we have found working with our TIGER client. In order to 
map it "nicely" with good cartographic results, some substantial 
processing is required, both to make things label nicely at local zoom 
levels and to provide generalized views at county/regional/state zoom 
levels.

Our approach right now is to write an FME script for data loading, that 
will process the TIGER data into multiple output tables in postgis, 
suitable for use in geocoding and also in cartographic mapping. Among 
the tables we are populating are things like:

- tiger_roads_local
- tiger_roads_local_cartographic
- tiger_roads_connector
- tiger_roads_connector_cartographic
- tiger_rails
- tiger_ferries
- tiger_water_lines
- tiger_water_polygons
- tiger_places
- tiger_tracts
- tiger_county_subunits
- tiger_counties
- tiger_zipcodes
- tiger_landmarks_polygons
- tiger_landmarks_points

Basically we are denormalizing and in places generalizing (in the 
"cartographic" tables) TIGER for easier use for analytics and mapping. 
We are also doing a mapserver map file that uses the tables we are 
creating to make really nice base maps.

Since TIGER is freely redistributable, when we have run the whole data 
set, we will re-export the results as dump files by state, so people can 
load up the tables they want. Hopefully the postgis user population is 
not so large that they will give us a massive bandwidth bill on the 
downloads.

> I am curious now about any plans or ideas for PostGIS to support
> spatial data with a structural complexity more akin to what GML is
> capable of encoding, perhaps by being able to use complex objects in
> other than geometry columns, or by spreading complex properties among
> several tables. 

Yes, but not with any new capabilities (well, maybe one or two). I have 
a couple projects now where a topology model would be useful, and am 
going to do some experiments. Fundamentally, a topology model, with some 
triggers, and a new "polygonize" function should allow us to store 
topology but also draw the contents of the database onscreen in pretty 
pictures.

> I would be interested in your views on this, or to
> chat at some point about it. It's a discussion to have with 
> developers of Geoserver and MapServer as well. It appears that the 
> deegree developers are themselves thinking along the lines of using 
> whatever object serialization the java package "hibernate" performs,
>  which worries me somewhat.

I think the database should do the work. One of the first add-ons to our 
uDig project will be a module for handling the editing of topology data, 
in Oracle and PostGIS. Other than line manipulation, the database should 
do the rest, updating built features etc. The mapping side should just 
read the built features.

Oh, one new PostgreSQL feature might help us a lot. "Materialized 
views". There has been some work on that lately (I talked to a guy at 
OSCON who is working on them) and they would help with complex things 
like a materialized view of a local level table that generates a 
simplified regional level cartographic view on the fly.

> We do have some development capabilities to contribute to addressing
> this problem, if a consensus can develop on what approach to take.

Well, we should start by examining the Oracle topology model and 
deciding what conventions we would like in a topology model of our own. 
Once we define the column names and link tables, we can write it up and 
do some PL/PGSQL triggers to maintain some of the basic relationships of 
a topology model.

Paul