Re: [mapserver-users] Build 5.6.5 with AGG, weird error
Hi Gregor, You should not need to download, build and install agg anymore. The source code that we use from agg has been port into the mapserver source. So when you configure use: --with-agg to build with the embeded agg or leave it off to not build with it. my configure command looks like: ./configure \ --enable-runpath \ --enable-ignore-missing-data \ --with-proj=/usr \ --with-agg \ --with-gd= \ --with-freetype=/usr \ --with-postgis \ --without-tiff \ --with-wmsclient \ --with-fribidi-config=/usr/local/lib/pkgconfig/fribidi.pc \ --with-httpd=/usr/sbin/apache2 \ --with-gdal \ --with-ogr -Steve W http://imaptools.com/ Gregor at HostGIS wrote: Hey guys. Long time, no chat. :) I'm trying to build 5.6.5 on Slackware/Slamd64. I have AGG installed (as best one can since it doesn't do "make install", copied libagg.a and the include files). If I do not use --with-agg=no, MapServer's build process tries to use AGG and fails miserably: g++ -fPIC -D_FILE_OFFSET_BITS=64 -fPIC -Wall -DHAVE_VSNPRINTF -DNEED_STRLCAT -DNEED_STRRSTR-DUSE_WMS_LYR -DUSE_WFS_LYR -DUSE_SOS_SVR -DUSE_LIBXML2 -DUSE_CURL -DUSE_WCS_SVR -DUSE_WFS_SVR -DUSE_WMS_SVR -DUSE_MYGIS -DUSE_POSTGIS -DPOSTGIS_HAS_SERVER_VERSION -DUSE_GDAL -DUSE_OGR -DUSE_GEOS -DGEOS_HAS_SIMPLIFY -DUSE_THREAD -DUSE_PROJ -DUSE_EPPL -DUSE_AGG -DUSE_PDF -DUSE_GD_GIF -DUSE_GD_PNG -DUSE_GD_JPEG -DUSE_GD_WBMP -DUSE_GD_FT -DGD_HAS_FTEX_XSHOW -DGD_HAS_GDIMAGEGIFPTR -DGD_HAS_GETBITMAPFONTS -DUSE_ICONV -DUSE_ZLIB -I/usr/include -I/usr/include/freetype2 -I/usr/include -I/usr/include -I/usr/include -I/usr/include/mysql-I/usr/include -I/usr/include/libxml2 shp2img.o -L. -lmapserver -L/usr/lib -lgd -ljpeg -L/usr/lib64 -Wl,--rpath -Wl,/usr/lib64 -lfreetype -lz -lpng -lz -lXpm -lX11 -L/usr/lib -lpdf -ljpeg -L/usr/lib64 -Wl,--rpath -Wl,/usr/lib64 -lfreetype -lz -lpng -lz -lXpm -lX11 -lproj -ljpeg -lpng -L/usr/lib -lgdal -L/usr/lib -lgeos_c -L/usr/lib -lexpat -L/usr/lib -lxerces-c -lpthread -L/usr/lib -lNCSEcw -lNCSCnet -lNCSUtil -L/usr -L/usr/lib -lnetcdf -lpq -L/usr/lib -lpq -lz -L/usr -L/usr/lib -pthread -lm -lrt -ldl -L/usr/lib64 -lcurl -lidn -lssl -lcrypto -ldl -lssl -lcrypto -ldl -lz -L/usr/lib -lpq -lpgport -lssl -lcrypto -lz -lreadline -ltermcap -lcrypt -ldl -lm -L/usr/lib/mysql -lmysqlclient -lz -lcrypt -lnsl -lm -L/usr/lib64 -lssl -lcrypto -lmysqlclient -L/usr/lib64 -lcurl -lidn -lssl -lcrypto -ldl -lssl -lcrypto -ldl -lz -L/usr/lib -lgeos_c -lpthread -lc -lz -lxml2 -lz -lm -lm -lstdc++ -o shp2img /usr/lib64/gcc/x86_64-slackware-linux/3.4.6/../../../../x86_64-slackware-linux/bin/ld: skipping incompatible /usr/lib/libjpeg.so when searching for -ljpeg /usr/lib64/gcc/x86_64-slackware-linux/3.4.6/../../../../x86_64-slackware-linux/bin/ld: skipping incompatible /usr/lib/libjpeg.so when searching for -ljpeg /usr/lib64/gcc/x86_64-slackware-linux/3.4.6/../../../../x86_64-slackware-linux/bin/ld: skipping incompatible /usr/lib/libjpeg.so when searching for -ljpeg `.gnu.linkonce.t._ZN9mapserver18rasterizer_sl_clipINS_12ras_conv_intEE7line_toINS_19rasterizer_cells_aaINS_7cell_aaEvRT_ii' referenced in section `.rodata' of ./libmapserver.a(agg_font_freetype.o): defined in discarded section `.gnu.linkonce.t._ZN9mapserver18rasterizer_sl_clipINS_12ras_conv_intEE7line_toINS_19rasterizer_cells_aaINS_7cell_aaEvRT_ii' of ./libmapserver.a(agg_font_freetype.o) collect2: ld returned 1 exit status make: *** [shp2img] Error 1 It's some sort of linker error, but I'm baffled as to what it is. I compiled libagg.a with -fPIC but that didn't make a difference. Any ideas? ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users
[mapserver-users] Build 5.6.5 with AGG, weird error
Hey guys. Long time, no chat. :) I'm trying to build 5.6.5 on Slackware/Slamd64. I have AGG installed (as best one can since it doesn't do "make install", copied libagg.a and the include files). If I do not use --with-agg=no, MapServer's build process tries to use AGG and fails miserably: g++ -fPIC -D_FILE_OFFSET_BITS=64 -fPIC -Wall -DHAVE_VSNPRINTF -DNEED_STRLCAT -DNEED_STRRSTR-DUSE_WMS_LYR -DUSE_WFS_LYR -DUSE_SOS_SVR -DUSE_LIBXML2 -DUSE_CURL -DUSE_WCS_SVR -DUSE_WFS_SVR -DUSE_WMS_SVR -DUSE_MYGIS -DUSE_POSTGIS -DPOSTGIS_HAS_SERVER_VERSION -DUSE_GDAL -DUSE_OGR -DUSE_GEOS -DGEOS_HAS_SIMPLIFY -DUSE_THREAD -DUSE_PROJ -DUSE_EPPL -DUSE_AGG -DUSE_PDF -DUSE_GD_GIF -DUSE_GD_PNG -DUSE_GD_JPEG -DUSE_GD_WBMP -DUSE_GD_FT -DGD_HAS_FTEX_XSHOW -DGD_HAS_GDIMAGEGIFPTR -DGD_HAS_GETBITMAPFONTS -DUSE_ICONV -DUSE_ZLIB -I/usr/include -I/usr/include/freetype2 -I/usr/include -I/usr/include -I/usr/include -I/usr/include/mysql-I/usr/include -I/usr/include/libxml2 shp2img.o -L. -lmapserver -L/usr/lib -lgd -ljpeg -L/usr/lib64 -Wl,--rpath -Wl,/usr/lib64 -lfreetype -lz -lpng -lz -lXpm -lX11 -L/usr/lib -lpdf -ljpeg -L/usr/lib64 -Wl,--rpath -Wl,/usr/lib64 -lfreetype -lz -lpng -lz -lXpm -lX11 -lproj -ljpeg -lpng -L/usr/lib -lgdal -L/usr/lib -lgeos_c -L/usr/lib -lexpat -L/usr/lib -lxerces-c -lpthread -L/usr/lib -lNCSEcw -lNCSCnet -lNCSUtil -L/usr -L/usr/lib -lnetcdf -lpq -L/usr/lib -lpq -lz -L/usr -L/usr/lib -pthread -lm -lrt -ldl -L/usr/lib64 -lcurl -lidn -lssl -lcrypto -ldl -lssl -lcrypto -ldl -lz -L/usr/lib -lpq -lpgport -lssl -lcrypto -lz -lreadline -ltermcap -lcrypt -ldl -lm -L/usr/lib/mysql -lmysqlclient -lz -lcrypt -lnsl -lm -L/usr/lib64 -lssl -lcrypto -lmysqlclient -L/usr/lib64 -lcurl -lidn -lssl -lcrypto -ldl -lssl -lcrypto -ldl -lz -L/usr/lib -lgeos_c -lpthread -lc -lz -lxml2 -lz -lm -lm -lstdc++ -o shp2img /usr/lib64/gcc/x86_64-slackware-linux/3.4.6/../../../../x86_64-slackware-linux/bin/ld: skipping incompatible /usr/lib/libjpeg.so when searching for -ljpeg /usr/lib64/gcc/x86_64-slackware-linux/3.4.6/../../../../x86_64-slackware-linux/bin/ld: skipping incompatible /usr/lib/libjpeg.so when searching for -ljpeg /usr/lib64/gcc/x86_64-slackware-linux/3.4.6/../../../../x86_64-slackware-linux/bin/ld: skipping incompatible /usr/lib/libjpeg.so when searching for -ljpeg `.gnu.linkonce.t._ZN9mapserver18rasterizer_sl_clipINS_12ras_conv_intEE7line_toINS_19rasterizer_cells_aaINS_7cell_aaEvRT_ii' referenced in section `.rodata' of ./libmapserver.a(agg_font_freetype.o): defined in discarded section `.gnu.linkonce.t._ZN9mapserver18rasterizer_sl_clipINS_12ras_conv_intEE7line_toINS_19rasterizer_cells_aaINS_7cell_aaEvRT_ii' of ./libmapserver.a(agg_font_freetype.o) collect2: ld returned 1 exit status make: *** [shp2img] Error 1 It's some sort of linker error, but I'm baffled as to what it is. I compiled libagg.a with -fPIC but that didn't make a difference. Any ideas? -- HostGIS, Open Source solutions for the global GIS community Greg Allensworth - SysAdmin, Programmer, GIS Person, Security Network+ Server+ A+ Security+ Linux+ PHP PostgreSQL MySQL DHTML/JavaScript/AJAX "No one cares if you can back up — only if you can recover." ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users
[mapserver-users] Installing on Debian Lenny
The procedure for installing mapnik sounds complicated. http://trac.mapnik.org/wiki/DebianInstallation My hesitations: - needs to be production stable. - is the 0.5 or so version in lenny workable at all? - do i really need post gres,(we are running mysql) - no experience with software installation without package management Thoughts, comforting noises etc welcome. Peter ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users
[mapserver-users] Installing on Debian Lenny
Sorry, wrong list. P. ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users
Re: [mapserver-users] logging GDAL queries
Thank Ivan, I appreciate your help. Regards On Mon, Aug 16, 2010 at 7:23 PM, Ivan Lucena wrote: > Sebastian, > > > the performance has not improved. Why should it ? the extra pyramid > > levels contains 46x66, 23x33, 11x16, 5x8, 2x4, 1x2 but the problems > > that I am having are for 95162x135711, 47581x67855, 23790x33927, > > 11895x16963... that are low pyramid levels... (ie: high zoom=low pyramid > > level)... > > If you are still having problem with MapViewer I suggest you to post your > log at [http://forums.oracle.com/forums/forum.jspa?forumID=727]. Any > improvement on MapServer+GeoRaster through GDAL would take a little bit of > time to adapt the initial ETL design. > > Regards, > > Ivan > > -- Sebastian E. Ovide ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users
Re: [mapserver-users] logging GDAL queries
Sebastian, > the performance has not improved. Why should it ? the extra pyramid > levels contains 46x66, 23x33, 11x16, 5x8, 2x4, 1x2 but the problems > that I am having are for 95162x135711, 47581x67855, 23790x33927, > 11895x16963... that are low pyramid levels... (ie: high zoom=low pyramid > level)... If you are still having problem with MapViewer I suggest you to post your log at [http://forums.oracle.com/forums/forum.jspa?forumID=727]. Any improvement on MapServer+GeoRaster through GDAL would take a little bit of time to adapt the initial ETL design. Regards, Ivan ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users
Re: [mapserver-users] logging GDAL queries
Hi Ivan, I did create those extra pyramid levels Overviews: 95162x135711, 47581x67855, 23790x33927, 11895x16963, 5947x8481, 2973x4240, 1486x2120, 743x1060, 371x530, 185x265, 92x132, 46x66, 23x33, 11x16, 5x8, 2x4, 1x2 the performance has not improved. Why should it ? the extra pyramid levels contains 46x66, 23x33, 11x16, 5x8, 2x4, 1x2 but the problems that I am having are for 95162x135711, 47581x67855, 23790x33927, 11895x16963... that are low pyramid levels... (ie: high zoom=low pyramid level)... thanks On Mon, Aug 16, 2010 at 1:30 PM, Ivan Lucena wrote: > Hi Sebastian, > > Did you fix the problem with the pyramid levels? > > Do you see any improved where the performance was poor before? > > Thanks for your valuable test. I appreciate. > > Regards, > > Ivan > -- Sebastian E. Ovide ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users
Re: [mapserver-users] logging GDAL queries
Hi Sebastian, Did you fix the problem with the pyramid levels? Do you see any improved where the performance was poor before? Thanks for your valuable test. I appreciate. Regards, Ivan ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users
Re: [mapserver-users] logging GDAL queries
Hi Ivan, On Mon, Aug 16, 2010 at 6:02 AM, Lucena, Ivan wrote: > Sebastian, > > I have this little piece of code in Python that shows how 18 levels of > pyramids would look like: > > ... ... > 10 185 265 1 1 1049401 > 11 92 132 1 1 1049402 > ** What you don't have: ** > 12 46 66 1 1 1049403 > 13 23 33 1 1 1049404 > 14 11 16 1 1 1049405 > 15 5 8 1 1 1049406 > 16 2 4 1 1 1049407 > 17 1 2 1 1 1049408 > > Where: > > > ... ... > > You said that “it performs very well at zoom level under 12” and performs > poorly with zoom level between 13 and 17. > > are MapServer/GoogleMaps zoom level exactly the same as Oracle PyramidLevels ? For example... in Oracle , Pyramid level 0 means maximum zoom... that in MapServer/GoogleMaps it would something like 20 ??? > The problem is that you don't have those levels built into your GeoRaster > object. > > So, before doing any change to the system settings, could you please try to > increase the number of pyramids to 17? > > Building the pyramids is a internal process on the server. Even if you use > gdaladdo, that will just call a function from the GeoRaster PL/SQL > extension. > > It wouldn't take as long as before because it will add up to the existing > levels. > > The PL/SQL call should looks like that: > > declare > gr sdo_georaster; > begin > select georaster into gr from fluvd04q200pj where id = 1 for update; > sdo_geor.generatePyramid(gr, 'rlevel=17 resampling=NN'); > update fluvd04q200pj set georaster = gr where id = 1; > commit; > end; > / > > from Oracle documentation rLevel (for example, rLevel=2): Specifies the maximum reduction level: the number of pyramid levels to create at a smaller (reduced) size than the original object. If you do not specify this keyword, pyramid levels are generated until the smaller of the number of rows or columns is between 64 and 128. The dimension sizes at each lower resolution level are equal to the truncated integer values of the dimension sizes at the next higher resolution level, divided by 2. I've ignored the Oracle documentation and I've run it anyway... It toked 0.5 seconds to run ! In my case that code would not create any pyramids as I have already run sdo_geor.generatePyramid(gr, 'resampling=NN'); which would build the maximun levels of pyramids... > And the gdaladdo command should look like that: > > gdaladdo > georaster:geoserver,geoserver,MFPRODUK_11G,fluvd04q200pj,georaster,id=1 2 4 > 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 32768 65536 > > Best regards, > > Ivan > > > > Sebastian E. Ovide wrote: > >> Ivan, >> >> >> >>Yes! >> >>and >> >>No! >> >>That query creates a *cursor* to go through the whole raster, >>meaning, all the rows on the RasterDataTable that satisfy that query >>in the order stipulated by it. >> >>It does require a some memory but it looks like you got it. >> >> mmm... that makes me little bit nervous... I am testing it with a small >> map. Its is only UK with 5mx5m pixel Just wondering how this approach >> would scale to larger maps... US is 40 times bigger than UK... and they have >> more accurated maps and more than a single layer Just wondering how >> many manual configuration I'll be forced to do (Oracle created Spatial >> extention exactly for this reason... so the developer do not to think about >> handling blobs for him self anymore... reducing costs and risks) >> >> >>By the way, how long does it take to produce a geotiff file? Have >>loaded that image on QuantumGIS using the oracle_raster plugin? Hoes >>does it perform? >> >> >> it is not possible to create a TIFF as it would be too big (max size is >> 4GB)... and UK would be arounf 16GB (300MB in Oracle as I'm using deflate) >> >> I am testing Oracle MapViewer on the same table and it HAS the same >> problem The strange thing is that using MapBuilder (Oracle software to >> prepare the maps to use with MapViewer) the maps are displayed very fast at >> ANY zoom level !... therefore there is a way to do it fast (as MapBuilder >> does...) >> >> >>I was expecting to find in the logs some query that reads a >>subset of the whole image (just the tile/metatile that MapServer >>is serving) for example using SDO_GEOR.getRasterSubset.. >> >> >>That would be very slow. The GDAL driver access the BLOB directly. >> >> not sure about that... well I guess that at least it releases some work >> from the Oracle server... Anyway, as I have a spatial index, why don't just >> query only the right blobs? >> >> >>I have more questions: >> >>Are you using Mapserver FastCGI with a recent version? >> >> >> nop... I have not tried that yet... I'll try on Monday... I have tried as >> cgi and recently as mod_python. >> >>If you do, them the process will remains in memory, the GDALDataset >>associated with that GeoRaster will be keet, the *cursor* you remain >>alive and all the zooms and pans are going to work faster. Like for >>QGIS.
