[Geoserver-devel] Slow rendering - isometric

Hi List,
While optimisations are on our minds (who needs holidays anyway?), I thought I’d bring up a function that seems to be particularly slow. Namely the “isometric” one.

Same parameters as before (single test instance, 1 thread, coming from Oracle).
I’m getting GeoServer to render this png:
http://maps.warwickshire.gov.uk/misc/with-isometric.png

There are about 9000 buildings on there.

My response times for this layer using jmeter average 8500ms! Now, much of that is Oracle (booo!), however I’ve noticed that it seems to take considerably longer when I’m using the “isometric” function than some of my other stylings that don’t use that.

If I disable just the isometric effect (so comment out the below; the features are still rendering, but just without going through the isometric function):

se:Geometry
<ogc:Function name=“isometric”>
ogc:PropertyNameSDO_GEOMETRY</ogc:PropertyName>
ogc:Literal2</ogc:Literal>
</ogc:Function>
</se:Geometry>

My request time drops to 7300ms - a significant saving.
(Optimisation for me - The output is almost identical at that scale - http://maps.warwickshire.gov.uk/misc/without-isometric.png - so I’ll turn it off at that scale in the future.)

There’s also an offset function which is being used here - disabling that results in absolutely no difference.

But even for a small subset of those (i.e., zoomed in), the isometric thing severely bogs down rendering.

========

Something related I noticed in the Geoserver logs while investigating this:

2013-12-31 17:44:08,379 DEBUG [org.geotools.jdbc] - SELECT OSMMSTYLE_NAME,SDO_GEOMETRY as SDO_GEOMETRY FROM OSMM.OS_MM_TOPOGRAPHIC_AREA WHERE (SDO_FILTER(SDO_GEOMETRY, ?, ‘mask=anyinteract querytype=WINDOW’) = ‘TRUE’ AND (OSMMSTYLE_NAME = ? OR OSMMSTYLE_NAME = ? OR OSMMSTYLE_NAME = ? OR OSMMSTYLE_NAME = ?))
2013-12-31 17:44:08,379 DEBUG [org.geotools.data.oracle.sdo] - Using layer SRID: 27700
2013-12-31 17:44:08,379 DEBUG [org.geotools.jdbc] - Setting parameter 1 as MDSYS.SDO_GEOMETRY(2003,27700,NULL,MDSYS.SDO_ELEM_INFO_ARRAY(1,1003,3),MDSYS.SDO_ORDINATE_ARRAY(431115.10000000003,265345.6461141951,432915.5,267131.3538858049))
2013-12-31 17:44:08,379 DEBUG [org.geotools.jdbc] - 1 = POLYGON ((431115.10000000003 265345.6461141951, 431115.10000000003 267131.3538858049, 432915.5 267131.3538858049, 432915.5 265345.6461141951, 431115.10000000003 265345.6461141951))
2013-12-31 17:44:08,379 DEBUG [org.geotools.jdbc] - 2 = buildingFill
2013-12-31 17:44:08,379 DEBUG [org.geotools.jdbc] - 3 = structureFill
2013-12-31 17:44:08,379 DEBUG [org.geotools.jdbc] - 4 = buildingFill
2013-12-31 17:44:08,379 DEBUG [org.geotools.jdbc] - 5 = structureFill
201

Note that GeoServer has appended OR clauses for buildingFill and structureFill twice (I guess because they’re in separate FeatureTypeStyles). I’m sure Oracle optimises that out, but it might be worth doing it on the GeoServer end anyway.

Unfortunately they’re locking up the building now, so I can’t do any further testing until Thursday. I can create JIRA’s for these if desired.

And Happy New Year all!

Jonathan

This transmission is intended for the named addressee(s) only and may contain sensitive or protectively marked material up to RESTRICTED and should be handled accordingly. Unless you are the named addressee (or authorised to receive it for the addressee) you may not copy or use it, or disclose it to anyone else. If you have received this transmission in error please notify the sender immediately. All email traffic sent to or from us, including without limitation all GCSX traffic, may be subject to recording and/or monitoring in accordance with relevant legislation.

On Tue, Dec 31, 2013 at 7:20 PM, Jonathan Moules <
jonathanmoules@anonymised.com> wrote:

Hi List,
While optimisations are on our minds (who needs holidays anyway?), I
thought I'd bring up a function that seems to be particularly slow. Namely
the "isometric" one.

Same parameters as before (single test instance, 1 thread, coming from
Oracle).
I'm getting GeoServer to render this png:
http://maps.warwickshire.gov.uk/misc/with-isometric.png

Hmm... does not respond (at least to me).

There are about 9000 buildings on there.

My response times for this layer using jmeter average 8500ms! Now, much of
that is Oracle (booo!), however I've noticed that it seems to take
considerably longer when I'm using the "isometric" function than some of my
other stylings that don't use that.

If I disable just the isometric effect (so comment out the below; the
features are still rendering, but just without going through the isometric
function):

<se:Geometry>

            <ogc:Function name="isometric">
              <ogc:PropertyName>SDO_GEOMETRY</ogc:PropertyName>
              <ogc:Literal>2</ogc:Literal>
            </ogc:Function>
          </se:Geometry>

My request time drops to 7300ms - a significant saving.
(Optimisation for me - The output is almost identical at that scale -
http://maps.warwickshire.gov.uk/misc/without-isometric.png - so I'll turn
it off at that scale in the future.)

Hmm... one consideration here. The isometric function creates the illusion
of a 3d building by using
a isometric extrusion of it. See a result here:
http://mapping-malaysia.blogspot.it/2010/07/pseudo-3d-buildings-in-geoserver.html

Now, to do that, each segment is turned into a rhombus representing the
projection of that side.
In other word, each vertex in the original geometry is replaced by 4 new
vectices (as we have to create
one rhombus for the segment at the left, and one at the right).
So, the painting effort becomes 4 times bigger, in term of vertices, and
each rhombus needs to be both
stroked and filled, moreover, to get a good effect, you have to use
translucent filling, which is also
quite expensive.

The source code of the isometric function is here, not sure there is much
to be optimized
(yes, there are micro optimizations that could be done here and there,
doubt very much they would result in any significant speedup):
https://github.com/geotools/geotools/blob/master/modules/library/main/src/main/java/org/geotools/filter/function/FilterFunction_isometric.java

Long story short, the overhead you're seeing does not seem to be that much
considering the extra effort
required to perform the extrusions and paint them. I'd suggest to enable
this style only
when you're fairly zoomed in. If you want to have a nice effect for the
other zoom levels you could
consider using the offset function and drop shadows instead?
http://docs.geoserver.org/stable/en/user/styling/sld-extensions/geometry-transformations.html#drop-shadow

Cheers
Andrea

--
*== GeoSolutions will be closed for seasonal holidays from 23/12/2013 to
06/01/2014 ==*

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

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

This transmission is intended for the named addressee(s) only and may contain sensitive or protectively marked material up to RESTRICTED and should be handled accordingly. Unless you are the named addressee (or authorised to receive it for the addressee) you may not copy or use it, or disclose it to anyone else. If you have received this transmission in error please notify the sender immediately. All email traffic sent to or from us, including without limitation all GCSX traffic, may be subject to recording and/or monitoring in accordance with relevant legislation.

···

Hmmm, looks like my IIS server broke for the new year. I’ll have to fix it tomorrow.

I’m actually using the drop-shadow method already (I’d provide a link but given the server is dead… ), however the isometric looks significantly better so I’ve converted to that. The cost is the significant processing overhead, but we’re pre-rendering most tiles anyway.

I kind of guessed it may not be optimisable, but figured it was worth bringing up anyway.

Per your suggestion and my tests, I’ll tweak my SLD so only the drop-shadow is used at 1:5000 scale (currently has isometric too), and the isometric comes on at 1:2500 where it will be visible.

Thanks,
Jonathan

Hmm… does not respond (at least to me).