PHP Map Obj Serialize

[P Kishor]

On 8/15/06, Stuart Eve <stuarteve at lparchaeology.com> wrote:
> Hi there
> >
> > querystrings have nothing to do with CGI MapServer exclusively ... you
> > use them with or without CGI, with or without scripting... after all,
> > how else does the user communicate with the server... the only known
> > possible ways for a browser to communicate with a server are
> > GET|POST|XMLHttpRequest, afaik. That said...
> Thanks for the reply, we are writing quite a complex application in php
> and afaik you have listed the most common ways that the user may
> communicate with the server.

Not just the "most common ways" but, afaik, the only ways.

> We also make use of session variables as
> well, meaning we can also use some quite complicated multi-dimensional
> arrays to set up and change various variables.

Nothing to do with how the _user_ communicates with the _server_.

>
> This is one of the reasons why I was wondering if it was possible to
> serialise the map object, save it to the session and then rebuild it
> afterwards, so that we could avoid the performance loss of reading in a
> text file and then recreating the map object each time.
> > Yes, in that case, what you doing is probably one correct way to do it
> > (I am sure TMTOWTDI).
> Does anyone have any other ideas what these other ways may be - I am
> interested to try to streamline this as much as possible.
> >
> > You can continue to do what you are doing... just store the unique,
> > associative threesome of the memorable name ('My favorite house'), the
> > mapfile for it, and the cached png's name in a db table. When the user
> > wants to see her favorite house, query the db and grab the png name
> > and the mapfile... check to make sure the png still exists, and if
> > yes, show it. Else, regenerate the darn thing using the mapfile. All
> > these three things are already plain vanilla text, and can be easily
> > stored in your persistent mechanism of choice.
> I think that there will be a performance hit reading in and comparing
> plain vanilla text files, especially if we have a lot of saved mapfiles.
> For example, if we have 5000 saved mapfiles, the application will need
> to open and read in and compare 5000 mapfiles each reload. Thats going
> to be quite processor heavy. Does anyone have any suggestions?

first, why do you have to read and compare 5000 files for each reload?
Here is the use case --

1. madam mapmaker customizes her map and saves it as her 'favorite map'

2.1. your application stores in that user's list of maps, a triple combo of

mapname => 'favorite map',
mapfile => <unique_id>.map,
pngfile => <unique_id>.png


2.2. your app makes sure that the '<unique_id>.png' is swept away into
some persistent cache where it won't get cleaned up.

2.3. your app makes sure the '<unique_id>.map' is swept away into some
persistent cache where it won't get cleaned up.

3. mm comes back a few days later and wants to see her 'favorite map'.
You query your persistent store, determine that her 'favorite map'
exists, determine that the associated '<unique_id>.png' exists, and if
it does, show it, and if it doesn't, then grab the associated
'<unique_id>.map', regenerate the whole mess, and show it.

Unless I missed something, you didn't have to go through opening and
reloading 5000 mapfiles at all... just the one requested.

As far as performance is concerned, my advice would be to not
speculatively worry about performance. When in doubt, benchmark, and
then decide. You don't have to store all the mapfiles in one folder
(most operating systems slow down when there are too many files in one
folder). Instead, create a simple, hierarchical folder system (CPAN is
organized that way -- I used that as an inspiration for storing all my
website wiki data as flat files, and it works great).

If you still don't want to store flat text files (I totally believe in
them, by the way, over databases, for most problems), well then, store
them in your database. Instead of storing the mapfile name, just store
the darn file. It is just plain text after all.


> > On the other hand, as I said, TMTOWTDI.
> >
> >
> >> This means
> >> we would need to load the querystring with definitions for each layer
> >> and class within the mapfile which may become a little unmanageable.
> >>
> >> Stuart
> >>
> >> P Kishor wrote:
> >> > I know very little about the current state of PHP/MapScript, but I
> >> > have implemented what you propose below. It does not require mucking
> >> > around with mapObj at all.
> >> >
> >> > Think of how any given map is formed -- it requires a query sent
> >> > either via GET or POST. All you have to do is store that query (it is
> >> > already serialized by http for you), associate it with a memorable
> >> > name ('My House', 'My Cat's Sleeping Place') and the resulting png
> >> > image cached somewhere safe where it doesn't get cleaned up by your
> >> > normal hard disk maid service, and store the three as you wish -- in
> >> > an associative array, in a file, in 3 fields of a database table,
> >> > whatever you want.
> >> >
> >> > Next time your user clicks on her 'My House', you check if the
> >> > associate png is present and use it, if not, use the associated query
> >> > to regenerate it, and restore it.
> >> >
> >> > On 8/15/06, Stuart Eve <stuarteve at lparchaeology.com> wrote:
> >> >> Dear all,
> >> >>
> >> >> We are attempting to think of a way to provide a 'permalink' to a
> >> >> particular map object. In addition we would like to do a check to
> >> see if
> >> >> the server has already created that map (with its specific
> >> >> configuration) before and so just load up the cached png instead of
> >> >> recreating the png each time.
> >> >>
> >> >> I realise we can save out the mapfile to a .txt file and then read
> >> it in
> >> >> - and compare it to all of the other mapfiles we have saved, but it
> >> >> seems like it may be a little processor heavy. We were hoping to save
> >> >> something out to a field in the MySQL table. We were thinking
> >> along the
> >> >> lines of a serialized array which could then be compared with the
> >> other
> >> >> cached arrays in the MySQL table and see if theres a match.
> >> >>
> >> >> Our main problem, though, is that we can't unserialize a map
> >> object (as
> >> >> it loses all of its methods). Is there a way to unserialize the map
> >> >> object and make it function properly again as a map object or
> >> >> alternatively output the mapfile to a field in the database and then
> >> >> recreate the map object from that? Does the mapObj constructor
> >> only work
> >> >> from files?
> >> >>
> >> >> We are using Mapserver 4.8 and PHPMapscript.
> >> >>
> >> >> Thanks in advance
> >> >>
> >> >> Stuart
> >> >>


-- 
Puneet Kishor http://punkish.eidesis.org/
Nelson Inst. for Env. Studies, UW-Madison http://www.ies.wisc.edu/
Open Source Geospatial Foundation https://edu.osgeo.org/