map performance
boice tomlin
boice at RUNSKIP.COM
Wed Dec 6 08:41:38 PST 2006
Hi Ed,
Yes. I'm aware of where PHP fits in. I was just trying to make it
clear that I've not overlooked the PHP part of the process and don't
have any bottlenecks there.
Attached are both of the map files. One is pre processing and post.
It looks mostly as I expected. Your input would be greatly appreciated.
I'm open to different approaches. I hear people mention creating
their own shape files or modifying their shape files directly. How
could I benefit from that? Also I can create dbf files dynamically.
I'm guessing I can do a join with those directly from the map file.
I don't know if there would be any advantage from that.
thanks,
boice


On Dec 6, 2006, at 7:54 AM, Ed McNierney wrote:
> Boice -
>
> I want to make sure you realize that your "PHP work" is really doing
> nothing more than creating the data structures to be used in rendering
> your map. It's not reading any shapefiles, drawing output images,
> etc.
> - it's just looping and creating instructions for the "draw" method to
> follow. The fact that it happens "really fast" is both
> unsurprising and
> unimportant.
>
> It's as if you were running a program to generate instructions for
> yourself to follow; generating a list that says "scratch your ear" 500
> times is fast to generate and (relatively) fast to perform, but
> generating a list that says "fly to Patagonia" 500 times is equally
> fast
> to generate but enormously slower to perform.
>
> Your fast code is simply generating the list. The map-drawing is
> doing
> the work of following the instructions, so Steve's suggestion is
> still a
> good one. If you can use the $map->save() method and post the
> results,
> then we can see what the instructions are.
>
> - Ed
>
> Ed McNierney
> President and Chief Mapmaker
> TopoZone.com / Maps a la carte, Inc.
> 73 Princeton Street, Suite 305
> North Chelmsford, MA 01863
> Phone: +1 (978) 251-4242
> Fax: +1 (978) 251-1396
> ed at topozone.com
>
> -----Original Message-----
> From: UMN MapServer Users List [mailto:MAPSERVER-
> USERS at LISTS.UMN.EDU] On
> Behalf Of Boice Tomlin
> Sent: Tuesday, December 05, 2006 10:52 PM
> To: MAPSERVER-USERS at LISTS.UMN.EDU
> Subject: Re: [UMN_MAPSERVER-USERS] map performance
>
> Thanks Steve,
>
> I will save the map file and take a look. great tip.
>
> In my case I have a few layers which are always on because I know the
> get displayed on every request. For instance I have on layer called
> county.
> Every contry rendered on the map is from that single layer.
>
> What I do is grab all county data that are complete(a user has
> complete
> data for the chosen layer in that geography) - green - and form a long
> regular expression with all thouse counties. Then I form a class
> dynamically and set the color to green.
>
> Then I do the same thing for in-progress data, form a regular
> expression
> from several hundred results, create a class from that same county
> layer
> and set the color to orange.
>
> I'm not sure Steve if I'm hearing you right. You may be referring
> to a
> completely different method that I'm not getting. The thing is
> that the
> PHP work described above happens fast, really fast.
>
> The amount of time the maps takes to render is proportionate to the
> amount of counties, cities, etc. in my regular expression.
>
> does that make my situation clearer.
>
> thank you for your help,
>
> boice
>
>
>
>> Might be interesting to see what the resulting mapfile (after your
>> dynamic work) looks like (use $map->save(...)).
>>
>> We'd really need to know more about the data, how you're doing
>> classifications and such to comment more. There may be lots of
>> ways to
>
>> make things go faster. From the looks of it for each geography (city,
>> county, tribe, state, nation) you have a bunch of variables that
>> indicate if a data theme is available. One could organize that data
>> like so (for example state level data):
>>
>> State Hydrography Watersheds ...
>> MN 0 1
>> WI 3 2
>> IA 3 0
>> FL 1 3
>>
>> Where 0 means no responce, 1 complete and so on. So in that case your
>> class definitions would always be the same you'd be simply changing
>> the variable you're mapping on (e.g. CLASSITEM), and you wouldn't
>> need
>
>> dynamic classes (or even MapScript for that matter). Just thinking
>> out loud...
>>
>> Steve
>>
>>>>> boice tomlin <boice at RUNSKIP.COM> 12/4/2006 1:24:58 PM >>>
>>
>> Hello users,
>>
>> The map located here;
>>
>> http://gisinventory.net/status_maps.html
>>
>> takes a while to load. At least at the national view where there
>> is a
>
>> lot of area to render.
>>
>> I am looking for alternative ways to generate the map that will
>> significantly improve performance.
>>
>> Currently I am using php and looping through data and turning on
>> layers as I go. The PHP part is lightning fast. But after I get the
>> map ready mapserver takes several seconds to generate it.
>>
>> I'm curious about alternative ways to handle this problem and wonder
>> if anyone had comments on any of them.
>>
>> 1) modifying the shape files in some way so the layer information is
>> in those files so that all mapserver has to do is load those files
>> and
>
>> not depend on the map files.
>> 2) using a db such as postgres with postgis so that layer information
>> is available all in one compact source.
>>
>> Right now I have to generate a bunch of dynamic classes in PHP using
>> the general method below.
>>
>> $lyr = $this->ramona_map->getLayerByName("state_yes");
>> $cla = $lyr->getClass(0);
>> $cla->setExpression("/".$expression."/");
>> $lyr->set("status", MS_ON);
>>
>> I have to do this several hundred times to represent all of the data.
>> The time it takes to generate the map seem proportionate to the
>> amount
>
>> of layers I make visible. And again this is on the mapserver side
>> and
>
>> not PHP. PHP does its part of the operation in thousandths of a
>> second.
>>
>> anyone's thoughts are greatly appreciated.
>>
>> -boice tomlin
>>
>>
>>
>> ////////////////////////////
>> Run Skip
>> http://runskip.com/
>>
>>
>> boice tomlin
>>
>>
>> boice at runskip.com
>>
>>
>> 503-528-6204
>>
>
>
>
> ////////////////////////////
> Run Skip
>
> boice tomlin
>
> boice at runskip.com
>
> 503-528-6204
////////////////////////////
Run Skip
http://runskip.com/
boice tomlin
boice at runskip.com
503-528-6204
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-users/attachments/20061206/48dc445a/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: post.render.us.map
Type: application/octet-stream
Size: 14774 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/mapserver-users/attachments/20061206/48dc445a/attachment.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-users/attachments/20061206/48dc445a/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pre.render.us.map
Type: application/octet-stream
Size: 8770 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/mapserver-users/attachments/20061206/48dc445a/attachment-0001.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-users/attachments/20061206/48dc445a/attachment-0002.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
URL: <http://lists.osgeo.org/pipermail/mapserver-users/attachments/20061206/48dc445a/attachment.sig>
More information about the MapServer-users
mailing list