[mapserver-dev] Toronto sprint hopes and dreams

[Steve Lime]

Regarding the one-pass queries. Can we get an RFC in place before the event? I have some
ideas on how this can be accomplished and it would be a good idea to get on the same page 
ahead of time. I was thinking of attaching a feature cache of some sort to the result set object
that we already have. Then, if one-pass is desirable you'd stuff shapes into the cache for
presentation. The various drivers wouldn't have to be touched.

Perhaps you are thinking of something more general...

Steve

>>> On 2/4/2009 at 9:15 AM, in message
<f3b73b7d0902040715k686b5904lcf1fc3fafb78735a at mail.gmail.com>, Tamas Szekeres
<szekerest at gmail.com> wrote:
> Folks,
> 
> Unfortunately I won't be able to take part on this event, but I'm quite
> interested in addressing this one pass query issue and will probably have a
> working example by the time.
> 
> I'd also presume that the substantial changes would continue to have
> accepted by the PSC according to RFC1 especially if the "When is vote
> required?" section applies to that particular change in time before it gets
> the final implementation.
> In this regard I'd support having the significant additions to be manifested
> in an RFC in time before the event is getting started since we normally
> expect 2 business days before the final decision according to RFC1.
> 
> 
> 
> Best regards,
> 
> Tamas
> 
> 
> 
> 
> 
> 2009/2/2 Paul Ramsey <pramsey at opengeo.org>
> 
>> One-pass query would be a good candidate for the sprint, since we
>> could Big Bang the changes into lots of drivers at one go.
>>
>> P.
>>
>> PS - I hadn't realized the differences were so stark. The shapefile
>> speed is what we should be expecting.
>>
>> On Mon, Feb 2, 2009 at 1:14 PM, Jim Klassen <Jim.Klassen at ci.stpaul.mn.us>
>> wrote:
>> > My goal is to speed up oraclespatial layers especially over WFS. (Right
>> now a simple GetFeature with no filters takes 27min  from an oraclespatial
>> source, 2min 40 sec using ogr2ogr converting from the same table (via OCI)
>> to GML. The same data takes 4min from PostGIS and 12 seconds from Shape via
>> mapserver and WFS.)
>> >
>> > Also there were at one point (I haven't checked in awhile) some bugs if
>> there were differing coordinate systems for WFS and the MAP Projection
>> object where the LatLon BBOX was calculated incorrectly that I would like to
>> fix, if it hasn't been already.
>> >
>> >>>> Paul Ramsey <pramsey at opengeo.org> 02/02/09 2:01 PM >>>
>> > Resolution of the proj4/epsg/caching issues. Either with working code
>> > or an agreed approach. It is the largest outstanding performance issue
>> > for Mapserver.
>> >
>> > On Mon, Feb 2, 2009 at 11:57 AM, Howard Butler <hobu.inc at gmail.com>
>> wrote:
>> >> I just wanted to start a thread for folks to toss around ideas for
>> things
>> >> they'd hope to accomplish for the Toronto sprint.  Here's my list:
>> >>
>> >> - GetFeatureIDColumn vtable method
>> >> http://lists.osgeo.org/pipermail/mapserver-dev/2009-January/008156.html 
>> >> - A prototype mod_mapserver http://trac.osgeo.org/mapserver/ticket/2565 
>> >> - Finish up website automation items
>> >>
>> >> What do you hope to start, finish, or work on during your sprint
>> efforts?
>> >>
>> >> Howard
>> >> _______________________________________________
>> >> 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 
>> >
>> > _______________________________________________
>> > 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 
>>