<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-15">
<META content="MSHTML 6.00.2800.1505" name=GENERATOR></HEAD>
<BODY style="MARGIN: 4px 4px 1px; FONT: 10pt Comic Sans MS">
<DIV>Ed,</DIV>
<DIV> </DIV>
<DIV>While I do have 72 STYLE def's, I only have 11 layers defined in my Googlish mapfile, that's 11 layer definitions for essentially the same data type, Street centerlines. That would equate to approximately 60 real layers being queried, granted, the googlish mapfile I've been working on is somewhat complex, but I would venture that most layers could be as complex with similar cartographic needs.</DIV>
<DIV> </DIV>
<DIV>A couple of the layers i have are for Legends and such for additional output control, and if the control were not a big factor, they could be removed altogether if needed. But it does point to the need in some circles (like those of us who fancy ourselves as some sort of fancy "Cartographer" ;c) to be able to add in our flourishes to the outputs that do indeed require defining more than one layer.</DIV>
<DIV> </DIV>
<DIV>Some instances will require these mapfiles to get very large, and the standards bar is being risen very fast IMHO, and is getting harder and harder to keep up with some of the average user expectations for readability as well as printabilty of online maps. This is a high priority item with me, mostly because I don't want to be stuck doing cartography day in and day out. I'm hoping that there will be some discussion to come out of this Thread related to developing some different methods for applying styles that may end up being easier to maintain as well as easier to teach to others.</DIV>
<DIV> </DIV>
<DIV>bobb</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>
<DIV align=center><STRONG><FONT size=6><FONT size=1></FONT> </DIV>
<DIV align=right>
<TABLE cols=3 align=center border=0>
<TBODY>
<TR>
<TD align=right>
<DIV><STRONG><FONT size=6></FONT></STRONG> </DIV>
<DIV><STRONG>Bob Basques</STRONG></DIV>
<DIV><STRONG><FONT size=2><A href="http://gis.ci.stpaul.mn.us/">GIS</A> Systems Developer</FONT></STRONG></DIV>
<DIV><STRONG><FONT size=1><A href="http://www.ci.stpaul.mn.us/">City of Saint Paul, MN</A></FONT></STRONG></DIV></TD>
<TD><BR><A href="http://gis.ci.stpaul.mn.us/"><IMG alt="Moose Powered GISMO" hspace=0 src="cid:WEUQSYEXUJVH.IMAGE_61.gif" align=middle border=0></A></TD>
<TD>
<DIV><STRONG><FONT size=6></FONT></STRONG> </DIV>
<DIV><STRONG><FONT size=6><A href="http://gis.ci.stpaul.mn.us/"><FONT size=5>GISmo</FONT></A> </FONT></STRONG></DIV>
<DIV align=center><FONT size=2>Powered by</FONT></DIV>
<DIV align=center><STRONG><A href="http://www.geomoose.org/moose/"><FONT size=2>GeoMOOSE</FONT></A></STRONG></DIV></TD></TR></TBODY></TABLE></DIV></FONT></STRONG>
<DIV align=center> </DIV><A href="http://gis.ci.stpaul.mn.us/"></A><BR><BR>>>> Ed McNierney <ed@TOPOZONE.COM> wrote:<BR></DIV>
<DIV style="PADDING-LEFT: 7px; MARGIN: 0px 0px 0px 15px; BORDER-LEFT: #050505 1px solid; BACKGROUND-COLOR: #f3f3f3">Ritesh -<BR><BR>Obviously you cannot possibly need 658 layers to respond to a single map =<BR>request. The first thing to do is figure out how to split up this one =<BR>map file into multiple map files and then use some front-end logic to =<BR>select the appropriate map file to serve a particular request. You may =<BR>find the INCLUDE directive helpful, but you should simply begin by =<BR>eliminating the unnecessary. The theoretical ideal would be that a =<BR>single MapServer request would specify a map file that contained nothing =<BR>more than the symbols, fonts, and layers required to serve that single =<BR>request - nothing more.<BR><BR>- Ed<BR><BR>Ed McNierney<BR>Chief Mapmaker<BR>Demand Media / TopoZone.com<BR>73 Princeton Street, Suite 305<BR>North Chelmsford, MA=A0 01863<BR>ed@topozone.com<BR>Phone: +1 (978) 251-4242<BR>Fax: +1 (978) 251-1396<BR><BR>-----Original Message-----<BR>From: UMN MapServer Users List [mailto:MAPSERVER-USERS@LISTS.UMN.EDU] On =<BR>Behalf Of ritesh ambastha<BR>Sent: Wednesday, January 23, 2008 2:44 PM<BR>To: MAPSERVER-USERS@LISTS.UMN.EDU<BR>Subject: Re: [UMN_MAPSERVER-USERS] Map file with 35,000+ Lines... =<BR>management issue<BR><BR>Thanks Bob,<BR><BR>The map file consists of 658 Layers.<BR>It runs with openlayers and postgis.<BR><BR>Now, am trying to sort out the best way for solving this issue.<BR>Your reply helped me to view at the problems+solutions in broad =<BR>spectrum..<BR><BR>Warm Regards,<BR>Ritesh<BR><BR>On Jan 24, 2008 1:04 AM, Bob Basques <Bob.Basques@ci.stpaul.mn.us> =<BR>wrote:<BR>><BR>><BR>> Ritz,<BR>><BR>> Whew, 35k lines, that big. How many layers is that anyway? The =<BR>Googlish<BR>> mapfile I just did only has 1100 lines in it, and that's mostly for<BR>> readability. I could probably get it down to half that size if I =<BR>tried.<BR>><BR>> Don't know what I can contribute as a "Best Practice", because I feel =<BR>that<BR>> in most cases, that form follows function, if you need a capability, =<BR>you<BR>> build it. Anyway, here are some of my thoughts.<BR>><BR>> These same sorts of performance questions crossed my mind too. The =<BR>Googlish<BR>> mapfile I've been working on has 72 separate STYLE definitions for =<BR>example.<BR>> Mostly ranged around threshholding of certain styles. I can see that =<BR>adding<BR>> in the Water bodies, Railroad, Parks, and such, is really going to =<BR>make this<BR>> thing big. I may just do those as separate MapFiles though since =<BR>GeoMoose<BR>> handles things like these separations very nicely.<BR>><BR>> These are some of the primary reasons that contributed to the way =<BR>we've<BR>> built GeoMoose as a client and why it runs against MapServer CGI, so =<BR>that it<BR>> can abstract the layer calls in this fashion. We're running 135+ =<BR>layers<BR>> internally at the moment, and they all have their own MAPFILE and are =<BR>all<BR>> called separately from the client. It has made life much easier with =<BR>regard<BR>> to MapFile creation and maintenance, since each data custodian handles =<BR>their<BR>> respective MAPFILE. The performance issues are minimized well since =<BR>even<BR>> the data intensive layers are not too bad from a performance =<BR>standpoint.<BR>><BR>> But even my Googlish looking mapfile got prettty big (in my opinion) =<BR>for<BR>> simply displaying centerlines of streets. I've learned quite a bit =<BR>from<BR>> these exercises about these types of questions. While I have yet to =<BR>attack<BR>> the performance side of things, I anticpate that I'll need to =<BR>segregate the<BR>> data out at differing thresholds in order to gain some performance =<BR>boots.<BR>> We're all about doing dynamic requests here since many of our datasets<BR>> change very frequently, in some cases, down to the minute. I may look =<BR>into<BR>> tiling at some point in the future, but it will still be only for some =<BR>of<BR>> the layers, there will still be a need to have this dynamic request<BR>> structure in place.<BR>><BR>> bobb<BR>><BR>><BR>><BR>><BR>><BR>><BR>> Bob Basques<BR>> GIS Systems Developer<BR>> City of Saint Paul, MN<BR>><BR>><BR>> GISmo<BR>> Powered by<BR>> GeoMOOSE<BR>><BR>><BR>> >>> riteshambastha <ritesh.linux@GMAIL.COM> wrote:<BR>><BR>> Dear Readers,<BR>><BR>> I have developed a map file with more than 35,000 Lines. Its size will =<BR>grow<BR>> by double/triple in next few months. Now, I am trying to tune my map =<BR>file by<BR>> removing unwanted lines. Still, I am bit confused about its =<BR>maintenance.<BR>><BR>><BR>> Please throw some lights over writing map files by following best =<BR>practices.<BR>><BR>> Thanks in advance.<BR>><BR>> Regards,<BR>> Ritz<BR>> --<BR>> View this message in context:<BR>> =<BR><A href="http://www.nabble.com/Map">http://www.nabble.com/Map</A>-file-with-35,000+-Lines...-management-issue-tp1=<BR>5048892p15048892.html<BR>><BR>> Sent from the Mapserver - User mailing list archive at Nabble.com.<BR>><BR><BR><BR><BR>--=20<BR>Ritesh Ambastha,<BR><BR>Project Manager<BR>Mobiance Technologies,<BR>Bangalore<BR><BR>+91-80-41264755<BR></DIV></BODY></HTML>