[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [udig-devel] Multiple FeatureTypes in a Layer
|
First of all I would encourage you to update to 1.1.1 - it is actually
stable and much better then the long string of release candidates :-)
Joe Dente wrote:
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.
That is the background I need :-) To start out with we *really* should
get you started on making
your own MemoryDataStore that is tuned for rendering. Please understand
that the MemoryDataStore
was actually done as "documentation" by me for DataStore developers. As
such I went to great trouble
to make it behave exactly like a remote database or remote WFS. As such
it actually copies the data out
of an internal TreeMap; copying one feature at a time; and doing a "deep
copy" of all the geometry
data. Why do this? Well I wanted to be sure that if someone modified
the data they got out of the
datastore it would behave exactly like the content was off site ...
Also note it is using a TreeMap (sorted by FeatureId) rather than
something nice for rendering like
a spatial index.
Do I encourage you to make your own MemoryDataStore (and of course would
love if you shared
it with the community because then I will not have to make one).
However ... the split you are seeing between more features in a layer
and more layers is very real. Each layer
has its own renderer and its own raster that it is rendering into; and
the more rasters you have like this the
longer the "composition" step as the rasters are combined in the current
z-order into a final image.
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.
That does not make too much sense to me .. each layer has its own raster
and they are combined together
using a simple for loop. Perhaps Emily can shed some light on this?
So while I believe you; the problem does not match my understanding of
the code. :-(
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.
This is a case of those memory datastores offering transaction
independence; I cannot remember if these
issues were sorted out by RC14 or not. There was a bug where the
rendering was not using the Transaction
(and thus seeing different data) then what was being edited (on a
transaction).
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 suspect that the issues are actually in uDig - and were the kind of
issues being ironed out as uDig 1.1.0 was
put together.
I appreciate any advice you can offer and thanks for taking the time to
read this post.
Not a problem Joe; thanks for providing enough detail.I am hoping one of
the other developers here
recognizes something in your description. I currently do not work on the
stable branch of uDig and am
unlikely to help on a casual basis. There are however several active
developers on the stable branch; the
next step may be to set up a test case so others can see the problem.
I assume that this is the kind of annoying timing based issue that does
not appear if you are stepping through
with a debugger?
Jody
Thanks,
Joe
-----Original Message-----
From: udig-devel-bounces@xxxxxxxxxxxxxxxxxxxxx
[mailto:udig-devel-bounces@xxxxxxxxxxxxxxxxxxxxx] 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
