Thank you for your suggestions and sorry for the late reply.
It sounds like I could reuse the Streaming render in a "MultiRenderer" having several instances of it.
Does it sound reasonable to you using the decorator pattern and having the "MultiRender" implementing the GTRenderer interface?
As for the datastore, we have enough memory to put everything in memory so I think this is the best solution.
But when you say "You'll need a quadtree index, because data will be changing." I am not sure to understand why quadtree is THE solution.
Can you please explain a bit?
Finally, I have a few more questions about StreamingRenderer: What is the concatTransforms flag used for?
Can it be used to rotate the map? If no, is rotation somehow supported by the renderer?
Thank you for your help.
Olivier
2006/10/26, Andrea Aime <[EMAIL PROTECTED]>:
Olivier Doucet ha scritto:
> Hi all,
>
> I am currently working on a GIS monitoring application that has to
> provide 2D view(s) of a dynamic geographic dataset (here a communication
> network with its nodes and links, but also moving vehicles). I belive
> GeoTools has a lot to offer here.
> The network is not supposed to move, but the nodes' attributes will
> change over the time and we want to render it accordingly, using SLD rules.
>
> The point here is that most of our data is vector data (except a
> background satellite image) and the complete dataset is not very big,
> say maximum 500,000 features in total, but each feature can potentially
> be updated (at least one attribute per feature, maybe more), say every 5s.
> In addition, there will be a few static features, most likely coming
> from shapefiles.
>
> Since GIS dataset are usually way bigger and more static, I wonder if
> the streaming renderer is suited for this dynamic usage. If not what
> would you suggest?
> Again, if not, how difficult would it be to adapt one of the existing
> renderers to ensure a good performance with higher refresh rates and
> many changes?
>
> We are actually considering using a memory datastore. Then my second
> question is: is the MemoryDatastore a good option? Or should we
> implement our own memory datastore? Extending the existing MemoryDatastore?
I would suggest the following:
* use a separate renderer/buffered image for each dynamic layer, and one
for the group of static ones, and then merge the images manually.
Keep the rendered images around.
* if you have enough memory, yes, use a memory data store... with
500.000 features you may want to add a spatial index in it so that
bbox queries performed when moving/zooming are fast enough.
You'll need a quadtree index, because data will be changing.
* when data changes, re-render only the layer that changed, and
perform again the image merging.
If the application is a server side one, you may want to setup a cache
of tiles for the static images too.
That should be enough to make it work fast.
Cheers
Andrea Aime
------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________ Geotools-gt2-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
