Hi Stephan,
Interesting. You're also right that I could separate out the layerType
check. I'm using a OCG WMS to fetch a small block of KML objects
surrounding a point (geoserver WMS with KML output). In response to a user
query, I loop through the collection checking if the query coord is inside
any of the KML polygons. If so, I use the jQuery we've been discussing to
harvest the details I care about from the KML description. If not, I
requery using the user's new location. Time for the kml query seems to be
~200-300 ms (as opposed to 30 seconds for a standard WFS query).
Of course in all likelihood, the operation occurs few enough times that the
speeds we've been discussing (just over 1 ms vs .2 ms) is relatively
meaningless when it comes to optimizing the full webapp as a whole. The
question was mostly a curiosity of what is most efficient/good habits. In
this case, I suspect the pure JS route is a bad idea for this instance, as
the KML format has already changed once (tables to lists), and it may even
be that the hash table route would be preferable given how little this saves
in time.
My thanks!
Josh
On Mon, Mar 2, 2009 at 4:21 AM, Stephan Veigl <stephan.ve...@gmail.com>wrote:
>
> Hi Josh,
>
> it looks like $foo.find(":header") has a problem since there is no
> single root element. Wrapping your data packet into <div> would help:
> $foo = $("<div>"+foo+"</div>");
>
> but since you are after a speed optimization I would suggest:
> layerType = $(queryTarget[0]).text();
> This gets the text of your first element, which is your header.
>
> One remark to the speed measurement:
> Do you get each packet from a different source type or do they came in
> streams from one source?
> If you have to do the layer look up for every packet, you have to
> account this time to your speed measurement as well.
>
> If you are really after high speed, you could use a pure JavaScript
> variant, which is about 25x faster than the original approach in IE.
> For that you would have to remove white spaces between your nodes, to
> avoid browser quirks.
> var $foo = $(foo.replace(/>\s+</g,"><"));
> see: http://jsbin.com/ukewu
> But be warned, with this optimization you are hard coded to the
> current data packet layout and may not even change a point in it!
> This is a general remark: optimization goes against readability and
> flexibility in most cases.
> So you have to decide for every project and optimization step, what's
> worth more, speed vs. flexibility / scalability vs. readability /
> simplicity
>
> by(e)
> Stephan
>
>
>
> 2009/3/2 Josh Rosenthal <maric...@gmail.com>:
> > Hi Stephen,
> > My apologies for not getting back to you sooner. I've been sick and my
> > projects have gotten away from me.
> > We now return to the email I'd started writing before I lost track of
> > everything. ....
> > Thank you! Trebly so!
> > First, yes, the data is ordered based on a template in geoserver that
> > produces the KMLs. Unfortunately, I'd simplified the issue in order to
> ask
> > my question. There are actually two parcel sources, which each produce
> > different sets of fields. The snippet I included above is from the low
> > quality parcels. In the high quality parcels, MAP_ID becomes MAP_PAR_ID,
> > (hence my use of MAP_ as my search term). Similarly, the indices change
> > depending on the layer.
> > However, I can detect which layer i'm using (listed in the header), so in
> > theory I could detect and then use indices appropriate to the layer.
> Mind
> > you, on trying this, I can't get $foo.find(":header").text(); to work, so
> > I'm not quite sure how to get it to work. - http://jsbin.com/ujocousing
> > queryTarget for the second index attempt.
> > Given that the name of the fields change, I don't think I can use the
> hash
> > solution in any way other than the if layername == check that I was
> trying
> > before (which in any case requires a .find('header') to work).
> > Second, my thanks for the very cool site link. Definitely great for
> sample
> > snippets.
> > Thirdly, the sample speed measurement code - one reason for the question
> in
> > the first place was not knowing how to measure speed. The sample helps a
> > lot.
> > Thanks a lot, and sorry for the delay in responding,
> > Josh
> >
> > On Thu, Feb 19, 2009 at 5:12 AM, Stephan Veigl <stephan.ve...@gmail.com>
> > wrote:
> >>
> >> Hi Josh,
> >>
> >> are your data ordered? (e.g. MAP_ID is the first <li>, SITE_ADDRESS
> >> the second, ...)
> >>
> >> If yes you can use a index based approach (from 4.8ms to 0.9ms on IE).
> >> var $foo = $(foo);
> >> var data = $foo.find(".atr-value");
> >> var parcelOutput = 'Parcel ID: ' +
> >> $(data[0]).text() +
> >> '<br>' +
> >> 'Address: ' +
> >> $(data[1]).text();
> >>
> >>
> >> Otherwise you can build a hash table of your name - value attributes
> >> and du a hash lookup (from 4.8ms to 2.7ms on IE)
> >> var $foo = $(foo);
> >> var names = $foo.find(".atr-name");
> >> var data = $foo.find(".atr-value");
> >> var hash = {};
> >> for (var j=0; j<names.length; j++) {
> >> hash[$(names[j]).text()] = $(data[j]).text();
> >> }
> >> var parcelOutput = 'Parcel ID: ' +
> >> hash['MAP_ID'] +
> >> '<br>' +
> >> 'Address: ' +
> >> hash['SITE_ADDRESS'];
> >>
> >>
> >> see my examples on the profiling test page:
> >> http://jsbin.com/ifico/edit
> >>
> >> by(e)
> >> Stephan
> >>
> >>
> >> 2009/2/18 Josh Rosenthal <maric...@gmail.com>:
> >> > So... a question regarding selector efficiency.
> >> > The following snippet of HTML describes attributes associated with a
> >> > polygon
> >> > in an KML. Its basically a table of data, contained as <span>s in
> <li>s
> >> > in
> >> > a <ul>. Given this snippet, what would be the best (fastest) way to
> >> > return
> >> > the values of MAP_ID and SITE_ADDRESS
> >> > foo = "<h4>GISDATA.ASSESSPARNC_POLY_PUBLIC</h4>
> >> >
> >> > <ul class="textattributes">
> >> > <li><strong><span class="atr-name">MAP_ID</span>:</strong> <span
> >> > class="atr-value">16-27</span></li>
> >> > <li><strong><span class="atr-name">SITE_ADDRESS</span>:</strong>
> <span
> >> > class="atr-value">396 Main St</span></li>
> >> > <li><strong><span class="atr-name">SITE_OTHER_FIELD</span>:</strong>
> >> > <span
> >> > class="atr-value">Grat Data</span></li>
> >> > <li><strong><span class="atr-name">USE_CODE</span>:</strong> <span
> >> > class="atr-value">101</span></li>
> >> > <li><strong><span class="atr-name">TOWN_ID</span>:</strong> <span
> >> > class="atr-value">116</span></li>
> >> > <li><strong><span
> >> > class="atr-name">WARREN_GROUP_05_MAP_ID</span>:</strong>
> >> > <span class="atr-value">M:0016 B:0000 L:0027</span></li>
> >> > <li><strong><span class="atr-name">ACRES</span>:</strong> <span
> >> > class="atr-value">0.67102373655</span></li>
> >> >
> >> > </ul>"
> >> >
> >> > The following works
> >> > parcelOutput = 'Parcel ID: ' +
> >> >
> >> >
> jQuery(foo).find('li:contains("MAP_")').not('li:contains("WARREN_GROUP")').children('.atr-value').text()
> >> > + '<br>' + 'Address: ' +
> >> >
> >> >
> jQuery(foo).find('li:contains("SITE_ADDRESS")').children('.atr-value').text();
> >> > Is there a better/more efficient way to return these values?
> >> > Thanks!
> >
> >
>
