[Gdal-dev] Arc Binary Coverages

Wed Nov 16 07:49:21 EST 2005

On Wed, Nov 16, 2005 at 02:29:18PM +0200, Ari Jolma wrote:
> Craig Miller kirjoitti:
> 
> >I'm not sure about librarian, but image catalog data is stored in the info
> >database.  Infolib allows you to work with info databases directly and has
> >been around since around 1990.  I'm not sure of the status of it these days
> >though.
> > 
> >
> 
> I found this: http://www.epa.gov/Region10/dbf2info.html#contents by 
> this: 
> http://www.intevation.de/pipermail/freegis-list/2001-February/000268.html 
> but the links to the actual software are dead.

You may try this:

http://web.archive.org/web/20020802025730/http://www.epa.gov/r10earth/dbf2info.html

In the archive the link to " The full source release is available in compressed"
works (gzip doesn't).

Markus

> Is the image catalog data 
> vital somehow? In some info-dirs of our data I see a lot of *.nit and 
> *.dat files but some of those are read by ogr?
> 
> Ari
> 
> >--Craig
> >
> >
> >-----Original Message-----
> >From: Ari Jolma [mailto:ari.jolma at tkk.fi] 
> >Sent: Tuesday, November 15, 2005 11:43 PM
> >To: Craig Miller
> >Cc: 'Matthew Perry'; 'Gdal-Dev'
> >Subject: Re: [Gdal-dev] Arc Binary Coverages
> >
> >Seems like the obvious solution is to write a new driver: "Arc/Info Binary
> >Coverage B"?
> >
> >I have very little experience with a/i binary coverages. Is there any way
> >(even non-ogr but non a/i) to read librarian and image catalog data now?
> >
> >Ari
> >
> >Craig Miller kirjoitti:
> >
> > 
> >
> >>Matt,
> >>
> >>A coverage contains one data layer, along with different types of 
> >>topology.
> >>These would all continue to be accessible if the Workspace was 
> >>considered the datasource.  They would all have the same name, but a 
> >>different type attribute.  Perhaps we would have to append something to 
> >>the coverage name to make it clear since OGIS (and as a result OGR) 
> >>doesn't support as many types as the Arc Coverage model, but rather 
> >>maps some of the types to a simple feature.  A name such as <layer> 
> >><type> would work.  For example, "Streams (ARC)".  This appears to be 
> >>more intuitive, informative, unique, and closer to the true name of the
> >>   
> >>
> >coverage that always using "ARC".
> > 
> >
> >>The workspace is also where the attribute database is stored and it 
> >>contains information such as Librarian data and Image Catalog data.  
> >>Right now, there is no way to add support for Librarian to the driver 
> >>(which is actually where I started looking at this).
> >>
> >>I was thinking that regions will continue to be supported with a name 
> >>such as <layername> - <region> <type>.  For example "Streams - 
> >>Lake_Wenatchee_Basin (region)"
> >>
> >>I'm still pretty confident that the two data models map perfectly onto 
> >>each other with exception to the fact that OGIS/OGR have smaller set of 
> >>supported layer types.  Naming conventions seems like an easy way to 
> >>work around this and still preserve the simple features nature of the OGR
> >>   
> >>
> >library.
> > 
> >
> >>--Craig
> >>
> >>
> >>-----Original Message-----
> >>From: Matthew Perry [mailto:perrygeo at gmail.com]
> >>Sent: Monday, November 14, 2005 2:52 PM
> >>To: Craig Miller
> >>Cc: Gdal-Dev
> >>Subject: Re: [Gdal-dev] Arc Binary Coverages
> >>
> >>Craig,
> >>
> >>There are good reasons to treat the coverage, rather than the 
> >>workspace, as the dataset. The biggest reason is that a coverage 
> >>contains multiple data layers (tics,lines, centroids, polygons or 
> >>points, etc). In addition ArcInfo's regions data model allows you to 
> >>store many spatially-related layers within a single coverage.
> >>
> >>If the workspace were the dataset and the coverage were the layer, 
> >>there would be no way to get at the region layers (or tics, or any of 
> >>the other supporting spatial data) within the coverage.
> >>
> >>I happen to work with regions occasionally so I'm very thankful for the 
> >>way OGR handles ArcInfo Coverages! ;-)
> >>
> >>matt
> >>
> >>On 11/14/05, Craig Miller <craig.miller at spatialminds.com> wrote:
> >>
> >>
> >>   
> >>
> >>>Is there a reason why the Arc Binary Coverage driver uses the Coverage 
> >>>directory instead of the Workspace that is traditionally used in 
> >>>Arc/Info?
> >>>
> >>>
> >>>
> >>>E.g. I would have expected to pass a directory to the workspace like 
> >>>/data/county and receive back a list of coverages in that workspace 
> >>>such
> >>>  
> >>>
> >>>     
> >>>
> >>as:
> >>
> >>
> >>   
> >>
> >>>Lakes - Type:Polygon
> >>>
> >>>Lakes - Type:Point (Polygon Labels)
> >>>
> >>>Lakes - Type:Linestring (Polygon boundary with line topology built)
> >>>
> >>>Roads - Type:Linestring
> >>>
> >>>Etc.
> >>>
> >>>
> >>>
> >>>Instead it asks for a path to the coverage /data/county/lakes and 
> >>>returns layers named things such as ARC.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>_______________________________________________
> >>>Gdal-dev mailing list
> >>>Gdal-dev at lists.maptools.org
> >>>http://lists.maptools.org/mailman/listinfo/gdal-dev
> >>>
> >>>
> >>>  
> >>>
> >>>     
> >>>
> >>--
> >>Matt Perry
> >>perrygeo at gmail.com
> >>http://www.perrygeo.net
> >>
> >>
> >>_______________________________________________
> >>Gdal-dev mailing list
> >>Gdal-dev at lists.maptools.org
> >>http://lists.maptools.org/mailman/listinfo/gdal-dev
> >>
> >>
> >>   
> >>
> >
> >
> >--
> >Prof. Ari Jolma
> >Kartografia ja Geoinformatiikka / Cartography and Geoinformatics 
> >Teknillinen
> >Korkeakoulu / Helsinki University of Technology POBox 1200, 02015 TKK,
> >Finland
> >Email: ari.jolma at tkk.fi URL: http://www.tkk.fi/~jolma
> >
> >
> >
> > 
> >
> 
> 
> -- 
> Prof. Ari Jolma
> Kartografia ja Geoinformatiikka / Cartography and Geoinformatics
> Teknillinen Korkeakoulu / Helsinki University of Technology
> POBox 1200, 02015 TKK, Finland
> Email: ari.jolma at tkk.fi URL: http://www.tkk.fi/~jolma
> 
> 

-- 
Markus Neteler     <neteler itc it>       http://mpa.itc.it
ITC-irst -  Centro per la Ricerca Scientifica e Tecnologica
MPBA - Predictive Models for Biol. & Environ. Data Analysis
Via Sommarive, 18        -       38050 Povo (Trento), Italy