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:[EMAIL PROTECTED] On Behalf Of ritesh ambastha
Sent: Thursday, January 24, 2008 9:39 AM
To: MAPSERVER-USERS@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
<[EMAIL PROTECTED]> 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@LISTS.UMN.EDU ] On
Behalf Of riteshambastha
Sent: Thursday, January 24, 2008 9:16 AM
To: MAPSERVER-USERS@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 <
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> >
>> 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 < [EMAIL PROTECTED]> 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
