On Mon, Jan 24, 2011 at 7:49 AM, Jody Garnett wrote:
> I was wondering why it was chosen not to derive the interface of
> FeatureCollection from the general Collection interface in java, as it
> implements all the same methods.
>
> To answer that question - we did derive from java.util.Collection
Jody,
You misunderstand, too :P
I know you don't need to load all the features into memory for "accepts"
to work.
But in the template implementation, "accepts" is *used* to go through
all the features and load them all at once in a list.
In principle, I have nothing against implementing accepts
> I was wondering why it was chosen not to derive the interface of
> FeatureCollection from the general Collection interface in java, as it
> implements all the same methods.
>
>
To answer that question - we did derive from java.util.Collection - however
when we moved to Java 5 - the language
You miss understand; you do not need to load all the features into memory for
"Accepts" to work. It is really intended to be an easier for loop for people to
code against (indeed they are thinking of making this style of programming part
of Java 7 - and calling it an "inner" iterator).
Here is
Yeah I guess that would be easy to do, but as i said, I don't think we
/want/ all features to be loaded in memory at once.
I was looking at a different option, but need to threat a
FeatureCollection as a Collection for that. I was wondering why it was
chosen not to derive the interface of Featur
On 22/01/11 07:39, Jody Garnett wrote:
On 21/01/2011, at 5:01 PM, Niels wrote:
I succeeded in getting wms:getFeatureInfo produce GML3 output from complex
features (Yay!).
However, I am now working on using HTML templates with getFeatureInfo.
I noticed in the code that processes templates, th
