Can you give me a link to the CSV tutorial? All I could find in the wiki is a source location
http://svn.refractions.net/udig/udig/branches/1.1.x/udig/tutorials/net.refractions.udig.tutorials.catalog.csv/, and I don't see any renderer stuff in there. By now my guess is that the problem is somewhere in the Geotools StreamingRenderer, I tried stepping into it, but I didn't get very far, since the source attachment to the gt-renderer.jar does not seem to match the jar. (I may have messed that up myself, having three or four different versions of uDig and Geotools on my laptop by now....) I'll try and get everything clean from the trunk. If all the usual test cases use one feature type per layer, it seems I'm walking down an untrodden path, so I'm not surprised to see problems... I did go through the SLD spec and experimented with the SLD styles a lot. At first I had all styles for all feature types in one SLD file, and that did not work at all: not the only the drawing order was wrong, but in fact there were lots of polygons clipped at random edges that did not exist in my data. The SLD spec is fairly clear to me, but I don't quite see how the Geotools Streaming Renderer follows the spec... Multiple feature styles per SLD did not work, so I'm now using multiple rules in one style where each rule matches exactly one feature type. Regarding that "Legend View", of course you could somehow condense the presentation to the user and work with some hundred layers internally. The major problem with that is that I would have to iterate over each tile a hundred times, once per feature type. (The features per tile are sorted by drawing order and feature type, but there is no random access to features of type 99.) (Note: My tiles are partitions in the datastore, not image buffers for the renderer. All features are clipped to tile borders during datastore generation.) Well, I'll try to isolate the problem and come back with more specific questions, hopefully, either here on on the Geotools list. Harald -----Ursprüngliche Nachricht----- Von: [EMAIL PROTECTED] im Auftrag von Jody Garnett Gesendet: Di 16.09.2008 22:14 An: User-friendly Desktop Internet GIS Cc: Betreff: Re: [udig-devel] Renderer woes A couple of questions for you: > I'm working with a custom file format for car navigation databases which > by now has plugins both for JUMP and uDig. I would be happy to drop > support for JUMP and finally move to uDig, but a major obstacle is the > renderer which appears to me 1) rather incomprehensible Were you able to go through the tutorials examples for csv service, csv renderer and style. I hope that provides sufficient background to understand what is going on. We have been doing our best to revise the javadocs in response to questions on the mailing list. > and 2) buggy > Emily has been finding several cases where extra refreshes are made; but in general the rendering system is doing well. Do you have any specific bugs to discuss? > Browsing through the mailing list archives, it seems I'm not the only > one who is not really happy with the renderer, so I'm just wondering > what the current status is and if anyone is working on improving the > renderer or implementing alternative renderers. Or maybe everything is > bright and easy on the trunk? > On trunk the rendering system is being revised to make an option of using "tiles" available; allowing smooth panning. As part of this work we are revisiting the rendering contract; clearing up javadocs so they make sense and so on. There are two actual changes: - the RenderingMetrics class has changed to better communicate issues of latency and performance; for uDig 1.1.x it was only communicating ability - The references to viewportmodel.getBounds() are being replaced with getContext().getBounds() - ie please check the tile you are drawing into - rather than the screen. > I'm currently working with uDig 1.1-SC1 and JUMP 1.2.0. All the feature > decoding and caching stuff specific to my file format is in shared > bundles used both by JUMP and uDig, so since things work smoothly in JUMP, > I'm rather confident that the problem is not in my own code... So > far I haven't done any customization in the rendering area, so my features > simply get passed to the BasicFeatureRenderer. > > There are two main issues: > 1) Drawing Order > Draw order is based on two things: - the zorder of the layers - and within a layer the BasicFeatureRenderer will have an order of Rules; Symbolizers and so on which control what order individual styling elements are drawn in. You may wish to draw a thick line; and then a dashed thin line to represent a hiway for example. > 2) Out of memory errors > This should not be the case; uDig by itself does not load anything into memory. How are you staging your data for use? Are you trying to keep information at all? A renderer will often be made when you zoom or pan; so keeping information at the render level is not recommended. If you must store some information (say a spatial index?) please store it in the layer blackboard. > 1) Drawing order: My data has multiple levels of details and about 100 > different feature types. The features are grouped by tiles which can be > loaded separately. In each tile, the features are stored in the intended > drawing order, background to foreground, starting with ocean, country, > landuse, buildings, etc... > I am working with a similar data set right now for a customer. I assume "level of detail" is not based on zoom level; but is quality of your dataset; much like having the same shapefile at different levels of decimation... > I do not want to see more than two or three uDig layers per level of detail, > and providing a separate layer per feature type _and_ LOD is > simply out of the question. > I think you may be confusing the Layers view (which literally shows zorder) with a "Legend view" which would communicate data categories to a normal user. You may wish to create a Legend View on your own (perhaps only showing layers that are visible at the current scale for example). Either way you have a choice between: - creating many simple renderers (and using render metrics information like zoom level to choose the correct one) - making a small number of more complicated renders > However, the BasicFeatureRenderer seems to have problems with multiple types > and styles per layer. > All the data sets it has been tested with only have a single FeatureType per layer; you can have rules that engage different sets of symbolizers depending on checking attribute values but it sounds like you are aware of that. > I did go as far as creating separate layers for point, line and polygon > features in each LOD (just to avoid some of the problems - in JUMP, > there is no need to do that). Do you have your data model? You can have a FeatureType that as a generic geometry for its spatial data ... > Each layer loads its drawing styles from a dedicated SLD file. Each SLD file > has a rule per feature type, the types > are ordered background to foreground. All rules have min and max scale > denominators for the LOD magic. > That sounds fine; you have many options within an SLD file for determining draw order- - multiple FeatureTypeStyles can be used - within a FetaureTypeStyle you can have multiple Rules; and an "other" Rule for anything that does not match - within a Rule you have a list of symbolizers which are applied > Now when I zoom in and out and pan around my map in uDig, the drawing order > simply gets messed up in some of the tiles: background polygons > hide others that should be in the foreground. This appears to be > non-deterministic. Is there a chance for styles from different layers to > interfere with each other? How does the renderer decide which features to > render in what order? > We follow the SLD specification; pretty much to the letter since the fellow implementing the involved in the spec. > Is there an alternative renderer I could try? Are there any substantial > differences in this area between 1.1 and trunk which might address these > issues? > For my own work in this area I am making a custom renderer; and not using SLD. > Anybody working on other renderers? (I did some experiments with Java3D in a > stand-alone Swing JFrame, just for a plain 2D map; it was fairly > easy to use and extremely fast. So if I have to get involved with renderers - > which I would like to avoid - this is a route that looks > promising to me.) > > 2) Memory: To support large databases (e.g. all of Europe at house number > level of detail), our data format is split into tiles. For JUMP > and uDig, I created a TiledFeatureCollection which internally has one feature > collection per tile and tries to retrieve the tiles matching a > query rectangle from its cache, loading them from the datastore if required. > The cache is based on soft references to avoid heap overflow. > So in principle, any feature collection from a tile outside the current > viewport or not matching the current scale should be eligible for > garbage collection. > That sounds fine. The rendering system will not hold onto any of your FeatureCollections; indeed they are only their to set up for a call to iterator(). > This works fine in JUMP, but in uDig, I still get out of memory errors. > Does uDig itself cache features no; indeed this is one of our motivations for creating it. > or pre-rendered images? The final image for each layer is cached; but are thrown away when you move or zoom. > If so, how to avoid that? > > Any hints appreciated... > Can you run with a profiler? See where your memory is being leaked? In order to follow the specification the geotools streaming renderer may create a buffered image for each Rule (or perhaps it just does multiple passes through your FeatureCollection?). In anycase the SLD specification is very clear on what gets drawn when and we do our best to follow that. There are several good profilers for the eclipse development environment. Jody _______________________________________________ User-friendly Desktop Internet GIS (uDig) http://udig.refractions.net http://lists.refractions.net/mailman/listinfo/udig-devel ******************************************* innovative systems GmbH Navigation-Multimedia Geschaeftsfuehrung: Edwin Summers - Kevin Brown - Regis Baudot Sitz der Gesellschaft: Hamburg - Registergericht: Hamburg HRB 59980 ******************************************* Diese E-Mail enthaelt vertrauliche und/oder rechtlich geschuetzte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtuemlich erhalten haben, informieren Sie bitte sofort den Absender und loeschen Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the contents in this e-mail is strictly forbidden. *******************************************
<<winmail.dat>>
_______________________________________________ User-friendly Desktop Internet GIS (uDig) http://udig.refractions.net http://lists.refractions.net/mailman/listinfo/udig-devel
