[UMN_MAPSERVER-USERS] MS RFC 22: Data adapter support

[Frank Warmerdam]

Tamas Szekeres wrote:
> Every vtable function definitely provide access to the corresponding
> layer object. Most of the
> functions have a direct layerObj *layer parameter. The only exception
> is LayerApplyFilterToLayer
> where the layerObj reference should be retrieved using the layer index
> if needed.

Tamas,

Cool.  To my embarrassment I never even realized there was
an ApplyFilterToLayer method in the vtable.  That certainly takes
care of my concern.

>> I'm also still feeling that the existing layer plugin mechanism could be
>> used to implement the equivelent to data adapters without changing any 
>> code
>> in mapserver.
>>
> I was thinking a lot of this approach but I couldn't find a convenient
> way to do this.
> Without changing any code I would be restricted to implement an externally
> loadable layer of  type MS_PLUGIN. Actually I would not want to write an
> externally loadable layer, and I cannot imagine how to configuration
> of the original layer will be brought into the picture.

I don't understand your point about not being able to imagine how
the configuration of the original layer will be brought into the
picture.  By way of illustration, I'm suggesting something like:


LAYER
   NAME "abc_raw_data"
   TYPE POLYGON
   CONNECTIONTYPE OGR
   CONNECTION "abc.mif"
   DATA "abc"
END

LAYER
   NAME "abc"
   TYPE POLYGON
   CONNECTIONTYPE FEATURECACHER
   CONNECTION "abc_raw_data"
   STATUS ON
   PROCESSING "MAX_MEM=100MB"
   CLASS
     ...
   END
END

So in the above case, the "abc_raw_data" layer is just used for data
access, and has no classes or other styling particulars.   The layer
"abc" is used for styling and and also implemented cached feature
semantics at the data access level.

In the above scenario it is assumed that FEATURECACHER is a built
in layer implementation, but the same approach could be applied for
plugins.

This seems somewhat analygous to the secondary layer approach
to tileindexes already implemented in MapServer, and seen in this
example:

LAYER
   STATUS OFF
   NAME "time_idx"
   TYPE TILEINDEX
   DATA "data/AIRS/testindex.shp"
   FILTERITEM "TIME"
   FILTER "%TIME%"
END

LAYER
     NAME 'AIRSRGB2'
     TYPE RASTER
     STATUS ON
     DEBUG ON
     DUMP  TRUE
     TILEINDEX 'time_idx'
     TILEITEM  'location'
     EXTENT -180.0 -90.0 180.0 90.0

     PROJECTION
         "init=epsg:4326"
     END
END


> You have mentioned to have a reference to another layer in the
> mapObj's layer list
> but it would be highly unmanageable from the perspective of the
> adapter developer.

I'm not sure why referring to another layer by name would be
difficult from the adapter writers perspective.

> It would also bring in a high degree of confusion from the user's
> point because she
> would be incited to define extra layers that should be definitely hidden.

This is a concern, but it seems to be a line we already crossed with the
above illustrated approach to tile indexes.

I'd add that some of the semantic confusion here comes from the fact
that we have a mixture of data access operations (different connection
types, filtering, etc) and layer presentation (classification, styling)
all mixed into the layerObj.

PS. I've taken the liberty of just replying to -dev.

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    | President OSGeo, http://osgeo.org