Cart
[Home] [By Thread] [By Date] [Recent Entries]
> The Java code keeps all the data in memory, organized by area > and ordered by date/time. In order to minimize the processing > time (since it's intended to compare the actual XML > marshalling/unmarshalling > performance) it checks rectangle intersections between the > query lat/long range and that of each area to determine which > areas need to be checked, then does binary searches through > the ordered array of quakes within an area for the start/end > times in the query. Once it has the range of possible > matching quakes, it does the final checks on lat/long and > magnitude for each individual quake. I suspect the binary > search part is more than you want to take on in XSLT, so we > can try comparisons both with the search part enabled in the > Java code and with it disabled (instead doing a check on each > quake within the area). Ideally one would have an XQuery implementation that optimizes using multi-dimensional indexes so that all of this is taken care of beneath the covers. I don't know of an implementation that does that, unfortunately, though some might give you access to the spatial data support in an underlying RDBMS. Short of that, there's a danger here that you end up comparing two different search algorithms both implemented at application level, rather than two different technologies/languages for writing the application. But it should be an interesting exercise all the same. Michael Kay http://www.saxonica.com/
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
