[postgis-users] building a vmap db

[Mike Jackson]

Randy George wrote:

> I imagine it would
> be beneficial to keep vmap0 separate from vmap1 at least in a separate table
> set if not a separate db.

I guess I'll put them in seperate databases.


> I have not used ogr2ogr for vmap so I don't know
> how the output is organized.

It queries a layer from the dataset, and puts it directly into a table, something like this:

ogr2ogr -f PostgreSQL PG:dbname=vmap0 $DATA_URL -lco OVERWRITE=yes -nln polbndp_bnd 
'polbndp at bnd(*)_point'

You have to run that type of command for every layer in the dataset - ~55 if I understood the vpf 
layers correctly.


> For sure it would be best to merge the four
> continental categories into a single db. You would want to work out a way to
> eliminate the duplicate features in the continental overlaps. These were not
> consistent in the early vmap0.

I put them all of the vmap0 into a single db, so layer data from all 4 continents are inside each 
table. There are still only 55 tables.

I have no idea how to go about eliminating duplicate data from overlaps. This seems like it would 
be a fairly complex task. Do you know of the vmap1 data suffers from the same problem?


> Alternatively:	db vmap0	db vmap1
> 			  dn		   dn
> 			  po		   po
> 			  pp		   pp

This is basically how I have decided to arrange the data.


>   What would be the relative performance hit for placing all features in a
> single table with feature layers identified by field rather than as
> separated db/tables? This is not a huge amount of data. As binary dwg it was
> around 650Mb which I'm guessing would be comparable in PostGIS.

The vmap1 data (what is currently available, which is less than half by file count) is ~6 times 
larger than the vmap0. The current vmap1 data weighs in at 12GB uncompressed into vpf format. The 
missing half of the vmap1 data is mostly from europe, which is densely layered, so I imagine that 
the complete data set would be ~30-40GB.

--
mike