On Mon, Aug 29, 2011 at 5:58 PM, Andrea Aime
wrote:
> The other open issue is that yes, you can configure a max number of open
> files,
> yet that has to be multiplied by the number of concurrent requests, so
> on a server
> app it's still relatively easy to break the max file open limit.
> Not s
No good suggestions.
One long term bad suggestion; start to make the "Register" smarter again (it
was smart initially and responsible for cross data store locks). If you do
allow it to be smart you could allow it to be backed by a local H2 database
which it could use to supplement the functio
On Mon, Aug 29, 2011 at 4:43 PM, Justin Deoliveira wrote:
> Wow indeed, very impressive. Definitely +1 for merging it into main,
> most particularly ContentDataStore, since the is the recommended starting
> point for new datastores these days. Since it is a wrapping feature reader
> this should be
Wow indeed, very impressive. Definitely +1 for merging it into main,
most particularly ContentDataStore, since the is the recommended starting
point for new datastores these days. Since it is a wrapping feature reader
this should be trivial. Great stuff.
On Mon, Aug 29, 2011 at 2:06 AM, Michael Be
Hi Andrea,
Many thanks - this sounds really good. I can make immediate use of it
in a current project.
Like Jody, I'd be very keen to have this in gt-main.
Michael
--
EMC VNX: the world's simplest storage, starting unde
Oh wow Andrea :-)
That is amazing timing as the "dissolve" process was stuck behind sorting
features correctly prior to the dissolve (and Levi was working on dissolve).
Can we please merge that to gt-main (as I was about to try and take the in
memory approach into wider use).
Jody
--
Jody G
Hi,
today I've build a generic feature sorter that I'd like to share
with the community.
The code can build a sorted SimpleFeatureReader or a sorted
SimpleFeatureIterator starting from an unsorted one without
taxing memory.
The code takes the original reader, the SortyBy[] clause, a max
number of
It was part of the Filter 1.1 stuff - and I agree it has not been
communicated to my satisfaction either. At the time not a lot of people
were on trunk and I did well to even write down the interface changes.
Bleck,
Jody
> Jody Garnett ha scritto:
>> Nope I ment FeatureList - the provided query
Jody Garnett ha scritto:
> Nope I ment FeatureList - the provided query was supposed to request a
> sort order :-(
Jody,
frankly it's the first time I've heard speaking about FeatureList, and
of the supposed requirement to return an instance of it when sorting
stuff...
Cheers
Andrea
--
Nope I ment FeatureList - the provided query was supposed to request a
sort order :-(
Jody
> Gertjan van Oosten ha scritto:
>> As quoted from Jody Garnett <[EMAIL PROTECTED]>:
>>> I have gathered up the two FeatureList examples provided and place
>>> them onto the following page:
>>> - http://do
Gertjan van Oosten ha scritto:
> As quoted from Jody Garnett <[EMAIL PROTECTED]>:
>> I have gathered up the two FeatureList examples provided and place them
>> onto the following page:
>> - http://docs.codehaus.org/display/GEOTDOC/10+FeatureList
>
> You wrote:
>
> FeatureList featureList = (Fe
As quoted from Jody Garnett <[EMAIL PROTECTED]>:
> I have gathered up the two FeatureList examples provided and place them
> onto the following page:
> - http://docs.codehaus.org/display/GEOTDOC/10+FeatureList
You wrote:
FeatureList featureList = (FeatureList) source.getFeatures(query);
Can I
I have gathered up the two FeatureList examples provided and place them
onto the following page:
- http://docs.codehaus.org/display/GEOTDOC/10+FeatureList
> Well, actually I was using:
>
> final FeatureIterator iter = features.features();
> while (iter.hasNext()) {
> // ...
> }
> iter.
Hi Gertjan,
Andrea is correct when he states that FeatureCollection is an
inconsistent entity in geotools. To be quite honest with you it is a
complete mess.
The *only* part of the FeatureCollection api that is actually
implemented relativley consistently is the iterator part of it. This is
s
As quoted from Andrea Aime <[EMAIL PROTECTED]>:
> Geoserver uses feature sorting, so it works, but only if you specify
> it in the Query apparently?
For those keeping notes (or trying to get their own question answered by
searching through the archives): this way of sorting does not currently
work
Gertjan van Oosten ha scritto:
> As quoted from Andrea Aime <[EMAIL PROTECTED]>:
>> FeatureCollection is one of those topics where geotools developers
>> are not agreeing with each other, as such is not evenly covered usage
>> wise (which also mean QA wise). I personally don't like them, and
>> don
As quoted from Andrea Aime <[EMAIL PROTECTED]>:
> FeatureCollection is one of those topics where geotools developers
> are not agreeing with each other, as such is not evenly covered usage
> wise (which also mean QA wise). I personally don't like them, and
> don't rely on them more than as a glorif
Gertjan van Oosten ha scritto:
> Hello again,
>
> If I try to sort a FeatureCollection, I get a null FeatureList.
> So I do:
>
> final FeatureCollection fc = source.getFeatures(filter);
>
> and this returns my feature collection (an instance of
> JDBCFeatureCollection to be precise). Good. B
Hello again,
If I try to sort a FeatureCollection, I get a null FeatureList.
So I do:
final FeatureCollection fc = source.getFeatures(filter);
and this returns my feature collection (an instance of
JDBCFeatureCollection to be precise). Good. But:
final SortBy rt = ff.sort(sortField,
I have not had time to make a 2.3 release, perhaps those working on WCS
can give it a go. I would like to see a release around next week for
those attending the conference to point people at.
Jody
> It saddens me that i did all the deprecation of the filter interfaces
> last year and we still hav
It saddens me that i did all the deprecation of the filter interfaces
last year and we still haven't had a release out of it. Well SortBy
already extends geoapi SortBy and is deprecated. So after we get 2.3 out
we can kill it. With a single module ( MemoryDataStore ) using it
shouldn't be a huge im
Here is the problem Justin,
MemoryDataStore implements sorting in GeoTools 2.2 - since this is
against our own GeoTools interface SortBy interface; we need to do the
deprecation dance as we move to GeoAPI. Aside: SortBy2 is our convention
to allow extensions beyond the OGC specifications, the
Justin Deoliveira ha scritto:
> Hi all,
...
> To do sorting across the board in data store land looks to be quite a
> bit of work. The FeatureCollection interface has a sort() method, but
> from I can tell it is ignored. And since most data stores don't do the
> work of implementing their own Fea
Hi all,
Starting to tackle sorting as part of wfs 1.1. The state of things as
they sit today is:
- Query has a reference to a SortBy which is deprecated, replaced by the
geoapi version.
- There is a SortBy2 interface which adds the ability to supply an
arbitrary expression to sort by
>From what
24 matches
Mail list logo
