Hi Joe
There are two steps to rendering that kind of occur at right angles to
each other ....
1. Portrayal: Content is pulled from the GeoResource (or several!) and
rendered onto a raster ..
2. Composition: the rasters for each layer are merged up into a single
image that is displayed
A few renderers (like WMS) actually portray several "layers" of
information onto a single raster; the feature based renderers currently
do not do this ... but you could experiment with that if you think it
will make a difference.
I would like to make sure you think this will make a difference; you say
that your performance issues seem to be realted to the number of layers
rather than the number of features. Can you give me an idea where your
features come from? The system groups the renders according to what they
are up to ... you often only want two disk based renders going at once
(or your hard drive disk will "thrash" as it goes back and forth on the
disk between files). For external data sources like databases and web
feature servers we are not as concerned.
The code that controls how many layers a renderer wants to handle is the
RenderMetricsFactory and RenderMetrics. The fact that a layer has many
IGeoResources available to it is more to cover the case where the same
information is available form several services and you may want to have
failover; or the different services may offer different abilities for
the same data. An easy example is information published by geoserver is
available as a WMS and a WFS. You can display the WMS; but do features
selection using the WFS. For more details see the section on rendering
in the developers guide.
Emily has also looked into performance issues on trunk and has a "tiled"
rendering system that you may be interested in; the idea is to save what
has been rendered for a little bit so you can pan around the screen
smoothly.
If you are working with remote WMS services trunk also has support for
WMS-C (as implemented by GeoWebCache and TileServer). The same
functionality (ie caching tiles) should be available on the client side
using udig if we can make a user interface allowing people to define
their "tilesets". I *think* LISASoft just got some work in this area so
we may see some progress on this soon.
I will also point out you can make a custom renderer to render several
layers of your choosing - you do not need to stick to the ones provided
out of the box.
So if you can provide more information about what you are up to; the
size of data you are using and so on we can give better advise.
For the general problem of rendering features their are a couple of
obvious directions:
- set the min / max scale for the layer ... only show the feature
content when you are "close enough" for it to matter .... this is very
popular and has enabled a few projects I have worked on to be
successful. (this works and you can use it)
- feature decimation (ie simplification) and storing the result in a
cache ... would enable you to work with features quickly when zoomed out
(Nobody is working on this now)
- feature cache ... if the dataset is small enough you can cache it in
memory (there are two caches available QuadTree and SRTree). I think
emily is looking at this now on the geotools-devel list - when she gets
closer you should volunteer to help her test)
- storing the result of rendering .. this is the "tiled renderer"
approach that Emily just made available on trunk in October.
Finally I am sure you are aware their are developers around that can
help you; I mentioned Emily a couple of times; Jesse wrote the rendering
system and can probably be hired, and I am training a couple of
developers at LISAsoft that can be available in the new year.
Aside: Did you get your PointSymbolizer displacement stuff sorted out? I
am considering adding all the set methods back into the style objects...
Jody
Joe Dente wrote:
Hi,
Is there a way to put multiple FeatureTypes in the same layer in UDig?
We’ve been trying to cut back on the number of layers we produce in
UDig when putting Features on maps, as we have performance issues that
seem to be related to the number of layers we have rather than the
number of features. After digging around in the code and google for
some time I do not believe this is possible, but I wanted to be sure.
The way I understand things, each IGeoResource can only have a single
FeatureType and FeatureSource. LayerImpl, contains a list of
IGeoResources, which would lead me to believe that you can put
multiple IGeoResources and therefore multiple FeatureTypes into a
single layer. However, almost all the code in LayerImpl I see simply
uses the first IGeoResource found in the list (getBounds(),
getCrsInternal(), and getSchema() to name a few). Also, the
LayerFactoryImpl does not contain any methods for creating layers with
multiple IGeoResources. Why then does the LayerImpl contain a list of
IGeoResources rather than just a single IGeoResource member variable?
Thanks,
Joe
------------------------------------------------------------------------
_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel
_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel
