Thanks for the response, First, with regards to your aside about PointSymbolizer displacement, I never found a solution and didn't have time to dive into the Geotools mailing lists. I basically ended up creating two versions of my icons, a displaced version and a centered version to achieve the affect I was going after. This is hardly ideal, but I was running out of time for that feature.
Now, let me give you a better description of our setup so that maybe you can provide some clues to our performance issues. First, we have been using the RC12 release of UDig for some time now and we probably won't have the time to upgrade for a while. As far as our mapping environment is concerned, we get layers from two sources: in memory and layers hosted by Geoserver using WMS. In our application, when a user creates a new map, they select a set of WMS hosted layers as their basemap. These layers basically become the user's canvas and cannot be interacted with by the user. We do not really have performance issues with the basemaps; we regularly use full Tiger Road data for the entire US. We spent some time tweaking the performance of the basemaps using a custom SLD to achieve the right level of responsiveness. Our in memory layers are constructed on the fly and are not persisted between sessions. I construct these layers in the following fashion: 1) Construct a FeatureType using a FeatureTypeBuidler 2) I then construct the Feature for the FeatureType by setting values for all attributes and then calling FeatureType.create(Object[], String) 3) I construct a MemoryDataStore around my Feature[] 4) I create an IGeoResource around each FeatureType and FeatureStore and register them with my IService 5) Add the layers using the AddLayersCommand 6) Style the layers and open on a map These layers created using the MemoryDataStore perform very poorly. They generally have a simple Geometry (LineString, Polygon, or Point) and are occasionally heavily styled (2 to 8 symbolizers per Feature). We have several sporadic render issues that only happen when we have several MemoryDataStore layers active (problems normally start happening when we have 10 or more MemoryDataStore layers). It doesn't seem to matter how many Features are in a layer. We can have hundreds of point Features in a single layer and have better performance than if we had 10 point features in 10 layers. The first issue we regularly see is a Z-Order render issue; the Z-Order will be correct on the data model, but incorrect when it's rendered. This failure is sporadic and it's more likely to occur if you have more MemoryDataStore layers active. The second issue occurs when we write to the FeatureStore to edit our Features. We have a widget that can adjust the geospatial data of Featuers (adjust the location of points that make up a polygon, etc). If several MemoryDataStore layers are active, rendering issues start occurring where the data model and the content of the FeatureStore will be correct, but the rendering will be incorrect (for example, the FeatureStore will have a polygon of 3 points, but a polygon of 4 points will be rendered). When this happens triggering an extra refresh after the canvas finishes rendering will normally cleanup any rendering artifacts. Both of the above issues are extremely distracting and both seem to be directly related to the number of MemoryDataStore layers we are trying to render. I appreciate any advice you can offer and thanks for taking the time to read this post. Thanks, Joe -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Jody Garnett Sent: Wednesday, December 17, 2008 5:07 PM To: User-friendly Desktop Internet GIS Subject: Re: [udig-devel] Multiple FeatureTypes in a Layer 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 _______________________________________________ User-friendly Desktop Internet GIS (uDig) http://udig.refractions.net http://lists.refractions.net/mailman/listinfo/udig-devel
