<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Message</TITLE>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2900.3243" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=457045415-24012008><FONT face=Arial color=#0000ff size=2>I
would suggest a tileindex to display all of the individual shapefiles that make
up your state_roads layer in one layer. Same thing for your country_roads
layer if it is split up in to smaller data files. </FONT></SPAN></DIV>
<DIV><SPAN class=457045415-24012008><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=457045415-24012008><FONT face=Arial color=#0000ff size=2>You
may even want to put MINSCALE/MAXSCALE values in place so
your state_roads doesn't display when zoomed out too far.
</FONT></SPAN></DIV>
<DIV><SPAN class=457045415-24012008><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=457045415-24012008><FONT face=Arial color=#0000ff size=2>Then,
for symbology purposes, you can create multiple classes for each layer, each
with their own MINSCALE/MAXSCALE values so you can style your roads differently
based on how far you are zoomed into.</FONT></SPAN></DIV>
<DIV><SPAN class=457045415-24012008><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=457045415-24012008><FONT face=Arial color=#0000ff
size=2>David.</FONT></SPAN></DIV>
<BLOCKQUOTE style="MARGIN-RIGHT: 0px">
<DIV></DIV>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left><FONT
face=Tahoma size=2>-----Original Message-----<BR><B>From:</B> UMN MapServer
Users List [mailto:MAPSERVER-USERS@LISTS.UMN.EDU] <B>On Behalf Of </B>ritesh
ambastha<BR><B>Sent:</B> Thursday, January 24, 2008 9:39 AM<BR><B>To:</B>
MAPSERVER-USERS@LISTS.UMN.EDU<BR><B>Subject:</B> Re: [UMN_MAPSERVER-USERS] Map
file with 35,000+ Lines... management issue<BR><BR></FONT></DIV>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="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid">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 </BLOCKQUOTE></BODY></HTML>