zmapserver-developers Mailing List for ZMapServer (Page 5)
Status: Alpha
Brought to you by:
sgillies
Menu
▾
▴
zmapserver-developers — ZMapServer Developers List
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
(3) |
Jun
(5) |
Jul
(7) |
Aug
(2) |
Sep
(4) |
Oct
|
Nov
|
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
|
Feb
(4) |
Mar
(2) |
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
(9) |
Sep
(4) |
Oct
(3) |
Nov
(10) |
Dec
(2) |
| 2005 |
Jan
(18) |
Feb
(10) |
Mar
(11) |
Apr
(10) |
May
(26) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Sean G. <sgi...@fr...> - 2004-08-17 17:10:20
|
On Aug 17, 2004, at 1:25 AM, Silke Reimer wrote: > Hi Sean, > > On Mon, Aug 16, 2004 at 10:48:40AM -0600, Sean Gillies wrote: >> Hi, >> >> I've made a new release of ZMapServer which enables it to work >> with MapServer 4.2 and take advantage of major improvements in >> MapServer 4.2.2. There are no new features (other than improved >> stability) in this release. >> >> Future work on ZMapServer is going to involve major refactoring. >> I have spent the past months learning more about MapServer, and >> about programming mapscript apps using other frameworks like >> Twisted and mod_python. I plan to factor out of ZMapServer >> everything that can be useful to non-Zope applications and call >> this package 'Python Cartographic Library' or something like that. >> It will be a more Python-friendly facade in front of the awkward >> MapServer mapscript module and will, in the future, rely more or >> less upon MapServer depending on the future development of the >> MapServer software. The future ZMapServer product will then >> contain only Zope-specific code and will draw upon the new package >> for cartographic capabilities. > > These are great news for me. I often thought about using the > ZMapServer for my projects and I always had the problem that I would > like to use my applications within the Zope as well as without Zope > mainly depending on whether a user management is needed or not. It > has never been very urgent for me so I didn't find the time to > seperate the code into Zope and non-Zope specific parts. > >> >> If you are at all interested in contributing to discussion or work >> on a new and improved Python cartographic/MapServer module, please >> email me. I am also on the #mapserver channel on freenode.net >> and happy to discuss it in that forum. > > At the moment we are considering of developing such a > cartographic/MapServer module that you are talking about (as Free > Software of course). So it will be possible that I can and will > contribute some parts to it. Do you already have some concrete > plans how you want to set up the architecture? > > Greetings, > > Silke > Hi Silke, Thanks for the feedback. Concrete plans? No class diagrams yet if that's what you mean, but I can tell you the general plan so far by comparison to MapServer -- since I still intend to use MapServer for much of the low-level stuff, replacing it as necessary with new code. - Focus on Layers: good bye to the MapServer map/layer/class hierarchy. As with WMS, complicated maps will be formed from a tree of Layers. Have you used the elementtree module for XML? I think this could be a good model for a tree of mapping layers. Any layer will have full mapping capbility: drawing, querying, etc. - Separation of data and presentation: pull style directives out of layer/class and instead use some sort of stylesheet. Maybe CSS-like, maybe more like OGC SLD? Major conceptual change from MapServer is that instead of loading a mapfile from disk, parsing map file, parsing expressions, and drawing an output map we will start with persistable Python objects that are factories for MapServer objects. I'm no longer interested in improving the fundamental mapscript objects, we'll just use them as transient things for drawing and querying and then throw them away just as the CGI mapserver applications do. cheers, Sean -- Sean Gillies sgillies at frii dot com http://users.frii.com/sgillies |
|
From: Silke R. <Sil...@in...> - 2004-08-17 07:59:29
|
Hi Sean, On Mon, Aug 16, 2004 at 10:48:40AM -0600, Sean Gillies wrote: > Hi, >=20 > I've made a new release of ZMapServer which enables it to work > with MapServer 4.2 and take advantage of major improvements in > MapServer 4.2.2. There are no new features (other than improved > stability) in this release. >=20 > Future work on ZMapServer is going to involve major refactoring. > I have spent the past months learning more about MapServer, and > about programming mapscript apps using other frameworks like > Twisted and mod_python. I plan to factor out of ZMapServer > everything that can be useful to non-Zope applications and call > this package 'Python Cartographic Library' or something like that. > It will be a more Python-friendly facade in front of the awkward > MapServer mapscript module and will, in the future, rely more or > less upon MapServer depending on the future development of the > MapServer software. The future ZMapServer product will then > contain only Zope-specific code and will draw upon the new package > for cartographic capabilities. These are great news for me. I often thought about using the ZMapServer for my projects and I always had the problem that I would like to use my applications within the Zope as well as without Zope mainly depending on whether a user management is needed or not. It has never been very urgent for me so I didn't find the time to seperate the code into Zope and non-Zope specific parts. >=20 > If you are at all interested in contributing to discussion or work > on a new and improved Python cartographic/MapServer module, please > email me. I am also on the #mapserver channel on freenode.net > and happy to discuss it in that forum. At the moment we are considering of developing such a cartographic/MapServer module that you are talking about (as Free Software of course). So it will be possible that I can and will contribute some parts to it. Do you already have some concrete plans how you want to set up the architecture? Greetings, Silke --=20 Silke Reimer Intevation GmbH http://intevation.de/ FreeGIS http://freegis.org/ |
|
From: Sean G. <sgi...@fr...> - 2004-08-16 16:48:48
|
Hi, I've made a new release of ZMapServer which enables it to work with MapServer 4.2 and take advantage of major improvements in MapServer 4.2.2. There are no new features (other than improved stability) in this release. Future work on ZMapServer is going to involve major refactoring. I have spent the past months learning more about MapServer, and about programming mapscript apps using other frameworks like Twisted and mod_python. I plan to factor out of ZMapServer everything that can be useful to non-Zope applications and call this package 'Python Cartographic Library' or something like that. It will be a more Python-friendly facade in front of the awkward MapServer mapscript module and will, in the future, rely more or less upon MapServer depending on the future development of the MapServer software. The future ZMapServer product will then contain only Zope-specific code and will draw upon the new package for cartographic capabilities. If you are at all interested in contributing to discussion or work on a new and improved Python cartographic/MapServer module, please email me. I am also on the #mapserver channel on freenode.net and happy to discuss it in that forum. cheers, Sean -- Sean Gillies sgillies at frii dot com http://users.frii.com/sgillies |
|
From: <ben...@id...> - 2004-05-22 12:55:46
|
Dear Open Source developer I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate. You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it. With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development. With many thanks for your participation, Benno Luthiger PS: The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/. We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_en.html for registration to this mailing list. _______________________________________________________________________ Benno Luthiger Swiss Federal Institute of Technology Zurich 8092 Zurich Mail: benno.luthiger(at)id.ethz.ch _______________________________________________________________________ |
|
From: Sean G. <sgi...@fr...> - 2004-03-11 14:59:58
|
On Mar 11, 2004, at 7:34 AM, Titus v.d. Malsburg wrote: > > I have now a few addtitions to WMSAdapter.py, WMSClient.py, > wmsCapabilities.zpt and wmsMetaData.zpt > > * a refresh button for the "wms capabillities" tab > (get new capabillities from the WMS server) > * an slightly improved capabillities parser > (arbitraryly deep nested layers) > * getFeatureInfo Support > * wmsMetaData.zpt shows protocol version > > I now want to know how to contribute these changes. Sean, in one of > your last mails you asked me if I have a sourceforge accoutn. I don't > have one and I don't really know how this sourceforge stuff works. > Would I commit my changes directly into the main CVS-tree? Somehow I > would prefer if you would look over my changes before cecking it in. > Maybe you don't like some of the things I do. Therefore I propose to > send you either one patch containing everything the simply the > affected files. > > Some things remain unsolved: > > * getFeatureInfo: Mapserver returns error-messages as > png files (not in the specified format) > > As reponse format for getFeatureInfo requests Mapserver supports three > formats: text/html, text/plain and GML. There are now two problems: > > * If I send a getFeatureInfo request for a layer containing > pixel-data, Mapserver returns a error message that is > obviously wrong. It tells that the QUERY_LAYERS parameter > was not supplied (which is not true in my case) > > * the errormessage is a png-file with the message drawn on > it (not GML or whatever I specified). > > It is left to the user of WMSAdapter to detect this and do something > appropriate. > > Another nice thing (besides the solutions for these problems) would be > the validation of the capabillities before the actual parsing. > > Sorry, this is little bit much at once. > > Titus > Hi Titus, Send me personally the files and I will be happy to try them out and add the changes to WMSAdapter. Thanks for the contribution! cheers, Sean -- Sean Gillies sgillies at frii dot com http://users.frii.com/sgillies |
|
From: Titus v.d. M. <mal...@cl...> - 2004-03-11 14:44:24
|
I have now a few addtitions to WMSAdapter.py, WMSClient.py,
wmsCapabilities.zpt and wmsMetaData.zpt
* a refresh button for the "wms capabillities" tab
(get new capabillities from the WMS server)
* an slightly improved capabillities parser
(arbitraryly deep nested layers)
* getFeatureInfo Support
* wmsMetaData.zpt shows protocol version
I now want to know how to contribute these changes. Sean, in one of
your last mails you asked me if I have a sourceforge accoutn. I don't
have one and I don't really know how this sourceforge stuff works.
Would I commit my changes directly into the main CVS-tree? Somehow I
would prefer if you would look over my changes before cecking it in.
Maybe you don't like some of the things I do. Therefore I propose to
send you either one patch containing everything the simply the affected
files.
Some things remain unsolved:
* getFeatureInfo: Mapserver returns error-messages as
png files (not in the specified format)
As reponse format for getFeatureInfo requests Mapserver supports three
formats: text/html, text/plain and GML. There are now two problems:
* If I send a getFeatureInfo request for a layer containing
pixel-data, Mapserver returns a error message that is
obviously wrong. It tells that the QUERY_LAYERS parameter
was not supplied (which is not true in my case)
* the errormessage is a png-file with the message drawn on
it (not GML or whatever I specified).
It is left to the user of WMSAdapter to detect this and do something
appropriate.
Another nice thing (besides the solutions for these problems) would be
the validation of the capabillities before the actual parsing.
Sorry, this is little bit much at once.
Titus
|
|
From: Titus v.d. M. <mal...@cl...> - 2004-02-25 16:49:17
|
>> When you ask about WMSAdapter/WMSClient are you referring to the
>> PyOGCLib project?
>
>
> No, this was about why the functionality of the Zope product
> WMSAdapter is provided by the classes WMSAdapter _and_ WMSCLient; or:
> Why didn't you put all this stuff simply in WMSAdapter.py?
Ok, ok, this question is answered. I just looked a little though the
pyOGCLib (which I didn't know before) documenation. :-)
Titus
|
|
From: Titus v.d. M. <mal...@cl...> - 2004-02-25 16:04:18
|
(forgot to cc the list)
Sean Gillies wrote:
> Now, about the tuple of layers and children. It is certainly an
> improvement,
> but if you want to go to deeper nesting it could start to be
> cumbersome? There
> was a time when I considered using the DOM object created in __init__
> but this
> would not be good for performance.
Hm, maybe you are right. This nested lists of tuples format is indeed a
little ugly. How about adding a field to the dict that represents Layer?
layer = {
'name': name,
'title': title,
'srs': srs,
'bbox': {
'minx': float(eBBOX.getAttribute('minx')),
'miny': float(eBBOX.getAttribute('miny')),
'maxx': float(eBBOX.getAttribute('maxx')),
'maxy': float(eBBOX.getAttribute('maxy'))
},
'child layers': [list-of-layers]
}
The method that parses the capabilities would then return a list of
layer-dicts (because there can be more than one top level layers).
Next topic: I would like to have the parsing code in an extra method
(like get_server_capabilities). That would make it nicer to have
something like a refresh feature. In our development process we change
the configuration of our WMS very often. As far as I understand, there
is no other way to get the new capabilities into WMSAdapter than making
a new WMSAdapter instance in Zope. As a quick hack I added the
following to WMSAdapter:
def refresh(self,REQUEST):
self.__init__(self.online_resource)
...
But hey ... ;-)
> Are you familiar with elementtree?
>
> http://effbot.org/zone/element-index.htm
>
> Element is a lightweight and fast DOM-like container object that could
> be a
> good way to keep nested layers.
I didn't know it. But it looks quite nice. But IMO its not a good idea
to add dependencies to a third-party module if it doesn't add something
substantial. In this case it would only add a little bit convenience.
> When you ask about WMSAdapter/WMSClient are you referring to the
> PyOGCLib project?
No, this was about why the functionality of the Zope product WMSAdapter
is provided by the classes WMSAdapter _and_ WMSCLient; or: Why didn't
you put all this stuff simply in WMSAdapter.py?
Another addition I made is adding
def feature_info(self, width, height, srs, bbox, query_layers, x, y,
exceptions=None)
to WMSAdapter.py which calls
def getFeatureInfo(self, resource, version, width, height, srs,
bbox, query_layers, x, y, exceptions=None):
in WMSClient.py
Since the reponse format for the GetFeatureInfo request is not (!)
specified by the OGC, this returns simply the plain reponse of the WMS
(a silly ascii-format in the case of UMN MapServer). It is left to the
caller to interpret this.
Titus
|
|
From: Sean G. <sgi...@fr...> - 2004-02-25 14:36:28
|
On Feb 25, 2004, at 5:24 AM, Titus v.d. Malsburg wrote: > > Hi! > > At the moment I work in a project that makes heavy use of WMSAdapter. > I arrived at a point were WMSAdapter starts to not fulfill our > requirements anymore. Therefore I will probably invest some work the > code. (Attention: my knowledge of the OpenGIS standard is not > extremely firm) The following questions arise: > > The WMS capabillities description allow arbitrarily deep neested > layers (right?) like > > <LAYER ... > > <LAYER ...> > .... > </LAYER> > </LAYER> > > * As far as I understand the code this is not reflected in the code > that parses the layers > * the datastructure that holds the layers (WMSAdapter.layers) is a > list and is in this form not able to represent the hirarchical > structure of the layer > > I now need access to this hirarchical structure and question myself > how to add this information without changing to much of the current > design. My approach would be to rewrite the code that parses the > layers by code that traverses the tree recursively and replace the > list layers by a list that holds tuples of the form > (layer, <list-of-children>), > where <list-of-children> is a empty list if there are no childen. Any > preferences / ideas? > > > What about this WMSAdapter/WMSClient thing? Is this historical? Are > there any plans to merge these? > > Regards, > Titus > Hello Titus, Yes, WMS does allow for deep nesting of layers. The WMSAdapter originated as a MapServer (http://mapserver.gis.umn.edu) application and like MapServer is limited to an array of layers. Removing this limitation has been on my todo list for some time. I welcome any contribution to the code that you'd like to make. If you are serious and have registered with Sourceforge, send me your SF login and I will add you to the list of developers. Now, about the tuple of layers and children. It is certainly an improvement, but if you want to go to deeper nesting it could start to be cumbersome? There was a time when I considered using the DOM object created in __init__ but this would not be good for performance. Are you familiar with elementtree? http://effbot.org/zone/element-index.htm Element is a lightweight and fast DOM-like container object that could be a good way to keep nested layers. When you ask about WMSAdapter/WMSClient are you referring to the PyOGCLib project? Yes, when J.F. and I released that I was planning to streamline the WMSAdapter code by importing pyogclib. Haven't been able to get to it yet. I'm looking forward to hearing what you think about Element. cheers, Sean -- Sean Gillies sgillies at frii dot com http://users.frii.com/sgillies |
|
From: Titus v.d. M. <mal...@cl...> - 2004-02-25 12:25:55
|
Hi!
At the moment I work in a project that makes heavy use of WMSAdapter. I
arrived at a point were WMSAdapter starts to not fulfill our
requirements anymore. Therefore I will probably invest some work the
code. (Attention: my knowledge of the OpenGIS standard is not extremely
firm) The following questions arise:
The WMS capabillities description allow arbitrarily deep neested layers
(right?) like
<LAYER ... >
<LAYER ...>
....
</LAYER>
</LAYER>
* As far as I understand the code this is not reflected in the code
that parses the layers
* the datastructure that holds the layers (WMSAdapter.layers) is a
list and is in this form not able to represent the hirarchical structure
of the layer
I now need access to this hirarchical structure and question myself how
to add this information without changing to much of the current design.
My approach would be to rewrite the code that parses the layers by code
that traverses the tree recursively and replace the list layers by a
list that holds tuples of the form
(layer, <list-of-children>),
where <list-of-children> is a empty list if there are no childen. Any
preferences / ideas?
What about this WMSAdapter/WMSClient thing? Is this historical? Are
there any plans to merge these?
Regards,
Titus
|
|
From: Sean G. <sgi...@fr...> - 2003-12-29 16:33:13
|
Hi all, Is anyone planning to go to EuroPython next year? Unfortunately, it conflicts with the MapServer Users Meeting, but I'd be greatly interested in going to Sweden to demonstrate ZMapServer. cheers, Sean -- Sean Gillies sgillies at frii dot com http://users.frii.com/sgillies |
|
From: Sean G. <sgi...@fr...> - 2003-09-08 06:46:46
|
Notes Release Name: zmapserver-0.7.5 Notes: This release fixes all known bugs. To get the most out of ZMapServer, download and apply the mapscript-4.0-patch1 (from the ZMapServer file downloads page) to your Python MapScript and make sure that you are configuring MapServer with support for threads (--with-threads). On Windows this means downloading and installing a port of the pthreads library. Changes: 0.7.5 ----------------------------------------------------------------- Fixed bugs 776050 (Mapfile export), 786378 (Unnamed classes), and 794694 (ZMapLayers of POINT type). cheers, Sean -- Sean Gillies sgillies at frii dot com http://www.frii.com/~sgillies |
|
From: Sean G. <sgi...@fr...> - 2003-09-05 14:24:03
|
On Friday, September 5, 2003, at 01:44 AM, Michael Schulz wrote: > Hi Sean, > > when you are using zmapserver on your apple, do you experience > segfaults of your zope server at all? > > I am working on a windows based zmapserver application that with the > recent versions of mapscript/zmapserver (well, 4.0/0.7.4) keeps > segfaulting, but when i start the zope server with the option to only > use one thread (-t 1) then it is more stable. > > Could it be that mapscript/zmapserver has problems with the threading > mechanisms of zope? > > Another hint i am looking into, is that your demo application is > working without problems, so it also has to do with the application > implementation. And one difference could be different ways of calling > zmapserver instance calls, e.g. i used <dtml-with> tags rather > frequent, these seemed to cause problems, after removing them the > application was more stable. Also, i am using full url's rather than > relative one's. > > I think this all has to do with the way new threads are being created, > and if that happens (perhaps in combination with the use of the > sessions) mapscript segfaults. > > Cheers, Michael > The one segfault I experience lately occurs when exporting map files. I've entered this one into the ZMapServer issue tracker. Another source of segfaults is from a bug in the MapScript exceptions wrapper code. Michael, you have this fix, but others may not. I've fixed it in the MapServer CVS and as soon as Steve Lime agrees to a 4.0.1 release, it'll be more available. Meanwhile, I really need to put a patch up on the MapServer site. As J.F. mentions in another msg, MapServer has not been certified thread-safe. I made the decision to begin with ZMapServer despite the threading uncertainty believing that MapServer would soon catch up, and I trust that MapServer will soon be made thread-safe. There are many groups (PHP, Java, mod-perl users) other than ZMapServer users, so our collective needs will be met. Meanwhile, my policy has been to use locks from the Python threading module around unsafe MapScript code (like the mapObj() constructor), and to be hopeful about the drawing code. I don't think that DTML is especially triggering thread problems any more than the TAL stuff in my demo, but I can't say for sure. Here are some other MapScript threading issues of which I am aware: If you build Python2.1 from source, threading support is not built by default (correct me if I am wrong). I cannot say whether your Python from RPM or from an ActiveState installer was configured --with-threads. I think that Python threads are a must, particularly for Zope. If you are using the Python distributed with a Win32 Zope binary, I think that you should be covered. Yes? MapServer should be configured and built --with-threads. On Win32 systems this means getting the Win32 pthreads and installing them. Unless thread support is built into MapServer, you will almost certainly experience problems with MapServer errorObjs and the MapScript exception wrappers. cheers, Sean -- Sean Gillies sgillies at frii dot com http://www.frii.com/~sgillies |
|
From: <Jea...@CC...> - 2003-09-05 13:25:56
|
Michael,
The MapServer core is known not to be officially thread safe ... That =
is,
nobody has gone through the hole code base to make sure everything IS =
...
This issue also afflicts PHP/MapScript, which is why one needs to run =
PHP as
a cgi with mapserver right now ...
I've run into segfaults using python/mapscript even outside of zope =
myself,
running regular python scripts form the command line. They are not =
easily
reproduced consistently however ... This was compiled on RH7.3 mind =
you,
don't know about windows.
I'm no good at debugging core dumps though ... Any one out there up to =
the
task ? Does windows produce an equivalent ?
My .02$ :)
J.F.
-----Original Message-----
From: Michael Schulz [mailto:ms...@we...]
Sent: Friday, September 05, 2003 3:44 AM
To: zmap-dev
Subject: [ZMapServer-Developers] mapserver/zmapserver - zope segfaults
Hi Sean,
when you are using zmapserver on your apple, do you experience =
segfaults=20
of your zope server at all?
I am working on a windows based zmapserver application that with the=20
recent versions of mapscript/zmapserver (well, 4.0/0.7.4) keeps=20
segfaulting, but when i start the zope server with the option to only=20
use one thread (-t 1) then it is more stable.
Could it be that mapscript/zmapserver has problems with the threading=20
mechanisms of zope?
Another hint i am looking into, is that your demo application is =
working=20
without problems, so it also has to do with the application=20
implementation. And one difference could be different ways of calling=20
zmapserver instance calls, e.g. i used <dtml-with> tags rather =
frequent,=20
these seemed to cause problems, after removing them the application was =
more stable. Also, i am using full url's rather than relative one's.
I think this all has to do with the way new threads are being created,=20
and if that happens (perhaps in combination with the use of the=20
sessions) mapscript segfaults.
Cheers, Michael
--=20
-----------------------------------------------------------
Michael Schulz in medias res
Dipl.-Geologe Gesellschaft f=FCr
Informationstechnologie mbH
In den Weihermatten 66
79108 Freiburg
0761 55695-95 (Fax 96)
ms...@we... www.webgis.de/www.zopecms.de
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
ZMapServer-Developers mailing list
ZMa...@li...
https://lists.sourceforge.net/lists/listinfo/zmapserver-developers
|
|
From: Michael S. <ms...@we...> - 2003-09-05 07:48:10
|
Hi Sean,
when you are using zmapserver on your apple, do you experience segfaults
of your zope server at all?
I am working on a windows based zmapserver application that with the
recent versions of mapscript/zmapserver (well, 4.0/0.7.4) keeps
segfaulting, but when i start the zope server with the option to only
use one thread (-t 1) then it is more stable.
Could it be that mapscript/zmapserver has problems with the threading
mechanisms of zope?
Another hint i am looking into, is that your demo application is working
without problems, so it also has to do with the application
implementation. And one difference could be different ways of calling
zmapserver instance calls, e.g. i used <dtml-with> tags rather frequent,
these seemed to cause problems, after removing them the application was
more stable. Also, i am using full url's rather than relative one's.
I think this all has to do with the way new threads are being created,
and if that happens (perhaps in combination with the use of the
sessions) mapscript segfaults.
Cheers, Michael
--
-----------------------------------------------------------
Michael Schulz in medias res
Dipl.-Geologe Gesellschaft für
Informationstechnologie mbH
In den Weihermatten 66
79108 Freiburg
0761 55695-95 (Fax 96)
ms...@we... www.webgis.de/www.zopecms.de
|
|
From: Sean G. <sgi...@fr...> - 2003-08-11 16:28:11
|
Greetings, WMS Adapter 0.8 is released. It's now a stand-alone product for and will not be included in future ZMapServer releases. The source for WMS Adapter will, however, continue to reside in the ZMapServer CVS. I can't spare the time to start a new CVS tree right now and WMS Adapter is also dependent upon the WMS classes shared with ZMapServer in ZMapWMS/WMS. The way I am managing WMS Adapter as a separate product is to maintain a list of files that "belong" to WMS Adapter in etc/WMSAdapter_manifest and then tag these files for WMS Adapter releases. A sh script in tools/wmsa-packager is used to create a stand-alone WMS Adapter archive from a more general ZMapServer CVS checkout. So far so good. cheers, Sean -- Sean Gillies sgillies at frii dot com http://www.frii.com/~sgillies |
|
From: Sean G. <sgi...@fr...> - 2003-08-06 19:45:41
|
ZMapServer 0.7.4
6 August 2003
Two classes of memory leaks are now plugged in ZMapServer, bringing
it closer to production readiness.
An 0.8 release is due in ~2 weeks with support for MapServer
queries and documentation.
cheers,
Sean
CHANGES
0.7.4
-----------------------------------------------------------------
This release introduces minor feature changes and major
performance enhancements.
Now that MapServer 4.0 is released, there will not be any need to
download nightly development snapshots of MapServer in order to
move ahead with ZMapServer. All future releases of ZMapServer up
to 1.0 will require only the latest stable 4.0.x release of
MapServer.
All 'draw' methods inherited from classes in ZSessionProxy have
been renamed 'session_draw'. Use of these methods remains the
same. The name 'draw' is now used for a method of the ZMap class
which returns imagery in a WMS-ish manner using the same
interface as the WMS Adapter. The goal here is to make instances
of WMS Adapter and ZMap interchangeable for Zope applications.
To clarify: session_draw() requires no arguments, it draws map
imagery as defined in the session (through setExtent() etc). The
draw() method is defined as:
def draw(self, format='', width=0, height=0, srs=0, bbox={},
layers=() )
where
format:string is an imagery mimetype supported by the map.
Defaults to the current value of
self.getSubject().outputformat.mimetype.
width:int is the image width. Defaults to the current width:
self.getSubjectAttr('width').
height:int is the image height. Defaults to current height.
srs:int is an EPSG code number like 4326. Defaults to the
current projection.
bbox:dict has floating point values for keys 'minx', 'miny',
'maxx', 'maxy'. Defaults to the current extent.
layers:tuple is a sequence of layer names in drawing order.
Note that the map is also a layer in the OGC WMS sense.
Defaults to the map: layers = (self.id,).
The performance enhancement is a result of finally tracking down
and plugging several big memory leaks. I have posted a detailed
description of the leaks and the fix at
http://mapserver.gis.umn.edu/cgi-bin/wiki.pl?PythonMapScriptMemoryLeaks
Bottom line is that you'll have to patch your MapScript wrapper
code (mapscript_wrap.c) as I describe in the Wiki page, and
re-build the Python MapScript that you are using with ZMapServer.
A more permanent fix will be included in the next MapServer
release (4.0.1). No need to patch the ZMapServer code.
With these leaks plugged, it looks like the current session map
interface defined in the classes of ZSessionProxy.py does not
need to be dropped after all.
--
Sean Gillies
sgillies at frii dot com
http://www.frii.com/~sgillies
|
|
From: Sean G. <sgi...@fr...> - 2003-07-25 00:06:14
|
Hello, I was alerted to a bug in ZMapServer's WMSAdapter.py. The bug is fixed and the new file is available through sourceforge: https://sourceforge.net/project/showfiles.php?group_id=71074 Replace the 0.7.2 WMSAdapter.py with this new file. thanks! Sean -- Sean Gillies sgillies at frii dot com http://www.frii.com/~sgillies |
|
From: Sean G. <sgi...@fr...> - 2003-07-24 15:50:05
|
Greetings, ZMapServer 0.7.2 is released and available at http://zmapserver.sourceforge.net This release includes a WMS client product, the ZMapServer WMS Adapter. I'd really appreciate reports on how the adapter works. Some changes have been made to ZMapServer to make it a more fully compliant WMS server and it now works very well with the WMS Adapter. Not that you'd want to use it this way on the same server. The WMS adapter is also available as a stand-alone product which does _not_ require MapServer or Python MapScript. If you are a WMS map provider, this will be a great product for your Zope-using customers. It's quite useable, but I'd like to add a few more features before I release it to the Zope community. The stand-alone is called 'wmsadapter' and is available through the same sourceforge download page. Two WMS map providers have granted permission to offer their map services as starting points for new users. Thank you Dante Fuster (REPSAT SAC) and Daniel Morissette (DM Solutions). DM Solutions led MapServer to OGC WMS compliance and their service is the seminal MapServer WMS service. BTW, posting the news of ZMapServer 0.7.0 to zope.org had great results. There was a huge spike in site visits and downloads, with the result that my zope.org members site is now the first result returned by a Google search for 'Python GIS'. Wow. cheers, Sean -- Sean Gillies sgillies at frii dot com http://www.frii.com/~sgillies |
|
From: Michael S. <ms...@we...> - 2003-07-18 08:17:56
|
Hey Sean,
i am not sure at all if Ullrich has the power this year to turn it on. He was
sacked from the Team German Telekom because he was trying to improve his
power be illegal means ;-) (and he also was caught driving drunk in his
Porsche smashing a bunch of 12 bicycles!!). Then he was banned nearly one
year. Now he finally landed in the team Bianchi, well the team might be not
so strong, but Ullrich is anyhow pretty strong (rank 6 at the moment). Ok,
stop.
Is a new (aka MS 4.0 beta 2) mapserver required for the new zmapserver? If
not, it is no bother at all. I'll go ahead and tell you when i am ready.
> I think the three areas of development would be:
>
> - zmap instances including WMS server
> - WMS adapter instances
> - zmap session
ok, that sounds good.
> The client area will be my focus for the near future.
That is the WMS adapter instances, right?
> I'd also love to discuss how we might change the session framework
> so that it incorporates the WMS adapter.
Yep. I will have to look at all the code first, before i dare start
discussing, but soon...
> What do you think about
> reducing the scope of our session framework so that the session
> only holds map extent? Currently, keeping a MapScript mapObj
> in the session data manager results in memory leaks. We could
> cut down or eliminate the leaks by simply storing extents in the
> session data.
Is the Session Data Manager the problem, or the type of the mapscript object,
or what? What makes it so different from other objects hold in it? Its
swigging origin?
> Hope all is going well in Freiburg. June was cool and wet in
> Colorado, but now summer has arrived. It is consistently 35+
> every day and no measureable rain in almost two weeks!
Same here, we are currently flooding our office because of the heat ;-))
Cheers, Michael
PS.: BTW, the python mapscript mdp howto has finally turned up and is on the
cvs 3.6 branch. It is outdated now, but it may be a starting point. I hope we
will soon have a version for MS 4.0.
--
-----------------------------------------------------------
Michael Schulz in medias res
Dipl.-Geologe Gesellschaft für
Informationstechnologie mbH
Sautierstr. 38, 79104 Freiburg
0761 55695-95 (Fax 96)
ms...@we... www.webgis.de
|
|
From: Sean G. <sgi...@fr...> - 2003-07-16 17:14:50
|
Hi Michael, Do you follow bike racing? When is Ullrich going to turn it on? And why did he leave Telekom? It seems like Bianchi is not so strong. OK, back to the web and maps :) I am going to weave my response into yours below: On Friday, July 4, 2003, at 08:04 AM, Michael Schulz wrote: > Dear Sean, > > thank you very much for the ZmapServer presentation, that as far as i > could see from your slides, looks really interesting and also puts the > ZmapServer Product in its appropriate position. > > I have read your mail over and over again and your ideas sound very > promising. I agree with you, that in order for ZmapServer to be a > competitive player in the MapServer Interfacing League (like MapLab or > so) the OGC WMS compatibility is crucial. > > I think your idea of creating a WMS class that would act like Zope DA > is > great and also goes in a similar direction like the data layer object > seperate from the zmap instance that you thought of a while ago. > Implementing this to work with zmap instances would be a good step in > separating data administration, map administration and web layout > tasks. > I am starting to get serious about the WMS adapter classes this week. This could be really exciting, because it will make it possbile for Zope programmers to begin to access WMS services for map content without having to know anything about MapServer! The WMS adapters will behave as much as possible like a ZMap instance so that site developers can treat them identically. To begin, this means that a WMS adapter instance will have a draw() method. > It seems to me that in your proposal you stress very much the OGC WMS > Client features (i.e. connecting to distant WMS servers, using their > data, etc.). But i think also very relevant are the features of a > ZmapServer (?) / WMS server class that has WMS serving capabilities, in > order for distant servers to include your own WMS layers and to be able > to provide cascading WMS capabilities. ZMapServer 0.7 is a OGC WMS 1.1.1 server. The next few (0.7.2+) releases will add some backwards compatibility to earlier WMS versions. Is there any chance you'd be willing to delete the stuff you have on www.zopecms.de:446/map_test and replace it with the stuff from zmapserver 0.7.1? > To come back to the Zmap/Zsession classes. I think it important to have > a fully functional zmap interface, that is, being able to provide the > complete map instance editing capabilities over the ZMI, thus through > the web (with all the Zope security and roles management stuff these > are > features that other mapping TTW interfaces or CMSs hardly can provide). > If this is achieved we would already have thorough WMS serving > capabilities. I think you are right, that the ZmapSession Object is > already at a reasonible functional level. > >> From this point it would be really good if we can specialize certain > features and seperate them to form individual classes with individual > functionality. > > Perhaps we should think of working simultaneously in three branches > (more crosses more important at the moment in my opinion): > - zmap instances development +++ > - zmapSession development + > - WMS instance development ++ > > Ok, that's my 2 ct. > > Cheers, Michael > I think the three areas of development would be: - zmap instances including WMS server - WMS adapter instances - zmap session The client area will be my focus for the near future. I'd also love to discuss how we might change the session framework so that it incorporates the WMS adapter. What do you think about reducing the scope of our session framework so that the session only holds map extent? Currently, keeping a MapScript mapObj in the session data manager results in memory leaks. We could cut down or eliminate the leaks by simply storing extents in the session data. Hope all is going well in Freiburg. June was cool and wet in Colorado, but now summer has arrived. It is consistently 35+ every day and no measureable rain in almost two weeks! cheers, Sean -- Sean Gillies sgillies at frii dot com http://www.frii.com/~sgillies |
|
From: Sean G. <sgi...@fr...> - 2003-07-15 00:25:24
|
New release which fixes some bugs and implements some new code from Grit Schuster. It's a must for anyone who wants to try management of class labels. CHANGES 0.7.1 ----------------------------------------------------------------- Release to fix bugs and expand ZMapReference functionality. We've put in the missing ZMapStyle property management form, fixed crashing when managing ZMapLabel objects in the case that the parent ZMap has no defined fontset, and now a new ZMap automatically sets its WMS_SRS property. New functionality for the reference map is a method named 'transformPixel'. It works exactly like the ZMap method of the same name, except that it operates with the extents and image size of the reference map rather than the main map. |
|
From: Sean G. <sgi...@fr...> - 2003-07-09 03:39:18
|
Greetings, Released a new ZMapServer today. Here are the release notes and change log. ZMapServer 0.7.0 8 July 2003 ZMapServer 0.7 is an OGC 1.1.1. WMS Server. This is the first step in our new direction for the application. The previous session map interface remains, but will be changed in the near future to be more WMS-friendly. CHANGES 0.7 ----------------------------------------------------------------- ZMapServer 0.7 is an OGC 1.1.1 WMS Server, implementing GetCapabilities and GetMap operations. This new release will break existing ZMap instances and so you will need to delete existing ZMapServer Maps. While you are at it, import the new demo from Demo.xml (see full instructions in demo/README.TXT). The new demo includes a page that will get you started with the new WMS server features. We have also fixed the dbflib import bug. No fixes have yet been made to the Session Map interface's memory leaks. |
|
From: Michael S. <ms...@we...> - 2003-07-04 14:07:40
|
Dear Sean,
thank you very much for the ZmapServer presentation, that as far as i
could see from your slides, looks really interesting and also puts the
ZmapServer Product in its appropriate position.
I have read your mail over and over again and your ideas sound very
promising. I agree with you, that in order for ZmapServer to be a
competitive player in the MapServer Interfacing League (like MapLab or
so) the OGC WMS compatibility is crucial.
I think your idea of creating a WMS class that would act like Zope DA is
great and also goes in a similar direction like the data layer object
seperate from the zmap instance that you thought of a while ago.
Implementing this to work with zmap instances would be a good step in
separating data administration, map administration and web layout tasks.
It seems to me that in your proposal you stress very much the OGC WMS
Client features (i.e. connecting to distant WMS servers, using their
data, etc.). But i think also very relevant are the features of a
ZmapServer (?) / WMS server class that has WMS serving capabilities, in
order for distant servers to include your own WMS layers and to be able
to provide cascading WMS capabilities.
To come back to the Zmap/Zsession classes. I think it important to have
a fully functional zmap interface, that is, being able to provide the
complete map instance editing capabilities over the ZMI, thus through
the web (with all the Zope security and roles management stuff these are
features that other mapping TTW interfaces or CMSs hardly can provide).
If this is achieved we would already have thorough WMS serving
capabilities. I think you are right, that the ZmapSession Object is
already at a reasonible functional level.
From this point it would be really good if we can specialize certain
features and seperate them to form individual classes with individual
functionality.
Perhaps we should think of working simultaneously in three branches
(more crosses more important at the moment in my opinion):
- zmap instances development +++
- zmapSession development +
- WMS instance development ++
Ok, that's my 2 ct.
Cheers, Michael
--
-----------------------------------------------------------
Michael Schulz in medias res
Dipl.-Geologe Gesellschaft für
Informationstechnologie mbH
Sautierstr. 38, 79104 Freiburg
0761 55695-95 (Fax 96)
ms...@we... www.webgis.de
|
|
From: Sean G. <sgi...@fr...> - 2003-06-24 14:58:13
|
Hello, Sean here. I am just back from a short vacation to the San Juan islands of Washington. So peaceful and civilized, must be the proximity to Canada, eh? :) I did not bring my computer on the trip and took the opportunity, while biking and kayaking, to finally digest all the presentations, workshops, and conversations which I experienced at the 1st MapServer Users Meeting two weeks ago. I've concluded that ZMapServer needs another change of direction if it is going to be useful to the MapServer community, and I want to now outline a proposal for this change. Hearing from J-F Doyon, Daniel Morisette, Ed McNierney, and others has convinced me that, in order to be relevant, ZMapServer needs to be very aware of the OGC's WMS specifications. I have been keeping this in mind, but now feel that we should probably stop work on the code in ZSessionMap.py and instead, focus on making ZMapServer an excellent product for creating WMS Server instances. I think that the ZSessionMap stuff could have a better future as separate group of classes for applications that connect to WMS servers. To complement the ZMapServer Map, I propose a new Z WMS Adapter class to provide a convenient interface to external WMS Services. I think of it as being sorta like a Zope Database Adapter. Would be very helpful for collecting, managing, and cataloging WMS. Below is a small illustration: |
