zmapserver-developers — ZMapServer Developers List

[ZMapServer-Developers] Map data

[Kai <kai...@mb...>]

Hello everyone

I have couple of questions concerning some publicly available map data.

I was looking into the world_borders data available from
http://www.mappinghacks.com/data/ which is used in the ZCO demo also and
I noticed some weird renderings that might indicate corrupted data. See
http://www.technocore.fi/~dokai/world_borders_corrupted.png for a
rendering of Europe. As you can see Norway and Finland aren't rendered
properly. Could this be due to some misconfiguration on my part or do
you think there could be something wrong with the data?

I was also looking into the VMAP0
(http://www.mapability.com/info/vmap0_index.html) data which seemed good
to me. I also found out that converting the data to a usable format by
mapserver (preferably shapefile) takes quite a bit of effort, so I was
wondering if anyone here would have the data (the eurnasia section would
do nicely) already converted that I could use?

cheers,
Kai

=20
--=20
Kai H=E4nninen                  mobile:+358-44-541 9567
Software engineer             www.mbconcert.fi
MB Concert Ky                 kai...@mb...

[ZMapServer-Developers] Fwd: Archetype wrapper products for ZCO

[Sean G. <sgi...@fr...>]

Begin forwarded message:

> From: "Moisan Yves" <ym...@gr...>
> Date: April 27, 2005 12:52:18 PM MDT
> To: "Sean Gillies" <sgi...@fr...>
> Subject: Archetype wrapper products for ZCO
>
> Hi Sean,
>
> Please forward to ZMapServer-developers.  IT promised they would try to
> find out why I can't email directly to the list ...
>
> Thanx
>
> Yves
>
> Hi All,
>
> This is a call to arms for all those ZCO developers who want to have a
> sharp and slick mapping interface in Zope/Plone.
>
> I would like to propose my view of sample content Archetype wrapper
> products to Sean's ZCO so that Zope/Plone users can have their own map
> profiles and all the nifty things a CMS is supposed to provide.  Some 
> of
> you may recognize my pet applications, but I tried to keep the subject
> matter as general as possible.  I would *really* appreciate feedback
> from the community and I would also like to know if people are doing
> some stuff in their basements with ZCO that I (we !!) could leverage 
> on.
>
> IMO, PCL 0.8.1 + ZCO 0.5 is pretty mature.  Of course there will be
> stuff to connect to postGIS and certainly other nifty stuff (e.g. being
> able to use another rendering backend, such as Agg or Matplotlib/Agg)
> coming along but for all intents and purposes I believe Sean's work has
> all that's needed in terms of basic map display in Zope.
>
> With the upcoming release of Plone 2.1 with all content types being AT
> (ATCT) and with the current impetus among AT developers to bridge the
> gap with Zope 3, I think AT (not CMF) is the way to go to develop
> content objects.  CPS/Silva developers, speak up if that doesn't work
> with you!
>
> What I am interested in are 3 AT products (names are only suggestions) 
> :
>
>
> - GeoDataContainer,
> - GeoDataObject (or GeoDataDocument ?),
> - OGCMapContext
>
> The scope of this email is about *content* types, that is things people
> will work with TTW in the Plone interface.  For example, people will
> want to add a new station, or a new GPS point, or a new Map Context
> document etc.  I don't think there should be a "map" AT product to wrap
> a MapRenderer, for example (but I may be wrong, especially if one uses
> somtehing like CMFContentPanels to brush up a collection of products in
> one nice UI).  Also, things like layers visible as a function of scale
> won't be controllable in the content space (only through ZMI).
>
> The basic mechanism I see for now is that AT content products would
> override the attributes necessary for ZCO to work (e.g. bbox, layers
> ...).  Controls over actual map generation and viewing space (map view,
> choice of layers, zooming/panning, automatic legend generation ...)
> would be thru-the-ZMI.
>
> ==== GeoDataContainer ====
>
> Purpose : provide a general geodata container.  The definition of
> containment for such an object would have to rely on some bbox or some
> WKT representation : we are talking about geographical containment 
> here,
> although it would be paralleled in the CMS as a mere object 
> containment.
>
> Use Case :
>
> - for content developers (ContentAdmin, see Glossary below): derive 
> from
> this object, e.g. to get a Watershed object; contained objects could be
> other instances of GeoDataContainer (e.g. for a "SubWateshed") in which
> the bbox (and other attributes ??) could be overridden;
>
> - add GeoDataObject instances (see below), e.g. point measurements,
> station locations, etc; there should be validation to make sure such
> GeoDataObject instances are within the WKT or bbox defined by the
> container object.
>
> Implementation :
>
> - derive from the base folder schema (option of a BTreee folder ??) and
> add a bbox string attribute (and other attributes ??); maybe a WKT
> representation would be better than a bbox, like Sean mentioned in an
> earlier email; in that case we would need to provide either a simple 
> WKT
> edit form or else allow uploading vertex data from a shapefile thru OGR
> ??  MapRenderer would use WKT to derive a bbox automatically.
>
> ==== GeoDataObject ====
>
> Purpose : provide a general geodata object.  Would be contained in a
> GeoDataContainer (or could be independent ??)
>
> Use Case :
>
> - for developers : derive from this object, e.g. to get a
> "PointMeasurement" or a "StationLocation" or whatever.
>
> "Add GeoDataObject" or a derived object would prompt the user with an
> edit form with potentially FGDC metadata info ...
>
> Implementation :
>
> - derive from the base document schema and add a bbox or WKT string
> attribute
>
> ==== OGCMapContext ====
>
> Purpose : Provide an object (folderish ?) to hold one's mapping
> preferences.
>
> Following index_html and especially mapping_html from Sean's ZCO demo
> folder where the page templates are calling themselves upon form
> submission and showing some default layers if selected_layers == None,
> we could just add a TAL condition to check for the existence of a
> context document upon first form post (not upon postback though ...).
> The resulting UI effect could be that all layers are shown and only
> those in the context document are ticked on.  The user can always tick
> layers on/off and zoom/pan away, but the default would come from some
> context.  We could even show a dropdwon of all available context
> documents so that predefined set ups could be readily available to 
> users
> (e.g. inherit one from their group membership for example).
>
> Independent of GeoDataContainer ??  Maybe but not of the general 
> mapping
> context of the application, defined by the available ZCOLayers etc.
>
> NOTE : "context" now replaces "here" in TAL expressions, so we should
> refrain ourselves from talking about "context" documents ...
>
> Use cases :
>
> - users could "Add OGCMapContext" in their member folder; they would be
> prompted an edit form to add all relevant information : bbox, layers (a
> dropdown list based on SiteAdmin choice of layers), title ?.
>
> - users could copy/paste such documents to some accessible directory 
> for
> other users to go fetch it (or just point to it) or somehow share it
> through group membership
>
> - users could edit their OGCMapContext (but beware of overriding
> previous versions of the object : maybe some Plone version product 
> could
> be used here)
>
> - users could eventually export their OGCMapContext documents as an XML
> OGC context document (maybe we could build on Zope's export as XML
> functions here, modulo an XSLT transform ??)
>
> Is there a need for a ZCOMapContext object ?  I don't think so, since
> defining a context just means overriding bbox and layers (symbols?).
> There is definitely a need to keep session information to allow a user
> to "Save Current Mapping Context" though.
>
> Implementation :
>
> - derive from the base document schema and add a bbox or WKT string
> attribute and a layer string attribute; do we want to provide layer
> ordering options as well (e.g. "Add New Layer" would add a new layer
> string attribute and it would be a matter of calling ZCO with a string
> concatenation of those layers in the order specified by the user) ??
> For now, I would tend not to do that and basically let the user choose
> the layers they want as it is currently done in index_html, which would
> store the concatenated string.  Same is true for Symbols : in the short
> term, I would not give the user the possibility to upload whatever PNG
> they want to represent a station or a geological cross section : 
> symbols
> should be accessible from the SiteAdmin only (ZMI).  Allowing full
> control over one's symbols and map layout falls in the realm of desktop
> apps IMO.
>
> ==== Zooming/Panning Utilities : Javascript ! ====
>
> We need a nifty zoom/pan interface.  Where are those JavaScript
> experts??  All we would need is to call the zoomMap/shiftMap Python
> Scripts found in Sean's demo with JS.  Should be easy right ??  Sean
> proposed a look ala Google Maps (with all pan directions grouped in the
> top left corner).  A zoom slider would be neat to : it would be a 
> matter
> of calling zoomMap with a zoom factor.
>
> I tried playing with Javascript in the <head> of a ZPT, but I found out
> that using the Plone machinery to render (e.g. fill-main) effectively
> bypasses any information in the <head> of any particular ZPT.  I found
> that out when I tried to add a <style> in the <head> : it wouldn't
> render and I had to put it in ploneCustom.css for it to work; same 
> holds
> true for JS in Plone, but I don't know where to stick it : somebody on
> this list must know!.
>
> ==== Data Access Utilities : AJAX !? ====
>
> Clicking on a point, we need to have a means of outputting some
> attribute data or calling in some simple data visualisation goodies
> (tables, plots ...).  I don't know how to tie this in yet, but we need
> to think of some framework.  AT provides an alternate storage mechanism
> so data could be stored in a postGIS back end for example so we would
> need an AJAX strategy to fetch data from such a backend (that is get 
> the
> data without having to redraw the map).
>
> Since Plone 2.1 will ship with Kupu as a default editor and since Kupu
> heavily relies on AJAX (Asynchronous JavaScript And XML) to work, there
> should be ample example code to implement an AJAX solution for data
> retrieval.
>
> ==== Action plan ====
>
> I can take on AT development (at least set the wheel turning!) unless
> someone has stuff I can build upon.  It would be great if other folks
> could take Zooming/Panning Utilities and Data Access Utilities.  I 
> guess
> the former can be readily addressed, but I don't know about the latter.
> IMO, a nice zooming/panning experience is key in promoting Sean's nice
> work.  It would be nice if we had some repository for code so that
> Sean's demo site (or any one else's) can show it off.
>
> So, what is going on out there with you ZCO developers.  Does this make
> sense ?
>
> Thanx for your comments !
>
> Yves Moisan
>
>
> ==== Glossary ====
>
> ContentAdmin : user has edit control over all the content space, but no
> ZMI access (??)
>
> SiteAdmin : ContentAdmin + ZMI access (e.g. to play with ZCO objects
> directly)
>

[ZMapServer-Developers] Fwd: Wishlist for a PZP mapping product

[Sean G. <sgi...@fr...>]

Forwarded from Yves Moisan ...

Begin forwarded message:

> From: "Moisan Yves" <ym...@gr...>
> Date: April 20, 2005 1:51:45 PM MDT
> To: "Sean Gillies" <sgi...@fr...>
> Subject: Wishlist for a PZP mapping product
>
> Hi Sean,
>
> Please bounce this email to the ZMapServer list (I still can't post to
> the damn list !!).
>
> This email is intended to give a perspective (mine!) on what a web
> mapping application based on the PZ(P) platform could be.  PZP stands
> for Python/Zope/Plone and I deliberately put the Plone "P" in
> parentheses to show that it should be replaceable (by CPS, Silva ...).
> My immediate concerns for an end product is Plone, though, and I will
> sometimes refer to Plone in this email.
>
> To summarize, the aim for me is to get something like Chameleon in 
> terms
> of functionality, as fast as Google Maps and that provides a good
> collaborative environment.  IMO, the latter two are not strong points 
> of
> Chameleon, but I may be wrong because I have not developed any
> application using Chameleon.  A definite strong point of PZP is the
> collaborative environment.  As to the speed, the AJAX (Asynchronous
> Javascript And XML) model used by google Maps is used in some parts of
> the Plone UI (namely when the Kupu editor ships as the default editor,
> in Plone 2.1 due in about 4 weeks) but it is not a definite advantage 
> of
> the PZP platform : it could be built into Chameleon as well.
>
> Of course, it's an ideal, but my increasing experience in the PZP world
> suggests that it is attainable.  I'll try to point some development
> ideas to meet that requirement.  Please bear in mind that I am not a
> hardcore developer as Sean is.  Accordingly take any development ideas
> with a grain of salt especially when it comes to practical
> considerations!
>
> Let's take this typical Chameleon app and get started : point your
> browsers at
> http://cgdi-dev.geoconnections.org/prototypes/owsview/index.html.
>
> I'll mention what I like and don't like about that site in general
> (sometimes haphazard) terms and, from that, I will propose development
> paths that I would favor.  I don't claim to review each and every 
> aspect
> of that site's functionnality and you may find that I've forgotten to
> mention this or that.  Of course, feel free to answer this email and
> voice your opposition or approval!
>
> ==== What I like ====
>
> - Arbitrary layer addition : Although I am not very impressed at the
> "SLD" and "SCS" buttons (maybe 'cos I don't know intuitively what to do
> with them), it is relatively straightforward to add a OWS layer (WMS
> only ?).  I am not sure I would make that a top requirement to let the
> user use any OWS layer they wish because I am not sure such latitude
> really belongs to a web application. To me, it belongs more to desktop
> apps like uDig or Thuban but the line is blurring more and more between
> web apps and desktop apps in the context of OWS.  But still, being able
> to add arbitrary layers is interesting.
>
> - Layer order selection : playing with the blue arrows; self explained
> but beware to press on the "delete layer button" no undo around !  BTW,
> a tooltip would be useful here : the only way to know what a button 
> does
> is to look in the left bottom corner of the browser and deduce from the
> name of the Javascript function called ...
>
> - Load and save context
>
> - Lat/lon position instantly refreshed : should be a default feature of
> any map
>
>
> ==== What I don't like ====
>
> - it's slow (although "zoom to previous view" is fast)
>
> - a bunch of functionnality is not intuitive (e.g. "apply time query to
> maps", Add feature button, SLD button : where does the SLD definition 
> go
> ??)
>
> - some functionality adresses more technical points : does the user 
> have
> to see details of a WFS response or EPSG codes ?  Certainly not the
> casual user.
>
> - "zoom to region" doesn't stay at current predefined zoom (e.g. when
> you zoom to Canada, the dropdown list should be there)
>
> - zoom/pan not very good (although this is a better chameleon app
> zoomwise :
> http://www.ontariowatersheds.ca/htdocs/viewdata/public/view_wq.phtml )
>
> - context map (bottom left) : not sure what its use is really but 
> that's
> a matter of taste; could be useful if the scale of the context map
> changed as a function of zoom level in the main pane : for fun, zoom to
> Canada and zoom in 4-5 times : the context map ends up with a red cross
> showing a collapsed polygon
>
> - graphic rendering : try asking for political bounadries only for the
> world, it's awful; even worse when you show political boundaries and 
> ask
> a "Zoom to region = Canada" !  but wait : ask for political boudaries +
> coastlines and you get something more like it should be ...  Still, not
> very nice to look at.
>
> - windows popping up all the time : my personal preference would be to
> show the info in some left/right/bottom pane; I hate to keep closing
> windows all the time
>
>
> ==== Preferred development directions ===
>
> Given we are in the realm of a web application, I would tend to favor
> the following development axes :
>
> - zoom to predefined regions : easy with PZP (set some bbox attribute);
> but can we think of an actual Zope (AT) content type, probably relying
> on one attribute of a more general WMC content type ?  For example, the
> "Canada" instance of such a WMC content type could be a stripped out
> instance with just a bbox attribute.  I would make it a content type
> instance so we can use it's bbox attribute from anywhere in the Zope
> site and override the bbox using some WMC content type instance 
> "closer"
> in the acquisition path (e.g. the member's WMC document instance).
>
> - easy way of shuffling layers around (orderwise)
>
> - easy way of saving one's current mapping options/preferences/styles 
> in
> the form of a context: in the PZP world, we can even think of having 
> WMC
> content objects (Archetypes for now, Zope 3 schema in the mid term) 
> that
> could potentially inherit from some user group setting and that could
> even be shared between users : just copy and paste!  I think this is a
> major selling point for the PZP platform for any collaborative work
> environment : people can share their contexts; I even think of 
> extending
> the context idea to things like reporting tools (e.g. data plots) but
> that is beyond the Web Mapping application per se.
>
> - find* : the Chameleon site allows one to find some placename, or some
> watershed number or some postal code and zoom to it; that's a pretty
> general find functionality IMO; however, given a PZP context with
> georeferenced objects (e.g. some Zope or Plone objects having some geo
> attribute attached to them), giving access to "find arbitrary Zope
> object" (would have to be labeled differently of course for users) 
> would
> be one heck of a plus; in a PZP context, a "layer" could be merely a
> "geo-enabled content type".  If I take the example of petrol stations
> that popped up on this list a while back, making an actual AT content
> type to represent such an object and inheriting from some more general
> schema definition for a "georeferenced" content type could do the trick
> : all objects of a given geo-enabled content type could be treated as
> findable (and queryable) objects; thinking out loud, I think we need a
> fairly general schema that we can use to extend arbitrary content types
> to become geo-enabled; if people look at the Article.py file in the
> Archetypes products directory, one sees it inherits the "id" and "name"
> fields from a base object schema and adds it's own peculiar fields; the
> same could be done to geo-enable objects (although there would be a 
> need
> to define view and edit widgets!)
>
> - query attributes : it should be easy to select a queryable layer and
> ask for data in given spatio-temporal bounds; the requirements would
> have to be detailed a bit more here though (e.g. plot the data, put it
> on a FTP site for user download ...); this is where AJAX comes into 
> play
> : we want the site to be swift!
>
> - data upload : in the PZP context, that would probably mean allowing
> users to create content type instances (e.g. a new 'petrol station')
> with the help of the map, e.g. by letting the user georeference his
> content instance by optionally clicking in the map; I think the holy
> grail in the PZP world is to have content types for everything and
> actuallt store objects (even if the storage of those objects could be a
> postGIS backend, something possible using Archetypes); possible uploads
> : points ('petrol station', 'measurement', 'way point' ...), polygons
> ('watershed', 'administrative region', ...); both points and polygons
> could take input from the web map, but I would favour uploading 
> polygons
> from the filesystem.
>
> ==== Interesting, though not top priority, development paths ====
>
> - panning (it's nice to have a responsive pan as in Google Maps, but I
> think this is a quality people expect of a desktop GIS mainly; although
> heck Google Maps is faster than ArcGIS !!)
>
> - arbitrary layer addition : again, not sure we want a "uDiged" web app
> ??
>
> - arbitrary style edition : web users can live with some defaults
> (however site managers should have easy means of setting styles, e.g.
> point symbol for a petrol station)
>
> - digitize : could be interesting for people to upload arbitrary paths
> or polygons, but again IMO that belongs more to a desktop app OR to a
> site admin (e.g. upload a shapefile)
>
> - measure distance : the scope of the type of web apps I care about 
> does
> not include things like routing and commute time from point A to point
> B; this is stuff for MapQuest and Google Maps IMO
>
>
> At this point, I think we need experienced Archetypes people to speak
> up.  What would be an appropriate AT abstraction of a ZCO Layer object?
> Do we need such an abstraction or should content types be limited to
> objects that use ZCO objects and attributes?  Plone 2.2 (due out this
> Fall) will include Zope 2.8 and Five (see glossary below).  IMO,
> geo-enabled content types should be based on the schema model both AT
> and Zope 3 follow (for an interesting and very short article on Zope 3,
> see http://www.linux-magazine.com/issue/54/Zope_X30_Review.pdf).  What
> do people on this list think?  Are we all interested by some sort of a
> merge between GIS, the Web and data analysis tools ameanable to
> collaborative development ?
>
> Cheers all!
>
> Yves Moisan
>
> ==== Short glossary ====
>
> AT = Archetypes : the now default way to define new content types in
> Plone (and to a lesser extent in CMF : there's also CPS Schemas); the
> point is that content types are now preferably defined by a descriptive
> "schema" where one defines the name type, widgets etc. of individual
> fields; the sum of those fields forms the new content type.  Zope 3 
> uses
> its own schemas to define content types and there are activities
> underway to map AT schemas to Zope 3 schemas.  IMO, this is crucial
> because Zope 3 is the future of Zope (see "Five" below).
>
> Five : Five is 2 + 3, that is Zope 2 + Zope 3.  Five is a product that
> allows one to have *both* Zope 2 and Zope 3 running at the same time 
> and
> therefore one can use (some of) the Zope 3 machinery from a Zope 2
> application like Plone.  As of Zope 2.8, Five will be shipped in the
> Zope core AFAIK.
>

Re: [ZMapServer-Developers] ReferenceMap

[Sean G. <sgi...@fr...>]

On Apr 13, 2005, at 8:41 AM, Florian Edelmaier wrote:

> Hi list!
>
> Because we need a reference-map for our application, we extended the 
> PCL-0.7
> source code:
> to manage this, we added a 'createRefMap'-function in
> cartography/engine/mapserver/mapserver.py and extended 
> cartography/mapping.py
> for a ReferenceMap class. These functions are close to the 
> mapscript-attributes
> and far from intention of independent use of map-engines. Has anyone 
> better
> sugestions for implementing a refernce-map? If someone want's to 
> improve the
> code, please tell us about the changes.
>
> florian & michael
>

Hi Florian and Michael,

Thanks for the contribution.  I'm curious to see what kind of 
application you are making of PCL.

My intention for reference maps has been to not use new classes at all, 
but simply treat the reference map as another small map:

1. create a raster data store using a small GeoTIFF or georeferenced 
JPEG, and wrap in a Layer
2. Use an in-memory feature store to hold the main map's view as a 
rectangle
3. Define a polygon symbolizer for the main map's view
4. Draw these two layers to an image using a PCL map renderer

The reason why I want to avoid any more MapServer/mapscript specific 
code is that I am considering a new mapping engine for PCL based on 
matplotlib + Agg and/or Agg by itself.  See the most recent posts on my 
news site for an example:

   http://zcologia.com/news/

Keeping all the mapscript use behind the 
engine.mapserver.rendering.MapRenderer will make it easier to write 
engine-independent code for PCL.

Back to the idea of a reference map class for PCL ... I want to make it 
easy to make reference maps and scalebars, but I don't think that such 
classes really fit in well with PCL.  I want PCL to remain at a 
slightly lower level.  The ZCO project, which extends PCL for use with 
Zope, is an example of where I think reference map and scalebar classes 
belong -- at the application level and not the library level.

cheers,
Sean


> #### mapserver.py: ###########################################
> def createRefMap( mapSize, mapExt, srs, img, refSize, refExt, imgType 
> = 'PNG'):
> 	"""Draw Reference Map"""
> 	mo = mapscript.mapObj()
> 	# set map-attributes
> 	mo.setSize(  mapSize[ 0 ], mapSize[ 1 ] )
> 	mo.setExtent( mapExt[ 0 ], mapExt[ 1 ], mapExt[ 2 ], mapExt[ 3 ] )
> 	mo.setImageType( imgType )
> 	mo.setProjection( 'init=%s' % srs )
> 	# set refMap-attributes
> 	mo.reference.image = img
> 	mo.reference.width = refSize[ 0 ]
> 	mo.reference.height = refSize[ 1 ]
> 	mo.reference.extent.minx = refExt[ 0 ]
> 	mo.reference.extent.miny = refExt[ 1 ]
> 	mo.reference.extent.maxx = refExt[ 2 ]
> 	mo.reference.extent.maxy = refExt[ 3 ]
> 	# box-attributes are default
> 	mo.reference.outlinecolor.setRGB( 255, 0, 0 )
> 	mo.reference.color.setRGB( -1, -1, -1 )
> 	# draw image
> 	im = mo.drawReferenceMap()
>
> 	image = mapping.Image()
> 	#for the upcoming mapserver function
> 	if hasattr(im, 'getBytes'):
> 		image.data.write(im.getBytes())
> 	else:
> 		im.write(image.data)
>
> 	image.size = [im.width, im.height]
> 	image.mimetype = im.format.mimetype
>
> 	del im
> 	del mo
> 	return image
>
> ### mapping.py: ##################################################
> class ReferenceMap:
>
>     """ReferenceMap from createRefMap() in mapserver.py
>
>     Attributes
>     ----------
>     mapSize : list
>         image.width, image.height of map
>
>     mapExt : list
>         map bounding box like '[xmin, ymin, xmax, ymax]'
>
>     srs : string
>         like: 'EPSG=31294'
>
>     img : string
>         path to image-object like 'context/irmi/img/...'
>
>     refSize: list
>         image.width, image.height of ReferenceMap
>
>     refExt : list
>         ReferenceMap bounding box like '[xmin, ymin, xmax, ymax]'
>
>     imgType : string
>        default is 'PNG'
>
>     """
>
>     def __init__( self, mapSize, srs, img, refSize, refExt, imgType = 
> 'PNG' ):
>         self.__mapSize = mapSize
>         self.__mapExt = []
>         self.__srs = srs
>         self.__img = img
>         self.__refSize = refSize
>         self.__refExt = refExt
>         self.__imgType = imgType
>
>     def draw( self, mapExt, refExt=None ):
>         self.__mapExt = mapExt
>         if refExt:
>             self.__refExt = refExt
>         ref = engine.mapserver.mapserver.createRefMap( self.__mapSize,
> self.__mapExt, self.__srs,
>                                       self.__img, self.__refSize, 
> self.__refExt,
> self.__imgType )
>
>         return ref
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real 
> users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> ZMapServer-Developers mailing list
> ZMa...@li...
> https://lists.sourceforge.net/lists/listinfo/zmapserver-developers
>
>
--
Sean Gillies
sgillies at frii dot com
http://users.frii.com/sgillies

Re: [ZMapServer-Developers] Render a .map with PCL 0.7 / ZCO 0.4

[Sean G. <sgi...@fr...>]

It is not currently possible to load a mapserver map file into ZCO.  I=20=

have some ideas on how it can be done, but I have no immediate plans to=20=

do anything about it until I have a customer that really needs this=20
feature.

Sean

On Apr 12, 2005, at 9:34 AM, S=E9bastien Didelet wrote:

> Sean,
>
>  Excuse me to disturbing you, but I'm not sure to understand. If I=20
> have a .map file to render, I won't be able to do it with ZCO ? I have=20=

> to develop a zope module to allow end user to add there .map file to=20=

> this module. If I cannot, I will do it using zmapserver.
>
>  Cheers,
>  Seb
>
> On Apr 12, 2005 5:05 PM, Sean Gillies <sgi...@fr...> wrote:
> Seb,
>
> ZCO doesn't use MapServer map files.=A0=A0Please read the ZCO user =
manual
> that you can find from a link on this page:
> http://zmapserver.sourceforge.net/
>
> Sean
>
> On Apr 12, 2005, at 8:57 AM, S=E9bastien Didelet wrote:
>
> > Sean,
> >
> >=A0=A0How can I render a .map file ? I don't understand what I have =
to do
> > ... Is there any ZCO documentation ?
> >=A0=A0An other question ... Do you know where can I find .map files ?
> >
> >=A0=A0Seb
> >
> > On Apr 12, 2005 4:35 PM, Sean Gillies <sgi...@fr...> wrote:
> > Seb,
> >
> > You can not use a MapServer map file like this with ZCO.=A0=A0ZCO =
Data
> > Stores must point to shapefiles, raster images, or WMS services.
> >
> > Sean
> >
> > On Apr 12, 2005, at 8:27 AM, S=E9bastien Didelet wrote:
> >
> > > Sean,
> > >
> > >=A0=A0I've already installed the ZCO demo, I see all the layers. I =
tried
> > to
> > > add the itasca.map file to the ZCO demo without any succes.
> > >
> > >=A0=A0I add itasca.map file to the mapserver test directory (where =
other
> > > layers are),
> > >=A0=A0I added a ZCO Data Store called "map" in the data directory =
with=20
> the
> > > following property :
> > >=A0=A0=A0=A0- path =3D itasca.map
> > >=A0=A0I created a ZCO layer called "testMap" in the layers =
directory=20
> with
> > > the following properties :
> > >=A0=A0=A0=A0- geometrytype =3D RASTER
> > >=A0=A0=A0=A0- srs =3D EPSG:4326
> > >=A0=A0=A0=A0- datastore =3D ../../data/map
> > >=A0=A0I changed the index_html file to add my layer "testMap" to =
the
> > > layers_path constant.
> > >
> > >=A0=A0I surely done a mistake but I don't know where ... I have no=20=

> script
> > > error ...
> > >
> > >=A0=A0cheers,
> > >=A0=A0Seb
> > >
> > > On Apr 12, 2005 3:21 PM, Sean Gillies <sgi...@fr...> wrote:
> > > On Apr 12, 2005, at 2:04 AM, S=E9bastien Didelet wrote:
> > >
> > > > Hi everyone,
> > > >
> > > >=A0=A0I would like to render a .map file using PCL 0.7 and ZCO =
0.4, I
> > > don't
> > > > know how can I do ... maybe with the IMapRenderer ... could you
> > send
> > > > me an example ?
> > > >
> > > >=A0=A0thank you,
> > > >=A0=A0Seb
> > > >
> > >
> > > Use the ZCO.MapRenderer.MapRenderer class.=A0=A0The best example =
is in
> > the
> > > ZCO demo application.=A0=A0Import ZCO/demo/demo.zexp into your =
Zope
> > > instance and look at the Python Script named demo/getmap.=A0=A0It =
shows
> > an
> > > example of using a map renderer.
> > >
> > > cheers,
> > > Sean
> > >
> > > --
> > > Sean Gillies
> > > sgillies at frii dot com
> > > http://users.frii.com/sgillies
> > >
> >
> >
>
>

[ZMapServer-Developers] ReferenceMap

[Florian E. <Flo...@ui...>]

Hi list!

Because we need a reference-map for our application, we extended the PCL-0.7
source code:
to manage this, we added a 'createRefMap'-function in
cartography/engine/mapserver/mapserver.py and extended cartography/mapping.py
for a ReferenceMap class. These functions are close to the mapscript-attributes
and far from intention of independent use of map-engines. Has anyone better
sugestions for implementing a refernce-map? If someone want's to improve the
code, please tell us about the changes.

florian & michael

#### mapserver.py: ###########################################
def createRefMap( mapSize, mapExt, srs, img, refSize, refExt, imgType = 'PNG'):
	"""Draw Reference Map"""
	mo = mapscript.mapObj()
	# set map-attributes
	mo.setSize(  mapSize[ 0 ], mapSize[ 1 ] )
	mo.setExtent( mapExt[ 0 ], mapExt[ 1 ], mapExt[ 2 ], mapExt[ 3 ] )
	mo.setImageType( imgType )
	mo.setProjection( 'init=%s' % srs )
	# set refMap-attributes
	mo.reference.image = img
	mo.reference.width = refSize[ 0 ]
	mo.reference.height = refSize[ 1 ]
	mo.reference.extent.minx = refExt[ 0 ]
	mo.reference.extent.miny = refExt[ 1 ]
	mo.reference.extent.maxx = refExt[ 2 ]
	mo.reference.extent.maxy = refExt[ 3 ]
	# box-attributes are default
	mo.reference.outlinecolor.setRGB( 255, 0, 0 )
	mo.reference.color.setRGB( -1, -1, -1 )
	# draw image
	im = mo.drawReferenceMap()

	image = mapping.Image()
	#for the upcoming mapserver function
	if hasattr(im, 'getBytes'):
		image.data.write(im.getBytes())
	else:
		im.write(image.data)

	image.size = [im.width, im.height]
	image.mimetype = im.format.mimetype

	del im
	del mo
	return image

### mapping.py: ##################################################
class ReferenceMap:

    """ReferenceMap from createRefMap() in mapserver.py

    Attributes
    ----------
    mapSize : list
        image.width, image.height of map

    mapExt : list
        map bounding box like '[xmin, ymin, xmax, ymax]'

    srs : string
        like: 'EPSG=31294'

    img : string
        path to image-object like 'context/irmi/img/...'

    refSize: list
        image.width, image.height of ReferenceMap

    refExt : list
        ReferenceMap bounding box like '[xmin, ymin, xmax, ymax]'

    imgType : string
       default is 'PNG'

    """

    def __init__( self, mapSize, srs, img, refSize, refExt, imgType = 'PNG' ):
        self.__mapSize = mapSize
        self.__mapExt = []
        self.__srs = srs
        self.__img = img
        self.__refSize = refSize
        self.__refExt = refExt
        self.__imgType = imgType

    def draw( self, mapExt, refExt=None ):
        self.__mapExt = mapExt
        if refExt:
            self.__refExt = refExt
        ref = engine.mapserver.mapserver.createRefMap( self.__mapSize,
self.__mapExt, self.__srs,
                                      self.__img, self.__refSize, self.__refExt,
self.__imgType )

        return ref

Re: [ZMapServer-Developers] Render a .map with PCL 0.7 / ZCO 0.4

[Sean G. <sgi...@fr...>]

Seb,

You can not use a MapServer map file like this with ZCO.  ZCO Data=20
Stores must point to shapefiles, raster images, or WMS services.

Sean

On Apr 12, 2005, at 8:27 AM, S=E9bastien Didelet wrote:

> Sean,
>
>  I've already installed the ZCO demo, I see all the layers. I tried to=20=

> add the itasca.map file to the ZCO demo without any succes.
>
>  I add itasca.map file to the mapserver test directory (where other=20
> layers are),
>  I added a ZCO Data Store called "map" in the data directory with the=20=

> following property :
>  =A0 - path =3D itasca.map
>  I created a ZCO layer called "testMap" in the layers directory with=20=

> the following properties :
>  =A0 - geometrytype =3D RASTER
>  =A0 - srs =3D EPSG:4326
>  =A0 - datastore =3D ../../data/map
>  I changed the index_html file to add my layer "testMap" to the=20
> layers_path constant.
>
>  I surely done a mistake but I don't know where ... I have no script=20=

> error ...
>
>  cheers,
>  Seb
>
> On Apr 12, 2005 3:21 PM, Sean Gillies <sgi...@fr...> wrote:
> On Apr 12, 2005, at 2:04 AM, S=E9bastien Didelet wrote:
>
> > Hi everyone,
> >
> >=A0=A0I would like to render a .map file using PCL 0.7 and ZCO 0.4, I=20=

> don't
> > know how can I do ... maybe with the IMapRenderer ... could you send
> > me an example ?
> >
> >=A0=A0thank you,
> >=A0=A0Seb
> >
>
> Use the ZCO.MapRenderer.MapRenderer class.=A0=A0The best example is in =
the
> ZCO demo application.=A0=A0Import ZCO/demo/demo.zexp into your Zope
> instance and look at the Python Script named demo/getmap.=A0=A0It =
shows an
> example of using a map renderer.
>
> cheers,
> Sean
>
> --
> Sean Gillies
> sgillies at frii dot com
> http://users.frii.com/sgillies
>

Re: [ZMapServer-Developers] Render a .map with PCL 0.7 / ZCO 0.4

[Sean G. <sgi...@fr...>]

On Apr 12, 2005, at 2:04 AM, S=E9bastien Didelet wrote:

> Hi everyone,
>
>  I would like to render a .map file using PCL 0.7 and ZCO 0.4, I don't=20=

> know how can I do ... maybe with the IMapRenderer ... could you send=20=

> me an example ?
>
>  thank you,
>  Seb
>

Use the ZCO.MapRenderer.MapRenderer class.  The best example is in the=20=

ZCO demo application.  Import ZCO/demo/demo.zexp into your Zope=20
instance and look at the Python Script named demo/getmap.  It shows an=20=

example of using a map renderer.

cheers,
Sean


--
Sean Gillies
sgillies at frii dot com
http://users.frii.com/sgillies=

[ZMapServer-Developers] Render a .map with PCL 0.7 / ZCO 0.4

[<seb...@gm...>]

Hi everyone,

I would like to render a .map file using PCL 0.7 and ZCO 0.4, I don't know=
=20
how can I do ... maybe with the IMapRenderer ... could you send me an=20
example ?=20

thank you,=20
Seb

[ZMapServer-Developers] PCL 0.8 Source Release

[Sean G. <sgi...@fr...>]

Hi all,

New release today.  Details on my news site: http://zcologia.com/news/20

cheers,
Sean

--
Sean Gillies
sgillies at frii dot com
http://users.frii.com/sgillies

[ZMapServer-Developers] PCL recipes on my news site

[Sean G. <sgi...@fr...>]

Hi all,

In the past week I have published two PCL recipes on my news site.  One 
demonstrates the Python GEOS module that I plan to use for spatial 
predicates in PCL filters:

   http://zcologia.com/news/14

The other demonstrates new PROJ4 support and rendering a graticule 
layer:

   http://zcologia.com/news/18

Each of these use the code from CVS that I will release as PCL 0.8 
later in the week.

cheers,
Sean

--
Sean Gillies
sgillies at frii dot com
http://users.frii.com/sgillies

Re: [ZMapServer-Developers] Create dynamically a layer point

[<sgi...@fr...>]

> Hi everybody,
>
> I'm a new Zope and MapServer user and I have to make a Zope module to
> allow users to get some map from the repository and add some layers to
> them also from the repository. To do this I have some source code
> example. But furthermore I have to allow user to dynamicaly build
> layers to add information points to the map like towns, special
> buildings, ... etc, for this functionnality I have no idea about what
> technology to use ... ZMapServer, ZCO/PCL, others ... the users will
> just have to click on the map and adding information like the name of
> the building, the coordinate have to be automatically filled.
>
> Do you have any idea to solve my problem ?
>
> Thanks for your help, Sebastien Didelet.
>

Sebastien,

ZCO and PCL do not have any data collection capability, you will need to
customize this for your application.  ZCO/PCL *do* have the capability
to work with many different data sources.  For example, see the examples
of deomo/zdata/cpoints and demo/zdata/zpoints in the demo application.
This would give you the option of storing user-defined features in a CSV
formatted file, or storing them in an external database.  If you use a
database, the PostGIS extension for PostgreSQL is excellent.  For points,
two columns in a MySQL table may suffice.  All you would need would be
several Python Scripts that implement ZCO's IDataStore interface.

I hope this helps.  I can't provide any better examples until I return to
my office next week.

cheers,
Sean

[ZMapServer-Developers] Create dynamically a layer point

[<seb...@gm...>]

Hi everybody,

I'm a new Zope and MapServer user and I have to make a Zope module to
allow users to get some map from the repository and add some layers to
them also from the repository. To do this I have some source code
example. But furthermore I have to allow user to dynamicaly build
layers to add information points to the map like towns, special
buildings, ... etc, for this functionnality I have no idea about what
technology to use ... ZMapServer, ZCO/PCL, others ... the users will
just have to click on the map and adding information like the name of
the building, the coordinate have to be automatically filled.

Do you have any idea to solve my problem ?

Thanks for your help, Sebastien Didelet.

[ZMapServer-Developers] PCL: MapServer-specific datastore committed to CVS

[Sean G. <sgi...@fr...>]

As I mentioned in a previous email, the GEOS software that I would like 
to use for evaluation of spatial predicates ("intersects", "contains", 
etc) resists compilation on windows with MSVC6.  This means that PCL 
users on windows will not be able to use GEOS until they upgrade to 
Python 2.4.  2.4 binaries should be compiled using the next higher 
version of the MS compiler.  As far as I know, there is not a stable 
Zope release that is perfectly compatible with Python 2.4 ... which 
leaves a gap to bridge.

As a bridge, I've committed a new data store and filtering iterator to 
PCL's engine.mapserver.data module that operate without any dependency 
on GEOS.  Unfortunately, MapServer's own geometry operations are 
limited to "intersects".  Usage is like this (from the tests):

     from cartography.engine.mapserver.data import DiskFeatureStore
     from cartography.data import Query
     from cartography.filter import PythonFilter
     from cartography.spatial import Point

     subject_p = Point(0.0, 51.5)
     pyfilt = PythonFilter('g.intersects(p)')
     query = Query(filter=pyfilt, p=subject_p)
     features = [f for f in self.features(query)]
     assert len(features) == 1, len(features)

Etienne, it is not as fast as a query using mapscript, but a loss of 
speed is the price we pay now for the richer and more powerful filter 
expressions.  If you have access to the MSVC6 compiler. you may want to 
check out the latest PCL from CVS and give it a try.

I'm going to be out of the office through Saturday, catch up with you 
then.

cheers,
Sean

--
Sean Gillies
sgillies at frii dot com
http://users.frii.com/sgillies

[ZMapServer-Developers] PCL: moving spatial reference from Layer to DataStore

[Sean G. <sgi...@fr...>]

Hi all,

I believe that I have made a small mistake in the design of PCL.  I'd 
like to move our spatial reference information from the Layer class to 
the DataStore class.  Any thoughts?

cheers,
Sean

--
Sean Gillies
sgillies at frii dot com
http://users.frii.com/sgillies

[ZMapServer-Developers] Fwd: Beginning of a quick hack for ZCO properties

[Sean G. <sgi...@fr...>]

Begin forwarded message:

> From: "Moisan Yves" <ym...@gr...>
> Date: March 10, 2005 7:46:54 AM MST
> To: "Sean Gillies" <sgi...@fr...>
> Subject: RE: Beginning of a quick hack for ZCO properties
>
>> And my preference would be that this would be displayed within its =
own
>> tab, maybe named "Cartography"?  This tab would be the 1st and =
default
>> view within the ZMI.
>
> +1
>
>> Extra goodies to consider would be a layer preview (ala
>> layer/viewLayer) right in the tab or a depiction of symbolizers.
>
> Let me verbalize how that would work.  If I understand, clicking=20
> "View" simulates a browser request, which boils down to calling the=20
> index_html method or else an index_html object if one is defined.  For=20=

> example, I have this hierarchy :
>
> test/layers/ZCOLayerObj/ZCOStyleObj
>
> If I press the "View" tab when I am at the ZCOStyleObj level in the=20
> ZMI, I get the index_html object that is defined up in the test folder=20=

> but the objectWithProperty script that lives in index_html gets=20
> executed in the context of ZCOStyleObj.  Since there is no object that=20=

> has a Datastore property at that level, I get an empty table.
>
> If I hit the View tab in the layers folder, I get to see all the=20
> objects in that folder that have a property "Datastore" (that's where=20=

> all my layers are so for sure a lot of objects show up in the table)=20=

> so indeed the index_html template acquired by the test object executes=20=

> the objectWithProperty script in the context of the layers folder. =20
> Exact same thing as layer/viewLayer.  Only this would be the default=20=

> view and not the "View" tab.
>
> Now, I think an advantage of having things in a ZPT is that we can=20
> define macros or assign the output to a portlet (e.g. fill-slot could=20=

> be other than "main", e.g. "preview_slot") because one day or another=20=

> we'll have to get out of the ZMI and go to the "User" UI.
>
> When at that level, what I would really crave for is some elegant way=20=

> of defining "profiles" where we could store default values for layers,=20=

> styles ... that could be tied to users or better yet to groups of=20
> users (I think the next version of Plone will have yet better support=20=

> for groups).  For example, department X wants its users to see some=20
> default map (in a specific layer order, styles, default bbox ...). =20
> Users could acquire such a profile by virtue of being group members=20
> but could potentially override the default group values and make their=20=

> own profiles and eventually share them amongst other users in the same=20=

> group (or even with users in other groups, but that would probably=20
> require some sort of "deep copy" to get all the acquired properties of=20=

> the group to be transferred over to the other group).
>

Perhaps we should look at using the OGC's web map context spec for use=20=

in such profiles.

> Heck, it could even be possible to put together a Plone CMF UI similar=20=

> to uDIG : map in the center and a bunch of surrounding portlets!  That=20=

> contradicts a bit my previous email to Ka=EF where I argued the map=20
> should be displayed in a "side portlet" and not in the main one, but=20=

> I'm slowly making up my mind that mapping, even though it really is=20
> another way to represent data and as such should be displayed in a=20
> "satellite portlet", is complex enough to warrant its own environment.=20=

>  I am more and more thinking of implementing mapping in Plone as a=20
> separate Plone site instance altogether, the idea being that a "map"=20=

> portlet in my main (content) site would spawn another browser window=20=

> altogether.
>
> For the preview tab, I think it would not make sense to duplicate the=20=

> "view" tab, that is have a "Preview" tab that calls the exact same=20
> machinery called in by the "View" tab.  I wonder if some sort of=20
> cached image could be used instead?  Since we are not in a general map=20=

> context (IMO, you would press the "View" tab in the right location for=20=

> that) and it's just a matter of showing a line style for example, the=20=

> preview could just focus on presenting a "thick red dotted line".  My=20=

> point is to avoid the overhead of calling in the whole map generation=20=

> machinery, but I don't know how useful that would be.
>
> Cheers,
>
>
> Yves
>

Yves, I agree that we should not override the normal behavior of the=20
"view" tab.

cheers,
Sean

[ZMapServer-Developers] Anyone attending EuroPython?

[Sean G. <sgi...@fr...>]

All of my paying Zope and MapServer work in the past year has been done 
for European clients, and almost all of ZCO developers and users are 
European ... this leads me to ask if any you have plans to attend the 
2005 EuroPython conference?  It sounds like it could be an interesting 
and fun event.

cheers,
Sean

--
Sean Gillies
sgillies at frii dot com
http://users.frii.com/sgillies

Re: [ZMapServer-Developers] PCL/ZCO CVS head

[Sean G. <sgi...@fr...>]

On Mar 8, 2005, at 2:10 AM, Kai H=E4nninen wrote:

> ma, 2005-03-07 kello 12:22 -0700, Sean Gillies kirjoitti:
>
>> It is likely that the HEADs of PCL and ZCO are out of synch right =
now.
>> That layerObj_addFeature() method from mapscript is expecting a
>> reference to a mapscript shapeObj and it must be getting something=20
>> else
>> instead.
>
> I reverted to PCL 0.7 / ZCO 0.4 and still get the same problem with=20
> both
> the demo and my project. Does the demo work for you with the 0.7/0.4
> combination?
>

Kai,

I have an idea ... did you import the demo.zexp file included with ZCO=20=

0.4?  The zdata/points_catalog data store in 0.3 had WKB geometries,=20
but in 0.4 we are now using PCL's geometries.

cheers,
Sean

--
Sean Gillies
sgillies at frii dot com
http://users.frii.com/sgillies=

[ZMapServer-Developers] Question about labeling

[Sean G. <sgi...@fr...>]

On Mar 7, 2005, at 10:20 PM, Etienne Desgagn=E9 wrote:

> Hi Sean,
>
>
>     After some research, I have found that Mapserver has capabilities =20=

> to show
> label following the orientation of a feature (for LINE features) by =20=

> defining
> ANGLE auto in a MAPFILE.
>
> More interesting, I also found that by specifying a LABELANGLEITEM, I =20=

> think that
> we can adjust the rotation of the labels with angles values stock in =20=

> an item.
>
> Does these options are available in PCL (I don't think so)?
>
> Does PCL/ZCO users can expect to have access to these functionalities =20=

> in futur?
>
> (Sorry if I disturb you with all my questions... I'm a big fan of your =
=20
> product!)
>
> Etienne
>

Etienne,

We have this issue in the tracker and it is going to be in PCL and ZCO. =20=

  My only reservation about a feature like MapServer's LABELANGLEITEM is =
=20
that, in my opinion, presentation-specific information like label =20
angles (or colors or symbol sizes) should not be stored with data.

I'm going to forward this along to the mapserver-developers list as =20
well and ask for opinions.  Do PCL and ZCO users need the =20
LABELANGLEITEM feature, or can we try a different way that is not =20
directly modeled on one of MapServer's quirky features?  My first idea =20=

is that instead of storing label angles in the data, we reprocess your =20=

data to create a new shapefile of small lines that are oriented exactly =20=

as you want your labels.

Please see the tracker issue for the original report with images:

   =20
http://sourceforge.net/tracker/index.php?=20
func=3Ddetail&aid=3D1105690&group_id=3D71074&atid=3D530069

cheers,
Sean


--
Sean Gillies
sgillies at frii dot com
http://users.frii.com/sgillies=

Re: [ZMapServer-Developers] PCL/ZCO CVS head

[Kai <kai...@mb...>]

ma, 2005-03-07 kello 12:22 -0700, Sean Gillies kirjoitti:

> It is likely that the HEADs of PCL and ZCO are out of synch right now. =
 =20
> That layerObj_addFeature() method from mapscript is expecting a =20
> reference to a mapscript shapeObj and it must be getting something else=
 =20
> instead.

I reverted to PCL 0.7 / ZCO 0.4 and still get the same problem with both
the demo and my project. Does the demo work for you with the 0.7/0.4
combination?

Kai

--=20
Kai H=E4nninen                  mobile:+358-44-541 9567
Software engineer             www.mbconcert.fi
MB Concert Ky                 kai...@mb...

Re: [ZMapServer-Developers] PCL/ZCO CVS head

[Sean G. <sgi...@fr...>]

On Mar 7, 2005, at 4:07 AM, Kai H=E4nninen wrote:

> Hi
>
> I was trying the current CVS head for both PCL/ZCO and bumped into a
> following problem with both the ZCO demo and my own project. While
> trying to render the map, the exception at the bottom of this message
> occurs.
>
> In my case the problem occurs when I render layers with
> MemoryFeatureStore as datastore. Without them the map renders as it
> should. The demo suffers from this too, simply viewing the index_html
> fails rendering all the images.
>
> Have you bumped into this, Sean?
>
> I'll try this again with a clean install tomorrow if it still occurs
> then, but let me know if it's something else.
>
> cheers,
> Kai
>
>
> ---begin-stack-trace---
>
> 2005-03-07T12:54:32 ERROR(200) SiteError
> http://some.site/demo/layers/cpoints/dot/viewLayer
> Traceback (most recent call last):
>   File "/usr/local/zope/lib/python/ZPublisher/Publish.py", line 101, =
in
> publish
>     request, bind=3D1)
>   File "/usr/local/zope/lib/python/ZPublisher/mapply.py", line 88, in
> mapply
>     if debug is not None: return debug(object,args,context)
>   File "/usr/local/zope/lib/python/ZPublisher/Publish.py", line 39, in
> call_object
>     result=3Dapply(object,args) # Type s<cr> to step into published
> object.
>   File "/usr/local/zope/lib/python/Shared/DC/Scripts/Bindings.py", =
line
> 306, in __call__
>     return self._bindAndExec(args, kw, None)
>   File "/usr/local/zope/lib/python/Shared/DC/Scripts/Bindings.py", =
line
> 343, in _bindAndExec
>     return self._exec(bound_data, args, kw)
>   File
> "/usr/local/zope/lib/python/Products/PythonScripts/PythonScript.py",
> line 323, in _exec
>     result =3D f(*args, **kw)
>   File "Script (Python)", line 37, in viewLayer
>   File "/usr/local/zope/inst-main/Products/ZCO/MapRenderer.py", line
> 172, in render
>     def draw(self, symbolizer, format=3D'image/png', size=3D[16, 16],
>   File
> "/usr/lib/python2.3/site-packages/cartography/engine/mapserver/=20
> mapserver.py", line 149, in render
>     fkeys, c_filters)
>   File
> "/usr/lib/python2.3/site-packages/cartography/engine/mapserver/=20
> mapserver.py", line 980, in _render_layer_memory_intrinsic
>     lo.addFeature(shape)
>   File "/usr/lib/python2.3/site-packages/mapscript.py", line 764, in
> addFeature
>     def addFeature(*args): return =
_mapscript.layerObj_addFeature(*args)
> TypeError: Expected a pointer
>
> --=20
> Kai H=E4nninen                  mobile:+358-44-541 9567
> Software engineer             www.mbconcert.fi
> MB Concert Ky                 kai...@mb...
>

Kai,

It is likely that the HEADs of PCL and ZCO are out of synch right now.  =20=

That layerObj_addFeature() method from mapscript is expecting a =20
reference to a mapscript shapeObj and it must be getting something else =20=

instead.

Sean

--
Sean Gillies
sgillies at frii dot com
http://users.frii.com/sgillies=

[ZMapServer-Developers] PCL/ZCO CVS head

[Kai <kai...@mb...>]

Hi

I was trying the current CVS head for both PCL/ZCO and bumped into a
following problem with both the ZCO demo and my own project. While
trying to render the map, the exception at the bottom of this message
occurs.

In my case the problem occurs when I render layers with
MemoryFeatureStore as datastore. Without them the map renders as it
should. The demo suffers from this too, simply viewing the index_html
fails rendering all the images.

Have you bumped into this, Sean?

I'll try this again with a clean install tomorrow if it still occurs
then, but let me know if it's something else.

cheers,
Kai


---begin-stack-trace---

2005-03-07T12:54:32 ERROR(200) SiteError
http://some.site/demo/layers/cpoints/dot/viewLayer
Traceback (most recent call last):
  File "/usr/local/zope/lib/python/ZPublisher/Publish.py", line 101, in
publish
    request, bind=3D1)
  File "/usr/local/zope/lib/python/ZPublisher/mapply.py", line 88, in
mapply
    if debug is not None: return debug(object,args,context)
  File "/usr/local/zope/lib/python/ZPublisher/Publish.py", line 39, in
call_object
    result=3Dapply(object,args) # Type s<cr> to step into published
object.
  File "/usr/local/zope/lib/python/Shared/DC/Scripts/Bindings.py", line
306, in __call__
    return self._bindAndExec(args, kw, None)
  File "/usr/local/zope/lib/python/Shared/DC/Scripts/Bindings.py", line
343, in _bindAndExec
    return self._exec(bound_data, args, kw)
  File
"/usr/local/zope/lib/python/Products/PythonScripts/PythonScript.py",
line 323, in _exec
    result =3D f(*args, **kw)
  File "Script (Python)", line 37, in viewLayer
  File "/usr/local/zope/inst-main/Products/ZCO/MapRenderer.py", line
172, in render
    def draw(self, symbolizer, format=3D'image/png', size=3D[16, 16],
  File
"/usr/lib/python2.3/site-packages/cartography/engine/mapserver/mapserver.=
py", line 149, in render
    fkeys, c_filters)
  File
"/usr/lib/python2.3/site-packages/cartography/engine/mapserver/mapserver.=
py", line 980, in _render_layer_memory_intrinsic
    lo.addFeature(shape)
  File "/usr/lib/python2.3/site-packages/mapscript.py", line 764, in
addFeature
    def addFeature(*args): return _mapscript.layerObj_addFeature(*args)
TypeError: Expected a pointer

--=20
Kai H=E4nninen                  mobile:+358-44-541 9567
Software engineer             www.mbconcert.fi
MB Concert Ky                 kai...@mb...

Re: [ZMapServer-Developers] bbox attribute container

[Sean G. <sgi...@fr...>]

On Feb 23, 2005, at 9:48 AM, Moisan Yves wrote:

> Hi Sean,
>
> I've been playing around lately with ZCO and I would like to share some
> thoughts.  The context is that I am trying to find a way to override 
> the
> default bbox values sent to the getMap script (demo/index_html),
> specifically bbox values to implement zooming.
>
> First, the layer object.  Looking at the attributes sequentially :
>
> - datastore : OK since the layer is a sort of ZCO wrapper or 
> abstraction
> of the DataStore
> - geometryType, srs : those really are attributes of the DataStore 
> (??),
> except maybe for srs which can be thought of as the datastore srs or 
> the
> "desired" srs for map viewing (which points to a view object IMO, at
> least comceptually)
> - bbox (e.g. the layers/line object in the ZCO demo) : IMO this is an
> attribute for some other object; in fact, I've been creating layers for
> a personal demo and I never put any bbox (if it had been a necessary
> attribute, I would have been brought naturally to add a bbox attribute
> to my layers).
>
> So in short I view the Layer object as a Python/Zope wrapper object to 
> a
> DataStore and a container for style variants.
>
> Now, the bbox attribute.  Considering the width/height invariant,
> zooming/panning and providing default views really are just bbox
> arithmetic stuff.  I was wondering where the bbox attribute would find
> its best home (Zope object).
>
> Use Case : I have users in city X and other is city Y.  Those
> geographical attributes are mimicked in a zope hierarchy, e.g.
> country/province/city.  Upon entering the cityX folder, I would like my
> map portlet to display a predetermined zone of my layers, which would
> call for some object holding the bbox (or a folder property ??).  Since
> I'll be reusing the same layers, I wouldn't want to define a Layer to
> hold my bbox attribute corresponding to predefined views.
>
> I don't know where bbox should be held.  I think isolating it in some
> sort of view object to allow one to set specific views in the current
> context is interesting.  I wonder if a bbox container in the current
> context could be used to write user-specified zooms?  E.g. a box asking
> the user for a zoom level (potentially float) the contetn of which 
> would
> be stored in the current mapper context and somehow hooked to before 
> the
> call to getMap.  We could probably think of objects to allow for bbox
> arithmetic first on the client side (combination of zoom and pan
> requests from the user) that would not call MapServer, then once the
> user is ready after playing around, he can send the request.
>
> Cheers,
>
> Yves Moisan
>

Yves,

Sorry it's taken me a while to respond.  The bbox property that I am 
using the demo isn't really an attribute of any ZCO object.  It's 
purely an application property that is used by the getmap Python 
Script.  I chose the name "bbox" to keep the getmap script's parameters 
as close as possible to those of a WMS GetMap request, but I haven't 
planned to reserve the name specifically for any one ZCO object.

I've been putting off work on programming specific property sheets for 
the ZCO objects, but maybe the time is now.  If anybody has experience 
and interest in helping out on this, please let me know.

cheers,
Sean

--
Sean Gillies
sgillies at frii dot com
http://users.frii.com/sgillies

[ZMapServer-Developers] bbox attribute container

[Moisan Y. <ym...@gr...>]

Hi Sean,

I've been playing around lately with ZCO and I would like to share some
thoughts.  The context is that I am trying to find a way to override the
default bbox values sent to the getMap script (demo/index_html),
specifically bbox values to implement zooming.

First, the layer object.  Looking at the attributes sequentially :=20

- datastore : OK since the layer is a sort of ZCO wrapper or abstraction
of the DataStore
- geometryType, srs : those really are attributes of the DataStore (??),
except maybe for srs which can be thought of as the datastore srs or the
"desired" srs for map viewing (which points to a view object IMO, at
least comceptually)
- bbox (e.g. the layers/line object in the ZCO demo) : IMO this is an
attribute for some other object; in fact, I've been creating layers for
a personal demo and I never put any bbox (if it had been a necessary
attribute, I would have been brought naturally to add a bbox attribute
to my layers).

So in short I view the Layer object as a Python/Zope wrapper object to a
DataStore and a container for style variants.

Now, the bbox attribute.  Considering the width/height invariant,
zooming/panning and providing default views really are just bbox
arithmetic stuff.  I was wondering where the bbox attribute would find
its best home (Zope object).

Use Case : I have users in city X and other is city Y.  Those
geographical attributes are mimicked in a zope hierarchy, e.g.
country/province/city.  Upon entering the cityX folder, I would like my
map portlet to display a predetermined zone of my layers, which would
call for some object holding the bbox (or a folder property ??).  Since
I'll be reusing the same layers, I wouldn't want to define a Layer to
hold my bbox attribute corresponding to predefined views.

I don't know where bbox should be held.  I think isolating it in some
sort of view object to allow one to set specific views in the current
context is interesting.  I wonder if a bbox container in the current
context could be used to write user-specified zooms?  E.g. a box asking
the user for a zoom level (potentially float) the contetn of which would
be stored in the current mapper context and somehow hooked to before the
call to getMap.  We could probably think of objects to allow for bbox
arithmetic first on the client side (combination of zoom and pan
requests from the user) that would not call MapServer, then once the
user is ready after playing around, he can send the request.

Cheers,

Yves Moisan

[ZMapServer-Developers] PCL 0.7 and ZCO 0.4 releases

[Sean G. <sgi...@fr...>]

Hi all,

New releases are out.  I've also updated the intro and API docs under

   http://zmapserver.sourceforge.net/PCL/

and have written a brief HOWTO regarding the new PCL feature query 
capabilities

   http://zmapserver.sourceforge.net/PCL/query.html

Full PCL 0.7 releases notes are at the end of this email.  ZCO has 
changed very little, only a few tweaks behind the curtain to work with 
the new PCL.  The demo application included with the ZCO source 
(demo.zexp) has been tested and works.  Anyone who has been playing 
around with Zope objects that implement IDataStore and IStyle will have 
to make some changes in their Python Scripts: some classes of the 
cartography.data module have been renamed for the sake of clarity.  I 
don't want to do this too much, but I also don't want bad names to be 
carved in stone.

My next task is to address the bugs in the tracker and make a quick 
0.4.1 release of ZCO, and then make room in the source for a Plone 
product.

cheers,
Sean

================================
  Python Cartographic Library 0.7
  13 February 2005
================================

New developments are noted in CHANGES.TXT but the following require 
further
explanation.

ogr.py
======

PCL 0.7 requires the GDAL/OGR ogr.py module for accessing local disk 
data
stores from a GDAL 1.2.x release or higher.  Windows users will want to 
grab
Frank Warmerdam's FWTools installer from

    http://fwtools.maptools.org/

FWTools 0.9.5 is compatible with Python 2.3 and 2.3.4.  Earlier 
versions were
aimed at Python 2.1 and so will not be of use to PCL.  Install FWTools 
to some
location on your system and copy the ogr.py, gdal.py, osr.py, 
gdalconst.py,
and _gdal.dll files from FWTool's pymod directory into your own Python's
Lib/site-packages.  Add the path to the FWTools/bin directory to your
environment's PATH and set the GDAL_DATA environmental variable to the
FWTools/data path.

New setup.py and MapServer bridge module msbridge.py
====================================================

PCL 0.7 is no longer pure Python.  A C extension module exists under
cartography/engine/mapserver and this extension module requires 
specification
of a local path to a MapServer source directory so that various 
MapServer
headers can be found.  If your various MapServer libraries are 
installed in
non-standard locations, you may need to explicitly pass include paths 
to the
build_ext target of setup.py
::

     $ python setup.py build_ext -I path1;path2;...;pathN install

Test Code Coverage
==================

Under cartography/tests is a runcoverage shell script used to measure 
the
extent to which the package's code is covered by the unit tests.  It 
requires
the coverage.py module from

   http://www.nedbatchelder.com/code/modules/coverage.html

be copied into the cartography/tests directory.  Current results are 
shown
below
::

     coverage of modules in ../
     Name         Stmts   Exec  Cover
     --------------------------------
     data           188    175    93%
     filter          38     38   100%
     __init__         0      0   100%
     interfaces      14     14   100%
     mapping        107    106    99%
     spatial        185    176    95%
     --------------------------------
     TOTAL          532    509    95%

     coverage of modules in ../engine
     Name       Stmts   Exec  Cover
     ------------------------------
     __init__       0      0   100%

     coverage of modules in ../engine/mapserver
     Name        Stmts   Exec  Cover
     -------------------------------
     __init__        1      1   100%
     mapserver     331    276    83%
     msbridge       91     60    65%
     -------------------------------
     TOTAL         423    337    79%

Coverage is pretty good, but there is still room for improvement.

Example Scripts
===============

Under PCL/examples are two example applications that demonstrate the new
features of version 0.7.  These are not included in the windows 
binaries, and
so windows users will have to download the PCL source separately.