You're right, Even, I was working with a different version of the file. The dataset must have changed in the past few days. I now get the same result for MAX(area) that you're getting.
I now get about 60 s for both OGR and JEQL. Not sure why the new file takes so much longer - it's actually smaller than the one I was using. Could be fun trying to track this down... I'd say one thing, though - you must have a fast C compiler, and a slow Java implementation! Over 8 min for the JEQL script seems awfully slow. Your box is beefier than mine (mine is pretty old - 2 GHz, dual core, 2 GB RAM). Possibly 64-bit makes a difference? On 4/22/2012 5:12 AM, Even Rouault wrote: >> Hi, >> >> Ok, this is interesting for several reasons : >> >> 1) Trying to run the 'ogrinfo -sql "select max(OGR_GEOM_AREA) from tpi_1" >> tpi_1.shp' showed that a badly written optimization in OGR 1.9.0 broke such >> a query. Now fixed per http://trac.osgeo.org/gdal/ticket/4633 >> >> 2) Width GDAL trunk, 1.9, 1.8 and 1.7, I never get Martin's result. I >> always get : >> >> MAX_OGR_GEOM_AREA (Real) = 70726589354.8597 >> >> Reached on shape index = 289 (first shape is index = 0): >> >> OGRFeature(tpi_1):289 >> id (Real) = 904743.0000000000000000000000000000000 >> gridcode (Real) = 4.0000000000000000000000000000000 >> class_name (String) = Plains or Open Slopes >> >> I though it could come from a compiler issue, but I get the same results >> with GCC 4.4.3 in debug and optimized mode, and also with MSVC 2008 >> >> 3) This runs in about ~ 5 seconds on all those versions on my machine >> (after several runs so that the I/O cache is hot) >> >> OS: Ubuntu 10.04 64bit >> CPU : Intel(R) Core(TM) i5 CPU 750 @ 2.67GHz >> RAM : 4 GB > I've just tried with http://tsusiatsoftware.net/jeql/files/jeql-0.11.zip and I > get the following results : > > time java -cp commons- > lang-2.6.jar:h2.jar:javaproj-1.0.6.jar:jcommon-1.0.16.jar:jeql-0.11.jar:jfreechart-1.0.13.jar:jts-1.12.jar:jtsio-1.12.jar:proj4j-0.1.0.jar:stax2-2.1.jar:stax- > api-1.0.1.jar:wstx-lgpl-3.2.7.jar -Xms256M -Xmx1024M jeql.JeqlCmd script.jql > col0:Double > 70726589354,85522 > > real 8m30.478s > user 8m29.480s > sys 0m0.530s > > I've also inserted that shape into a Spatialite and PostGIS DB and they also > return very close areas with their ST_Area() implementation. > > So I'm not sure that Martin and I are working on the same shapefile... > > Here is mine : > > -rw-r--r-- 1 even even 322589721 2012-04-21 06:52 tpi_1.dbf > -rw-r--r-- 1 even even 893 2012-04-21 07:03 tpi_1.prj > -rw-r--r-- 1 even even 389028108 2012-04-21 06:53 tpi_1.shp > -rw-r--r-- 1 even even 8039716 2012-04-21 06:52 tpi_1.shx > > $ md5sum tpi_1.shp > c50c502cae5b172e270dc02e8562c69c tpi_1.shp > > >> Best regards, >> >> Even >> _______________________________________________ >> gdal-dev mailing list >> [email protected] >> http://lists.osgeo.org/mailman/listinfo/gdal-dev > > ----- > No virus found in this message. > Checked by AVG - www.avg.com > Version: 2012.0.1913 / Virus Database: 2411/4952 - Release Date: 04/22/12 > > ------------------------------------------------------------------------------ For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 _______________________________________________ Jump-pilot-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
