Okay they are all handled the same now… and throw IOExceptions like it says on
the tin.
Additional utility method:
- DataUtilities.visit( FeatureCollection, FeatureVisitor, ProgerssListener )
--
LogMeIn Central: Instant,
Andrea they are all now consistent, and throw an IOException at the first sign
of trouble.
Jody--
LogMeIn Central: Instant, anywhere, Remote PC access and management.
Stay in control, update software, and manage PCs from
On Sun, Nov 4, 2012 at 12:58 PM, Jody Garnett wrote:
> Yes - Processing collection throws IOExceptions, BaseFeatureCollection
> follows the "keep calm and carry on" moto.
>
> I was probably too quick in my evaluation, it calls
> progress.exceptionOccured( exception ) alloying the client code to de
> > Yes - Processing collection throws IOExceptions, BaseFeatureCollection
> > follows the "keep calm and carry on" moto.
> >
>
I was probably too quick in my evaluation, it calls progress.exceptionOccured(
exception ) alloying the client code to decide what to do …
> I believe this is a re
> Other things noticed:
> - is there any difference between the accepts method in the processing
> collection
> and the one in base collection?
Yes - Processing collection throws IOExceptions, BaseFeatureCollection follows
the "keep calm and carry on" moto.
> - BaseFeatureCollection can use so
On Sun, Nov 4, 2012 at 9:05 AM, Andrea Aime
wrote:
> Btw, ProcessingCollection has its own WrappingIterator which I guess could
> be now replaced with BridgeIterator, if I got the right idea about
> what BridgeIterator
> is.
Other things noticed:
- is there any difference between the accepts meth
On Sun, Nov 4, 2012 at 9:47 AM, Jody Garnett wrote:
> Other things noticed:
> - is there any difference between the accepts method in the processing
> collection
> and the one in base collection?
>
> Yes - Processing collection throws IOExceptions, BaseFeatureCollection
> follows the "keep calm an
On Sun, Nov 4, 2012 at 8:24 AM, Jody Garnett wrote:
> I had a go and ProcessingCollection extends BaseFeatureCollection, and
> arrived at one critical implementation difference.
> ProcessingFeatureCollection takes care to lazily create the schema; I can
> image for some process this work can be
>
I had a go and ProcessingCollection extends BaseFeatureCollection, and arrived
at one critical implementation difference.
ProcessingFeatureCollection takes care to lazily create the schema; I can image
for some process this work can be
fairly significant.
Additional helper methods:
- DataUtilit
> > - RasterAsPointFeatureCollection now extends BaseFeatureCollection in order
> > to avoid the use of WrappingIterator
>
> Hum... ok, Wondering what level of overlap there is now between
> BaseFeatureCollection
> and that processing oriented feature collection base I've made some time ago
Chec
10 matches
Mail list logo
