Support for iterating layer features in mapscript effectively

[szekerest]

In the current implementation (4.6.1) the features drawn on the map can be 
accessed using layeobj.getFeature which calls msLayerGetShape to provide 
random access to features based on a previous query.
Depending on the underlying data source it would be more convenient to expose 
msLayerWhichShapes and  msLayerNextShape functions as layer methods in the 
mapscript interface.


Tamas Szekeres

[sdlime]

Since Sean is trying to get out of the MapScript loop...

Steve

[sgillies@…]

Thanks, Steve. I'm happy to fix bugs, but I'm not interested in adding new
features to mapscript. My last bit of nagging is about tests and documentation:
i'm noticing that new mapscript features haven't been getting mentioned in the
API documentation and have no tests. 

[sdlime]

This one qualifies as a new feature for sure...

The last feature (and only feature) I have added is there as a documentation 
bug so in theory someone should pick that up. I'd do it myself if I new what 
friggin' website should be updated.

As for tests, are there (I imagine there are) instructions on how to that?

Steve

[szekerest]

If I have time to make this change I will post it as a proposed patch.
I would be disappointed if the mapscript line became out of support.


Tamas

[sdlime]

MapScript is going nowhere. Over time you are bound to have new people working 
on different parts of a project. I should be able to add the methods over the 
weekend...

Steve

[sdlime]

Ok, I have exposed the whichShapes and nextShape methods in MapScript (SWIG-only
at this point). I followed Sean's lead with the getFeature method so nextShape
returns a shapeObj and NULL when there are no more shapes to read. Also,
assuming users want to iterate a layer I've assumed that they would want all
layer items. We could make this an option- comments?

A simple script in perl looks like:

#!/usr/bin/perl

use mapscript;

$map = new mapscript::mapObj('test.map');

$layer = $map->getLayerByName('test');

$status = $layer->open();
die mapscript::msGetErrorString("\n") if $status != $mapscript::MS_SUCCESS;

$status = $layer->whichShapes($map->{extent});
die mapscript::msGetErrorString("\n") if $status != $mapscript::MS_SUCCESS;

while ($shape = $layer->nextShape()) {
  print $shape->{index} ."\n";
}

# clean-up...

The changes are in .../mapscript/swiginc/layer.i...

As an aside I think we can make ALL queries work like this thus eliminating a
second pass for data sources for which that is expensive. That is, a query
method would do what whichShapes method does...

Need to add a test for this. Will work with Sean.

Turning over to the PHP-MapScript component, and finally to documentation.

Steve

[szekerest]

Thanks Steve. It worked for me. It would be practical to support the 
possibility to give the search rectangle in the spatial reference of the map 
as well, since the map extent is used most of the time.

Tamas

[sdlime]

I'll have to check the underlying code, but I believe the extent passed to 
msLayerWhichShapes() must be in the SRS of the layer. So, for the time being it 
will be the responsibility of the calling program to ensure that's the case. 
Users have easy access to projection transformations via MapScript already.

If I can get all queries to work this way then those wrappers already contain 
the projection logic and the problem goes away.

Steve

[assefa]

Steve,

 Do you get a crash if you just do call to nextShape without doing a 
whichShapes ? I have this issue with php mapscript crahing in function 
msLayerNextShape. Is there a way to test for this ?

[assefa]

Added the functions whichshape and nextshape in php/mapscript. There is still 
the issue described in comment #9 that I did not fix.

[sdlime]

msLayerWhichShapes checks to make sure a layer is open so it's possible that 
msLayerNextShape could to the same check. It's driver specific though. I'll 
take a look.

Steve