[Aust-NZ] Live CDs for the FOSS4G conference and DebianGIS

[Hamish]

Robert Coup wrote:
> Realise that the Cadastral/Topo stuff from LINZ are in proprietary
> ASCII formats, so they can't just be loaded into PostGIS or uDig. And
> Cadastral stuff is a DB dump - its 80+ tables (iirc) with only a small
> spatial component.

How "proprietary" are we talking here? Is the specification known?
ie is it unknown or just unusual? Is that "can't just be loaded" from a
technical (wrong layout) or fundamental (square peg into round hole)
meaning?  ASCII is good.

It is good news that we don't have to start from shapefiles, they may be
universal but parts of the format (DBF) are lossy and unnice.

What format are the DB dump tables? Something from Oracle?

It seems to be PostgreSQL/PostGIS would be the strongest candidate for a
target. (I'd guess Brent could answer that much better than me though...)



> topo data is ~4.5GB as shapefiles, but includes semi-irrelevant stuff
> like label points and boundaries of polygons as linestrings. At
> Koordinates we've normalised the cadastral stuff into some 'themed'
> layers - addresses (1GB), parcels (2GB), titles (1GB), etc by plucking
> selected stuff from the DB tables. About 50% of the cadastral data
> isn't relevant for most people - survey marks & observations.

Personally, I like to deal with intact raw data and scripts which can
reprocess that data whenever there is an upstream update or an
improvement to the conversion algorithm is developed.

But for the purposes of FOSS4G LiveCDs full of functional goodies, I am
sure we can compromise on some kind of "useful for most" collection.
It might be nice to throw other things on there like some LANDSAT and
NDVI satellite data. A diversity of data to showcase the diversity of OS
products, or someblurb like that.


> Thanks, I'll have a look. OSM is versioned, but we want to improve on
> LINZs data but at the same time be able to replace stuff with what
> LINZ has been improving offline. OSM has had some bad experiences with
> 'bulk' imports before (TIGER) so it'd need to occur in a structured
> but incremental fashion too.

Perhaps if the LINZ->PostGIS (or whatever) lossless scripts were written
first, then it would be much easier for OSM to extract the data in a
standardized/reusable/well tested way.

A FOSS license for the conversion scripts would benefit all of course. :)


regards,
Hamish




      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ