[Gdal-dev] Arc Binary Coverages

[Ari Jolma]

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