Renderer slows down when adding PointSymbolizer to Style

[Bernhard Kastner]

Hi list,

I just experienced the following problem: I'm using the
shapefile-renderer and want to render 2 layers: the first is a very big
shapefile, symbolized by the LineSymbolizer.
The second one is a smaller shapefile, symbolized by the PointSymbolizer.

Rendering for the big shape usually takes about 8 seconds, if rendering
the whole one.
Rendering for the small shape, takes less than 1 second.

Anyways, when defining the PointSymbolizer in the XML-thing, the big
shapefile needs about 30 seconds or more to render, whether I render the
small one too or not.

Why is that? Is there a mistake in my XML-Definition, but if, shouldn't
the parser just stop?

Bernhard

8<---snip-snap-----------------------

final Style style
         = loadStyle
              ("  <UserStyle>"
               + " <FeatureTypeStyle>"
               + "  <Rule>"
               + "   <LineSymbolizer>"
               + "    <Stroke>"
               + "     <CssParameter name=\"stroke\">#000000</CssParameter>"
               + "     <CssParameter name=\"width\">1.0</CssParameter>"
               + "    </Stroke>"
               + "   </LineSymbolizer>"
               + "  </Rule>"
               + "  <Rule>" // when adding this one, it takes very long
to render.
               + "   <PointSymbolizer>" // when removing it, whether I
render the small one or not
               + "       <Fill>" // it works as fast as expected
               + "            <!-- CssParameters allowed are fill"
               + "            (the color) and fill-opacity -->"
               + "            <CssParameter
name=\"fill\"><Literal>#FF0000</Literal></CssParameter>"
               + "        </Fill>"
               + "   </PointSymbolizer>"
               + "  </Rule>"
               + " </FeatureTypeStyle>"
               + "</UserStyle>");
8<---snip-snap-----------------------


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Geotools-gt2-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users

[Bernhard Kastner]

hmm, creating the style via the StyleBuilder works fine...

Bernhard Kastner wrote:

> Hi list,
>
> I just experienced the following problem: I'm using the
> shapefile-renderer and want to render 2 layers: the first is a very
> big shapefile, symbolized by the LineSymbolizer.
> The second one is a smaller shapefile, symbolized by the PointSymbolizer.
>
> Rendering for the big shape usually takes about 8 seconds, if
> rendering the whole one.
> Rendering for the small shape, takes less than 1 second.
>
> Anyways, when defining the PointSymbolizer in the XML-thing, the big
> shapefile needs about 30 seconds or more to render, whether I render
> the small one too or not.
>
> Why is that? Is there a mistake in my XML-Definition, but if,
> shouldn't the parser just stop?
>
> Bernhard
>
> 8<---snip-snap-----------------------
>
> final Style style
>         = loadStyle
>              ("  <UserStyle>"
>               + " <FeatureTypeStyle>"
>               + "  <Rule>"
>               + "   <LineSymbolizer>"
>               + "    <Stroke>"
>               + "     <CssParameter
> name=\"stroke\">#000000</CssParameter>"
>               + "     <CssParameter name=\"width\">1.0</CssParameter>"
>               + "    </Stroke>"
>               + "   </LineSymbolizer>"
>               + "  </Rule>"
>               + "  <Rule>" // when adding this one, it takes very long
> to render.
>               + "   <PointSymbolizer>" // when removing it, whether I
> render the small one or not
>               + "       <Fill>" // it works as fast as expected
>               + "            <!-- CssParameters allowed are fill"
>               + "            (the color) and fill-opacity -->"
>               + "            <CssParameter
> name=\"fill\"><Literal>#FF0000</Literal></CssParameter>"
>               + "        </Fill>"
>               + "   </PointSymbolizer>"
>               + "  </Rule>"
>               + " </FeatureTypeStyle>"
>               + "</UserStyle>");
> 8<---snip-snap-----------------------
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> Geotools-gt2-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
>
>

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Geotools-gt2-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users

[David Blasby-2]

Try putting the 2 symbolizers in the same rule.

I'm not quite sure what you're trying to do - you will be taking each
feature and rendering them twice -- once as a line (points should be
converted to a very small line) and once as a point (the centroid of
each line will be calculated).

What is your stylebuilder code?

dave



----------------------------------------------------------
This mail sent through IMP: https://webmail.limegroup.com/


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Geotools-gt2-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users

[Bernhard Kastner]

hmm, i thought the xml defines every style and depending on which
feature to render, it takes either the line, the point or whatever
symbolizer.
Now it makes sense to me: Every single symbolizer has it's own
XML-Definition :)

but this also works: interestingly it renders about 7-8% faster with the
style builder definition...

StyleBuilder sb = new StyleBuilder();
LineSymbolizer ls2 = sb.createLineSymbolizer(Color.BLACK, 1);
Style roadsStyle = sb.createStyle(ls2);
Mark redCircle =
sb.createMark(StyleBuilder.MARK_CIRCLE, Color.RED, Color.BLACK, 0);
Graphic grGZ = sb.createGraphic(null, redCircle, null);
PointSymbolizer psGZ = sb.createPointSymbolizer(grGZ);
Style GZStyle = sb.createStyle(psGZ);
context.addLayer
  (new ShapefileDataStore
   (new File
("/home/Kastna/workspace/total_neich/Grundstücke.SHP").toURI ().toURL ())
    .getFeatureSource (),roadsStyle);
context.addLayer
   (new ShapefileDataStore
    (new File
("/home/Kastna/workspace/applet02/gzpunkte.shp").toURI ().toURL ())
     .getFeatureSource (),GZStyle);


[hidden email] wrote:

> Try putting the 2 symbolizers in the same rule.
>
> I'm not quite sure what you're trying to do - you will be taking each
> feature and rendering them twice -- once as a line (points should be
> converted to a very small line) and once as a point (the centroid of
> each line will be calculated).
>
> What is your stylebuilder code?
>
> dave
>
>
>
> ----------------------------------------------------------
> This mail sent through IMP: https://webmail.limegroup.com/
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
>
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> Geotools-gt2-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Geotools-gt2-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users

[M. Purbo]

Dear All,

I apologize if this has been discussed before.

To put it simply, ihave:

1. a set of, say JPEG, images.
2. a CSV file describing the lat-lon coordinate box for each of the
images (each record also include the coordinate system code, scale name,
image size in pixel, etc.), something like:

image_name, cs, width, height, x1, y1, x2, y2, x3, y3, x4, y4
image1.jpg, 4801, 2000, 2000, 135.123, 39.123, ...
image2.jpg, 4801, 2000, 2000, 135.123, 39.123, ...
....

3. the boundary of the whole area covered.

My objective is:

to have a simple function to get an image given any box within the
boundary (3) above with a specific CRS. Something like:

Image getImage(float x1, float y1, float x2, float y2,
CoordinateReferenceSystem crs);

This function supposed to get some portion of one file, some from
another, etc., should the box requested covers the area of more than 1
image.

I was thinking of using GridCoverage, and I tried to study
GridCoverage2D, FileSystemGridCoverageExchange, .. and other seemingly
related classes, but I am currently stuck on how to knit these things
together..

So, basically, my question is:

1. Is it even possible to use geotools to do what I wanted.
2. If it is possible, I would appreciate very much if anybody could give
me as much as a hint on which classes/methods I should go to.
3. If it is not possible, is there any other kind of data/file/info,
etc. that is required to achive this objective.

Thanks a lot in advance,

Purbo


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Geotools-gt2-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users

[Martin Desruisseaux-2]

M. Purbo a écrit :

> My objective is:
>
> to have a simple function to get an image given any box within the
> boundary (3) above with a specific CRS. Something like:
>
> Image getImage(float x1, float y1, float x2, float y2,
> CoordinateReferenceSystem crs);
>
> This function supposed to get some portion of one file, some from
> another, etc., should the box requested covers the area of more than 1
> image.

There is not method in Geotools at this time for assembling many images
into a single one. GridCoverage2D may still be of some help however,
especially if images have different CRS or resolution.

A GridCoverage2D is basically:

    RenderedImage + CRS + Envelope (+ some info about the pixel values)

Create one GridCoverage for each image with proper CRS and Envelope
informations. Next, choose a CRS and image size for the destination
image (the CRS doesn't need to be the same than source images). Then,
create the GridGeometry2D which describe the geometry of yours target image:

Rectangle r = ... yours image size
Envelope  e = ... the envelope of the target image
GridGeometry2D gm = new GridGeometry2D(new GeneralGridRange(r), e);

Then, resample each source images using:

target = (GridCoverage2D) Operations.resample(source, crs, gm, null);

where 'crs' is yours target CRS (should be the same than the Envelope
CRS, if a CRS were given to 'e' above). You will get a bunch of images
with exactly the same size, envelope and CRS. You should be able to
combine them using JAI operations (I have not searched the JAI javadoc
for the exact method).

Note: the above method may take a fair amount of memory since each
target image may have only a small area actually covered by pixel
values. In order to crop each target image to only the required part,
add the following line before the call to 'resample':

gm = new GridGeometry2D(null, gm.getGridToCoordinateSystem());

It will basically erase the 'grid range' information from the grid
geometry. The resample operation will then compute the minimal grid
range needed for each image. It will use less memory, but assembling
images in a single one may be more difficult.

        Martin.


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
<a href="http://ads.osdn.com/?ad_idv37&alloc_id865&op=click">http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
_______________________________________________
Geotools-gt2-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users