|
From: Alex P. <ap...@fs...> - 2005-10-28 20:40:30
|
<P> <BR><BR><FONT FACE=3D"Monospace,Courier"> >How many records are= there? </FONT></P><P>select count(*) from contours;<BR> count<BR>-------<B= R> 400</P><P> </P><P>><FONT FACE=3D"Monospace,Courier">Are y= our tables indexed (spatially and primary key, other queried values)?</FONT= ></P><P>\d contours;</P><P>Indexes:<BR> "contours=5Fpkey&= quot; primary key, btree (gid)<BR> "oid" btree (oid)= <BR> "tiff=5Fname" btree (tiff=5Fname)<BR><FONT FACE= =3D"Monospace,Courier">>Now if your view is everything, that could expla= in a long rendering<BR>time. But it still seems excessively long.</FONT></P= ><P> </P><P><FONT FACE=3D"Monospace,Courier">From these 400 rows, I wa= nt to see (Filter) a single row:</FONT></P><P> </P><P><Filter><B= R> <PropertyIsEqualTo><BR> <PropertyName>tiff=5Fname</Proper= tyName><BR> <Literal>O3=5F00=5F00</Literal><BR> </Propert= yIsEqualTo><BR> </Filter></P><P> </P><P><FONT FACE=3D"Monospa= ce,Courier">Here tiff=5Fname is a unique value, that matches a single row. = Now, the multilinestring geometry is long, but it is still just a single ro= w.</FONT></P><P><FONT FACE=3D"Monospace,Courier">From what I understood fro= m D Blasby's email (below), is that WMS queries ALL data from a Postgis tab= le, and does filtering and styling on the side of Geoserver.</FONT></P><P><= FONT FACE=3D"Monospace,Courier">The constructed SQL gives no indication of = the Filter clause being passed to Postgis. </FONT></P><P> </P><P><FONT= FACE=3D"Monospace,Courier">Any further advice is much appreciated,</FONT><= /P><P> </P><P><FONT FACE=3D"Monospace,Courier">Alex</FONT></P><P><FONT= FACE=3D"Monospace,Courier"> </FONT></P><P><FONT FACE=3D"Monospace,Cou= rier"><BR></FONT><BR><FONT FACE=3D"Monospace,Courier">><BR>> >2. T= he way WMS and WFS handle <filters> are different.<BR>><BR>> &g= t;For WFS, they do what you want them to do -- they always pass the<BR>>= <BR>> >filter off to the datastore. That means it gets converted into= the SQL<BR>><BR>> >WHERE clause.<BR>><BR>> >For WMS, it = handles <filters> differently because there could be<BR>><BR>> = >multiple filters and else clause (they renderer features that were not<= BR>><BR>> >caught by any of the other rules).<BR>><BR>> >= So, it makes a request for all the features that intersect the view<BR>>= <BR>> >rectangle. It also makes a set of Rules that are valid f= or the current<BR>><BR>> >scale range. The main loop looks l= ike this:<BR>><BR>> >For each Feature in the view rectangle (Datas= tore processes this)<BR>><BR>> >For each Rule (all handled by java= )<BR>><BR>> >IF the Feature satisfies the <Filter> render it= <BR>><BR>> >If no Rules were 'hit', then render with the <Else&= gt; rule<BR>><BR>><BR>> I see. So far my ideas to speed this up ar= e:<BR>><BR>> 1) Dynamically create a a view in postgis based on a sel= ected option on my<BR>> web page client.<BR>> This is an ugly workaro= und. For example, what if there are 2<BR>> simultaneous requests for cre= ating a view?<BR>><BR>> 2) Somehow use a RemoteOWS layer, which filte= rs the data in the postgis<BR>> table. This didn't appear to work,<BR>&g= t; since all records were retrieved once again.<BR>><BR>> What I need= to accomplish is very simple. Basically, my table contains a<BR>> list = of MULTISTRING geometries.<BR>><BR>> Based on a filter in an SLD=5FBO= DY, I need to pluck out a single row, where<BR>> the criteria in the fil= ter will match a distinct value:<BR>><BR>> <F= ilter><BR>> <PropertyIsEqualTo><BR>><BR= >> <Pr= opertyName>tiff=5Fname</PropertyName><BR>> = <Literal>O3=5F00=5F00</= Literal><BR>><BR>> </PropertyIsEqualTo>= <BR>> </Filter><BR>><BR>> >Also, one= way to make this faster, Alex, would be create a view based on<BR>> >= ;your query. Then simply call for the view in the getmap, rather than= <BR>> >the source table.<BR>> >Of course, this will only work i= f there are a small number of values for<BR>> >the discriminating att= ribute in your query, since you don't want to<BR>> >create 500 views = or something.<BR>> >--saul<BR>><BR>> Thank you Saul. I've alrea= dy thought of that--It's a good workaround and<BR>> has worked for me we= ll (until now).<BR>> The problem here is that the view would have to be = created based on a<BR>> user-selected option from a web page.<BR>><BR= >> Any more ideas on how to accomplish this, without selecting everythin= g<BR>> in the table prior to display (ala WFS GetFeature filter)?<BR>>= ;<BR>> I would love to be told what I am doing wrong here.<BR>><BR>&g= t; Pointers and the time you took to read this are greatly appreciated :-)<= BR>><BR>> Alex<BR>><BR></FONT></P>= |