Map file with 35,000+ Lines... management issue

Fawcett, David David.Fawcett at STATE.MN.US
Thu Jan 24 07:58:42 PST 2008


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.  
 
You may even want to put  MINSCALE/MAXSCALE   values in place so your
state_roads doesn't display when zoomed out too far.  
 
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.
 
David.

	-----Original Message-----
	From: UMN MapServer Users List
[mailto:MAPSERVER-USERS at LISTS.UMN.EDU] On Behalf Of ritesh ambastha
	Sent: Thursday, January 24, 2008 9:39 AM
	To: MAPSERVER-USERS at LISTS.UMN.EDU
	Subject: Re: [UMN_MAPSERVER-USERS] Map file with 35,000+
Lines... management issue
	
	
	Yeah, you pointed out a very valid point. 
	As open layers handled my map file in an efficient manner, I
didn't overloaded myself with implementation of Tiling. 
	
	But, there is one more serious thought. Lets try to understand
this problem: 
	
	Example: 
	
	Layer 1 : [shapefile] Roads of a country. 
	
	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. 
	So, for these zoom-levels, I used Maxscale/Minscale values and
developed multiple layers for this Layer.
	
	Layer 2: [shapefile] Roads of a state 
	
	The above case is true with this layer too. 
	
	I hope this could magnify my problem. 
	
	Regards,
	Ritz
	
	
	On Jan 24, 2008 8:55 PM, Fawcett, David
<David.Fawcett at state.mn.us> wrote:
	

		You mention creating individual layers for each
shapefile.  So, does
		this mean that if you have a shapefile of road data for
each state you
		are creating a MapServer layer for each shapefile?
		
		If this is the case, you can definitely reduce the
number of layers (and 
		likely increase performance) by using a tileindex.
		
		A tileindex is a polygon dataset, usually a shapefile,
with a polygon
		that defines the boundaries of each individual dataset.
In other words,
		you would use a utility to create a new shapefile with
polygons that 
		define the boundaries of each of your state road
shapefiles.  In the
		attribute table of your tileindex, there is a column
that tells
		MapServer where to find the actual shapefile represented
by a particular
		feature. 
		
		You then create just one layer using the tileindex as
the data source.
		Take a look at:
http://mapserver.gis.umn.edu/docs/howto/tileindex if
		you haven't already.
		
		David.
		

		-----Original Message-----
		From: UMN MapServer Users List
[mailto:MAPSERVER-USERS at LISTS.UMN.EDU ] On
		Behalf Of riteshambastha
		
		Sent: Thursday, January 24, 2008 9:16 AM
		To: MAPSERVER-USERS at LISTS.UMN.EDU
		Subject: Re: [UMN_MAPSERVER-USERS] Map file with 35,000+
Lines... 
		management issue
		
		
		
		Dear Stephen,
		
		The number of layers exceeded much because I am
including each
		individual shapefile multiple times for different
Maxcale/Minscale
		values.  So, a shapefile is now called by 3-4 layers,
each layer having 
		different Maxscale/Minscale values.
		
		I hope I made my point clear.
		
		Regards,
		Ritz
		
		
		Stephen Woodbridge wrote:
		>
		> Ok, I need to ask the obvious question, WHY? do you
feel you need 658 
		> layers. Is this because you have lots of shapefiles?
and most of the
		> layer definitions are the same except for the data
source?
		>
		> For Tiger data I have 33000 shapefiles, but I only
have about 20+- 
		> layers. Are you using tileindexes? Do you know what
they are? Just
		> trying to diagnose your situation a little better so
we can help.
		>
		> -Steve W
		
		>
		> ritesh ambastha wrote:
		>> Thanks Bob,
		>>
		>> The map file consists of 658 Layers.
		>> It runs with openlayers and postgis.
		>>
		>> Now, am trying to sort out the best way for solving
this issue. Your 
		>> reply helped me to view at the problems+solutions in
broad spectrum..
		>>
		>> Warm Regards,
		>> Ritesh
		>>
		>> On Jan 24, 2008 1:04 AM, Bob Basques <
Bob.Basques at ci.stpaul.mn.us <mailto:Bob.Basques at ci.stpaul.mn.us> >
		>> wrote:
		>>>
		>>> Ritz,
		>>>
		>>> Whew, 35k lines, that big.  How many layers is that
anyway?   The
		>>> Googlish
		>>> mapfile I just did only has 1100 lines in it, and
that's mostly for 
		>>> readability.  I could probably get it down to half
that size if I
		>>> tried.
		>>>
		>>> Don't know what I can contribute as a "Best
Practice", because I
		>>> feel that in most cases, that form follows function,
if you need a 
		>>> capability, you build it.  Anyway, here are some of
my thoughts.
		>>>
		>>> These same sorts of performance questions crossed my
mind too.  The
		>>> Googlish mapfile I've been working on has 72
separate STYLE 
		>>> definitions for example.
		>>> Mostly ranged around threshholding of certain
styles.  I can see
		that
		>>> adding
		>>> in the Water bodies, Railroad, Parks, and such, is
really going to 
		make
		>>> this
		>>> thing big.  I may just do those as separate MapFiles
though since
		>>> GeoMoose
		>>> handles things like these separations very nicely.
		>>>
		>>> These are some of the primary reasons that
contributed to the way
		>>> we've built GeoMoose as a client and why it runs
against MapServer
		>>> CGI, so that it can abstract the layer calls in this
fashion.  We're 
		
		>>> running 135+ layers internally at the moment, and
they all have
		>>> their own MAPFILE and are all
		>>> called separately from the client.  It has made life
much easier
		with
		>>> regard
		>>> to MapFile creation and maintenance, since each data
custodian
		handles
		>>> their
		>>> respective MAPFILE.  The performance issues are
minimized well since
		>>> even 
		>>> the data intensive layers are not too bad from a
performance
		standpoint.
		>>>
		>>> But even my Googlish looking mapfile got prettty big
(in my opinion)
		for
		>>> simply displaying centerlines of streets.   I've
learned quite a bit 
		>>> from
		>>> these exercises about these types of questions.
While I have yet to
		
		>>> attack the performance side of things, I anticpate
that I'll need to
		
		>>> segregate the 
		>>> data out at differing thresholds in order to gain
some performance
		>>> boots.
		>>> We're all about doing dynamic requests here since
many of our
		datasets
		>>> change very frequently, in some cases, down to the
minute.  I may 
		look
		>>> into
		>>> tiling at some point in the future, but it will
still be only for
		some
		>>> of
		>>> the layers, there will still be a need to have this
dynamic request 
		>>> structure in place.
		>>>
		>>> bobb
		>>>
		>>>
		>>>
		>>>
		>>>
		>>>
		>>> Bob Basques
		>>> GIS Systems Developer 
		>>> City of Saint Paul, MN
		>>>
		>>>
		>>> GISmo
		>>> Powered by
		>>> GeoMOOSE
		>>>
		>>>
		>>>>>> riteshambastha < ritesh.linux at GMAIL.COM> wrote:
		>>> Dear Readers,
		>>>
		>>> I have developed a map file with more than 35,000
Lines. Its size
		>>> will grow by double/triple in next few months. Now,
I am trying to 
		>>> tune my map file by
		>>> removing unwanted lines. Still, I am bit confused
about its
		maintenance.
		>>>
		>>>
		>>> Please throw some lights over writing map files by
following best 
		>>> practices.
		>>>
		>>> Thanks in advance.
		>>>
		>>> Regards,
		>>> Ritz
		>>> --
		>>> View this message in context:
		>>>
http://www.nabble.com/Map-file-with-35,000+-Lines...-management-issu
		>>> e-tp15048892p15048892.html
		>>> 
		>>> Sent from the Mapserver - User mailing list archive
at Nabble.com.
		>>>
		>>
		>>
		>>
		>
		>
		
		--
		View this message in context: 
		
	
http://www.nabble.com/Map-file-with-35%2C000%2B-Lines...-management-issu
		
		e-tp15048892p15065742.html
		
		Sent from the Mapserver - User mailing list archive at
Nabble.com.
		




	-- 
	Ritesh Ambastha,
	
	Project Manager
	Mobiance Technologies,
	Bangalore
	
	+91-80-41264755 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-users/attachments/20080124/c66918a8/attachment.htm>


More information about the MapServer-users mailing list