[mapserver-dev] RFC 64 Part Deux

Lime, Steve D (DNR) Steve.Lime at state.mn.us
Tue Nov 2 11:55:46 EDT 2010


Just an FYI, the RFC was added to SVN and should be available within the hour. That's the working version at this point...

-----Original Message-----
From: mapserver-dev-bounces at lists.osgeo.org [mailto:mapserver-dev-bounces at lists.osgeo.org] On Behalf Of Lime, Steve D (DNR)
Sent: Sunday, October 31, 2010 11:53 AM
To: Daniel Morissette; mapserver-dev at lists.osgeo.org
Subject: RE: [mapserver-dev] RFC 59 Part Deux

Thanks Dan. It's mostly done. The todo list at the bottom of the RFC describes the main issues. Some just need to be done (e.g. raster support) others are more technical decisions (such as how to manage the token list, right now it's a pre-allocated array- yuck). The scope is one I hadn't thought about all that much. I had thought about how many scopes one might define and only came up with two, layer/data vs scratch shapes. At this point I'd lean towards not touching the rest of the code but if there is good reason to do something different... I've added this to the todo piece. I also added on relative to exposing the queryByFilter method to MapScript and/or the CGI.

I've left the draft on the wiki for the moment but now with the correct number. (http://trac.osgeo.org/mapserver/wiki/RFC64-Draft). I'll move to docs trunk as soon as I get some time.

I'd really like to see some testing of the sandbox before trying to merge to make sure something stupid isn't being done. The merge would probably only take an evening's work.

Steve

________________________________________
From: mapserver-dev-bounces at lists.osgeo.org [mapserver-dev-bounces at lists.osgeo.org] On Behalf Of Daniel Morissette [dmorissette at mapgears.com]
Sent: Thursday, October 28, 2010 4:20 PM
To: mapserver-dev at lists.osgeo.org
Subject: Re: [mapserver-dev] RFC 59 Part Deux

Hi Steve (and Assefa),

Great RFC! Sounds like a good amount of work. Is it mostly done or is
there much left to do? And do you need help on specific parts to get
this in 6.0?

I think we should try to get those changes in trunk and start testing
them as soon as the code is in working shape (is it yet?), even if some
of the features still need to be worked on.

Here are a few notes, just to show that I did read the document ;)

- RFC-59 is already taken in SVN by a draft RFC, so you should pick a
new number and commit your RFC to
http://svn.osgeo.org/mapserver/trunk/docs/en/development/rfc/ ... the
next available number is RFC-64... the RFC should then appear on the
website within an hour or so... and no need to commit a copy of the RFC
in the branch-5-6 docs, the website now publishes RFCs out of trunk.

- In your RFC you propose the addition of "shapeObj scope" flag to mark
temporary shapes created in the context of expressions as having limited
scope and differentiate them from those coming from the layer/data
sources that should not be freed. Should we consider using a reference
count instead? Using a ref count may require updating all the mapserver
code that allocates and frees shapes (and not just the expression
stuff), but there may be benefits in using ref counts in other areas of
the software. I didn't look deeply into this yet, but I thought I'd
raise the idea.

Daniel

Lime, Steve D (DNR) wrote:
> It actually should work for all drivers. It's just a matter of where things are evaluated and at the moment it's all in MapServer...
>
> Steve
>
> -----Original Message-----
> From: mapserver-dev-bounces at lists.osgeo.org [mailto:mapserver-dev-bounces at lists.osgeo.org] On Behalf Of Yewondwossen Assefa
> Sent: Thursday, October 28, 2010 9:10 AM
> To: mapserver-dev at lists.osgeo.org
> Subject: Re: [mapserver-dev] RFC 59 Part Deux
>
> On 26/10/2010 1:25 AM, Lime, Steve D (DNR) wrote:
>> have a moment. If this is gonna make version 6.0 then I'd need to start on merging code ASAP. Assefa has also done a good
>> bit of WFS work with this new stuff and has been pretty successful I think. The RFC contains a couple of attachments showing use
> Jus to add to this, what was done as a test for the filter encoding is
> to convert the OGC filters (all logical,  comparison, spatial) into
> common expressions and used it to set the filter element on the layer
> and run the query. This is a big improvement in terms of code cleaning
> and optimization (when compared to running several queries for one ogc
> filter and then merge the resulting queries).  This works now for
> mapserver shape type layers. The ultimate goal is to have all underlying
> drivers to be able to convert all common expressions into appropriate
> queries.
>
> Assefa
>


--
Daniel Morissette
http://www.mapgears.com/
_______________________________________________
mapserver-dev mailing list
mapserver-dev at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-dev


_______________________________________________
mapserver-dev mailing list
mapserver-dev at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-dev




More information about the mapserver-dev mailing list