Re: [mapserver-users] queryByPoint still valid?
hmm... I changed a couple of things in my application: new template engine; moved from PHP4 to PHP5; and from mapserver 4.x to mapserver 5.x Now, the "identify" feature (click on a country and give me some info about it), has problems Is anything wrong with these lines? //Query the Map at the point clicked if (!$imgbox) $a = $map -> queryByPoint($click_pt, MS_MULTIPLE, -1); else $a = $map -> queryByRect($click_rt); Could anyone give me a hint what would be wrong with these lines? It seems that mapserver doesn't like it. But it doesn't spit out any error message. It just stops working... And after the doc, these commands should be quite alright. Thanks a lot, Stef ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users
Re: [MAPSERVER-USERS] Routing Algorithm Confusion !
I guess there are several research papers on fast/quick routing on road networks ... most of them modify dijkstra's ... there are citations on *parallel* dijkstra's if you want to scale ..to large number of nodes ... Thanks Sandeep On Fri, May 16, 2008 at 5:08 AM, Ritesh Ambastha <[EMAIL PROTECTED]> wrote: > > Dear Readers, > > I use Dijkstra's shortest path algorithm for route computation. I am > satisfied with the accurate result it gives. Still, I feel for road > segments > ~ 200Million, the route computation will take a lot of time. So, is there > another algorithms exist as best practices for route computation(like > A*,TSP,etc)? Or, geeks write their own algorithm for route computation? > > Thanks and Regards, > Ritesh Ambastha > -- > View this message in context: > http://www.nabble.com/Routing-Algorithm-Confusion-%21-tp17264809p17264809.html > Sent from the Mapserver - User mailing list archive at Nabble.com. > > ___ > mapserver-users mailing list > mapserver-users@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/mapserver-users > -- Thanks Regards Sandeep Kumar Jakkaraju ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users
Re: [MAPSERVER-USERS] instantclient-basic-win32-11.1.0.6.0 and MS4W 2.2.7
What is Oracle version you have? Is it 11.1.0.6.0? I guess that function was deprecated. Take a look at: http://www.gdal.org/ogr/drv_oci.html and http://download.osgeo.org/gdal/win32/1.5/ that is what you find on the OCI zip README.TXT: OGR 1.5 Oracle Plugin = Install --- Unzip on top of the gdalwin32exe15x package. It will put the plugin in gdalwin32-1.5\bin\gdalplugins. If you don't already have Oracle 10.2 OCI libraries available, you will need to download the Oracle 10.2 Instant Client (you will need an OTN login): http://download-uk.oracle.com/otn/nt/instantclient/instantclient-basiclite-win32-10.2.0.3-20061115.zip The Oracle DLLs can be placed in gdalwin32-1.5\bin or anywhere else in the path. If all this is successful "ogrinfo --formats" should list the OCI driver. Good Luck. Myopic wrote: Has anyone had problems or tried to get Oracle Spatial to work with MS4W 2.2.7 with instantclient-basic-win32-11.1.0.6.0? When I replace the dlls as per the readme.. http://www.maptools.org/ms4w/index.phtml?page=README_INSTALL.html http://www.maptools.org/ms4w/index.phtml?page=README_INSTALL.html I get the the following error when I do the "ogrinfo --formats" command: "The procedure entry point OCICollTRIM could not be located in the dynamic link library oci.dll" Which oracle client should I be using? Many thanks! (I apologize for the double post..) ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users
[MAPSERVER-USERS] instantclient-basic-win32-11.1.0.6.0 and MS4W 2.2.7
Has anyone had problems or tried to get Oracle Spatial to work with MS4W 2.2.7 with instantclient-basic-win32-11.1.0.6.0? When I replace the dlls as per the readme.. http://www.maptools.org/ms4w/index.phtml?page=README_INSTALL.html http://www.maptools.org/ms4w/index.phtml?page=README_INSTALL.html I get the the following error when I do the "ogrinfo --formats" command: "The procedure entry point OCICollTRIM could not be located in the dynamic link library oci.dll" Which oracle client should I be using? Many thanks! (I apologize for the double post..) -- View this message in context: http://www.nabble.com/instantclient-basic-win32-11.1.0.6.0-and-MS4W-2.2.7-tp17264849p17264849.html Sent from the Mapserver - User mailing list archive at Nabble.com. ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users
[MAPSERVER-USERS] Routing Algorithm Confusion !
Dear Readers, I use Dijkstra's shortest path algorithm for route computation. I am satisfied with the accurate result it gives. Still, I feel for road segments ~ 200Million, the route computation will take a lot of time. So, is there another algorithms exist as best practices for route computation(like A*,TSP,etc)? Or, geeks write their own algorithm for route computation? Thanks and Regards, Ritesh Ambastha -- View this message in context: http://www.nabble.com/Routing-Algorithm-Confusion-%21-tp17264809p17264809.html Sent from the Mapserver - User mailing list archive at Nabble.com. ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users
Re: [mapserver-users] about PHP and HTML
On 5/15/08, Francisco <[EMAIL PROTECTED]> wrote:
>
>
>
>
> Hello,
>
> It is possible to execute one function PHP using a button object in one form
>
> for example
>
> function showmy()
>
> {
>
> echo "Hello"
>
> }
>
> ..
>
>
>
> onClick="showmy()";
>
>
>
> Salas
>
you are confusing server-side PHP with client-side JavaScript. You can
certainly execute a JavaScript function called showmy() on clicking an
HTML form button, but to execute a sever-side PHP script, you have to
send the web page back to the server.
Look up a basic tutorial on server-side vs. client-side scripting for
further help.
___
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users
[mapserver-users] about PHP and HTML
Hello,
It is possible to execute one function PHP using a button object in one form
for example
function showmy()
{
echo "Hello"
}
..
Salas
___
Este mensaje esta libre de virus.
Revisado por Kaspersky Antivirus
Engine version: 4.0.1.14
Engine date: 2002/06/25
Definition count: 691841
Definition date: 2008/05/15
MDAV version: 2.2.9
Dpto de Sistemas Informáticos
Oficina Central Grupo Empresarial GEOCUBA
___
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users
Re: [mapserver-users] msLoadMap() Unable to access file
Hello, There were changes in MapServer 5.0 in the way CGI variables are passed...so you might try to replace that "map_web_imagepath" line in your hello.html with something like: -jeff On 15-May-08, at 4:47 PM, Νίκος Παπαδάκης wrote: Hello. I try to run an example i found in B. Kropla's book (Beginning MapServer - Open Source GIS Development) in windows XP. I create a hello.html template which is placed in htdocs folder of the Apache server. Also, hello.map is placed in htdocs folder as well. The contents of hello.html are: MapServer Hello World value="hello.map"> name="map_web_imagepath" value="c:\ms4w\Apache\htdocs\tmp\"> The conents of hello.map are: #This is our "Hello World" mapfile NAME "Hello_world" SIZE 400 300 IMAGECOLOR 249 245 186 IMAGETYPE png EXTENT -1.00 -1.00 1.00 1.00 WEB TEMPLATE "c:\ms4w\Apache\htdocs\hello.html" IMAGEPATH "c:\ms4w\Apache\htdocs\tmp\" IMAGEURL "\tmp\" END LAYER STATUS default TYPE point FEATURE POINTS 0.0 0.0 END TEXT "Hello World" END CLASS STYLE COLOR 255 0 0 END LABEL TYPE bitmap END END END END When i click on "Click me" button i get the message msLoadMap() Unable to access file hello.map. Furthemore,when i move hello.map in cgi-bin folder of the Apache server and change the corresponding line in hello.html to i get the message loadWeb(): Unknown identifier. Parsing error near (C):(line 1) Furthemore,when i open hello.html instead of getting just the click- me button i get the following: \par \lang1033\f1 \lang1032\f0 \par \lang1033\f1 \lang1032\f0 \par \lang1033\f1 \lang1032\f0 \par \lang1033\f1 \lang1032\f0 \par \lang1033\f1 \lang1032\f0 <[img].html>\par \par \par } I have read other mail on the same problem but i could not figure it out. Thank you. Nikos Papadakis Department of Computer & Communications Engineering Univercity of Thessaly. ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users
[MAPSERVER-USERS] GD 2.0.35 installed but not found
First time mapserver install. Below is my config script and output. Any insight into why libgd is not working out here?I am running this on Solaris 9. As you can see libgd.so definitely exists in the required directory and it has no problem accessing jpeg, freetype, png, iconv. Thanks! Dave unix:mapserver-5.0.2> cat conf_mapserv.sh # MapServer configure command # May 2 2008 ./configure --with-debug \ --with-freetype \ --with-zlib \ --with-png \ --with-jpeg \ --with-libiconv \ --with-gd=/usr/local/lib \ --with-proj \ --with-threads \ --with-ogr \ --with-gdal \ --with-tiff \ --with-oraclespatial \ --with-wfs \ --with-wcs \ --with-wfsclient \ --with-wmsclient \ --with-curl-config \ --with-warnings \ --enable-debug unix:mapserver-5.0.2> cat install_mapserver.log checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking for ranlib... ranlib checking for flex... flex checking for yywrap in -lfl... yes checking lex output file root... lex.yy checking whether yytext is a pointer... yes checking for bison... bison -y checking if compiler supports -R... yes checking for exp in -lm... yes checking for __gxx_personality_v0 in -lstdc++... yes checking how to run the C preprocessor... gcc -E checking for egrep... grep -E checking for ANSI C header files... yes checking for strcasecmp... yes checking for strncasecmp... yes checking for strdup... yes checking for strlcat... yes checking for vsnprintf... yes MapServer Version from mapserver.h: '5.0.2' configure: checking where FreeType 2.x is installed... checking for freetype-config... /usr/local/bin/freetype-config using libfreetype from -L/usr/local/lib -R/usr/local/lib -lfreetype -lz checking for FT_Init_FreeType in -lfreetype... yes using libfreetype -lfreetype from system libs. configure: checking where Zlib is installed... checking for zlibVersion in -lz... yes using libz from system libs (-DUSE_ZLIB). configure: checking where PNG is installed... checking for png_init_io in -lpng... yes using libpng from system libs. configure: checking whether we should include JPEG support... checking for jpeg_read_header in -ljpeg... yes using libjpeg from system libs. configure: checking where libXpm is installed... using libXpm from -L/lib -lXpm -lX11 configure: checking where libiconv is installed... checking for iconv_open in -lc... yes checking for libiconv_open in -liconv... yes using libiconv from -L -liconv libiconv found. Enabling internationalization (-DUSE_ICONV) configure: checking for GD 2.0.16 or higher... checking for gdFontCacheSetup in -lgd... no configure: checking whether GD needs libiconv... checking for gdFontCacheSetup in -lgd... no configure: error: Could not find gd.h or libgd.a/libgd.so in /usr/local/lib. Make sure GD 2.0.16 or higher is compiled before calling configure. You may also get this error if you didn't specify the appropriate location for one of GD's dependencies (freetype, libpng, libjpeg or libiconv). unix:mapserver-5.0.2> ls -l /usr/local/lib/libgd.* -rw-r--r-- 1 root other 806416 May 2 14:33 /usr/local/lib/libgd.a -rwxr-xr-x 1 root other 1055 May 2 14:33 /usr/local/lib/libgd.la* lrwxrwxrwx 1 root other 14 May 2 14:33 /usr/local/lib/libgd.so -> libgd.so.2.0.0* lrwxrwxrwx 1 root other 14 May 2 14:33 /usr/local/lib/libgd.so.2 -> libgd.so.2.0.0* -rwxr-xr-x 1 root other 815700 May 2 14:33 /usr/local/lib/libgd.so.2.0.0* unix:mapserver-5.0.2> grep VERSION /usr/local/include/gd.h #define GD_MAJOR_VERSION 2 #define GD_MINOR_VERSION 0 #define GD_RELEASE_VERSION 35 #define GD_EXTRA_VERSION "" #define GD_VERSION_STRING "2.0.35" -- View this message in context: http://www.nabble.com/GD-2.0.35-installed-but-not-found-tp17262832p17262832.html Sent from the Mapserver - User mailing list archive at Nabble.com. ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users
[mapserver-users] msLoadMap() Unable to access file
Hello. I try to run an example i found in B. Kropla's book (Beginning MapServer - Open Source GIS Development) in windows XP. I create a hello.html template which is placed in htdocs folder of the Apache server. Also, hello.map is placed in htdocs folder as well. The contents of hello.html are: MapServer Hello World The conents of hello.map are: #This is our "Hello World" mapfile NAME "Hello_world" SIZE 400 300 IMAGECOLOR 249 245 186 IMAGETYPE png EXTENT -1.00 -1.00 1.00 1.00 WEB TEMPLATE "c:\ms4w\Apache\htdocs\hello.html" IMAGEPATH "c:\ms4w\Apache\htdocs\tmp\" IMAGEURL "\tmp\" END LAYER STATUS default TYPE point FEATURE POINTS 0.0 0.0 END TEXT "Hello World" END CLASS STYLE COLOR 255 0 0 END LABEL TYPE bitmap END END END END When i click on "Click me" button i get the message msLoadMap() Unable to access file hello.map. Furthemore,when i move hello.map in cgi-bin folder of the Apache server and change the corresponding line in hello.html to i get the message loadWeb(): Unknown identifier. Parsing error near (C):(line 1) Furthemore,when i open hello.html instead of getting just the click-me button i get the following: \par \lang1033\f1 \lang1032\f0 \par \lang1033\f1 \lang1032\f0 \par \lang1033\f1 \lang1032\f0 \par \lang1033\f1 \lang1032\f0 \par \lang1033\f1 \lang1032\f0 \par \par \par } I have read other mail on the same problem but i could not figure it out. Thank you. Nikos Papadakis Department of Computer & Communications Engineering Univercity of Thessaly. ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users
Re: [MAPSERVER-USERS] color coding
Dear Kevin, Shortcuts are never good. You should write everything by yourself in the mapfile. Still, if you want to give a try, follow this shortcut. Install http://www.qgis.org/ QGIS (Freely available). Also, install http://www.python.org python (Freely available) Now, you can use QGIS as a desktop software where you can add multiple shapefiles, and play with them by giving required color combo's. Once you are satisfied with the color codes etc, you can EXPORT the rendered map into .map file format. Use this map file for rendering maps. That's all ! [I don't advice to use this way to generate map files] Regards, Ritesh Kevin Edmundson wrote: > > I have a layer that I want to color code the features for a specific > field. > > > > Is there a way in mapserver to have it automatically color all unique > values, or do I specifically have to identify the unique value/color > combinations myself in class items? > > > > Kevin Edmundson > > CIO > > WTH Technology, Inc > > 567 W Westfield Blvd > > Indianapolis, IN 46208 > > 317.259.0105 office > > 317.259.1423 fax > > 317.501.8560 mobile > > [EMAIL PROTECTED] > > > > NOTICE: This message is from the technology firm WTH Technology, Inc. > This message is intended only for the individual or entity to which it > is directed. If you are not the addressee, or if this message has been > addressed to you in error, you are not authorized to use, read, copy or > distribute this message and any attachments, and we ask that you please > immediately delete this message and attachments (including all copies), > and notify the sender by return e-mail so that our records can be > corrected. All personal messages express views only of the sender, which > are not to be attributed to WTH Technology, Inc, and may not be > distributed or copied without this statement. > > > > > ___ > mapserver-users mailing list > mapserver-users@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/mapserver-users > > -- View this message in context: http://www.nabble.com/color-coding-tp17239428p17260414.html Sent from the Mapserver - User mailing list archive at Nabble.com. ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users
Re: [mapserver-users] color coding
If your layer was raster, then you could use the COLORRANGE attribute to automatically assign a ramp of colors between a low value and a high value. See http://mapserver.gis.umn.edu/development/rfc/ms-rfc-6 On Wed, May 14, 2008 at 1:49 PM, Kevin Edmundson <[EMAIL PROTECTED]> wrote: > I have a layer that I want to color code the features for a specific field. > > Is there a way in mapserver to have it automatically color all unique > values, or do I specifically have to identify the unique value/color > combinations myself in class items? ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users
Re: [mapserver-users] testing mapserver large files rendering improvements
On Thu, May 15, 2008 at 10:15 AM, Bart van den Eijnden (OSGIS) <[EMAIL PROTECTED]> wrote: > 1) how will Mapserver know by default which depth to use for the index? On > large point shapefiles the default depth can result in negative performance. This says to me the heuristic needs to be smarter. I was just wondering that, when Frank said that the QIX can be larger than the SHP for points... that is not a given, perhaps the tree building code needs to be a little smarter > 2) currently shp2img does not report any error when it does not have write > permission on Linux, but I guess the new approach will first check write > permission before doing any analytics? shptree you mean? right, this will have to check first. > So it might make sense to have a layer setting to overrule the default > depth? Or to overrule automatic creation at all for a specific layer? if this option is enabled at compile time, the ability to shut it off in the map file will also be enabled. > Best regards, > Bart > > Stephen Woodbridge wrote: >> >> Paul, >> >> I think this is the best option because it gives control to the package >> builders and anyone that is a power user. >> >> I would also like to see msdebug report missing qix files. This is a >> valuable tuning tools for power users. >> >> Thanks, >> -Steve >> >> Paul Ramsey wrote: >>> >>> I have another "third way" option, which would be a compile-time >>> directive (--with-auto-qix) so that packagers can make dummy-friendly >>> builds if they so desire. >>> >>> ?? >>> >>> P >>> >>> On Thu, May 15, 2008 at 9:25 AM, Jeff McKenna <[EMAIL PROTECTED]> >>> wrote: My vote is for Paul's default qix creation option, by MapServer. Let's make life easy for those beginner Windows users. -jeff On 15-May-08, at 12:07 PM, Frank Warmerdam wrote: > Daniel Morissette wrote: >> >> Guillaume Sueur wrote: In my mind, we should do the right thing by default, and give the power users the option to opt out, rather than forcing everyone to become a power user to achieve something as basic as indexed file access. >>> >>> +1 for this approach >>> >> The right thing to do is not the same in everyone's eyes. > > Folks, > > I'm also against mapserver automatically creating .qix files, for the > reasons > Daniel and others have given. > > I'd add that current shapefile update tools (including he mapscript > shapefile > writing code, Shapelib and OGR) do *not* update .qix files. If > secretly > create a .qix file for a shapefile that is being periodically updated > all > hell is likely to break out. > > BTW, .qix files can be *relatively* large. For a shapefile of points, > the > .qix can easily be bigger than the .shx file. > > Best regards, > -- > ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users >>> ___ >>> mapserver-users mailing list >>> mapserver-users@lists.osgeo.org >>> http://lists.osgeo.org/mailman/listinfo/mapserver-users >> >> ___ >> mapserver-users mailing list >> mapserver-users@lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/mapserver-users >> >> > > > -- > Bart van den Eijnden > OSGIS, Open Source GIS > [EMAIL PROTECTED] > http://www.osgis.nl > > ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users
Re: [mapserver-users] testing mapserver large files rendering improvements
Want to toss in my 2 cents as well. I really find it a PITA what can happen if your qix file is out of sync with your shapefile. Very unpredictable things can happen, so I even find this a bigger problem than no qix file at all to be honest. A msDebug for this would be very much welcome. TatukGIS does the same when it opens up a shapefile, it checks if the spatial index is up to date and existing, if not it will update/create it. I think this makes sense, and a compile option would be a reasonable way to control this. A few questions though: 1) how will Mapserver know by default which depth to use for the index? On large point shapefiles the default depth can result in negative performance. 2) currently shp2img does not report any error when it does not have write permission on Linux, but I guess the new approach will first check write permission before doing any analytics? So it might make sense to have a layer setting to overrule the default depth? Or to overrule automatic creation at all for a specific layer? Best regards, Bart Stephen Woodbridge wrote: Paul, I think this is the best option because it gives control to the package builders and anyone that is a power user. I would also like to see msdebug report missing qix files. This is a valuable tuning tools for power users. Thanks, -Steve Paul Ramsey wrote: I have another "third way" option, which would be a compile-time directive (--with-auto-qix) so that packagers can make dummy-friendly builds if they so desire. ?? P On Thu, May 15, 2008 at 9:25 AM, Jeff McKenna <[EMAIL PROTECTED]> wrote: My vote is for Paul's default qix creation option, by MapServer. Let's make life easy for those beginner Windows users. -jeff On 15-May-08, at 12:07 PM, Frank Warmerdam wrote: Daniel Morissette wrote: Guillaume Sueur wrote: In my mind, we should do the right thing by default, and give the power users the option to opt out, rather than forcing everyone to become a power user to achieve something as basic as indexed file access. +1 for this approach The right thing to do is not the same in everyone's eyes. Folks, I'm also against mapserver automatically creating .qix files, for the reasons Daniel and others have given. I'd add that current shapefile update tools (including he mapscript shapefile writing code, Shapelib and OGR) do *not* update .qix files. If secretly create a .qix file for a shapefile that is being periodically updated all hell is likely to break out. BTW, .qix files can be *relatively* large. For a shapefile of points, the .qix can easily be bigger than the .shx file. Best regards, -- ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users -- Bart van den Eijnden OSGIS, Open Source GIS [EMAIL PROTECTED] http://www.osgis.nl ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users
Re: [mapserver-users] testing mapserver large files rendering improvements
I've ticketed the idea in this form. http://trac.osgeo.org/mapserver/ticket/2618 On Thu, May 15, 2008 at 11:05 AM, Stephen Woodbridge <[EMAIL PROTECTED]> wrote: > Paul, > > I think this is the best option because it gives control to the package > builders and anyone that is a power user. > > I would also like to see msdebug report missing qix files. This is a > valuable tuning tools for power users. > > Thanks, > -Steve > > Paul Ramsey wrote: >> >> I have another "third way" option, which would be a compile-time >> directive (--with-auto-qix) so that packagers can make dummy-friendly >> builds if they so desire. >> >> ?? >> >> P >> >> On Thu, May 15, 2008 at 9:25 AM, Jeff McKenna <[EMAIL PROTECTED]> >> wrote: >>> >>> My vote is for Paul's default qix creation option, by MapServer. Let's >>> make >>> life easy for those beginner Windows users. >>> >>> -jeff >>> >>> >>> >>> >>> >>> On 15-May-08, at 12:07 PM, Frank Warmerdam wrote: >>> Daniel Morissette wrote: > > Guillaume Sueur wrote: >>> >>> In my mind, we should do the right thing by default, and give the >>> power users the option to opt out, rather than forcing everyone to >>> become a power user to achieve something as basic as indexed file >>> access. >> >> +1 for this approach >> > The right thing to do is not the same in everyone's eyes. Folks, I'm also against mapserver automatically creating .qix files, for the reasons Daniel and others have given. I'd add that current shapefile update tools (including he mapscript shapefile writing code, Shapelib and OGR) do *not* update .qix files. If secretly create a .qix file for a shapefile that is being periodically updated all hell is likely to break out. BTW, .qix files can be *relatively* large. For a shapefile of points, the .qix can easily be bigger than the .shx file. Best regards, -- >>> ___ >>> mapserver-users mailing list >>> mapserver-users@lists.osgeo.org >>> http://lists.osgeo.org/mailman/listinfo/mapserver-users >>> >> ___ >> mapserver-users mailing list >> mapserver-users@lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/mapserver-users > > ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users
Re: [mapserver-users] testing mapserver large files rendering improvements
Paul, I think this is the best option because it gives control to the package builders and anyone that is a power user. I would also like to see msdebug report missing qix files. This is a valuable tuning tools for power users. Thanks, -Steve Paul Ramsey wrote: I have another "third way" option, which would be a compile-time directive (--with-auto-qix) so that packagers can make dummy-friendly builds if they so desire. ?? P On Thu, May 15, 2008 at 9:25 AM, Jeff McKenna <[EMAIL PROTECTED]> wrote: My vote is for Paul's default qix creation option, by MapServer. Let's make life easy for those beginner Windows users. -jeff On 15-May-08, at 12:07 PM, Frank Warmerdam wrote: Daniel Morissette wrote: Guillaume Sueur wrote: In my mind, we should do the right thing by default, and give the power users the option to opt out, rather than forcing everyone to become a power user to achieve something as basic as indexed file access. +1 for this approach The right thing to do is not the same in everyone's eyes. Folks, I'm also against mapserver automatically creating .qix files, for the reasons Daniel and others have given. I'd add that current shapefile update tools (including he mapscript shapefile writing code, Shapelib and OGR) do *not* update .qix files. If secretly create a .qix file for a shapefile that is being periodically updated all hell is likely to break out. BTW, .qix files can be *relatively* large. For a shapefile of points, the .qix can easily be bigger than the .shx file. Best regards, -- ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users
Re: [mapserver-users] testing mapserver large files rendering improvements
I have another "third way" option, which would be a compile-time directive (--with-auto-qix) so that packagers can make dummy-friendly builds if they so desire. ?? P On Thu, May 15, 2008 at 9:25 AM, Jeff McKenna <[EMAIL PROTECTED]> wrote: > My vote is for Paul's default qix creation option, by MapServer. Let's make > life easy for those beginner Windows users. > > -jeff > > > > > > On 15-May-08, at 12:07 PM, Frank Warmerdam wrote: > >> Daniel Morissette wrote: >>> >>> Guillaume Sueur wrote: > > In my mind, we should do the right thing by default, and give the > power users the option to opt out, rather than forcing everyone to > become a power user to achieve something as basic as indexed file > access. +1 for this approach >>> The right thing to do is not the same in everyone's eyes. >> >> Folks, >> >> I'm also against mapserver automatically creating .qix files, for the >> reasons >> Daniel and others have given. >> >> I'd add that current shapefile update tools (including he mapscript >> shapefile >> writing code, Shapelib and OGR) do *not* update .qix files. If secretly >> create a .qix file for a shapefile that is being periodically updated all >> hell is likely to break out. >> >> BTW, .qix files can be *relatively* large. For a shapefile of points, the >> .qix can easily be bigger than the .shx file. >> >> Best regards, >> -- >> > > ___ > mapserver-users mailing list > mapserver-users@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/mapserver-users > ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users
Re: [mapserver-users] testing mapserver large files rendering improvements
My vote is for Paul's default qix creation option, by MapServer. Let's make life easy for those beginner Windows users. -jeff On 15-May-08, at 12:07 PM, Frank Warmerdam wrote: Daniel Morissette wrote: Guillaume Sueur wrote: In my mind, we should do the right thing by default, and give the power users the option to opt out, rather than forcing everyone to become a power user to achieve something as basic as indexed file access. +1 for this approach The right thing to do is not the same in everyone's eyes. Folks, I'm also against mapserver automatically creating .qix files, for the reasons Daniel and others have given. I'd add that current shapefile update tools (including he mapscript shapefile writing code, Shapelib and OGR) do *not* update .qix files. If secretly create a .qix file for a shapefile that is being periodically updated all hell is likely to break out. BTW, .qix files can be *relatively* large. For a shapefile of points, the .qix can easily be bigger than the .shx file. Best regards, -- ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users
Re: [mapserver-users] Trouble compiling 5.0.2 with AGG on Centos 4
try
--with-freetype=/usr/bin
and
--with-agg=/path/to/agg/build/dir
Guillaume
Dominik Schmid a écrit :
We've finally decided to move forward and replace our ageing Mapserver
4.0.1 installation with the latest and greatest version.
I came as far as thinking that the AGG make was successfull, but when I
try to configure Mapserver ("/.configure -with-agg --with-freetype") I
get the following error:
configure: error: freetype required for agg support - please configure
--with-freetype
I did include some directories with both options with the same result.
I'm not sure where AGG is exactly installed (directly in "agg-2.x" or in
a subdirectory in there) nor which freetype directory to use located
(the libfreetype.* files are in "/usr/lib" but freetype-config is in
"/usr/bin").
When I check in yum I see that freetype 2.1.9 is in fact installed. One
problem I see is with AGG, I can't get it through Centos 4 repositories
so I guess need to compile it myself. I've tried various instructions:
- http://trac.osgeo.org/mapserver/ticket/2215 (not sure if that's still
valid info)
- Rich Fromm's instructions posted on this list on Nov 27, 2007
The instruction in ticket 2215 don't result in the promised
agg_font_freetype.o file, neither in agg-2.4 nor agg-2.5.
Rich's instructions for build AGG (". autogen.sh") exits with the
following error:
./configure: line 4513: syntax error near unexpected token 'FREETYPE,'
./configure: line 4513: 'PKG_CHECK_MODULES(FREETYPE,'
I'm kind of lost with this, so I'm turning to this list for help.
Documentation for installing Mapserver 5 with AGG support seems scarce.
Here's some more system info:
- Centos 4.4
- Apache 2.0.52
- PHP 5.1.6
- pgsql 8.1.8
- freetype and freetype-devel 2.1.9
... I can give more specs if needed.
Any help is greatly appreciated
Dominik
___
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users
[mapserver-users] Trouble compiling 5.0.2 with AGG on Centos 4
We've finally decided to move forward and replace our ageing Mapserver
4.0.1 installation with the latest and greatest version.
I came as far as thinking that the AGG make was successfull, but when I
try to configure Mapserver ("/.configure -with-agg --with-freetype") I
get the following error:
configure: error: freetype required for agg support - please configure
--with-freetype
I did include some directories with both options with the same result.
I'm not sure where AGG is exactly installed (directly in "agg-2.x" or in
a subdirectory in there) nor which freetype directory to use located
(the libfreetype.* files are in "/usr/lib" but freetype-config is in
"/usr/bin").
When I check in yum I see that freetype 2.1.9 is in fact installed. One
problem I see is with AGG, I can't get it through Centos 4 repositories
so I guess need to compile it myself. I've tried various instructions:
- http://trac.osgeo.org/mapserver/ticket/2215 (not sure if that's still
valid info)
- Rich Fromm's instructions posted on this list on Nov 27, 2007
The instruction in ticket 2215 don't result in the promised
agg_font_freetype.o file, neither in agg-2.4 nor agg-2.5.
Rich's instructions for build AGG (". autogen.sh") exits with the
following error:
./configure: line 4513: syntax error near unexpected token 'FREETYPE,'
./configure: line 4513: 'PKG_CHECK_MODULES(FREETYPE,'
I'm kind of lost with this, so I'm turning to this list for help.
Documentation for installing Mapserver 5 with AGG support seems scarce.
Here's some more system info:
- Centos 4.4
- Apache 2.0.52
- PHP 5.1.6
- pgsql 8.1.8
- freetype and freetype-devel 2.1.9
... I can give more specs if needed.
Any help is greatly appreciated
Dominik
--
Dominik Schmid
Dipl. Umweltnaturwissenschafter ETH
ilu AG
Zentralstrasse 2a
CH-8610 Uster
Tel: +41 44 / 944 55 56(Direktwahl)
Tel: +41 44 / 944 55 55(allgemein)
Fax: +41 44 / 944 55 66
mailto:[EMAIL PROTECTED]
http://www.ilu.ch
___
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users
Re: [mapserver-users] testing mapserver large files rendering improvements
Daniel Morissette wrote: Guillaume Sueur wrote: In my mind, we should do the right thing by default, and give the power users the option to opt out, rather than forcing everyone to become a power user to achieve something as basic as indexed file access. +1 for this approach The right thing to do is not the same in everyone's eyes. Folks, I'm also against mapserver automatically creating .qix files, for the reasons Daniel and others have given. I'd add that current shapefile update tools (including he mapscript shapefile writing code, Shapelib and OGR) do *not* update .qix files. If secretly create a .qix file for a shapefile that is being periodically updated all hell is likely to break out. BTW, .qix files can be *relatively* large. For a shapefile of points, the .qix can easily be bigger than the .shx file. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| President OSGeo, http://osgeo.org ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users
Re: [mapserver-users] testing mapserver large files rendering improvements
On 5/15/08, Paul Ramsey <[EMAIL PROTECTED]> wrote: > It gets better... since most of our power users are on Linux, this > feature will never kick in for them: apache won't have write access to > their data directories. And since most of our new users on our > Windows, this feature will kick in for most of them. > > But I'd like to hear from more users, otherwise it's just us monkeys > nattering to each other. Since you asked. I favor your approach -- just do it for me, the non-power user. Remember those "turbo" buttons on old desktop PCs? For some reason, you could "choose" to run them fast, but they would default to slow (I am not talking about overclocking or any such nerdy thing... I am just talking about a button that said "turbo.") I can't imagine why anyone would want to run their desktop PCs slow on purpose... Just make the indexes that will help me do my work faster and spare me the details. For those who may want more control, give them an opt out. I know this increases your work to make this idiot-proof, but you asked for opinions. DWIM -- do what I mean, and I always mean faster. > > P > > On Thu, May 15, 2008 at 8:46 AM, Paul Ramsey <[EMAIL PROTECTED]> wrote: > > On Thu, May 15, 2008 at 9:21 AM, Stephen Woodbridge > > <[EMAIL PROTECTED]> wrote: > >> > >> -1 on magic happens. > >> 1) performance issues if the files already exist > > > > None. > > > >> 2) what if the filesystem is readonly > > > > Do nothing. > > > >> 3) what if the filesystem overflows > > > > Back out. > > > >> 4) etc > > > > It's not like this is un-precedented, ArcView3 merrily plops useful > > index files down next to .shp when it is asked to run ops that need > > indexes. It doesn't run slow and force you to figure out you need to > > run the "Create Index" option. > > > > In my mind, we should do the right thing by default, and give the > > power users the option to opt out, rather than forcing everyone to > > become a power user to achieve something as basic as indexed file > > access. > > > > P. > > > ___ > mapserver-users mailing list > mapserver-users@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/mapserver-users > -- Puneet Kishor http://punkish.eidesis.org/ Nelson Institute for Environmental Studies http://www.nelson.wisc.edu/ Open Source Geospatial Foundation (OSGeo) http://www.osgeo.org/ ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users
Re: [mapserver-users] testing mapserver large files rendering improvements
Guillaume Sueur wrote: In my mind, we should do the right thing by default, and give the power users the option to opt out, rather than forcing everyone to become a power user to achieve something as basic as indexed file access. +1 for this approach The right thing to do is not the same in everyone's eyes. In my eyes, creating .qix files by magic and risk filling up a hard drive partition and causing other tools relying on some amount of free space on the same partition to fail is not the right thing to do by default... but that's just me. Yes, I know, .qix files are relatively small, but you're opening the door to other operations of the same type that could end up really filling a disk without the admin even expecting it... because he thought of MapServer data access as a read-only operation like I used to. /me wonders why PostGIS doesn't create indexes on geometries by default if indexing is the right thing to do by default (or does it do that already?). Daniel -- Daniel Morissette http://www.mapgears.com/ ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users
Re: [mapserver-users] testing mapserver large files rendering improvements
In my mind, we should do the right thing by default, and give the power users the option to opt out, rather than forcing everyone to become a power user to achieve something as basic as indexed file access. +1 for this approach Guillaume ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users
Re: [mapserver-users] testing mapserver largefiles rendering improvements
- Check for every POSTGIS layer that the table has a GIST index - Check that TEMPLATE is set whenever TOLERANCE is set (or however one can find that a specific layer is intended to be queryable...) - Check that DUMP TRUE if wfs metadata is found I'm not convinced on the jpg,png -> tif conversion. Some data must be used in the user's desired format. Maybe just sending advices and command-lines would be enough. Paul Ramsey a écrit : mapperf -m foo.map -x -m is map file -x executes fixes default mode just reports issues Things it would do/report: - All shape files have up-to-date qix - Replace "init:epsg" entries in PROJECTION blocks with their proj4 literals and fill in the appropriate ows_ metadata to make up for the change - Convert .jpg, .png to .tif - Build overviews on .tif - Internally tile .tif - ... On Thu, May 15, 2008 at 8:34 AM, Burgholzer,Robert <[EMAIL PROTECTED]> wrote: If there is zero overhead to check for the existence of a ".qix" file and determine if it is up to date, I think this is a good default (no magic required). As for making it work out of the box for the typical user who is not interested in the nitty-gritty: Perhaps the "quick install" documents could say "Step X: Run the shptree on all your shape files". Robert W. Burgholzer Surface Water Modeler Office of Water Supply and Planning Virginia Department of Environmental Quality [EMAIL PROTECTED] 804-698-4405 Open Source Modeling Tools: http://sourceforge.net/projects/npsource/ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Guillaume Sueur Sent: Thursday, May 15, 2008 11:24 AM To: Daniel Morissette Cc: Mapserver-users Subject: Re: [mapserver-users] testing mapserver largefiles rendering improvements I'm not sure that "standard" user uses often msDebug(). My point was just to say that if somebody tries and tests MapServer, he/she will only read the basic documentation to have a working mapfile on a dataset. Once it works, no more reading will be done. And if a large shape is tested, the user can then be disappointed. The thing is that it's more than a specific tuning stuff, maybe more than a GIST index on a postGIS database. I think it should be mentionned at least in the Vector Data Access / shapefiles doc of the website. In addition to "Shapefiles are made up of a minimum of three similarly named files, with different suffixes..", one could write : "having a .qix file made with shptree improves considerabily the performances, mostly on large shapefiles" Beside this, I like the idea of building a MapFile Optimizer too... Daniel, what do you have in mind exactly ? -- Guillaume ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users -- Guillaume SUEUR Expert SIG et OpenSource NEOGEO 46 RUE MATABIAU 31000 TOULOUSE 06 74 91 95 20 Site web : http://www.neogeo-online.net ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users
Re: [mapserver-users] testing mapserver large files rendering improvements
It gets better... since most of our power users are on Linux, this feature will never kick in for them: apache won't have write access to their data directories. And since most of our new users on our Windows, this feature will kick in for most of them. But I'd like to hear from more users, otherwise it's just us monkeys nattering to each other. P On Thu, May 15, 2008 at 8:46 AM, Paul Ramsey <[EMAIL PROTECTED]> wrote: > On Thu, May 15, 2008 at 9:21 AM, Stephen Woodbridge > <[EMAIL PROTECTED]> wrote: >> >> -1 on magic happens. >> 1) performance issues if the files already exist > > None. > >> 2) what if the filesystem is readonly > > Do nothing. > >> 3) what if the filesystem overflows > > Back out. > >> 4) etc > > It's not like this is un-precedented, ArcView3 merrily plops useful > index files down next to .shp when it is asked to run ops that need > indexes. It doesn't run slow and force you to figure out you need to > run the "Create Index" option. > > In my mind, we should do the right thing by default, and give the > power users the option to opt out, rather than forcing everyone to > become a power user to achieve something as basic as indexed file > access. > > P. > ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users
Re: [mapserver-users] testing mapserver large files rendering improvements
On Thu, May 15, 2008 at 9:21 AM, Stephen Woodbridge <[EMAIL PROTECTED]> wrote: > > -1 on magic happens. > 1) performance issues if the files already exist None. > 2) what if the filesystem is readonly Do nothing. > 3) what if the filesystem overflows Back out. > 4) etc It's not like this is un-precedented, ArcView3 merrily plops useful index files down next to .shp when it is asked to run ops that need indexes. It doesn't run slow and force you to figure out you need to run the "Create Index" option. In my mind, we should do the right thing by default, and give the power users the option to opt out, rather than forcing everyone to become a power user to achieve something as basic as indexed file access. P. ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users
Re: [mapserver-users] testing mapserver largefiles rendering improvements
mapperf -m foo.map -x -m is map file -x executes fixes default mode just reports issues Things it would do/report: - All shape files have up-to-date qix - Replace "init:epsg" entries in PROJECTION blocks with their proj4 literals and fill in the appropriate ows_ metadata to make up for the change - Convert .jpg, .png to .tif - Build overviews on .tif - Internally tile .tif - ... On Thu, May 15, 2008 at 8:34 AM, Burgholzer,Robert <[EMAIL PROTECTED]> wrote: > If there is zero overhead to check for the existence of a ".qix" file > and determine if it is up to date, I think this is a good default (no > magic required). > > As for making it work out of the box for the typical user who is not > interested in the nitty-gritty: Perhaps the "quick install" documents > could say "Step X: Run the shptree on all your shape files". > > > > Robert W. Burgholzer > Surface Water Modeler > Office of Water Supply and Planning > Virginia Department of Environmental Quality > [EMAIL PROTECTED] > 804-698-4405 > Open Source Modeling Tools: > http://sourceforge.net/projects/npsource/ > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Guillaume > Sueur > Sent: Thursday, May 15, 2008 11:24 AM > To: Daniel Morissette > Cc: Mapserver-users > Subject: Re: [mapserver-users] testing mapserver largefiles rendering > improvements > > I'm not sure that "standard" user uses often msDebug(). > My point was just to say that if somebody tries and tests MapServer, > he/she will only read the basic documentation to have a working mapfile > on a dataset. Once it works, no more reading will be done. And if a > large shape is tested, the user can then be disappointed. > The thing is that it's more than a specific tuning stuff, maybe more > than a GIST index on a postGIS database. > I think it should be mentionned at least in the Vector Data Access / > shapefiles doc of the website. In addition to "Shapefiles are made up of > > a minimum of three similarly named files, with different suffixes..", > one could write : "having a .qix file made with shptree improves > considerabily the performances, mostly on large shapefiles" > > Beside this, I like the idea of building a MapFile Optimizer too... > Daniel, what do you have in mind exactly ? > > > -- > Guillaume > ___ > mapserver-users mailing list > mapserver-users@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/mapserver-users > ___ > mapserver-users mailing list > mapserver-users@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/mapserver-users > ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users
Re: [mapserver-users] testing mapserver large files rendering improvements
Guillaume Sueur wrote: I'm not sure that "standard" user uses often msDebug(). True. They need to be educated on how to optimize their mapfiles and data and looking at debug output at level 2 (tuning level) is one of the ways. I believe there is already a doc about optimizing maps and this should be added to it. Beside this, I like the idea of building a MapFile Optimizer too... Daniel, what do you have in mind exactly ? I don't have anything specific in mind, I was just thinking out loud... that could simply be a program that you would run on a mapfile and would make some performance tests and reports. It would look for common problems and report them or attempt to fix them. Daniel -- Daniel Morissette http://www.mapgears.com/ ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users
RE: [mapserver-users] testing mapserver largefiles rendering improvements
If there is zero overhead to check for the existence of a ".qix" file and determine if it is up to date, I think this is a good default (no magic required). As for making it work out of the box for the typical user who is not interested in the nitty-gritty: Perhaps the "quick install" documents could say "Step X: Run the shptree on all your shape files". Robert W. Burgholzer Surface Water Modeler Office of Water Supply and Planning Virginia Department of Environmental Quality [EMAIL PROTECTED] 804-698-4405 Open Source Modeling Tools: http://sourceforge.net/projects/npsource/ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Guillaume Sueur Sent: Thursday, May 15, 2008 11:24 AM To: Daniel Morissette Cc: Mapserver-users Subject: Re: [mapserver-users] testing mapserver largefiles rendering improvements I'm not sure that "standard" user uses often msDebug(). My point was just to say that if somebody tries and tests MapServer, he/she will only read the basic documentation to have a working mapfile on a dataset. Once it works, no more reading will be done. And if a large shape is tested, the user can then be disappointed. The thing is that it's more than a specific tuning stuff, maybe more than a GIST index on a postGIS database. I think it should be mentionned at least in the Vector Data Access / shapefiles doc of the website. In addition to "Shapefiles are made up of a minimum of three similarly named files, with different suffixes..", one could write : "having a .qix file made with shptree improves considerabily the performances, mostly on large shapefiles" Beside this, I like the idea of building a MapFile Optimizer too... Daniel, what do you have in mind exactly ? -- Guillaume ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users
Re: [mapserver-users] testing mapserver large files rendering improvements
I'm not sure that "standard" user uses often msDebug(). My point was just to say that if somebody tries and tests MapServer, he/she will only read the basic documentation to have a working mapfile on a dataset. Once it works, no more reading will be done. And if a large shape is tested, the user can then be disappointed. The thing is that it's more than a specific tuning stuff, maybe more than a GIST index on a postGIS database. I think it should be mentionned at least in the Vector Data Access / shapefiles doc of the website. In addition to "Shapefiles are made up of a minimum of three similarly named files, with different suffixes..", one could write : "having a .qix file made with shptree improves considerabily the performances, mostly on large shapefiles" Beside this, I like the idea of building a MapFile Optimizer too... Daniel, what do you have in mind exactly ? -- Guillaume ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users
Re: [mapserver-users] testing mapserver large files rendering improvements
On Thu, May 15, 2008 at 8:00 AM, Kristian Thy <[EMAIL PROTECTED]> wrote: > On Thu, May 15, Paul Ramsey wrote: >> I've been thinking about auto-building qix files... it would fix this >> problem and also fix the problem of the shape file that gets updated >> and out-of-synch with its index file. > > Seeing that this would probably lead to (slightly) decreased performance > since mapserver-cgi would need to verify the qix for each shapefile for > each request, I would at least encourage adding it as a map file option > (default off) Not really, we're talking about zero overhead. Only do it for shape files you are going to draw, and then all you're doing is checking for file existence and comparing the nrecords headers, all of which you have to do anyways for the draw. > Then again, you wouldn't get the benefit of it if you don't read the > docs, which is the problem you're trying to fix ;) Well yeah, it has to be on by default, or it misses the point of helping people get the most out of mapserver with the least start-up knowledge. > \\kristian > -- > ... et nemo ex vobis interrogat me: »Quo vadis?« > ___ > mapserver-users mailing list > mapserver-users@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/mapserver-users > ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users
Re: [mapserver-users] testing mapserver large files rendering improvements
Daniel Morissette wrote:
Paul Ramsey wrote:
I've been thinking about auto-building qix files... it would fix this
problem and also fix the problem of the shape file that gets updated
and out-of-synch with its index file.
I think programmers will hate the idea, but users, maybe they will
like it? What do you think?
You guessed right... I, as a programmer, am not keen on that kind of
magic behavior. I like to think of dataset access by MapServer as a
read-only operation, for security and various reasons I would not want
to allow write access to the data dirs. But I'd be happy to see a
"Mapfile optimizer" tool that does this kind of stuff.
BTW, a step we could easily take in the short term is add a msDebug()
message at level >= MS_DEBUGLEVEL_TUNING warning users that a given
shapefile hass no .qix and adding one could increase performance.
There could also be a test added at the same debug level and if the .shp
file date is newer than the .qix then produce a warning saying that the
.qix may be out of date.
Daniel
-1 on magic happens.
1) performance issues if the files already exist
2) what if the filesystem is readonly
3) what if the filesystem overflows
4) etc
+1 on optimizer tool(s)
1) find -name \*.shp -exec shptree {} \;
But please keep up with your wonderful stream of ideas and improvements.
-Steve W
___
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users
Re: [mapserver-users] testing mapserver large files rendering improvements
Paul Ramsey wrote: I've been thinking about auto-building qix files... it would fix this problem and also fix the problem of the shape file that gets updated and out-of-synch with its index file. I think programmers will hate the idea, but users, maybe they will like it? What do you think? You guessed right... I, as a programmer, am not keen on that kind of magic behavior. I like to think of dataset access by MapServer as a read-only operation, for security and various reasons I would not want to allow write access to the data dirs. But I'd be happy to see a "Mapfile optimizer" tool that does this kind of stuff. BTW, a step we could easily take in the short term is add a msDebug() message at level >= MS_DEBUGLEVEL_TUNING warning users that a given shapefile hass no .qix and adding one could increase performance. There could also be a test added at the same debug level and if the .shp file date is newer than the .qix then produce a warning saying that the .qix may be out of date. Daniel -- Daniel Morissette http://www.mapgears.com/ ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users
Re: [mapserver-users] testing mapserver large files rendering improvements
On Thu, May 15, Paul Ramsey wrote: > I've been thinking about auto-building qix files... it would fix this > problem and also fix the problem of the shape file that gets updated > and out-of-synch with its index file. Seeing that this would probably lead to (slightly) decreased performance since mapserver-cgi would need to verify the qix for each shapefile for each request, I would at least encourage adding it as a map file option (default off). Then again, you wouldn't get the benefit of it if you don't read the docs, which is the problem you're trying to fix ;) \\kristian -- ... et nemo ex vobis interrogat me: »Quo vadis?« ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users
Re: [mapserver-users] testing mapserver large files rendering improvements
I've been thinking about auto-building qix files... it would fix this problem and also fix the problem of the shape file that gets updated and out-of-synch with its index file. I think programmers will hate the idea, but users, maybe they will like it? What do you think? On Thu, May 15, 2008 at 7:09 AM, Guillaume Sueur <[EMAIL PROTECTED]> wrote: > Thanks for theses informations Jeff. > I'd like to suggest to emphasis the need of a .qix file a little bit more in > the mapserver documentation. It's only explained in 'Utility Programs' > Section and 'Optimizing vector data sources' doc, but the huge benefit of it > (25 x faster in this case, but still 5x on small shapes) is not, IMHO, > mentionned enough to make people use it on every shapefile. > > Regards, > > Guillaume > > > Jeff McKenna a écrit : >> >> Hello, comments inline below: >> >> >> On 15-May-08, at 9:27 AM, Guillaume Sueur wrote: >> >>> Hi, >>> >>> I've just been doing few tests on mapserver trunk version to get an idea >>> of how much the rendering of large shapefiles has been improved by paul's >>> hacks on shx handler (http://blog.cleverelephant.ca/2008/04/see_30.html) >>> >>> My shapefile is 1 208 668 features, 160 Mo for the .shp file itself with >>> a .shx of 5.2 Mo >>> >>> here are the times for a 5x5 km map to be drawn with shp2img, in PNG (no >>> AGG) >>> >>> NO QIX : >>> mapserv 5.0.2 : 0.680 s >>> mapserv trunk : 0.699 s (!) >>> >>> WITH QIX : >>> mapserv 5.0.2 : 0.124 s >>> mapserv trunk : 0.027 s >>> >>> >>> it looks like if the improvement only appears with use of a .qix file, >>> which is highly recommended but sometimes forgotten. >>> Has anyone had the same kind of experiment ? >> >> yes: http://lists.osgeo.org/pipermail/mapserver-dev/2008-April/007170.html >> >>> >>> >>> >>> By the way, I noticed that it doesn't seem mandatory anymore to write the >>> mapfile's DATA statement without the .shp extension to make use of the .qix >>> file, as the results are strictly identical on mapserver trunk if I write >>> "streets.shp" or "streets". Can someone confirm that ? >>> >> >> Confirmed. This was fixed recently (ticket: >> http://trac.osgeo.org/mapserver/ticket/590), verified, and documentation was >> updated. Therefore the next release of MapServer will no longer require you >> to omit the '.shp' for the DATA parameter for .qix use. >> >> -jeff >> >> >> ___ >> mapserver-users mailing list >> mapserver-users@lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/mapserver-users >> > > ___ > mapserver-users mailing list > mapserver-users@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/mapserver-users > ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users
Re: [MAPSERVER-USERS] PostGIS: Intersection of 2 areas
Susanne, (a) This is more a PostGIS query than a Mapserver query, you might have better luck on postgis-users. (b) It's impossible to know if you're getting right or wrong answers without knowing what geometries you are using. If A.Within(B) then A.Difference(B) will yield nothing, there will be nothing left. (c) You can do this op in one pass in SQL. No need for three queries. SELECT a.gid, b.gid, ST_Difference(a.the_geom, b.the_geom) FROM a, b WHERE a.gid = $gida AND b.gid = $gidb P On Thu, May 15, 2008 at 4:09 AM, SUSANNE <[EMAIL PROTECTED]> wrote: > > Hello, > > I am struggling with interserction of 2 areas of the same layer. > > $sql= "SELECT the_geom FROM " . $layername . " where gid= " . $gid1; > $res = pg_query ($sql); > $row = pg_fetch_array ($res); > $geom1= $row[0]; > > $sql= "SELECT the_geom FROM " . $layername . " where gid= " . $gid2; > $res = pg_query ($sql); > $row = pg_fetch_array ($res); > $geom2= $row[0]; > > $sql= "SELECT ST_Difference($geom1,$geom2)" ; > $res = pg_query ($sql); > $row = pg_fetch_array ($res); > $geom= $row[0]; > ^^^ > The current problem is that the last statement does not return anything ! > > The final goal of my efforts is to get rid of the common area in one of > two partially overlapping areas. > > Is my approach (see above) proper at all for that purpose ?!? > > With many thanks in advance for any comments and suggestions. > > Susanne > -- > View this message in context: > http://www.nabble.com/PostGIS%3A-Intersection-of-2-areas-tp17250805p17250805.html > Sent from the Mapserver - User mailing list archive at Nabble.com. > > ___ > mapserver-users mailing list > mapserver-users@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/mapserver-users > ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users
Re: [mapserver-users] testing mapserver large files rendering improvements
Thanks for theses informations Jeff. I'd like to suggest to emphasis the need of a .qix file a little bit more in the mapserver documentation. It's only explained in 'Utility Programs' Section and 'Optimizing vector data sources' doc, but the huge benefit of it (25 x faster in this case, but still 5x on small shapes) is not, IMHO, mentionned enough to make people use it on every shapefile. Regards, Guillaume Jeff McKenna a écrit : Hello, comments inline below: On 15-May-08, at 9:27 AM, Guillaume Sueur wrote: Hi, I've just been doing few tests on mapserver trunk version to get an idea of how much the rendering of large shapefiles has been improved by paul's hacks on shx handler (http://blog.cleverelephant.ca/2008/04/see_30.html) My shapefile is 1 208 668 features, 160 Mo for the .shp file itself with a .shx of 5.2 Mo here are the times for a 5x5 km map to be drawn with shp2img, in PNG (no AGG) NO QIX : mapserv 5.0.2 : 0.680 s mapserv trunk : 0.699 s (!) WITH QIX : mapserv 5.0.2 : 0.124 s mapserv trunk : 0.027 s it looks like if the improvement only appears with use of a .qix file, which is highly recommended but sometimes forgotten. Has anyone had the same kind of experiment ? yes: http://lists.osgeo.org/pipermail/mapserver-dev/2008-April/007170.html By the way, I noticed that it doesn't seem mandatory anymore to write the mapfile's DATA statement without the .shp extension to make use of the .qix file, as the results are strictly identical on mapserver trunk if I write "streets.shp" or "streets". Can someone confirm that ? Confirmed. This was fixed recently (ticket: http://trac.osgeo.org/mapserver/ticket/590), verified, and documentation was updated. Therefore the next release of MapServer will no longer require you to omit the '.shp' for the DATA parameter for .qix use. -jeff ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users
Re: [mapserver-users] testing mapserver large files rendering improvements
Hello, comments inline below: On 15-May-08, at 9:27 AM, Guillaume Sueur wrote: Hi, I've just been doing few tests on mapserver trunk version to get an idea of how much the rendering of large shapefiles has been improved by paul's hacks on shx handler (http://blog.cleverelephant.ca/2008/04/see_30.html ) My shapefile is 1 208 668 features, 160 Mo for the .shp file itself with a .shx of 5.2 Mo here are the times for a 5x5 km map to be drawn with shp2img, in PNG (no AGG) NO QIX : mapserv 5.0.2 : 0.680 s mapserv trunk : 0.699 s (!) WITH QIX : mapserv 5.0.2 : 0.124 s mapserv trunk : 0.027 s it looks like if the improvement only appears with use of a .qix file, which is highly recommended but sometimes forgotten. Has anyone had the same kind of experiment ? yes: http://lists.osgeo.org/pipermail/mapserver-dev/2008-April/007170.html By the way, I noticed that it doesn't seem mandatory anymore to write the mapfile's DATA statement without the .shp extension to make use of the .qix file, as the results are strictly identical on mapserver trunk if I write "streets.shp" or "streets". Can someone confirm that ? Confirmed. This was fixed recently (ticket: http://trac.osgeo.org/mapserver/ticket/590) , verified, and documentation was updated. Therefore the next release of MapServer will no longer require you to omit the '.shp' for the DATA parameter for .qix use. -jeff ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users
[mapserver-users] testing mapserver large files rendering improvements
Hi, I've just been doing few tests on mapserver trunk version to get an idea of how much the rendering of large shapefiles has been improved by paul's hacks on shx handler (http://blog.cleverelephant.ca/2008/04/see_30.html) My shapefile is 1 208 668 features, 160 Mo for the .shp file itself with a .shx of 5.2 Mo here are the times for a 5x5 km map to be drawn with shp2img, in PNG (no AGG) NO QIX : mapserv 5.0.2 : 0.680 s mapserv trunk : 0.699 s (!) WITH QIX : mapserv 5.0.2 : 0.124 s mapserv trunk : 0.027 s it looks like if the improvement only appears with use of a .qix file, which is highly recommended but sometimes forgotten. Has anyone had the same kind of experiment ? By the way, I noticed that it doesn't seem mandatory anymore to write the mapfile's DATA statement without the .shp extension to make use of the .qix file, as the results are strictly identical on mapserver trunk if I write "streets.shp" or "streets". Can someone confirm that ? Thanks Guillaume ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users
[mapserver-users] calculating extent on basis of distance from point
hi, i have OSGB36 data in postgre, srid 27700. what i want to do is to calculate the extent on basis of the distance from a given point. i have geom of type geometry in the table, from which to calculate extent. i have tried the funtions Distance(geom,geom)<50, but it is too slow, as it uses no index. i have calculated the point from the polygon by function Centroid(geom), from where the other distances have to be calculated, but i think its not working properly, as i am also testing it with the mapserver map and map saclebar, they are not matching exactly. i mean the scalebar is not showing 100 meter but instead showing 192 meters. the main isuue is of the time the distance query is taking. is there any why else to do this quickly. thanks ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users
Re: [mapserver-users] Customized layer for Mapserver/Kamap
Thank you very much Florin! This code is very useful, is not exactly what I needs but gives me orientation about how to implement my mapfile. 2008/5/14 Florin A. <[EMAIL PROTECTED]>: > Hi, > > In your mapfile you define the layers and the colors. See example below. > > If you have an SRID (projection) for the layer use it. You can see > what it is by selecting this sql in pgadmin: "select srid(the_geom) > from cities) . Use the number you get here in the mapserver layer > definition and in the projection definition as well. If you loaded > the cities with shp2pgsql then you should automatically have a gid > field on the cities table. And your cities table should have a > population field the type of which should be some kind of number. > > > LAYER >METADATA >"wms_title" "Cities layer" >END >NAME "cities" >TRANSPARENCY 100 >CONNECTIONTYPE postgis >CONNECTION "host=??? user=??? dbname=??? password='???'" >DATA "the_geom from cities using srid=??? USING UNIQUE gid" >TYPE POLYGON > > CLASS >NAME "Small cities" >EXPRESSION ( [population] <5) >COLOR 0 255 0 >END > >CLASS >NAME "Medium cities" >EXPRESSION ([population] >5 AND [population] <150 ) >COLOR 255 255 0 >END > >CLASS >NAME "Big cities" >EXPRESSION ([population] > 150 ) >COLOR 255 0 0 >END > > > END > > Hope this helps, > Florin > -- Emilio ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users
[MAPSERVER-USERS] PostGIS: Intersection of 2 areas
Hello, I am struggling with interserction of 2 areas of the same layer. $sql= "SELECT the_geom FROM " . $layername . " where gid= " . $gid1; $res = pg_query ($sql); $row = pg_fetch_array ($res); $geom1= $row[0]; $sql= "SELECT the_geom FROM " . $layername . " where gid= " . $gid2; $res = pg_query ($sql); $row = pg_fetch_array ($res); $geom2= $row[0]; $sql= "SELECT ST_Difference($geom1,$geom2)" ; $res = pg_query ($sql); $row = pg_fetch_array ($res); $geom= $row[0]; ^^^ The current problem is that the last statement does not return anything ! The final goal of my efforts is to get rid of the common area in one of two partially overlapping areas. Is my approach (see above) proper at all for that purpose ?!? With many thanks in advance for any comments and suggestions. Susanne -- View this message in context: http://www.nabble.com/PostGIS%3A-Intersection-of-2-areas-tp17250805p17250805.html Sent from the Mapserver - User mailing list archive at Nabble.com. ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users
Re: VS: [mapserver-users] Converting datum using ogr2ogr
Hi Jukka, and List, I got to the conversion that I expect with your advice. Now I understand how to use it. Many thanks ! Isao Rahkonen Jukka wrote: Hi Isao, I am sorry, I must admit that I haven't done my homework with datum shifting. However, I believe that reason for not getting any change in your reprojection is because the definition in the FWTools epsg ligrary for epsg:4301 is this: # Tokyo <4301> +proj=longlat +ellps=bessel +no_defs <> So it gives no towgs parameters which would tell what kind of shifting should be done. For comparison, this projection using bessel does have towgs84 parameters and a trial with that should lead to different result: # Bukit Rimpah <4219> +proj=longlat +ellps=bessel +towgs84=-384,664,-48,0,0,0,0 +no_defs <> If you can find somewhere the towgs84 parameters and insert them to your source projection you may get what you want. It is not necessary to edit the epsg text file but even better to give the projection directly for ogr2ogr this way: ogr2ogr -s_srs "+proj=longlat +ellps=bessel +towgs84=-384,664,-48,0,0,0,0 +no_defs" -t_srs epsg:4326 Of course with your correct towgs84 parameters. This way it is simple to play with adjusting the parameters, and most important, you know for sure what parameters ogr2ogr is going to use. It is possible that right parameters for you are TOWGS84=-148,507,685,0,0,0,0 but I can't be sure. It was just the first hit from altavista search. -Jukka Rahkonen- -Alkuperäinen viesti- Lähettäjä: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Puolesta NASUNO Isao Lähetetty: 15. toukokuuta 2008 7:59 Vastaanottaja: Rahkonen Jukka Kopio: mapserver-users@lists.osgeo.org Aihe: Re: [mapserver-users] Converting datum using ogr2ogr Hi Jukka, Thank you for your response. yes, I tried with the options (s/t_srs), however it makes conversion for projection but not for datum. In my case, I used following options but the input and output are exactly same. -s_srs "EPSG:4301" -t_srs "EPSG:4326" (GCS with bessel)(GCS with WGS84) I checked GDAL FAQ and found following. http://trac.osgeo.org/gdal/wiki/FAQCoordinateSystemsAndProject ions#WhydoesntGDALautomaticallychoosethedatumtransformation Why doesn't GDAL automatically choose the datum transformation? There is no such thing as an accurate "default" set of datum transformation parameters for a datum. OGR uses (NADCON) by default, which is the most accurate available for North America, but in the general case (worldwide) this is very hard to determine and there normally is no such thing as a default. The transformation that should be used depends on the exact area covered, accuracy required etc. In other words, user beware and do your homework. Is this the reason ? I am not sure if ogr2ogr can accept the parameters in manual. Please help if any idea. Thanks, Isao Rahkonen Jukka wrote: Hi, I don't think you need .prj file with your shapefiles and you should be able even to overrun it. You need to use parameters -s_srs for source projection and -t_srs for target projection. -Jukka Rahkonen- -Alkuperäinen viesti- Lähettäjä: [EMAIL PROTECTED] puolesta: NASUNO Isao Lähetetty: to 15.5.2008 4:59 Vastaanottaja: mapserver-users@lists.osgeo.org Aihe: [mapserver-users] Converting datum using ogr2ogr Hello, I am new in the mailing list. I want to use ogr2ogr to convert projection/datum of shape files to a same SRS before insert them into postgres for serving by MapServer. However ogr2ogr seems convert only projection even the shape file has .prj file. I checked out that GDAL has no default parameters to convert datum. I need the conversion before inserting to postgres with some reasons, I mean, with translation from shape to shape. Any suggestion to convert datum using ogr2ogr or other stand-alone program ? - The ogr2ogr is included in FWTools 2.1.0. - OS is windows xp. Thanks, Isao NASUNO ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users
