From steve.lime at dnr.state.mn.us Mon Dec 1 17:11:25 2003 From: steve.lime at dnr.state.mn.us (Steve Lime) Date: Fri Feb 8 14:56:41 2008 Subject: [Mapserver-dev] tag processing in templates Message-ID: I guess I'll file this one as a bug... >>> "Steve Lime" 11/13/2003 11:15:32 AM >>> Hi Folks: I've implemented a tag to output a queried shapes xy values in an ad hoc fashion. I uses the tag processing functions originally written for HTML legend templates. They work nice, thanks DMS! One thing I'd like more information on is how tag attributes are handled. It seems that quotes around attributes are not supported. Makes it hard to allow folks to use spaces within an attribute. Can someone confirm this? How hard to add it? Steve _______________________________________________ Mapserver-dev mailing list Mapserver-dev@lists.gis.umn.edu http://lists.gis.umn.edu/mailman/listinfo/mapserver-dev From morissette at dmsolutions.ca Mon Dec 1 17:48:59 2003 From: morissette at dmsolutions.ca (Daniel Morissette) Date: Fri Feb 8 14:56:41 2008 Subject: [Mapserver-dev] tag processing in templates In-Reply-To: References: Message-ID: <3FCBC55B.1060400@dmsolutions.ca> Oopps... sorry for the lack of replies... your message was still in my Inbox with a pile of others... short answer is that it's quite possible that quotes aren't supported, we would have to implement that. Filing a bug will ensure we don't forget... please include me in the CC. I'm not sure when I would have time to look at this so if there is any other taker then fine... Daniel Steve Lime wrote: > I guess I'll file this one as a bug... > > >>>>"Steve Lime" 11/13/2003 11:15:32 AM >>>> > > Hi Folks: I've implemented a tag to output a queried shapes xy values > in > an ad hoc fashion. I uses the tag processing functions originally > written for HTML legend templates. They work nice, thanks DMS! One > thing > I'd like more information on is how tag attributes are handled. It > seems > that quotes around attributes are not supported. Makes it hard to > allow > folks to use spaces within an attribute. Can someone confirm this? How > hard to add it? > > Steve From dhaur at hashprompt.com Mon Dec 1 23:56:22 2003 From: dhaur at hashprompt.com (Kaladhaur Palaniappan) Date: Fri Feb 8 14:56:41 2008 Subject: [Mapserver-dev] Image(x,y) to Extent... Message-ID: <3FCC1B76.60005@hashprompt.com> This is a multi-part message in MIME format. --------------080101050000070805080404 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi everybody, I am working under perl mapserver. I don't know how to convert Image coordinates(x,y) to corresponding extent value. I have sent few mails to this group earlier but no one is responding. please give me reply. Thanks and Regards KalaDhaur P Programmer Analyst Hash Prompt Infotech India Pvt. Ltd 101 Rana Lakshmanan Nagar Erode TN India - 638 011 Office Tel : +91 424 550 1129 If life is like a switch in 'C' then, You should not be a default The mind is like a parachute, it works best when it is open ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ CONFIDENTIALITY INFORMATION AND DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please delete it immediately and notify the sender. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --------------080101050000070805080404 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit
Hi everybody,
I am working under perl mapserver. I don't know how to convert Image coordinates(x,y) to corresponding extent value.

I have sent few mails to this group earlier but no one is responding. please give me reply.

signature.htm Thanks and Regards

KalaDhaur P
Programmer Analyst
Hash Prompt Infotech India Pvt. Ltd
101 Rana Lakshmanan Nagar
Erode TN India - 638 011
Office Tel : +91 424 550 1129

If life is like a switch in 'C' then,
You should not be a default

The mind is like a parachute, it works best when it is open

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
CONFIDENTIALITY INFORMATION AND DISCLAIMER:

This email and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom 
they are addressed. If you have received this email in error please 
delete it immediately and notify the sender.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

--------------080101050000070805080404-- From morissette at dmsolutions.ca Tue Dec 2 00:10:51 2003 From: morissette at dmsolutions.ca (Daniel Morissette) Date: Fri Feb 8 14:56:41 2008 Subject: [Mapserver-dev] Image(x,y) to Extent... In-Reply-To: <3FCC1B76.60005@hashprompt.com> References: <3FCC1B76.60005@hashprompt.com> Message-ID: <3FCC1EDB.80103@dmsolutions.ca> Kaladhaur Palaniappan wrote: > > I am working under perl mapserver. I don't know how to convert > Image coordinates(x,y) to corresponding extent value. > > I have sent few mails to this group earlier but no one is > responding. please give me reply. > Try sending your questions to the mapserver-users list which is a forum for users to exchange ideas and to help eash other. The mapserver-dev list is for developers of the software to discuss development issues and user questions are ignored by default on this list. -- ------------------------------------------------------------ Daniel Morissette morissette@dmsolutions.ca DM Solutions Group http://www.dmsolutions.ca/ ------------------------------------------------------------ From morissette at dmsolutions.ca Tue Dec 2 15:30:51 2003 From: morissette at dmsolutions.ca (Daniel Morissette) Date: Fri Feb 8 14:56:41 2008 Subject: [Mapserver-dev] Re: [Mapserver-users] recalculate scale with mapscript In-Reply-To: <093B382C-24D8-11D8-A2F8-000393B98B56@frii.com> References: <093B382C-24D8-11D8-A2F8-000393B98B56@frii.com> Message-ID: <3FCCF67B.2070807@dmsolutions.ca> Sean Gillies wrote: > > There's a setExtent extension to mapObj in the 4.1 (CVS) MapServer. Since > we had frozen the features of 4.0, I did not commit it to that source > branch. > You are welcome to paste it into your mapscript.i and re-build, it doesn't > depend on any other code in 4.1. > (I sent this reply to mapserver-dev...) Sean, There is already a setExtent() method in PHP MapScript that was there for several versions. It also recalculates the scale like yours does, but there is one difference: it takes 4 values as argument instead of a rectObj: void setextent(double minx, double miny, double maxx, double maxy) Set the map extents using the georef extents passed in argument. Would it be possible to change your new function to use the same prototype to bring both versions of MapScript in sync? Since it hasn't been released yet that shouldn't cause too much trouble. We need to take some time at some point to sync the PHP and SWIG MapScript... I'm not sure when we would have time though. Daniel -- ------------------------------------------------------------ Daniel Morissette morissette@dmsolutions.ca DM Solutions Group http://www.dmsolutions.ca/ ------------------------------------------------------------ From steve at spvi.com Tue Dec 2 15:56:12 2003 From: steve at spvi.com (Steve Spicklemire) Date: Fri Feb 8 14:56:41 2008 Subject: [Mapserver-dev] bug in mapswf.c (msDrawLabelCacheSWF)? In-Reply-To: <3FCCF67B.2070807@dmsolutions.ca> References: <093B382C-24D8-11D8-A2F8-000393B98B56@frii.com> <3FCCF67B.2070807@dmsolutions.ca> Message-ID: Hi (again) Mapserver folks, I have a map where msDrawLabelCacheSWF segfaults mapserver when OUTPUT_MOVIE=MULTIPLE. The problem is that if the last layer is not drawn, drawMap still tries to cache labels on that layer, and (mistakenly) tries to access the movie for that layer, which immediately segfaults since there is no movie for that layer (drawlayer never calls startlayer if the layer isn't visible). Anyway... this patch stops the crashing for me: Index: mapswf.c =================================================================== RCS file: /data2/cvsroot/mapserver/mapswf.c,v retrieving revision 1.31 diff -C3 -r1.31 mapswf.c *** mapswf.c 16 Jul 2003 16:44:58 -0000 1.31 --- mapswf.c 2 Dec 2003 20:53:18 -0000 *************** *** 2119,2128 **** /* set the current layer so the label will be drawn in the */ /* using the correct SWF handle. */ /* ==================================================================== */ ! image->img.swf->nCurrentMovie = cachePtr->layerindex; ! //msImageStartLayerSWF(map, layerPtr, image); ! image->img.swf->nCurrentLayerIdx = cachePtr->layerindex; /* ==================================================================== */ /* at this point the layer (at the shape level is closed). So */ /* we will open it if necessary. */ --- 2119,2134 ---- /* set the current layer so the label will be drawn in the */ /* using the correct SWF handle. */ /* ==================================================================== */ ! ! if (cachePtr->layerindex >= image->img.swf->nLayerMovies) { ! continue; ! } ! ! image->img.swf->nCurrentMovie = cachePtr->layerindex; ! ! //msImageStartLayerSWF(map, layerPtr, image); ! image->img.swf->nCurrentLayerIdx = cachePtr->layerindex; /* ==================================================================== */ /* at this point the layer (at the shape level is closed). So */ /* we will open it if necessary. */ I've not seen any trouble with it so far.. -steve From sgillies at frii.com Tue Dec 2 16:38:10 2003 From: sgillies at frii.com (Sean Gillies) Date: Fri Feb 8 14:56:41 2008 Subject: [Mapserver-dev] Re: [Mapserver-users] recalculate scale with mapscript In-Reply-To: <3FCCF67B.2070807@dmsolutions.ca> Message-ID: On Tuesday, December 2, 2003, at 01:30 PM, Daniel Morissette wrote: > Sean Gillies wrote: >> There's a setExtent extension to mapObj in the 4.1 (CVS) MapServer. >> Since >> we had frozen the features of 4.0, I did not commit it to that source >> branch. >> You are welcome to paste it into your mapscript.i and re-build, it >> doesn't >> depend on any other code in 4.1. > > (I sent this reply to mapserver-dev...) > > Sean, > > There is already a setExtent() method in PHP MapScript that was there > for several versions. It also recalculates the scale like yours does, > but there is one difference: it takes 4 values as argument instead of > a rectObj: > > void setextent(double minx, double miny, double maxx, double maxy) > Set the map extents using the georef extents passed in argument. > > Would it be possible to change your new function to use the same > prototype to bring both versions of MapScript in sync? Since it hasn't > been released yet that shouldn't cause too much trouble. > > We need to take some time at some point to sync the PHP and SWIG > MapScript... I'm not sure when we would have time though. > > Daniel > -- > ------------------------------------------------------------ > Daniel Morissette morissette@dmsolutions.ca > DM Solutions Group http://www.dmsolutions.ca/ > ------------------------------------------------------------ > Yes, I think it makes more sense to follow the precedence set in the PHP MapScript. Sean -- Sean Gillies sgillies at frii dot com http://www.frii.com/~sgillies From assefa at dmsolutions.ca Tue Dec 2 16:55:04 2003 From: assefa at dmsolutions.ca (Yewondwossen Assefa) Date: Fri Feb 8 14:56:42 2008 Subject: [Mapserver-dev] bug in mapswf.c (msDrawLabelCacheSWF)? In-Reply-To: References: <093B382C-24D8-11D8-A2F8-000393B98B56@frii.com> <3FCCF67B.2070807@dmsolutions.ca> Message-ID: <3FCD0A38.7060608@dmsolutions.ca> Hi There, Thanks for pointing this out. I have done the modifications to the source code to avoid the problem. Although the changes you did should avoid the crash, there was a potential error when assigning image->img.swf->nCurrentMovie = cachePtr->layerindex since the movie index and the layer index are not in sync. The crash happened for layerindex > nLayerMovies but the assignment could also be wrong without a crash. If you are willing to do the tests please contact me personally and I will send you the modifications before commiting the code. If not I will enter a bug and commit the code when I will do proper testing on my side. Late Steve Spicklemire wrote: > > Hi (again) Mapserver folks, > > I have a map where msDrawLabelCacheSWF segfaults mapserver when > OUTPUT_MOVIE=MULTIPLE. The problem is that if the last layer is not > drawn, drawMap still tries to cache labels on that layer, and > (mistakenly) tries to access the movie for that layer, which immediately > segfaults since there is no movie for that layer (drawlayer never calls > startlayer if the layer isn't visible). > > Anyway... this patch stops the crashing for me: > > Index: mapswf.c > =================================================================== > RCS file: /data2/cvsroot/mapserver/mapswf.c,v > retrieving revision 1.31 > diff -C3 -r1.31 mapswf.c > *** mapswf.c 16 Jul 2003 16:44:58 -0000 1.31 > --- mapswf.c 2 Dec 2003 20:53:18 -0000 > *************** > *** 2119,2128 **** > /* set the current layer so the label will be drawn in the > */ > /* using the correct SWF handle. > */ > /* > ==================================================================== */ > ! image->img.swf->nCurrentMovie = cachePtr->layerindex; > > ! //msImageStartLayerSWF(map, layerPtr, image); > ! image->img.swf->nCurrentLayerIdx = cachePtr->layerindex; > /* > ==================================================================== */ > /* at this point the layer (at the shape level is closed). So > */ > /* we will open it if necessary. > */ > --- 2119,2134 ---- > /* set the current layer so the label will be drawn in the > */ > /* using the correct SWF handle. > */ > /* > ==================================================================== */ > ! > ! if (cachePtr->layerindex >= image->img.swf->nLayerMovies) { > ! continue; > ! } > ! > ! image->img.swf->nCurrentMovie = cachePtr->layerindex; > ! > > ! //msImageStartLayerSWF(map, layerPtr, image); > ! image->img.swf->nCurrentLayerIdx = cachePtr->layerindex; > /* > ==================================================================== */ > /* at this point the layer (at the shape level is closed). So > */ > /* we will open it if necessary. > */ > > > I've not seen any trouble with it so far.. > > -steve > > _______________________________________________ > Mapserver-dev mailing list > Mapserver-dev@lists.gis.umn.edu > http://lists.gis.umn.edu/mailman/listinfo/mapserver-dev > -- ---------------------------------------------------------------- Assefa Yewondwossen Software Analyst Email: assefa@dmsolutions.ca http://www.dmsolutions.ca/ Phone: (613) 565-5056 (ext 14) Fax: (613) 565-0925 ---------------------------------------------------------------- From steve at spvi.com Tue Dec 2 23:13:41 2003 From: steve at spvi.com (Steve Spicklemire) Date: Fri Feb 8 14:56:42 2008 Subject: [Mapserver-dev] bug in mapswf.c (msDrawLabelCacheSWF)? In-Reply-To: <3FCD0A38.7060608@dmsolutions.ca> References: <093B382C-24D8-11D8-A2F8-000393B98B56@frii.com> <3FCCF67B.2070807@dmsolutions.ca> <3FCD0A38.7060608@dmsolutions.ca> Message-ID: <140A1894-2547-11D8-9D4A-000393468020@spvi.com> Hi Yewondwossen, Yes.. please send me your patch.. and I'll test it! thanks, -steve On Dec 2, 2003, at 4:55 PM, Yewondwossen Assefa wrote: > Hi There, > > Thanks for pointing this out. > > I have done the modifications to the source code to avoid the problem. > > Although the changes you did should avoid the crash, there was a > potential error when assigning image->img.swf->nCurrentMovie = > cachePtr->layerindex since the movie index and the layer index are not > in sync. The crash happened for layerindex > nLayerMovies but the > assignment could also be wrong without a crash. > > If you are willing to do the tests please contact me personally and I > will send you the modifications before commiting the code. If not I > will enter a bug and commit the code when I will do proper testing on > my side. > > Late > > > Steve Spicklemire wrote: > >> Hi (again) Mapserver folks, >> I have a map where msDrawLabelCacheSWF segfaults mapserver when >> OUTPUT_MOVIE=MULTIPLE. The problem is that if the last layer is not >> drawn, drawMap still tries to cache labels on that layer, and >> (mistakenly) tries to access the movie for that layer, which >> immediately segfaults since there is no movie for that layer >> (drawlayer never calls startlayer if the layer isn't visible). >> Anyway... this patch stops the crashing for me: >> Index: mapswf.c >> =================================================================== >> RCS file: /data2/cvsroot/mapserver/mapswf.c,v >> retrieving revision 1.31 >> diff -C3 -r1.31 mapswf.c >> *** mapswf.c 16 Jul 2003 16:44:58 -0000 1.31 >> --- mapswf.c 2 Dec 2003 20:53:18 -0000 >> *************** >> *** 2119,2128 **** >> /* set the current layer so the label will be drawn in the >> */ >> /* using the correct SWF handle. >> */ >> /* >> ==================================================================== >> */ >> ! image->img.swf->nCurrentMovie = cachePtr->layerindex; >> ! //msImageStartLayerSWF(map, layerPtr, image); >> ! image->img.swf->nCurrentLayerIdx = cachePtr->layerindex; >> /* >> ==================================================================== >> */ >> /* at this point the layer (at the shape level is closed). So >> */ >> /* we will open it if necessary. >> */ >> --- 2119,2134 ---- >> /* set the current layer so the label will be drawn in the >> */ >> /* using the correct SWF handle. >> */ >> /* >> ==================================================================== >> */ >> ! >> ! if (cachePtr->layerindex >= image->img.swf->nLayerMovies) { >> ! continue; >> ! } >> ! >> ! image->img.swf->nCurrentMovie = cachePtr->layerindex; >> ! >> ! //msImageStartLayerSWF(map, layerPtr, image); >> ! image->img.swf->nCurrentLayerIdx = cachePtr->layerindex; >> /* >> ==================================================================== >> */ >> /* at this point the layer (at the shape level is closed). So >> */ >> /* we will open it if necessary. >> */ >> I've not seen any trouble with it so far.. >> -steve >> _______________________________________________ >> Mapserver-dev mailing list >> Mapserver-dev@lists.gis.umn.edu >> http://lists.gis.umn.edu/mailman/listinfo/mapserver-dev > > > -- > ---------------------------------------------------------------- > Assefa Yewondwossen > Software Analyst > > Email: assefa@dmsolutions.ca > http://www.dmsolutions.ca/ > > Phone: (613) 565-5056 (ext 14) > Fax: (613) 565-0925 > ---------------------------------------------------------------- > > > > _______________________________________________ > Mapserver-dev mailing list > Mapserver-dev@lists.gis.umn.edu > http://lists.gis.umn.edu/mailman/listinfo/mapserver-dev From amontieri at risviel.it Fri Dec 5 12:20:22 2003 From: amontieri at risviel.it (Arturo Montieri) Date: Fri Feb 8 14:56:42 2008 Subject: [Mapserver-dev] Newbie: Win32 Compilation problem Message-ID: <007001c3bb54$10ca82a0$0400a8c0@risviel.risviel> This is a multi-part message in MIME format. ------=_NextPart_000_006D_01C3BB5C.727E21C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, has anyone tried to compile under Windows platform the mapserver = source? or has tried to create a .dws (a workspace) file? I have problems with unistd.h=20 where can I search the file for win32? =20 Thanx to all __________________________________________________ Art ------=_NextPart_000_006D_01C3BB5C.727E21C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi all, has anyone tried to = compile under=20 Windows platform the mapserver source?

or has tried to create a .dws (a = workspace)=20 file?

I have problems with unistd.h =

where can I search the file for=20 win32?

Thanx to all

__________________________________________________
Art

------=_NextPart_000_006D_01C3BB5C.727E21C0-- From assefa at dmsolutions.ca Fri Dec 5 13:38:16 2003 From: assefa at dmsolutions.ca (Yewondwossen Assefa) Date: Fri Feb 8 14:56:42 2008 Subject: [Mapserver-dev] Newbie: Win32 Compilation problem In-Reply-To: <007001c3bb54$10ca82a0$0400a8c0@risviel.risviel> References: <007001c3bb54$10ca82a0$0400a8c0@risviel.risviel> Message-ID: <3FD0D098.20201@dmsolutions.ca> Is your problem with maplexer.c ? If that is the case just move the #include after the #include and It should do the trick. It should be I guess corrected in maplexer.l but not sure how to do it. (I use nmake to do builds and not aware of a VC project created for Mapserver) Later, Arturo Montieri wrote: > Hi all, has anyone tried to compile under Windows platform the mapserver > source? > or has tried to create a .dws (a workspace) file? > > I have problems with unistd.h > where can I search the file for win32? > > Thanx to all > __________________________________________________ > Art -- ---------------------------------------------------------------- Assefa Yewondwossen Software Analyst Email: assefa@dmsolutions.ca http://www.dmsolutions.ca/ Phone: (613) 565-5056 (ext 14) Fax: (613) 565-0925 ---------------------------------------------------------------- From stephen.clark at focus.ca Mon Dec 8 12:15:38 2003 From: stephen.clark at focus.ca (Stephen Clark) Date: Fri Feb 8 14:56:42 2008 Subject: [Mapserver-dev] suggestion needed for using mapserver as a generic browser of 2000+ layers of data? References: Message-ID: <00ca01c3bdae$e6b6e190$6c000a0a@sclark> Hi all, I am working on a project to dynamically display over 2000+ layers of data (point, polygons, raster, etc.) and am interested in finding a way to get past the HARD CODED number of layers in mapserver / mapscript *.map files. OR maybe there is some short term solution for using PHP mapscript to dynamically generate *.map files from a list of map files each specified by a type (e.g., raster layers, polygon layers, ) Any thoughts? Also, is there plans to have the HARD CODED number of layers in mapserver bug fixed in the 4.1 release? thanks, Stephen From ed at topozone.com Mon Dec 8 11:32:04 2003 From: ed at topozone.com (Ed McNierney) Date: Fri Feb 8 14:56:42 2008 Subject: [Mapserver-dev] suggestion needed for using mapserver as a generic browser of 2000+ layers of data? Message-ID: <13858AA1A74F30419F319ACB66A9D1222C0727@mercator.topozone.com> Stephen - The HARD CODED number is easily changed in map.h, and a rebuild can make the number any size you like. There are some performance advantages to the current implementation, so deciding to call it a "bug" doesn't make it one . One can make a good case for either the current scheme or a "all you can load" scheme - the biggest disadvantage to the current implementation is that if you're not already set up to rebuild MapServer it can be a bit of work to make a rather simple change. - Ed Ed McNierney President and Chief Mapmaker TopoZone.com / Maps a la carte, Inc. 73 Princeton Street, Suite 305 North Chelmsford, MA 01863 ed@topozone.com (978) 251-4242 -----Original Message----- From: Stephen Clark [mailto:stephen.clark@focus.ca] Sent: Monday, December 08, 2003 12:16 PM To: mapserver-users@lists.gis.umn.edu Cc: mapserver-dev@lists.gis.umn.edu Subject: [Mapserver-dev] suggestion needed for using mapserver as a generic browser of 2000+ layers of data? Hi all, I am working on a project to dynamically display over 2000+ layers of data (point, polygons, raster, etc.) and am interested in finding a way to get past the HARD CODED number of layers in mapserver / mapscript *.map files. OR maybe there is some short term solution for using PHP mapscript to dynamically generate *.map files from a list of map files each specified by a type (e.g., raster layers, polygon layers, ) Any thoughts? Also, is there plans to have the HARD CODED number of layers in mapserver bug fixed in the 4.1 release? thanks, Stephen _______________________________________________ Mapserver-dev mailing list Mapserver-dev@lists.gis.umn.edu http://lists.gis.umn.edu/mailman/listinfo/mapserver-dev From stephen.clark at focus.ca Mon Dec 8 12:46:50 2003 From: stephen.clark at focus.ca (Stephen Clark) Date: Fri Feb 8 14:56:42 2008 Subject: [Mapserver-dev] Fw: [Mapserver-users] number of layers : DYNAMICALLY GENERATED ?? Message-ID: <012101c3bdb3$4291c170$6c000a0a@sclark> This is a multi-part message in MIME format. ------=_NextPart_000_011E_01C3BD70.340F2360 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Ed, I have attached an email from Daniel Morisette about the BUG 302 he = posted awhile back about this. I think I am probably familiar enough with C code to fix this "bug" or = to enhance mapserver but would like some help in any event. Would someone on this list be willing to post a VC7 (.NET edition) = project file so that I could start the process to "enhance mapserver". Thanks Stephen ----- Original Message -----=20 From: "Ed McNierney" To: "Stephen Clark" ; = Cc: Sent: Monday, December 08, 2003 8:32 AM Subject: RE: [Mapserver-dev] suggestion needed for using mapserver as a = generic browser of 2000+ layers of data? Stephen - The HARD CODED number is easily changed in map.h, and a rebuild can make = the number any size you like. There are some performance advantages to = the current implementation, so deciding to call it a "bug" doesn't make = it one . One can make a good case for either the current scheme or a = "all you can load" scheme - the biggest disadvantage to the current = implementation is that if you're not already set up to rebuild MapServer = it can be a bit of work to make a rather simple change. - Ed Ed McNierney President and Chief Mapmaker TopoZone.com / Maps a la carte, Inc. 73 Princeton Street, Suite 305 North Chelmsford, MA 01863 ed@topozone.com (978) 251-4242=20 ----- Original Message -----=20 From: "Daniel Morissette" To: "Stephen Clark" Cc: Sent: Friday, October 24, 2003 8:11 AM Subject: Re: [Mapserver-users] number of layers : DYNAMICALLY GENERATED = ?? > These are compile-time settings, there is still no way to set those=20 > values at run time. >=20 > We have bug 302 about this, so it's on our list of things to change: > http://mapserver.gis.umn.edu/bugs/show_bug.cgi?id=3D302 >=20 > Daniel >=20 >=20 > Stephen Clark wrote: > > =20 > >=20 > > ----- Original Message ----- > > *From:* Stephen Clark > > *To:* mapserver-users@lists.gis.umn.edu > > > > *Sent:* Wednesday, October 22, 2003 11:03 AM > > *Subject:* [Mapserver-users] Max number of layers > >=20 > > hi all, > > =20 > > Does anyone know if there is support to have the number of = layers > > generated dynamically? > > =20 > > In the "map.h" file the > > =20 > > #define MS_MAXLAYERS > > =20 > > and the > > =20 > > #define MS_MAXCLASSES > > =20 > > have to be set before compiling. > > =20 > > Is there anyone who knows if it is possible to dynamically set = this > > parameter or does it require significant amounts of code = rewrite. > > =20 > > Also, > > Is this the correct list to be posting this question? > > =20 > > =20 > > Stephen > > =20 >=20 >=20 > _______________________________________________ > Mapserver-users mailing list > Mapserver-users@lists.gis.umn.edu > http://lists.gis.umn.edu/mailman/listinfo/mapserver-users > ------=_NextPart_000_011E_01C3BD70.340F2360 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Ed,

I have attached an email from Daniel = Morisette about=20 the BUG 302 he posted awhile back about this.

I think I am probably familiar enough = with C code to=20 fix this "bug" or to enhance mapserver but would like = some help=20 in any event.

Would someone on this list be willing to = post a VC7=20 (.NET edition) project file so that I could start the process to = "enhance=20 mapserver".

Thanks Stephen

----- Original Message -----

From: "Ed McNierney" <ed@topozone.com>

To: "Stephen Clark" <stephen.clark@focus.ca>;=20 <mapserver-users@lists.gis.umn.edu>

Cc: <mapserver-dev@lists.gis.umn.edu>

Sent: Monday, December 08, 2003 8:32=20 AM

Subject: RE: [Mapserver-dev] suggestion = needed for=20 using mapserver as a generic browser of 2000+ layers of = data?

Stephen -

The HARD CODED number is = easily=20 changed in map.h, and a rebuild can make the number any size you = like. =20 There are some performance advantages to the current implementation, so = deciding=20 to call it a "bug" doesn't make it one <g>. One can make a = good case=20 for either the current scheme or a "all you can load" scheme - the = biggest=20 disadvantage to the current implementation is that if you're not already = set up=20 to rebuild MapServer it can be a bit of work to make a rather simple=20 change.

- Ed

Ed McNierney
President and Chief=20 Mapmaker
TopoZone.com / Maps a la carte, Inc.
73 Princeton Street, = Suite=20 305
North Chelmsford, MA 01863
ed@topozone.com
(978) = 251-4242=20

----- Original Message -----

From: "Daniel Morissette" <morissette@dmsolutions.ca>

To: "Stephen Clark" <stephen.clark@focus.ca>

Cc: <mapserver-users@lists.gis.umn.edu>

Sent: Friday, October 24, 2003 8:11 = AM

Subject: Re: [Mapserver-users] number = of layers :=20 DYNAMICALLY GENERATED ??

> These are compile-time settings, there is still no way to = set those=20
> values at run time.
>
> We have bug 302 about = this, so=20 it's on our list of things to change:
> http://mapserver.gis.umn.edu/bugs/show_bug.cgi?id=3D302
>
> Daniel
>
>
> = Stephen Clark=20 wrote:
> >
> >
> = >    =20 ----- Original Message -----
> >     = *From:*=20 Stephen Clark <mailto:stephen.clark@focus.ca>
> >     *To:* mapserver-users@lists.gis.umn.edu
> >     <mailto:mapserver-users@lists.gis.umn.edu>
> >     *Sent:* Wednesday, = October 22,=20 2003 11:03 AM
> >     *Subject:* = [Mapserver-users]=20 Max number of layers
> >
> >     = hi=20 all,
> >
>=20 >     Does anyone know if there is support to = have the=20 number of layers
> >     generated=20 dynamically?
> >
>=20 >     In the "map.h" file the
>=20 >
> >     = #define=20 MS_MAXLAYERS
> >
>=20 >     and the
> = >     =20
> >     #define MS_MAXCLASSES
>=20 >
> >     = have to=20 be set before compiling.
> >      =
>=20 >     Is there anyone who knows if it is possible = to=20 dynamically set this
> >     parameter or = does it=20 require significant amounts of code rewrite.
>=20 >
> >     = Also,
> >     Is this the correct list to = be=20 posting this question?
> >      =
>=20 >
> >     = Stephen
> >
>
> =
>=20 _______________________________________________
> Mapserver-users = mailing=20 list
> Mapserver-users@lists.gis.umn.edu
> http://lists.gis.umn.edu/mailman/listinfo/mapserver-users=
> ------=_NextPart_000_011E_01C3BD70.340F2360-- From woodbri at swoodbridge.com Mon Dec 8 11:54:07 2003 From: woodbri at swoodbridge.com (woodbri@swoodbridge.com) Date: Fri Feb 8 14:56:42 2008 Subject: [Mapserver-dev] suggestion needed for using mapserver as a generic browser of 2000+ layers of data? In-Reply-To: <00ca01c3bdae$e6b6e190$6c000a0a@sclark> Message-ID: <3FD4665F.26365.30B3C340@localhost> Stephen, The limit may not be a problem at all, it depends on how your applications deals with all these layers in the first place. He are a couple of thoughts: 1) you can change the hardcode limit to anything you want and recompile, so set it to 2500 or 3000 it only uses up memory that would get used anyway if it was dynamically allocated. 2) the limit is only the number of simultaneous layers that can be loaded into mapserver at a given instance. I think it is highly unlikely that you will need all 2000+ layers loaded for any map draw. 3) I would assume you would have some front-end that helps the user sort through all these layers by classifying them in some way and then letting the user select and browse a few of them at a time. If this is the case then I would recommend dynamically generating a mapfile for this user's session that just has the subset of layers selected. You can enforce the hardcoded limit of selected layers in your front end application. 4) If you want the user to be able to select layer ordering you would probably want to do that in the front end application also which would be another reason to dynamically generate the map files. HTH, -Steve H. On 8 Dec 2003 at 9:15, Stephen Clark wrote: > > Hi all, > > > I am working on a project to dynamically display over 2000+ layers of data > (point, polygons, raster, etc.) and am interested in finding a way to get > past the HARD CODED number of layers in mapserver / mapscript *.map files. > OR maybe there is some > short term solution for using PHP mapscript to dynamically generate *.map > files from a list of map files each specified by a type (e.g., raster > layers, polygon layers, ) > > Any thoughts? > > Also, is there plans to have the HARD CODED number of layers in mapserver > bug fixed in the 4.1 release? > > thanks, > Stephen > > _______________________________________________ > Mapserver-dev mailing list > Mapserver-dev@lists.gis.umn.edu > http://lists.gis.umn.edu/mailman/listinfo/mapserver-dev > From sgillies at frii.com Mon Dec 8 12:34:26 2003 From: sgillies at frii.com (Sean Gillies) Date: Fri Feb 8 14:56:42 2008 Subject: [Mapserver-dev] suggestion needed for using mapserver as a generic browser of 2000+ layers of data? In-Reply-To: <00ca01c3bdae$e6b6e190$6c000a0a@sclark> Message-ID: On Monday, December 8, 2003, at 10:15 AM, Stephen Clark wrote: > > Hi all, > > > I am working on a project to dynamically display over 2000+ layers of > data > (point, polygons, raster, etc.) and am interested in finding a way to > get > past the HARD CODED number of layers in mapserver / mapscript *.map > files. > OR maybe there is some > short term solution for using PHP mapscript to dynamically generate > *.map > files from a list of map files each specified by a type (e.g., raster > layers, polygon layers, ) > > Any thoughts? > > Also, is there plans to have the HARD CODED number of layers in > mapserver > bug fixed in the 4.1 release? > > thanks, > Stephen > > Stephen, I have entered two related feature enhancements to Bugzilla that may interest you: http://mapserver.gis.umn.edu/bugs/show_bug.cgi?id=357 http://mapserver.gis.umn.edu/bugs/show_bug.cgi?id=358 These are not about increasing the number of possible layers or making the number of layers dynamically extendable, but are about a new framework that makes it possible to accomplish your 2000+ layer problem. I'm proposing that layers be objects that can: 1) exist outside of a map, 2) be instantiated from a map file "fragment". In my use cases, what you would do is either 1) keep map file fragments which completely define a layer as text/varchar in your favorite RDBMS, allow a user to select layers, instantiate them from the fragments, then insert the layer object into a map object for rendering and output. or 2) store layer objects in an persistent object database and insert them into a map object as needed. My proposal primarily concerns MapScript (all flavors) but some have seen many useful applications for the mapserv app itself. cheers, Sean -- Sean Gillies sgillies at frii dot com http://www.frii.com/~sgillies From steve at spvi.com Tue Dec 9 06:58:55 2003 From: steve at spvi.com (Steve Spicklemire) Date: Fri Feb 8 14:56:42 2008 Subject: [Mapserver-dev] bug in mapswf.c (msDrawLabelCacheSWF)? In-Reply-To: <3FCDFFCD.5040204@dmsolutions.ca> References: <093B382C-24D8-11D8-A2F8-000393B98B56@frii.com> <3FCCF67B.2070807@dmsolutions.ca> <3FCD0A38.7060608@dmsolutions.ca> <140A1894-2547-11D8-9D4A-000393468020@spvi.com> <3FCDFFCD.5040204@dmsolutions.ca> Message-ID: <109E29E7-2A3F-11D8-9B55-000393468020@spvi.com> Hi Yewondwossen, Here's another patch to try. I was getting text cached on the wrong layers.. tracked it down to this: Index: mapswf.c =================================================================== RCS file: /data2/cvsroot/mapserver/mapswf.c,v retrieving revision 1.33 diff -a -u -r1.33 mapswf.c --- mapswf.c 3 Dec 2003 02:03:41 -0000 1.33 +++ mapswf.c 9 Dec 2003 11:56:18 -0000 @@ -2069,7 +2069,7 @@ { for (i=0; i Hi There, > > I have commited mapswf.c and map.h with the fix and you can get them > from CVS. Let me know how it goes. > > Later, > > Steve Spicklemire wrote: >> Hi Yewondwossen, >> Yes.. please send me your patch.. and I'll test it! >> thanks, >> -steve >> On Dec 2, 2003, at 4:55 PM, Yewondwossen Assefa wrote: >>> Hi There, >>> >>> Thanks for pointing this out. >>> >>> I have done the modifications to the source code to avoid the >>> problem. >>> >>> Although the changes you did should avoid the crash, there was a >>> potential error when assigning image->img.swf->nCurrentMovie = >>> cachePtr->layerindex since the movie index and the layer index are >>> not in sync. The crash happened for layerindex > nLayerMovies but >>> the assignment could also be wrong without a crash. >>> >>> If you are willing to do the tests please contact me personally and >>> I will send you the modifications before commiting the code. If not >>> I will enter a bug and commit the code when I will do proper >>> testing on my side. >>> >>> Late >>> >>> >>> Steve Spicklemire wrote: >>> >>>> Hi (again) Mapserver folks, >>>> I have a map where msDrawLabelCacheSWF segfaults mapserver when >>>> OUTPUT_MOVIE=MULTIPLE. The problem is that if the last layer is not >>>> drawn, drawMap still tries to cache labels on that layer, and >>>> (mistakenly) tries to access the movie for that layer, which >>>> immediately segfaults since there is no movie for that layer >>>> (drawlayer never calls startlayer if the layer isn't visible). >>>> Anyway... this patch stops the crashing for me: >>>> Index: mapswf.c >>>> =================================================================== >>>> RCS file: /data2/cvsroot/mapserver/mapswf.c,v >>>> retrieving revision 1.31 >>>> diff -C3 -r1.31 mapswf.c >>>> *** mapswf.c 16 Jul 2003 16:44:58 -0000 1.31 >>>> --- mapswf.c 2 Dec 2003 20:53:18 -0000 >>>> *************** >>>> *** 2119,2128 **** >>>> /* set the current layer so the label will be drawn in the >>>> */ >>>> /* using the correct SWF handle. >>>> */ >>>> /* >>>> ==================================================================== >>>> */ >>>> ! image->img.swf->nCurrentMovie = cachePtr->layerindex; >>>> ! //msImageStartLayerSWF(map, layerPtr, image); >>>> ! image->img.swf->nCurrentLayerIdx = cachePtr->layerindex; >>>> /* >>>> ==================================================================== >>>> */ >>>> /* at this point the layer (at the shape level is closed). >>>> So */ >>>> /* we will open it if necessary. >>>> */ >>>> --- 2119,2134 ---- >>>> /* set the current layer so the label will be drawn in the >>>> */ >>>> /* using the correct SWF handle. >>>> */ >>>> /* >>>> ==================================================================== >>>> */ >>>> ! >>>> ! if (cachePtr->layerindex >= image->img.swf->nLayerMovies) { >>>> ! continue; >>>> ! } >>>> ! >>>> ! image->img.swf->nCurrentMovie = cachePtr->layerindex; >>>> ! >>>> ! //msImageStartLayerSWF(map, layerPtr, image); >>>> ! image->img.swf->nCurrentLayerIdx = cachePtr->layerindex; >>>> /* >>>> ==================================================================== >>>> */ >>>> /* at this point the layer (at the shape level is closed). >>>> So */ >>>> /* we will open it if necessary. >>>> */ >>>> I've not seen any trouble with it so far.. >>>> -steve >>>> _______________________________________________ >>>> Mapserver-dev mailing list >>>> Mapserver-dev@lists.gis.umn.edu >>>> http://lists.gis.umn.edu/mailman/listinfo/mapserver-dev >>> >>> >>> >>> -- >>> ---------------------------------------------------------------- >>> Assefa Yewondwossen >>> Software Analyst >>> >>> Email: assefa@dmsolutions.ca >>> http://www.dmsolutions.ca/ >>> >>> Phone: (613) 565-5056 (ext 14) >>> Fax: (613) 565-0925 >>> ---------------------------------------------------------------- >>> >>> >>> >>> _______________________________________________ >>> Mapserver-dev mailing list >>> Mapserver-dev@lists.gis.umn.edu >>> http://lists.gis.umn.edu/mailman/listinfo/mapserver-dev > > > -- > ---------------------------------------------------------------- > Assefa Yewondwossen > Software Analyst > > Email: assefa@dmsolutions.ca > http://www.dmsolutions.ca/ > > Phone: (613) 565-5056 (ext 14) > Fax: (613) 565-0925 > ---------------------------------------------------------------- > > From DOtt at PALATINE.IL.US Tue Dec 9 13:19:46 2003 From: DOtt at PALATINE.IL.US (Dale Ott) Date: Fri Feb 8 14:56:42 2008 Subject: [Mapserver-dev] Re: Mapserver-dev digest, Vol 1 #206 - 1 msg (Auto Reply.) Message-ID: Sorry but I will be out of the Office until Tuesday, Dec. 16th, 2003 . I will be checking my email as soon as I return and will get back to you as soon as possible. Sorry for any inconvenience. Thanks! From steve.lime at dnr.state.mn.us Thu Dec 11 17:14:55 2003 From: steve.lime at dnr.state.mn.us (Steve Lime) Date: Fri Feb 8 14:56:42 2008 Subject: [Mapserver-dev] Lists of objects... Message-ID: Anyone have an opinion on how we might denote lists in map files? Initially I'm thinking about the IN operator for MapServer expressions but lists might be useful in other places like for SHAPEPATH. Given that []'s and ()'s already have significance to the lexer {}'s might be useful. Thoughts? Steve From Jean-Francois.Doyon at CCRS.NRCan.gc.ca Fri Dec 12 10:05:14 2003 From: Jean-Francois.Doyon at CCRS.NRCan.gc.ca (Jean-Francois.Doyon@CCRS.NRCan.gc.ca) Date: Fri Feb 8 14:56:42 2008 Subject: [Mapserver-dev] Lists of objects... Message-ID: <7CDD7B94357FD5119E800002A537C46E0B8B71D8@s5-ccr-r1.ccrs.nrcan.gc.ca> Steve, Being a Python guy, I just love the "in" statement indeed ... {} seem to make sense, it's kind of perl-ish :) So something like: EXPRESSION "[ATTRIBUTE] IN { 'CITY', 'VILLAGE' }" ?? Yup, I like it ... much more elegant than a bunch of "OR"'s, and such forms of expressions I think average users will find quite intuitive and easy to learn/understand. J.F. -----Original Message----- From: mapserver-dev-admin@lists.gis.umn.edu [mailto:mapserver-dev-admin@lists.gis.umn.edu]On Behalf Of Steve Lime Sent: Thursday, December 11, 2003 5:15 PM To: mapserver-dev@lists.gis.umn.edu Subject: [Mapserver-dev] Lists of objects... Anyone have an opinion on how we might denote lists in map files? Initially I'm thinking about the IN operator for MapServer expressions but lists might be useful in other places like for SHAPEPATH. Given that []'s and ()'s already have significance to the lexer {}'s might be useful. Thoughts? Steve _______________________________________________ Mapserver-dev mailing list Mapserver-dev@lists.gis.umn.edu http://lists.gis.umn.edu/mailman/listinfo/mapserver-dev From sgillies at frii.com Fri Dec 12 10:45:46 2003 From: sgillies at frii.com (Sean Gillies) Date: Fri Feb 8 14:56:42 2008 Subject: [Mapserver-dev] Lists of objects... In-Reply-To: <7CDD7B94357FD5119E800002A537C46E0B8B71D8@s5-ccr-r1.ccrs.nrcan.gc.ca> Message-ID: <40A410CB-2CBA-11D8-B6CF-000393B98B56@frii.com> It's too bad [] is already taken, because otherwise us Python users could do this: >>> list = ['CITY', 'VILLAGE'] >>> classobj.expression = '[ATTRIBUTE] IN ' + str(list) >>> print classobj.expression >>> [ATTRIBUTE] IN ['CITY', 'VILLAGE'] Can we use [] for the target list and have it mean differently when it follows 'IN' or 'in'? I don't know what's possible with the lexer. {} would be simpler for sure. Sean On Friday, December 12, 2003, at 08:05 AM, Jean-Francois.Doyon@CCRS.NRCan.gc.ca wrote: > Steve, > > Being a Python guy, I just love the "in" statement indeed ... {} seem > to > make sense, it's kind of perl-ish :) > > So something like: > > EXPRESSION "[ATTRIBUTE] IN { 'CITY', 'VILLAGE' }" > > ?? > > Yup, I like it ... much more elegant than a bunch of "OR"'s, and such > forms > of expressions I think average users will find quite intuitive and > easy to > learn/understand. > > J.F. > > -----Original Message----- > From: mapserver-dev-admin@lists.gis.umn.edu > [mailto:mapserver-dev-admin@lists.gis.umn.edu]On Behalf Of Steve Lime > Sent: Thursday, December 11, 2003 5:15 PM > To: mapserver-dev@lists.gis.umn.edu > Subject: [Mapserver-dev] Lists of objects... > > > Anyone have an opinion on how we might denote lists in map files? > Initially I'm thinking about the IN operator for MapServer expressions > but lists might be useful in other places like for SHAPEPATH. Given > that > []'s and ()'s already have significance to the lexer {}'s might be > useful. Thoughts? > > Steve > _______________________________________________ > Mapserver-dev mailing list > Mapserver-dev@lists.gis.umn.edu > http://lists.gis.umn.edu/mailman/listinfo/mapserver-dev > _______________________________________________ > Mapserver-dev mailing list > Mapserver-dev@lists.gis.umn.edu > http://lists.gis.umn.edu/mailman/listinfo/mapserver-dev > From steve.lime at dnr.state.mn.us Fri Dec 12 12:08:26 2003 From: steve.lime at dnr.state.mn.us (Steve Lime) Date: Fri Feb 8 14:56:42 2008 Subject: [Mapserver-dev] Lists of objects... Message-ID: As it sits now you can already do: EXPRESSION ("[ATTRIBUTE]" IN "CITY, VILLAGE") and I've just added numeric support as well so this works to: EXPRESSION ([attribute] IN "5,10,20") Perhaps there's no reason to go any further since the parser automatically turns the righthand argument into a list. The quotes may be enough. Steve >>> 12/12/2003 9:05:14 AM >>> Steve, Being a Python guy, I just love the "in" statement indeed ... {} seem to make sense, it's kind of perl-ish :) So something like: EXPRESSION "[ATTRIBUTE] IN { 'CITY', 'VILLAGE' }" ?? Yup, I like it ... much more elegant than a bunch of "OR"'s, and such forms of expressions I think average users will find quite intuitive and easy to learn/understand. J.F. -----Original Message----- From: mapserver-dev-admin@lists.gis.umn.edu [mailto:mapserver-dev-admin@lists.gis.umn.edu]On Behalf Of Steve Lime Sent: Thursday, December 11, 2003 5:15 PM To: mapserver-dev@lists.gis.umn.edu Subject: [Mapserver-dev] Lists of objects... Anyone have an opinion on how we might denote lists in map files? Initially I'm thinking about the IN operator for MapServer expressions but lists might be useful in other places like for SHAPEPATH. Given that []'s and ()'s already have significance to the lexer {}'s might be useful. Thoughts? Steve _______________________________________________ Mapserver-dev mailing list Mapserver-dev@lists.gis.umn.edu http://lists.gis.umn.edu/mailman/listinfo/mapserver-dev From Jean-Francois.Doyon at CCRS.NRCan.gc.ca Tue Dec 16 15:16:23 2003 From: Jean-Francois.Doyon at CCRS.NRCan.gc.ca (Jean-Francois.Doyon@CCRS.NRCan.gc.ca) Date: Fri Feb 8 14:56:42 2008 Subject: [Mapserver-dev] Testing thread-safety Message-ID: <7CDD7B94357FD5119E800002A537C46E0B8B71E7@s5-ccr-r1.ccrs.nrcan.gc.ca> G'Day, Daniel mentionned to me that thread safty should be fairly complete, though untested, in CVS. So, I'm trying to compile MapServer CVS with PHP 4.3.3, with all of them as modules. Not having much luck though! First MapServer seems to mis-detect the regex setting on my PHP, even though it's compiled with --with-regex=system, I get ugly errors (See at the end of this message). Apparently "configure" tests for the existence of "define REGEX 1" ... The funny thing is that this is true whether I compile PHP with "system" or "php" regex's !! The only way for this NOT to be true so far is to use the "apache" regex setting ... Which I didn't do. For now I've hacked the configure script to pretend like the test works, even when it doesn't :) Any ideas on what's going on here ? Is the PHP regex implementation sensitive to whether it's a module or not maybe ? Could I use "apache" for now, if only just for testing ? I haven't gotten there yet, but I've also obviously hacked the test for apxs to by-pass that. I've built mapserver with --with-threads also. Will this be enough ? Any insight would be much appreciated :) Here's the regex related error when using --with-regex=system and bypassing the test in configure: ... gcc -fPIC -O2 -Wall -DCOMPILE_DL=1 -DPHP4 -DUSE_WMS_LYR -DUSE_WMS_SVR -DUSE_GDAL -DUSE_OGR -DUSE_THREAD -DUSE_PROJ -DUSE_PROJ_API_H -DUSE_EPPL -DUSE_TIFF -DUSE_GD_GIF -DUSE_GD_PNG -DUSE_GD_JPEG -DUSE_GD_WBMP -DUSE_GD_FT -DGD_HAS_GDIMAGEGIFPTR -DUSE_JPEG -I/usr/src/mapserver -I/usr/local/include -I/usr/local/include -I/usr/local/include -I/usr/local/include -I/usr/src/mapserver/../php-4.3.3/ -I/usr/src/mapserver/../php-4.3.3//dl -I/usr/src/mapserver/../php-4.3.3//main -I/usr/src/mapserver/../php-4.3.3//Zend -I/usr/src/mapserver/../php-4.3.3//include -I/usr/src/mapserver/../php-4.3.3//TSRM -c -o php_mapscript.o php_mapscript.c In file included from /usr/src/mapserver/../php-4.3.3/main/php_regex.h:13, from /usr/src/mapserver/../php-4.3.3/main/php.h:74, from php_mapscript_util.h:58, from php_mapscript.c:218: /usr/src/mapserver/../php-4.3.3/regex/regex.h:33: warning: `REG_EXTENDED' redefined /usr/include/regex.h:257: warning: this is the location of the previous definition /usr/src/mapserver/../php-4.3.3/regex/regex.h:34: warning: `REG_ICASE' redefined /usr/include/regex.h:261: warning: this is the location of the previous definition /usr/src/mapserver/../php-4.3.3/regex/regex.h:35: warning: `REG_NOSUB' redefined /usr/include/regex.h:270: warning: this is the location of the previous definition /usr/src/mapserver/../php-4.3.3/regex/regex.h:36: warning: `REG_NEWLINE' redefined /usr/include/regex.h:266: warning: this is the location of the previous definition /usr/src/mapserver/../php-4.3.3/regex/regex.h:67: warning: `REG_NOTBOL' redefined /usr/include/regex.h:280: warning: this is the location of the previous definition /usr/src/mapserver/../php-4.3.3/regex/regex.h:68: warning: `REG_NOTEOL' redefined /usr/include/regex.h:283: warning: this is the location of the previous definition In file included from /usr/src/mapserver/../php-4.3.3/main/php_regex.h:13, from /usr/src/mapserver/../php-4.3.3/main/php.h:74, from php_mapscript_util.h:58, from php_mapscript.c:218: /usr/src/mapserver/../php-4.3.3/regex/regex.h:17: conflicting types for `regoff_t' /usr/include/regex.h:399: previous declaration of `regoff_t' /usr/src/mapserver/../php-4.3.3/regex/regex.h:23: conflicting types for `regex_t' /usr/include/regex.h:396: previous declaration of `regex_t' /usr/src/mapserver/../php-4.3.3/regex/regex.h:27: conflicting types for `regmatch_t' /usr/include/regex.h:427: previous declaration of `regmatch_t' make[1]: *** [php_mapscript.o] Error 1 make[1]: Leaving directory `/usr/src/mapserver/mapscript/php3' Thanks, Jean-François Doyon Internet Service Development and Systems Support / Développement des services et soutien de systèmes Internet GeoAccess Division / Division GéoAccès Canada Center for Remote Sensing / Centre canadien de télédétection Natural Resources Canada / Ressources naturelles Canada http://atlas.gc.ca Phone: (613) 992-4902 Fax: (613) 947-2410 From morissette at dmsolutions.ca Tue Dec 16 18:25:29 2003 From: morissette at dmsolutions.ca (Daniel Morissette) Date: Fri Feb 8 14:56:42 2008 Subject: [Mapserver-dev] Re: time support In-Reply-To: References: Message-ID: <3FDF9469.3010102@dmsolutions.ca> (I decided to move this to mapserver-dev) Steve Lime wrote: > Do you mean TILEINDEX or the new TIMEINDEX? I could certainly see doing > filtering on the TIMEINDEX, especially as applied to non-raster data. > Using filters on tiles could certainly be done but would there be any > real practical use for the output. The new TIMEINDEX is accomanied by a > TIMEID, and the TIMEID could be interpreted as a MapServer expression so > you could process mutiple files at one time. I didn't know about the name of the new TIMEINDEX so I really meant TILEINDEX. My idea was simply that instead of creating a new TIMEINDEX we could simply extend the existing TILEINDEX to support filter expressions. The expression could be based on time or on any other attribute in the tileindex file. We would also need to extend the expressions stuff in MapServer to support time comparisons and time ranges. That would be a generic enhancement to the expression stuff and could be class EXPRESSIONs and not just in the layer FILTER. Does it make more sense? I'm scared I'm not expressing myself very well... > That would be more work to > add than simply interpreting TIMEID as a single value. > I actually thought that extending the TILEINDEX to support FILTER would be simpler. Would it not just be a matter of adding a call to msEvalExpression() in the code that scans the tile index? Daniel -- ------------------------------------------------------------ Daniel Morissette morissette@dmsolutions.ca DM Solutions Group http://www.dmsolutions.ca/ ------------------------------------------------------------ From morissette at dmsolutions.ca Tue Dec 16 18:46:44 2003 From: morissette at dmsolutions.ca (Daniel Morissette) Date: Fri Feb 8 14:56:42 2008 Subject: [Mapserver-dev] Testing thread-safety In-Reply-To: <7CDD7B94357FD5119E800002A537C46E0B8B71E7@s5-ccr-r1.ccrs.nrcan.gc.ca> References: <7CDD7B94357FD5119E800002A537C46E0B8B71E7@s5-ccr-r1.ccrs.nrcan.gc.ca> Message-ID: <3FDF9964.60804@dmsolutions.ca> Jean-Francois.Doyon@ccrs.nrcan.gc.ca wrote: > > Any ideas on what's going on here ? Is the PHP regex implementation > sensitive to whether it's a module or not maybe ? Could I use "apache" for > now, if only just for testing ? > Yes, the PHP configure option --with-regex=system behaves differently whether it is compiling as a module or as a CGI. Actually when you compile as a module there is absolutely no way to use the system regex. This is a problem that I expected and for which I still don't have a nice solution, other than modifying MapServer (the core) to build with the PHP regex which can be quite a pain. My workaround is to configure PHP as a CGI, then configure MapServer, and then reconfigure PHP as a module and compile it... basically fooling the configure as you did, except that in my case it worked. ;) FYI there's a PHP bug that talks about this but I never got any feedback from them: http://bugs.php.net/bug.php?id=25704 So where do we go from here? I've filed this as a bug and will update the bug as soon as I have a solution: http://mapserver.gis.umn.edu/bugs/show_bug.cgi?id=520 This PHP MapScript issue is one of my top priorities before the next release. Daniel -- ------------------------------------------------------------ Daniel Morissette morissette@dmsolutions.ca DM Solutions Group http://www.dmsolutions.ca/ ------------------------------------------------------------ From spencer at dmsolutions.ca Tue Dec 16 21:54:44 2003 From: spencer at dmsolutions.ca (Paul Spencer) Date: Fri Feb 8 14:56:42 2008 Subject: [Mapserver-dev] Re: time support In-Reply-To: <3FDF9469.3010102@dmsolutions.ca> References: <3FDF9469.3010102@dmsolutions.ca> Message-ID: <3FDFC574.7010008@magma.ca> if I could add a couple of cents ... would it be possible to provide a TIMEINDEXFORMAT as well? By this, I mean that not everyone is going to have there time stored in the same way. The TIMEINDEXFORMAT could be used to convert the time from its internal storage (as defined by the source data) to an internal representation that could be used much more easily to evalutate expressions. I think that this would allow for more intelligent time based support, although it may cause things to run more slowly I guess. Cheers, Paul Daniel Morissette wrote: > (I decided to move this to mapserver-dev) > > > Steve Lime wrote: > >> Do you mean TILEINDEX or the new TIMEINDEX? I could certainly see doing >> filtering on the TIMEINDEX, especially as applied to non-raster data. >> Using filters on tiles could certainly be done but would there be any >> real practical use for the output. The new TIMEINDEX is accomanied by a >> TIMEID, and the TIMEID could be interpreted as a MapServer expression so >> you could process mutiple files at one time. > > > I didn't know about the name of the new TIMEINDEX so I really meant > TILEINDEX. > > My idea was simply that instead of creating a new TIMEINDEX we could > simply extend the existing TILEINDEX to support filter expressions. The > expression could be based on time or on any other attribute in the > tileindex file. > > We would also need to extend the expressions stuff in MapServer to > support time comparisons and time ranges. That would be a generic > enhancement to the expression stuff and could be class EXPRESSIONs and > not just in the layer FILTER. > > Does it make more sense? I'm scared I'm not expressing myself very well... > >> That would be more work to >> add than simply interpreting TIMEID as a single value. >> > > I actually thought that extending the TILEINDEX to support FILTER would > be simpler. Would it not just be a matter of adding a call to > msEvalExpression() in the code that scans the tile index? > > Daniel -- ----------------------------------------------------------------- |Paul Spencer spencer@dmsolutions.ca | |-----------------------------------------------------------------| |Applications & Software Development | |DM Solutions Group Inc http://www.dmsolutions.ca/| ----------------------------------------------------------------- From steve.lime at dnr.state.mn.us Wed Dec 17 00:21:30 2003 From: steve.lime at dnr.state.mn.us (Steve Lime) Date: Fri Feb 8 14:56:42 2008 Subject: [Mapserver-dev] Re: time support Message-ID: A timeindex would not be a shapefile, rather simply a temporal lookup table. An xbase file would do nicely. I'll have to think about just extending a TILEINDEX. that may be pushing things too far, but it may not. You'd probably want a seperate TILEFILTER and TILEFILTERITEM though. The timeindex itself would contain a few extra metadata fields. One would be a "band" column so that a single image where each band represents a different date or date range could be queried temporally. Either way I agree that filtering on time is desireable. I think I could write regular expressions in the lexer to identify at least a subset of extended date/time formats as defined in ISO8601, more if a date delimiter was used. From there it would be easy to add date comparisons IF a ISO8601 compliant library already exists, I'll start looking. That way date expressions could be used with any data source if a column contained ISO8601 formated date/time strings. In that case using a timeindex for anything but raster data may not be necessary. Raster data is certainly the task at hand for me. Steve >>> Daniel Morissette 12/16/03 5:25 PM >>> (I decided to move this to mapserver-dev) Steve Lime wrote: > Do you mean TILEINDEX or the new TIMEINDEX? I could certainly see doing > filtering on the TIMEINDEX, especially as applied to non-raster data. > Using filters on tiles could certainly be done but would there be any > real practical use for the output. The new TIMEINDEX is accomanied by a > TIMEID, and the TIMEID could be interpreted as a MapServer expression so > you could process mutiple files at one time. I didn't know about the name of the new TIMEINDEX so I really meant TILEINDEX. My idea was simply that instead of creating a new TIMEINDEX we could simply extend the existing TILEINDEX to support filter expressions. The expression could be based on time or on any other attribute in the tileindex file. We would also need to extend the expressions stuff in MapServer to support time comparisons and time ranges. That would be a generic enhancement to the expression stuff and could be class EXPRESSIONs and not just in the layer FILTER. Does it make more sense? I'm scared I'm not expressing myself very well... > That would be more work to > add than simply interpreting TIMEID as a single value. > I actually thought that extending the TILEINDEX to support FILTER would be simpler. Would it not just be a matter of adding a call to msEvalExpression() in the code that scans the tile index? Daniel -- ------------------------------------------------------------ Daniel Morissette morissette@dmsolutions.ca DM Solutions Group http://www.dmsolutions.ca/ ------------------------------------------------------------ From morissette at dmsolutions.ca Wed Dec 17 10:49:38 2003 From: morissette at dmsolutions.ca (Daniel Morissette) Date: Fri Feb 8 14:56:42 2008 Subject: [Mapserver-dev] Re: time support In-Reply-To: References: Message-ID: <3FE07B12.5090705@dmsolutions.ca> Steve Lime wrote: > A timeindex would not be a shapefile, rather simply a temporal lookup > table. An xbase file would do nicely. You're right. I didn't realize that. > That > way date expressions could be used with any data source if a column > contained ISO8601 formated date/time strings. In that case using a > timeindex for anything but raster data may not be necessary. Raster data > is certainly the task at hand for me. > Actually, some people might have one shapefile per time range (or time value), so I can see why this TIMEINDEX would be useful to shapefiles as well. Imagine an organization with 100 years of daily weather data: that's too much information to store in a single shapefile if you want reasonable performance. I guess they would be better using a RDBMS than shapefiles for this anyway, but that's an example where TIMEINDEX on shapefiles could be used. Daniel -- ------------------------------------------------------------ Daniel Morissette morissette@dmsolutions.ca DM Solutions Group http://www.dmsolutions.ca/ ------------------------------------------------------------ From steve.lime at dnr.state.mn.us Wed Dec 17 11:11:08 2003 From: steve.lime at dnr.state.mn.us (Steve Lime) Date: Fri Feb 8 14:56:42 2008 Subject: [Mapserver-dev] Re: time support Message-ID: I not convinced I'm right though. The more I've thought about it the more I like extending TILEINDEX. Franks here today, I'll bounce it off him. Steve >>> Daniel Morissette 12/17/2003 9:49:38 AM >>> Steve Lime wrote: > A timeindex would not be a shapefile, rather simply a temporal lookup > table. An xbase file would do nicely. You're right. I didn't realize that. > That > way date expressions could be used with any data source if a column > contained ISO8601 formated date/time strings. In that case using a > timeindex for anything but raster data may not be necessary. Raster data > is certainly the task at hand for me. > Actually, some people might have one shapefile per time range (or time value), so I can see why this TIMEINDEX would be useful to shapefiles as well. Imagine an organization with 100 years of daily weather data: that's too much information to store in a single shapefile if you want reasonable performance. I guess they would be better using a RDBMS than shapefiles for this anyway, but that's an example where TIMEINDEX on shapefiles could be used. Daniel -- ------------------------------------------------------------ Daniel Morissette morissette@dmsolutions.ca DM Solutions Group http://www.dmsolutions.ca/ ------------------------------------------------------------ From morissette at dmsolutions.ca Thu Dec 18 17:46:59 2003 From: morissette at dmsolutions.ca (Daniel Morissette) Date: Fri Feb 8 14:56:42 2008 Subject: [Mapserver-dev] KEYIMAGE at the layer level? Message-ID: <3FE22E63.8040201@dmsolutions.ca> Steve, and all, You may have seen this post to mapserver-users today where someone was trying to use KEYIMAGE with a 24 bits RGB raster and couldn't do it. The problem is that you need a CLASS to set the KEYIMAGE, but you cannot have CLASSes in a 24 bits RGB raster layer. What would you think of adding KEYIMAGE at the layer level as well? That would solve the problem of specifying the legend icon for 24 bits RGB rasters, and also for WMS layers which don't have classes. Actually that might also help with OGR layers using STYLEITEM AUTO. Daniel -- ------------------------------------------------------------ Daniel Morissette morissette@dmsolutions.ca DM Solutions Group http://www.dmsolutions.ca/ ------------------------------------------------------------ From sgillies at frii.com Mon Dec 29 11:12:15 2003 From: sgillies at frii.com (Sean Gillies) Date: Fri Feb 8 14:56:42 2008 Subject: [Mapserver-dev] GD 2.0.17 Message-ID: Hi all, The latest stable release of GD is out and claims to fix thread safety problems with freetype: http://www.boutell.com/gd/manual2.0.17.html#whatsnew2.0.17 I'll make an entry in Bugzilla about taking advantage of this. cheers, Sean -- Sean Gillies sgillies at frii dot com http://users.frii.com/sgillies From sgillies at frii.com Mon Dec 29 11:24:02 2003 From: sgillies at frii.com (Sean Gillies) Date: Fri Feb 8 14:56:42 2008 Subject: Bug 525 URL (Re: [Mapserver-dev] GD 2.0.17) In-Reply-To: Message-ID: <69D25E14-3A1B-11D8-9344-000393B98B56@frii.com> On Monday, December 29, 2003, at 09:12 AM, Sean Gillies wrote: > Hi all, > > The latest stable release of GD is out and claims to fix > thread safety problems with freetype: > > http://www.boutell.com/gd/manual2.0.17.html#whatsnew2.0.17 > > I'll make an entry in Bugzilla about taking advantage of this. > http://mapserver.gis.umn.edu/bugs/show_bug.cgi?id=525 cheers, Sean -- Sean Gillies sgillies at frii dot com http://users.frii.com/sgillies From sgillies at frii.com Mon Dec 29 12:57:37 2003 From: sgillies at frii.com (Sean Gillies) Date: Fri Feb 8 14:56:42 2008 Subject: [Mapserver-dev] [XML] Proposal for a MapScript XML Data Model Project and Discussion Message-ID: <7CA8EB7E-3A28-11D8-9344-000393B98B56@frii.com> Greetings, One of the things that I would most like to see in 2004 is more serious discussion about the future of an XML map configuration format for MapServer. To this end, I've written up a proposal on the MapServer Wiki. Will you please read it and consider joining in the discussion? I'm very interested in learning about how other MapServer users and developers imagine using XML. http://mapserver.gis.umn.edu/cgi-bin/ wiki.pl?MapScriptXMLDataModelProjectProposal ------------------------------------------------------------------------ ---- MapServer users regularly wish for an XML format map configuration. They wish it for different reasons and there has not yet been any coordinated effort to realize it. The time has come for users and developers who desire an XML map configuration to form a special interest group to plan for its future. A initial plan for the project is: 1. Recruit interested parties 2. Register the project as a MapServer component in the Bugzilla 3. Identify, dicuss and document use cases and risk factors 4. Propose a standard XML format for MapScript objects 5. Test code using proposed standard with MapScript 6. Incorporate XML standard into MapServer We'll use the MapServer developers email list with a [XML] in the subject line for discussion, copy important stuff to the Wiki, and also maintain URL links between the Wiki and issues in Bugzilla. No need to create any new frameworks for the project. The project could greatly benefit some users by stage 4: a standard will allow us to program and share Perl, PHP, and Python modules specializing in reading and writing the format. Ideally, this stage will be reached in time to present at the 2nd MapServer Users Meeting. Interested persons should sign themselves on to http://mapserver.gis.umn.edu/cgi-bin/ wiki.pl?MapScriptXMLDataModelProjectRoster and subscribe to the mapserver-dev list. Next they should begin to add to the Wiki documents. It should be very interesting to see what kind of applications are out there waiting for a standard XML map configuration format. For examples, check out http://mapserver.gis.umn.edu/cgi-bin/ wiki.pl?MapScriptXMLDataModelProjectUseCases. A peaceful and prosperous New Year to all, Sean -- Sean Gillies sgillies at frii dot com http://users.frii.com/sgillies From Jean-Francois.Doyon at CCRS.NRCan.gc.ca Tue Dec 30 15:56:20 2003 From: Jean-Francois.Doyon at CCRS.NRCan.gc.ca (Jean-Francois.Doyon@CCRS.NRCan.gc.ca) Date: Fri Feb 8 14:56:42 2008 Subject: [Mapserver-dev] [XML] Proposal for a MapScript XML Data Model Project and Discussion Message-ID: <7CDD7B94357FD5119E800002A537C46E0B8B7210@s5-ccr-r1.ccrs.nrcan.gc.ca> Ooops never mind this line: "- I would be careful about using the saying "XML Data Model" since that has wide ranging implications. I read that as meaning an XML representation of MapServer's Object model, which may or may not be related to expressing things in the MapFile. What we're really talking about here is an XML Mapfile right ?" I've now read the current use cases in the Wiki and realize you do mean a pure XML representation of the Data Model :) I especially like the serializing using XML idea, lots of potential there! J.F. -----Original Message----- From: Doyon, Jean-Francois Sent: Tuesday, December 30, 2003 3:51 PM To: 'Sean Gillies'; MapServer-Dev Subject: RE: [Mapserver-dev] [XML] Proposal for a MapScript XML Data Model Project and Discussion Well I don't know how much time I could spend on this, but I'l definitely vote for at least having the OPTION of an XML MapFile, I would REALLY REALLY REALLY love that :P So Mark me down as an interested party. A couple of early thoughts: - Let's not become overly academic and write OGC style schemas !!! - Steve had I believe started on a DTD for a mapfile ... Though I guess it never went anywhere ... A place to start though. (Is it still in CVS ?) - I would be careful about using the saying "XML Data Model" since that has wide ranging implications. I read that as meaning an XML representation of MapServer's Object model, which may or may not be related to expressing things in the MapFile. What we're really talking about here is an XML Mapfile right ? - XML support for MapFile should be optional, maybe at compile-time, by linking against libxml2, expat, or something like that. - The schema should be modular, one big advantage I'd like to see come out of this is the fact that I can have common parts of mapfiles exist only once instead of repeating my SCALEBAR definition in each mapfile for instance. (I will add this to the scenario/use case section of the Wiki) - Seems to me the overall model pretty much exists already, it is the structure of a mapfile and it's objects. The effort would consist mainly of XML'izing it, meaning agreeing on element names, data types, abstract schema's, what feature of XML to use/support (XLink?) or not and so on ? - If such support is added to mapserver then the mapserver core should now support not only reading but also writing of mapfiles in XML format (As it already supports writing of regular MapFiles). - I agree that writing tools/SDK's to work with said XML MapFiles would be crucial to their acceptance ... I'm sure you'd have a Python module ready in no time, right ? :P My .02$ ! Happy new year ! J.F. -----Original Message----- From: mapserver-dev-admin@lists.gis.umn.edu [mailto:mapserver-dev-admin@lists.gis.umn.edu]On Behalf Of Sean Gillies Sent: Monday, December 29, 2003 12:58 PM To: MapServer-Dev Subject: [Mapserver-dev] [XML] Proposal for a MapScript XML Data Model Project and Discussion Greetings, One of the things that I would most like to see in 2004 is more serious discussion about the future of an XML map configuration format for MapServer. To this end, I've written up a proposal on the MapServer Wiki. Will you please read it and consider joining in the discussion? I'm very interested in learning about how other MapServer users and developers imagine using XML. http://mapserver.gis.umn.edu/cgi-bin/ wiki.pl?MapScriptXMLDataModelProjectProposal ------------------------------------------------------------------------ ---- MapServer users regularly wish for an XML format map configuration. They wish it for different reasons and there has not yet been any coordinated effort to realize it. The time has come for users and developers who desire an XML map configuration to form a special interest group to plan for its future. A initial plan for the project is: 1. Recruit interested parties 2. Register the project as a MapServer component in the Bugzilla 3. Identify, dicuss and document use cases and risk factors 4. Propose a standard XML format for MapScript objects 5. Test code using proposed standard with MapScript 6. Incorporate XML standard into MapServer We'll use the MapServer developers email list with a [XML] in the subject line for discussion, copy important stuff to the Wiki, and also maintain URL links between the Wiki and issues in Bugzilla. No need to create any new frameworks for the project. The project could greatly benefit some users by stage 4: a standard will allow us to program and share Perl, PHP, and Python modules specializing in reading and writing the format. Ideally, this stage will be reached in time to present at the 2nd MapServer Users Meeting. Interested persons should sign themselves on to http://mapserver.gis.umn.edu/cgi-bin/ wiki.pl?MapScriptXMLDataModelProjectRoster and subscribe to the mapserver-dev list. Next they should begin to add to the Wiki documents. It should be very interesting to see what kind of applications are out there waiting for a standard XML map configuration format. For examples, check out http://mapserver.gis.umn.edu/cgi-bin/ wiki.pl?MapScriptXMLDataModelProjectUseCases. A peaceful and prosperous New Year to all, Sean -- Sean Gillies sgillies at frii dot com http://users.frii.com/sgillies _______________________________________________ Mapserver-dev mailing list Mapserver-dev@lists.gis.umn.edu http://lists.gis.umn.edu/mailman/listinfo/mapserver-dev From Jean-Francois.Doyon at CCRS.NRCan.gc.ca Tue Dec 30 15:50:57 2003 From: Jean-Francois.Doyon at CCRS.NRCan.gc.ca (Jean-Francois.Doyon@CCRS.NRCan.gc.ca) Date: Fri Feb 8 14:56:42 2008 Subject: [Mapserver-dev] [XML] Proposal for a MapScript XML Data Model Project and Discussion Message-ID: <7CDD7B94357FD5119E800002A537C46E0B8B720F@s5-ccr-r1.ccrs.nrcan.gc.ca> Well I don't know how much time I could spend on this, but I'l definitely vote for at least having the OPTION of an XML MapFile, I would REALLY REALLY REALLY love that :P So Mark me down as an interested party. A couple of early thoughts: - Let's not become overly academic and write OGC style schemas !!! - Steve had I believe started on a DTD for a mapfile ... Though I guess it never went anywhere ... A place to start though. (Is it still in CVS ?) - I would be careful about using the saying "XML Data Model" since that has wide ranging implications. I read that as meaning an XML representation of MapServer's Object model, which may or may not be related to expressing things in the MapFile. What we're really talking about here is an XML Mapfile right ? - XML support for MapFile should be optional, maybe at compile-time, by linking against libxml2, expat, or something like that. - The schema should be modular, one big advantage I'd like to see come out of this is the fact that I can have common parts of mapfiles exist only once instead of repeating my SCALEBAR definition in each mapfile for instance. (I will add this to the scenario/use case section of the Wiki) - Seems to me the overall model pretty much exists already, it is the structure of a mapfile and it's objects. The effort would consist mainly of XML'izing it, meaning agreeing on element names, data types, abstract schema's, what feature of XML to use/support (XLink?) or not and so on ? - If such support is added to mapserver then the mapserver core should now support not only reading but also writing of mapfiles in XML format (As it already supports writing of regular MapFiles). - I agree that writing tools/SDK's to work with said XML MapFiles would be crucial to their acceptance ... I'm sure you'd have a Python module ready in no time, right ? :P My .02$ ! Happy new year ! J.F. -----Original Message----- From: mapserver-dev-admin@lists.gis.umn.edu [mailto:mapserver-dev-admin@lists.gis.umn.edu]On Behalf Of Sean Gillies Sent: Monday, December 29, 2003 12:58 PM To: MapServer-Dev Subject: [Mapserver-dev] [XML] Proposal for a MapScript XML Data Model Project and Discussion Greetings, One of the things that I would most like to see in 2004 is more serious discussion about the future of an XML map configuration format for MapServer. To this end, I've written up a proposal on the MapServer Wiki. Will you please read it and consider joining in the discussion? I'm very interested in learning about how other MapServer users and developers imagine using XML. http://mapserver.gis.umn.edu/cgi-bin/ wiki.pl?MapScriptXMLDataModelProjectProposal ------------------------------------------------------------------------ ---- MapServer users regularly wish for an XML format map configuration. They wish it for different reasons and there has not yet been any coordinated effort to realize it. The time has come for users and developers who desire an XML map configuration to form a special interest group to plan for its future. A initial plan for the project is: 1. Recruit interested parties 2. Register the project as a MapServer component in the Bugzilla 3. Identify, dicuss and document use cases and risk factors 4. Propose a standard XML format for MapScript objects 5. Test code using proposed standard with MapScript 6. Incorporate XML standard into MapServer We'll use the MapServer developers email list with a [XML] in the subject line for discussion, copy important stuff to the Wiki, and also maintain URL links between the Wiki and issues in Bugzilla. No need to create any new frameworks for the project. The project could greatly benefit some users by stage 4: a standard will allow us to program and share Perl, PHP, and Python modules specializing in reading and writing the format. Ideally, this stage will be reached in time to present at the 2nd MapServer Users Meeting. Interested persons should sign themselves on to http://mapserver.gis.umn.edu/cgi-bin/ wiki.pl?MapScriptXMLDataModelProjectRoster and subscribe to the mapserver-dev list. Next they should begin to add to the Wiki documents. It should be very interesting to see what kind of applications are out there waiting for a standard XML map configuration format. For examples, check out http://mapserver.gis.umn.edu/cgi-bin/ wiki.pl?MapScriptXMLDataModelProjectUseCases. A peaceful and prosperous New Year to all, Sean -- Sean Gillies sgillies at frii dot com http://users.frii.com/sgillies _______________________________________________ Mapserver-dev mailing list Mapserver-dev@lists.gis.umn.edu http://lists.gis.umn.edu/mailman/listinfo/mapserver-dev