[Gdal-dev] Arc Binary Coverages

Matthew Perry perrygeo at gmail.com
Mon Nov 14 17:52:05 EST 2005


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




More information about the Gdal-dev mailing list