[Geoserver-users] pdf output

GeoServer GeoServer User
1

Hi
I guess I found the problem for the big-sized pdf-output: A simple WMS-request gets first all the features from the database that are within or are touching the BBOX. If the output is a raster that’s not a problem since you have e finite amount of pixels and the parts of the features not in the BBOX are clipped. Now I have a pdf and here it’s possible to store the whole feature even if it’s not in the visible part of the pdf-document.
I tried to solve the problem with a cql_filter intersect request. But this is not exactly the same as a “select intersection(geom1, geom2) from …” command in the database, it works like another BBOX-request. Is there a way to have the features really clipped (like in the db-command)?

regards
Stefan

-----Ursprüngliche Nachricht-----
Von: Ziegler Stefan
Gesendet am: Montag, 17. Dezember 2007 07:33
An: geoserver-users
Betreff: Re: [Geoserver-users] pdf output

I did try the 1.5.x branch and the 1.6 RC1 with the new iText library. In both cases I got the same results. I should take a closer look at the pdf producing part of geoserver during xmas holidays.

Stefan - waiting for rc2 :slight_smile:

-----Ursprüngliche Nachricht-----
Von: Andrea Aime [mailto:aaime@anonymised.com]
Gesendet am: Freitag, 14. Dezember 2007 21:50
An: Ziegler Stefan
Cc: geoserver-users
Betreff: Re: [Geoserver-users] pdf output

Ziegler Stefan ha scritto:

Hi
we want to use geoserver’s ability of producing pdf outputs for “high
quality web printing” (something like this:
http://www.john-longo.org/b1.pdf ). My problem is, that I get sometimes
quite small pdf-files (around 300 kb) but also “too” big ones (above 1
mb: http://www.john-longo.org/b2.pdf ).
The only difference between the two is a really small difference in the
Bounding Box. I was able to track down the following: the latter one has
a small part of a very large street-polygon (
http://www.john-longo.org/a1.pdf ). Then I tried to request a pdf of
only a part of this street ( http://www.john-longo.org/a2.pdf ) with the
same width- and height-parameters in the wms-request. I expected that
the pdf with the whole street will be larger than the small part… Far
from it. 240 kb versus 490 kb. Why is a small part of a large polygon
blowing up the pdf output?
Any ideas? Thanks.

Not really. We are not generating the PDF by hand, but drawing on
a java graphics context provided by iText, the java pdf library.
To us it’s no different than drawing on the screen or on a printer,
it’s iText that is doing the pdf conversion.

We recently upgraded the version of iText we’re shipping with to
cope with a rendering issue, so you might get different results
with it. If better or worse, I don’t know… be sure the check
out GeoServer 1.6.0-rc2 next week and tell us how it’s working
for you.

Cheers
Andrea

2

Right now I don't think there's a way to have GeoServer to do the clipping, or to tell the database to do the clipping. For all the other formats they actually do the clip, or else you probably want them not clipped (like if you're doing a WFS request).

I think in this case the ideal solution would be if the pdf output did the clipping. The other formats do the proper clipping when needed, so I'd say pdf should do the same.

Eventually we might implement some sort of processing operations which would let you do things like clipping, but right now there are no immediate plans to.

I'm sorry I can't be more helpful, thanks for the feedback on what the problem actually is. Unfortunately it's a bit of an edge case and I don't know that there will be a good solution soon.

best regards,

Chris

Ziegler Stefan wrote:

Hi
I guess I found the problem for the big-sized pdf-output: A simple WMS-request gets first all the features from the database that are within or are touching the BBOX. If the output is a raster that's not a problem since you have e finite amount of pixels and the parts of the features not in the BBOX are clipped. Now I have a pdf and here it's possible to store the whole feature even if it's not in the visible part of the pdf-document.
I tried to solve the problem with a cql_filter intersect request. But this is not exactly the same as a "select intersection(geom1, geom2) from ...." command in the database, it works like another BBOX-request. Is there a way to have the features really clipped (like in the db-command)?
regards
Stefan

    -----Ursprüngliche Nachricht-----
    *Von:* Ziegler Stefan
    *Gesendet am:* Montag, 17. Dezember 2007 07:33
    *An:* geoserver-users
    *Betreff:* Re: [Geoserver-users] pdf output

    I did try the 1.5.x branch and the 1.6 RC1 with the new iText
    library. In both cases I got the same results. I should take a
    closer look at the pdf producing part of geoserver during xmas
    holidays.

    Stefan - waiting for rc2 :slight_smile:

    -----Ursprüngliche Nachricht-----
    Von: Andrea Aime [mailto:aaime@anonymised.com]
    Gesendet am: Freitag, 14. Dezember 2007 21:50
    An: Ziegler Stefan
    Cc: geoserver-users
    Betreff: Re: [Geoserver-users] pdf output

    Ziegler Stefan ha scritto:
    > Hi
    > we want to use geoserver's ability of producing pdf outputs for "high
    > quality web printing" (something like this:
    > http://www.john-longo.org/b1.pdf ). My problem is, that I get
    sometimes
    > quite small pdf-files (around 300 kb) but also "too" big ones
    (above 1
    > mb: http://www.john-longo.org/b2.pdf ).
    > The only difference between the two is a really small difference
    in the
    > Bounding Box. I was able to track down the following: the latter
    one has
    > a small part of a very large street-polygon (
    > http://www.john-longo.org/a1.pdf ). Then I tried to request a pdf of
    > only a part of this street ( http://www.john-longo.org/a2.pdf )
    with the
    > same width- and height-parameters in the wms-request. I expected that
    > the pdf with the whole street will be larger than the small
    part... Far
    > from it. 240 kb versus 490 kb. Why is a small part of a large polygon
    > blowing up the pdf output?
    > Any ideas? Thanks.

    Not really. We are not generating the PDF by hand, but drawing on
    a java graphics context provided by iText, the java pdf library.
    To us it's no different than drawing on the screen or on a printer,
    it's iText that is doing the pdf conversion.

    We recently upgraded the version of iText we're shipping with to
    cope with a rendering issue, so you might get different results
    with it. If better or worse, I don't know... be sure the check
    out GeoServer 1.6.0-rc2 next week and tell us how it's working
    for you.

    Cheers
    Andrea

!DSPAM:4005,477e56b645012090977483!

------------------------------------------------------------------------

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

!DSPAM:4005,477e56b645012090977483!

------------------------------------------------------------------------

_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

!DSPAM:4005,477e56b645012090977483!