Christophe Rousson ha scritto:
> Hi,
>
> I added a wiki page for my SoC project :
>
> http://docs.codehaus.org/display/GEOTOOLS/SoC+2007+Caching+data
>
> Many ideas come from Andrea's :
>
> http://docs.codehaus.org/display/GEOTOOLS/Datastore+caching
>
> Cheers,
Hi Christophe,
the plan is a bit rough but interesting. I would just like to point
out some issues that may not be evident.
In your approach you're assuming that:
a) id are stable, that is, the same feature will always have the same id
b) gathering only ids is significantly faster than retrieving the whole
feature.
c) you can gather easiliy a high number of fids from the datastore
All assumptions are reasonable, but you must be aware that they
may be broken by certain data stores:
a) will be broken by shapefile data stores (when edited, since the id
is simply the row number in the dbf file), by jdbc data stores
mapping a table without a primary key, and by extension, by every
layer server by a remote WFS server such as Geoserver, when
Geoserver is using the above cited data stores
b) file based data stores may have to gather good part of the
feature to evaluate the filter, and reading data is where you pay
most of the price.
c) jdbc data stores will turn a fid filter with lots of fids into
a "fid in (f1, f2, ..., fn)" query, or an equivalent "fid = f1
or fid = f2 or .... or fid = fn". When fids are many, you may
hit the query size limit of the datastore. This is more of a
limitation in jdbc data stores implementation, but one you
may encounter when starting to play with big amounts of data.
Moreover, hashmap like data structure will use lots of memory if you
cache each single feature by its id, that's why I tried to split
the cartesian plane in tiles that can be cached as wholes, because
that would have reduced the number of entries in the hashtable.
That said, the solution I did propose it's a lot harder, so I'm
not here suggesting that you use it, but only
trying to make you aware of possible issues you'll encounter during
the development of your SoC project. Better be prepared than sorry no?
:-)
Cheers
Andrea
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
