[mapserver-dev] RFC 64 - Call for a vote...

[Yewondwossen Assefa]

On 29/11/2010 10:24 PM, Lime, Steve D (DNR) wrote:
> Equals is there, I implemented it with EQ or = rather than spelling it out. It uses msGEOSEquals()
> under the hood.
>
ok.
> Do you have any thoughts in regard to tolerances? I don't think we can handle them with filters. That
> means layer tolerances would be used in stock MapServer queries (by point, by rectify, by shape).
> Tolerances were really only intended for point queries against point/line layers but have weaseled their
> way elsewhere.
>
The filters should not need to have to use the tolerance. The 2 
operators that might have been related to tolerance are dwithin and 
beyond. (In both cases the filter can contain a distance parameter).   
The current implementation of these operators uses msGEOSDistance with a 
buffered shape (buffered shape is created using the distance). I was 
hoping that we could use the same logic with the expressions.


best regards


> Steve
> ________________________________________
> From: Yewondwossen Assefa [yassefa at dmsolutions.ca]
> Sent: Monday, November 29, 2010 4:42 PM
> To: Lime, Steve D (DNR)
> Cc: mapserver-dev at lists.osgeo.org
> Subject: Re: [mapserver-dev] RFC 64 - Call for a vote...
>
> H Steve,
>
>    Couple of comments regarding the todo list and OGC filter: I believe
> all the OGC filter operations are currently supported in the sand box?
> (I see that the "Equals" operator is not listed in the new operators
> section but I think is available , correct ?)
>
>    From the tests I have done in the sand box, the bbox filter contained
> in an OGC filter was transformed into a<Not><disjoint>  operator and
> that seems to work good enough.
>
> Regarding OGC filter, I think the first pass would be to use the new
> MapServer expression most of the time with the exception of some simple
> filters applied to DB drivers, where the filter can be transformed into
> sql expression and be treated  more efficiently.  The latter would
> eventually be completely replaced when RDBMS drivers would implement the
> expression to SQL translation.
>
> +1 for me.
>
>
>
> On 29/11/2010 11:26 AM, Lime, Steve D (DNR) wrote:
>> It's been a week with little comment, not sure how that should be interpreted. I know it's a long RFC. I feel a little uncomfortable declaring it "passed" based on only two votes though.
>>
>> Steve
>>
>> -----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: Monday, November 22, 2010 11:38 AM
>> To: Stephen Woodbridge; mapserver-dev at lists.osgeo.org
>> Subject: RE: [mapserver-dev] RFC 64 - Call for a vote...
>>
>> 1) Thread safety. At the moment I use thread locks as we always have. So there's no regression there. I'd like to try and make things thread safe (at least for parser, as opposed to flex for mapfiles) for 6.0.
>>
>> 2) I would like to push the IN operator optimization off (unless someone is motivated now). I don't think it's trivial exercise since we need to support both string and numeric lists on the right-hand side.
>>
>> Steve
>>
>> -----Original Message-----
>> From: mapserver-dev-bounces at lists.osgeo.org [mailto:mapserver-dev-bounces at lists.osgeo.org] On Behalf Of Stephen Woodbridge
>> Sent: Monday, November 22, 2010 11:19 AM
>> To: mapserver-dev at lists.osgeo.org
>> Subject: Re: [mapserver-dev] RFC 64 - Call for a vote...
>>
>> On 11/22/2010 11:39 AM, Lime, Steve D (DNR) wrote:
>>> Need to act on RFC 64 one way or another so I'll call for a vote.
>>>
>>> http://mapserver.org/development/rfc/ms-rfc-64.html
>> Steve,
>>
>> What are you thoughts on the TODO list? Are these getting pushed out
>> post 6.0?
>>
>> Are you planning to put thread locks around the parser global usage so
>> you don not break thread safety? As opposed to making the code thread
>> safe now? I do not think you can regress thread-safety and break that.
>>
>> For the IN optimization, if the IN list is large, load the tokens into a
>> btree structure and search will be very fast. I believe this is how
>> postgres does it internally.
>>
>> Unless there are some serious concerns from others on issues I'm not
>> seeing, this seems like a huge amount of value for relatively low risk,
>> other than changing a lot of code. I think this needs to go into 6.0.
>>
>> +1 for 6.0
>>
>> -Steve W
>> _______________________________________________
>> 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
>>
>
> --
> ----------------------------------------------------------------
> Assefa Yewondwossen
> Software Analyst
>
> Email: yassefa at dmsolutions.ca
> http://www.dmsolutions.ca/
>
> Phone: (613) 565-5056 (ext 14)
> Fax:   (613) 565-0925
> ----------------------------------------------------------------
>
>
>
>
> _______________________________________________
> mapserver-dev mailing list
> mapserver-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapserver-dev
>


-- 
----------------------------------------------------------------
Assefa Yewondwossen
Software Analyst

Email: yassefa at dmsolutions.ca
http://www.dmsolutions.ca/

Phone: (613) 565-5056 (ext 14)
Fax:   (613) 565-0925
----------------------------------------------------------------