[Gdal-dev] OGR Questions

[Frank Warmerdam]

Curt Mills, WE7U wrote:
>>>2) Shapefile "hole" polygons:  Are there other OGR formats that do
>>>something similar?  Should I check whether the datasource is a
>>>shapefile and implement "hole" polygons only for them?
>>
>>I'm not sure what a hole polygon is.  A shapefile polygon file may
>>have Polygon and MultiPolygon geometries.  Till just recently multipolygons
>>were just returned as polygons, but Radim recently fixed this.
>>
>>What do you mean?
> 
> 
> In Shapefiles, there are "fill" polygons, and there are "hold"
> polygons in those filled polygons.  The direction of the vertices
> as you walk around the polygon tells you which it is, hole or fill.
> I've seen some implementations of Shapefiles where they ignore this.
> You end up with problems like this:  Puget Sound (Seattle Area) has
> a water polygon.  On it is an Island (Whidbey Island), that has a
> lake with an island on it.  Without holes, the Island itself might
> not appear, same for the lake on the island, and the island in that.
> 
> I've seen the same problem with a Shapefile of San Fransisco area.
> 
> I was wondering if some of the other formats that OGR supports might
> have a similar thing in them.

Curt,

An OGRPolygon objects consists of one outer ring and zero or more
inner rings.  The inner rings are holes.  The C API kind of hides this
fact, but you should be able to assume that the first ring is an outer
ring, and ony other rings are inner rings (holes).  Note that in the
simple features geometry model you can't make any assumptions about
the winding direction of holes or outer rings.

Some polygons when read from Shapefiles will be returned as OGRMultiPolygon.
These are basically areas that have multiple outer rings.  For instance, if
you had one feature that was a chain of islands.  In the past (and likely
even now with some format drivers) these were just returned as polygons with
the outer and inner rings all mixed up.  But the development code includes
fixes (for shapefiles at least) to fix this up and convert into a multi
polygon so you can properly establish what are outer rings, and what
are inner rings (holes).

> One more question:  If a system already uses libproj, libshape, and
> libgeotiff, might it cause problems at link time if the gdal library
> is linked at the end, and some of the three mentioned libraries are
> older?  I know that gdal uses all three of these, but I don't know if
> it's linking to them at that stage.  I'm still getting runtime
> segfaults with OGR, both with Shapefiles and with SDTS so far, when
> coordinate translation code is invoked.  I'm just about to test with
> the different link order (-lgdal first) to see if that solves the
> problem.

On unix platforms I often run into problems with more than one copy of
a shared library gets linked in at the same time.  I have especially
noticed this with PROJ.4 where I would have a version that was
embedded in the OGDI shared libraries, and another version loaded from
a standalone PROJ.4 library.  It seemed that either version might get
called at random from higher level code.

Note that the libproj.so is loaded after application startup with a
dlopen() call for use with the OGRCoordinateTransformation class.  This
may have some relation to the problem as well.

While not always trivial to arrange, it is intended that libgdal can
be built with external versions of the various libraries that are
sometimes embedded, like libtiff, libgeotiff, libpng, libjpeg and libz.
Factoring this out properly can be critical when GDAL is used in a
complex applications with other dependencies on the same libraries.

Best regards,

-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent