[mapserver-dev] MS RFC 69 - Call for vote

[Lime, Steve D (DNR)]

So the mapdraw.c patch attached to the ticket is not used? I was going to say that it would be nice not to touch the drawing/query code and implement within the layer api only. Looks like that’s the approach you’ve taken. If so then it’s pretty compartmentalized and I’m a +1.

For RFC’s 68 and 69. Any security issues you can think of? Do the implementations follow the new guidelines Alan put together following his work?

Steve

From: mapserver-dev-bounces at lists.osgeo.org [mailto:mapserver-dev-bounces at lists.osgeo.org] On Behalf Of Tamas Szekeres
Sent: Monday, February 28, 2011 1:44 PM
To: mapserver-dev at lists.osgeo.org
Subject: [mapserver-dev] MS RFC 69 - Call for vote

Dear PSC,

I've tested the significant aspects (rendering, query handling, item handling, expressions etc) with the implementation of MS RFC 69<http://mapserver.org/development/rfc/ms-rfc-69.html> and it appears to be working well. Updated the implementation code<http://trac.osgeo.org/mapserver/attachment/ticket/3700/mapcluster.c> and added a sample image<http://trac.osgeo.org/mapserver/attachment/ticket/3700/cluster.png> to the corresponding ticket<http://trac.osgeo.org/mapserver/ticket/3700>.

With the current approach I'm plannig to include the single layer option only so this provider doesn't require a specific connection type. Currently I have 4 clustering parameters (including 2 expressions) to be exposed, so it is worth to create a new section (CLUSTER) in the mapfile to configure that. See the RFC document for the details.

I think this proposal is in good condition to call for a vote on it.

I start with my +1.


Tamas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/mapserver-dev/attachments/20110228/4eeae61d/attachment-0001.html