[Gdal-dev] Indexing with non-square boundary

[Ed McNierney]

Avi -

Well, "serious" is probably too strong a word <g>.  But the tileindex
mechanism is intended to be a very fast test that is expected to produce
some false positives.  The intent is, of course, to eliminate the large
majority of possible data sources so only a very small number of candidates
need to be inspected in more detail.

While your situation requires support for relatively simple polygons, the
simplest generalized point-in-polygon test is quite a bit more complex than
a point-in-rectangle test.  We might not think we need to protect users from
themselves all the time, it would be easy to let a polygonal tileindex
scheme get out of hand, with excessively-complex index shapefiles.

The polygonal tileindex is a risky way to solve your problem.  You're
depending on the query function to use that information to provide the
result.  The tileindex is supposed to be an optimization tool, and the
output you get should be identical (except for performance) whether the
tileindex is present or not.  A polygonal tileindex would create situations
in which you would get one result if the index were used and a different one
if there were no index, and I think that's not a good situation.

     - Ed
  
-- 
Ed McNierney
Chief Mapmaker
Demand Media / TopoZone.com
73 Princeton Street, Suite 305
North Chelmsford, MA  01863
Phone: (978) 251-4242
Fax: (978) 251-1396
ed at topozone.com


> From: Ed McNierney <ed at topozone.com>
> Date: Thu, 09 Aug 2007 15:13:55 -0400
> To: <sysadmin at satshot.com>, <gdal-dev at lists.maptools.org>
> Conversation: [Gdal-dev] Indexing with non-square boundary
> Subject: Re: [Gdal-dev] Indexing with non-square boundary
> 
> Avi -
> 
> I do not think you can do that with GDAL and I could probably make a case
> that it's not really what gdaltindex is meant to do.  The modification to
> allow polygonal tiles instead of rectangular ones would have serious
> implications to any tileindex client software.
> 
> I have addressed a similar problem by simply loading my imagery metadata
> into a PostGIS table.  I can then do a very simple point-in-polygon query
> against PostGIS to determine exactly which source image is being used for a
> particular location.
> 
>      - Ed
>   
> -- 
> Ed McNierney
> Chief Mapmaker
> Demand Media / TopoZone.com
> 73 Princeton Street, Suite 305
> North Chelmsford, MA  01863
> Phone: (978) 251-4242
> Fax: (978) 251-1396
> ed at topozone.com
> 
> 
>> From: Avi A Blackmore <support at satshot.com>
>> Organization: Agri ImaGIS Technologies
>> Reply-To: <sysadmin at satshot.com>
>> Date: Thu, 9 Aug 2007 13:49:42 -0500
>> To: <gdal-dev at lists.maptools.org>
>> Subject: [Gdal-dev] Indexing with non-square boundary
>> 
>> Hi there,
>> 
>> I've run into a thorny issue with gdaltindex, when indexing our satellite
>> imagery set.  The imagery taken by the satellites is, of course, shot on
>> an angle: the satellites' paths around the Earth are not vertical, but
>> skewed on an angle of about 12-13 degrees.  The actual image files, of
>> course, are rectangular, which results in large black "null" areas in the
>> image.  We use UMN Mapserver to display the imagery, and make the black
>> null areas transparent, so that they don't cause a display problem.
>> 
>> The problem is, these null areas, while invisible when the image is
>> displayed, are still considered "part" of the image as far as gdaltindex
>> is concerned.  The bounding box is calculated from the corners of the
>> image file, not from the actual corners of the "non-null" parts of the
>> image.  
>> 
>> The result is that, when our site does a query on the image index layer,
>> we get a lot of spurious "hits" in our imagery list: images whose bounding
>> box intersects the current extents of the map even though the actual
>> "live" image data is well outside those extents.
>> 
>> So my question is, using GDAL/OGR, how would I create a tile index whose
>> bounding boxes are polygons that reflect the actual image path, and omit
>> the black null areas?  I haven't found a way to do this using gdaltindex.
>> -- 
>> Avi Blackmore
>> System Administrator/Programmer
>> Agri ImaGIS Technologies, Inc.
>> 
>> _______________________________________________
>> Gdal-dev mailing list
>> Gdal-dev at lists.maptools.org
>> http://lists.maptools.org/mailman/listinfo/gdal-dev
> 
> _______________________________________________
> Gdal-dev mailing list
> Gdal-dev at lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/gdal-dev