Yeah, you pointed out a very valid point. <br>As open layers handled my map file in an efficient manner, I didn't overloaded myself with implementation of Tiling. <br><br>But, there is one more serious thought. Lets try to understand this problem:
<br><br>Example: <br><br>Layer 1 : [shapefile] Roads of a country. <br><br>The attributes of this road layer changes w.r.t. zoom-levels. For instance, at higher zoom level roads seems thinner, and at lower it seems broader.
<br>So, for these zoom-levels, I used Maxscale/Minscale values and developed multiple layers for this Layer.<br><br>Layer 2: [shapefile] Roads of a state <br><br>The above case is true with this layer too. <br><br>I hope this could magnify my problem.
<br><br>Regards,<br>Ritz<br><br><div class="gmail_quote">On Jan 24, 2008 8:55 PM, Fawcett, David <<a href="mailto:David.Fawcett@state.mn.us">David.Fawcett@state.mn.us</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
You mention creating individual layers for each shapefile. So, does<br>this mean that if you have a shapefile of road data for each state you<br>are creating a MapServer layer for each shapefile?<br><br>If this is the case, you can definitely reduce the number of layers (and
<br>likely increase performance) by using a tileindex.<br><br>A tileindex is a polygon dataset, usually a shapefile, with a polygon<br>that defines the boundaries of each individual dataset. In other words,<br>you would use a utility to create a new shapefile with polygons that
<br>define the boundaries of each of your state road shapefiles. In the<br>attribute table of your tileindex, there is a column that tells<br>MapServer where to find the actual shapefile represented by a particular<br>feature.
<br><br>You then create just one layer using the tileindex as the data source.<br>Take a look at: <a href="http://mapserver.gis.umn.edu/docs/howto/tileindex" target="_blank">http://mapserver.gis.umn.edu/docs/howto/tileindex
</a> if<br>you haven't already.<br><br>David.<br><div class="Ih2E3d"><br>-----Original Message-----<br>From: UMN MapServer Users List [mailto:<a href="mailto:MAPSERVER-USERS@LISTS.UMN.EDU">MAPSERVER-USERS@LISTS.UMN.EDU
</a>] On<br>Behalf Of riteshambastha<br></div><div class="Ih2E3d">Sent: Thursday, January 24, 2008 9:16 AM<br>To: <a href="mailto:MAPSERVER-USERS@LISTS.UMN.EDU">MAPSERVER-USERS@LISTS.UMN.EDU</a><br>Subject: Re: [UMN_MAPSERVER-USERS] Map file with 35,000+ Lines...
<br>management issue<br><br><br></div>Dear Stephen,<br><br>The number of layers exceeded much because I am including each<br>individual shapefile multiple times for different Maxcale/Minscale<br>values. So, a shapefile is now called by 3-4 layers, each layer having
<br>different Maxscale/Minscale values.<br><br>I hope I made my point clear.<br><br>Regards,<br>Ritz<br><br><br>Stephen Woodbridge wrote:<br>><br>> Ok, I need to ask the obvious question, WHY? do you feel you need 658
<br>> layers. Is this because you have lots of shapefiles? and most of the<br>> layer definitions are the same except for the data source?<br>><br>> For Tiger data I have 33000 shapefiles, but I only have about 20+-
<br>> layers. Are you using tileindexes? Do you know what they are? Just<br>> trying to diagnose your situation a little better so we can help.<br>><br>> -Steve W<br><div><div></div><div class="Wj3C7c">><br>
> ritesh ambastha wrote:<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. Your
<br>>> reply helped me to view at the problems+solutions in broad spectrum..<br>>><br>>> Warm Regards,<br>>> Ritesh<br>>><br>>> On Jan 24, 2008 1:04 AM, Bob Basques <<a href="mailto:Bob.Basques@ci.stpaul.mn.us">
Bob.Basques@ci.stpaul.mn.us</a>><br>>> wrote:<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<br>>>> feel that in most cases, that form follows function, if you need a
<br>>>> capability, you build it. Anyway, here are some of my thoughts.<br>>>><br>>>> These same sorts of performance questions crossed my mind too. The<br>>>> Googlish mapfile I've been working on has 72 separate STYLE
<br>>>> definitions for example.<br>>>> Mostly ranged around threshholding of certain styles. I can see<br>that<br>>>> adding<br>>>> in the Water bodies, Railroad, Parks, and such, is really going to
<br>make<br>>>> 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 built GeoMoose as a client and why it runs against MapServer<br>>>> CGI, so that it can abstract the layer calls in this fashion. We're
<br><br>>>> running 135+ layers internally at the moment, and they all have<br>>>> their own MAPFILE and are all<br>>>> called separately from the client. It has made life much easier<br>with<br>
>>> regard<br>>>> to MapFile creation and maintenance, since each data custodian<br>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><br>>>> attack the performance side of things, I anticpate that I'll need to<br><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<br>datasets<br>>>> change very frequently, in some cases, down to the minute. I may
<br>look<br>>>> into<br>>>> tiling at some point in the future, but it will still be only for<br>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 <
<a href="mailto:ritesh.linux@GMAIL.COM">ritesh.linux@GMAIL.COM</a>> wrote:<br>>>> Dear Readers,<br>>>><br>>>> I have developed a map file with more than 35,000 Lines. Its size<br>>>> will grow by double/triple in next few months. Now, I am trying to
<br>>>> tune my map 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>>>>
<a href="http://www.nabble.com/Map-file-with-35,000+-Lines...-management-issu" target="_blank">http://www.nabble.com/Map-file-with-35,000+-Lines...-management-issu</a><br>>>> e-tp15048892p15048892.html<br>>>>
<br>>>> Sent from the Mapserver - User mailing list archive at <a href="http://Nabble.com" target="_blank">Nabble.com</a>.<br>>>><br>>><br>>><br>>><br>><br>><br><br>--<br>View this message in context:
<br></div></div><div class="Ih2E3d"><a href="http://www.nabble.com/Map-file-with-35%2C000%2B-Lines...-management-issu" target="_blank">http://www.nabble.com/Map-file-with-35%2C000%2B-Lines...-management-issu</a><br></div>
e-tp15048892p15065742.html<br><div><div></div><div class="Wj3C7c">Sent from the Mapserver - User mailing list archive at <a href="http://Nabble.com" target="_blank">Nabble.com</a>.<br></div></div></blockquote></div><br><br clear="all">
<br>-- <br>Ritesh Ambastha,<br><br>Project Manager<br>Mobiance Technologies,<br>Bangalore<br><br>+91-80-41264755