MS 5.4 - Python-MS - queryByRect strange behavior

[Christian Jauvin]

Hi everyone,

I am currently developing a Python-MapScript based web-mapping
framework (http://dracones.surveillance.mcgill.ca) that worked fairly
well with earlier versions of MS (MS4W < 3 on Windows, and
package-based MS ~ 5.2 on Linux). This week I started playing with
Python 2.6 (looking, among other things, to port my framework from
mod_python to WSGI), and so it lead me to the latest beta of MS4W,
which I read has a version of Python-MS built for it. I am currently
using the Beta 7 of MS4W 3. I originally posted this to the MS4W-users
list only, suspecting that my problem was specific to it, but I was
then advised to post here as well, as it could point to a deeper MS
issue.

I have noticed a strange behavior with the queryByRect function,
different than what was before: when I programmatically add features
to a point layer and then try to retrieve a subset of them with
queryByRect, getNumResults gives the correct number of retrieved
features, but then the set of shapes returned by
layer.getFeature(layer.getResult(i).shapeindex) is not right. The best
way to explain the problem is this example: when I query for three
very distinct features, what I get is this:

 [<mapscript.shapeObj; proxy of <Swig Object of type 'shapeObj *' at
0x01EC71E0> >,
  <mapscript.shapeObj; proxy of <Swig Object of type 'shapeObj *' at
0x01EC71C0> >,
  <mapscript.shapeObj; proxy of <Swig Object of type 'shapeObj *' at
0x01EC71E0> >]

The first and third objects seem to be the same, according to their
pointers. No matter what query I try to perform, there is always a
similar problem occurring: some pointers seem to be pointing to shared
features, whereas they shouldn't (at least from what I understand).

I understand that this problem description may not be terribly helpful
since it may be hard to reproduce, but given that it would take time
to abstract away the suspicious code in my framework, I thought that I
would go for the high-level first, in case I am missing something
obvious. I am ready to try building a more thorough test case and file
it, if needed however.

Thanks in advance for any help,

Christian
_______________________________________________
mapserver-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapserver-dev

[Steve Lime]

A small test case will really help if you can create one that way we can try independently
of MS4W. As I read this it seems that you're doing a rect query on inline shapes. I don't
recall if that code changed a bit in 5.4 or not. Perhaps Tamas can confirm.

Steve

>>> On 11/6/2009 at 12:00 PM, in message
<[hidden email]>, Christian Jauvin
<[hidden email]> wrote:

> Hi everyone,
>
> I am currently developing a Python-MapScript based web-mapping
> framework (http://dracones.surveillance.mcgill.ca) that worked fairly
> well with earlier versions of MS (MS4W < 3 on Windows, and
> package-based MS ~ 5.2 on Linux). This week I started playing with
> Python 2.6 (looking, among other things, to port my framework from
> mod_python to WSGI), and so it lead me to the latest beta of MS4W,
> which I read has a version of Python-MS built for it. I am currently
> using the Beta 7 of MS4W 3. I originally posted this to the MS4W-users
> list only, suspecting that my problem was specific to it, but I was
> then advised to post here as well, as it could point to a deeper MS
> issue.
>
> I have noticed a strange behavior with the queryByRect function,
> different than what was before: when I programmatically add features
> to a point layer and then try to retrieve a subset of them with
> queryByRect, getNumResults gives the correct number of retrieved
> features, but then the set of shapes returned by
> layer.getFeature(layer.getResult(i).shapeindex) is not right. The best
> way to explain the problem is this example: when I query for three
> very distinct features, what I get is this:
>
>  [<mapscript.shapeObj; proxy of <Swig Object of type 'shapeObj *' at
> 0x01EC71E0> >,
>   <mapscript.shapeObj; proxy of <Swig Object of type 'shapeObj *' at
> 0x01EC71C0> >,
>   <mapscript.shapeObj; proxy of <Swig Object of type 'shapeObj *' at
> 0x01EC71E0> >]
>
> The first and third objects seem to be the same, according to their
> pointers. No matter what query I try to perform, there is always a
> similar problem occurring: some pointers seem to be pointing to shared
> features, whereas they shouldn't (at least from what I understand).
>
> I understand that this problem description may not be terribly helpful
> since it may be hard to reproduce, but given that it would take time
> to abstract away the suspicious code in my framework, I thought that I
> would go for the high-level first, in case I am missing something
> obvious. I am ready to try building a more thorough test case and file
> it, if needed however.
>
> Thanks in advance for any help,
>
> Christian
> _______________________________________________
> mapserver-dev mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/mapserver-dev

_______________________________________________
mapserver-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapserver-dev

[Christian Jauvin]

Hi Steve,

In a previous message I sent a very simple Python script along with a
mapfile, that showed the problem (independtly of MS4W). Did you
receive it? Both files were attached to my message.

But I also found earlier today that the MS 5.6 beta 5 patch (for MS4W)
solved this particular problem..

Thanks,

Christian



On Mon, Nov 9, 2009 at 1:55 PM, Steve Lime <[hidden email]> wrote:

> A small test case will really help if you can create one that way we can try independently
> of MS4W. As I read this it seems that you're doing a rect query on inline shapes. I don't
> recall if that code changed a bit in 5.4 or not. Perhaps Tamas can confirm.
>
> Steve
>
>>>> On 11/6/2009 at 12:00 PM, in message
> <[hidden email]>, Christian Jauvin
> <[hidden email]> wrote:
>> Hi everyone,
>>
>> I am currently developing a Python-MapScript based web-mapping
>> framework (http://dracones.surveillance.mcgill.ca) that worked fairly
>> well with earlier versions of MS (MS4W < 3 on Windows, and
>> package-based MS ~ 5.2 on Linux). This week I started playing with
>> Python 2.6 (looking, among other things, to port my framework from
>> mod_python to WSGI), and so it lead me to the latest beta of MS4W,
>> which I read has a version of Python-MS built for it. I am currently
>> using the Beta 7 of MS4W 3. I originally posted this to the MS4W-users
>> list only, suspecting that my problem was specific to it, but I was
>> then advised to post here as well, as it could point to a deeper MS
>> issue.
>>
>> I have noticed a strange behavior with the queryByRect function,
>> different than what was before: when I programmatically add features
>> to a point layer and then try to retrieve a subset of them with
>> queryByRect, getNumResults gives the correct number of retrieved
>> features, but then the set of shapes returned by
>> layer.getFeature(layer.getResult(i).shapeindex) is not right. The best
>> way to explain the problem is this example: when I query for three
>> very distinct features, what I get is this:
>>
>>  [<mapscript.shapeObj; proxy of <Swig Object of type 'shapeObj *' at
>> 0x01EC71E0> >,
>>   <mapscript.shapeObj; proxy of <Swig Object of type 'shapeObj *' at
>> 0x01EC71C0> >,
>>   <mapscript.shapeObj; proxy of <Swig Object of type 'shapeObj *' at
>> 0x01EC71E0> >]
>>
>> The first and third objects seem to be the same, according to their
>> pointers. No matter what query I try to perform, there is always a
>> similar problem occurring: some pointers seem to be pointing to shared
>> features, whereas they shouldn't (at least from what I understand).
>>
>> I understand that this problem description may not be terribly helpful
>> since it may be hard to reproduce, but given that it would take time
>> to abstract away the suspicious code in my framework, I thought that I
>> would go for the high-level first, in case I am missing something
>> obvious. I am ready to try building a more thorough test case and file
>> it, if needed however.
>>
>> Thanks in advance for any help,
>>
>> Christian
>> _______________________________________________
>> mapserver-dev mailing list
>> [hidden email]
>> http://lists.osgeo.org/mailman/listinfo/mapserver-dev
>
>

_______________________________________________
mapserver-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapserver-dev

[Steve Lime]

I didn't notice the python script at first but went through my archive and found it thanks. Given
that things work in 5.6 I don't think I'll do anything more though. Thanks for the update.

Steve

>>> On 11/9/2009 at 1:08 PM, in message
<[hidden email]>, Christian Jauvin
<[hidden email]> wrote:

> Hi Steve,
>
> In a previous message I sent a very simple Python script along with a
> mapfile, that showed the problem (independtly of MS4W). Did you
> receive it? Both files were attached to my message.
>
> But I also found earlier today that the MS 5.6 beta 5 patch (for MS4W)
> solved this particular problem..
>
> Thanks,
>
> Christian
>
>
>
> On Mon, Nov 9, 2009 at 1:55 PM, Steve Lime <[hidden email]> wrote:
>> A small test case will really help if you can create one that way we can try
> independently
>> of MS4W. As I read this it seems that you're doing a rect query on inline
> shapes. I don't
>> recall if that code changed a bit in 5.4 or not. Perhaps Tamas can confirm.
>>
>> Steve
>>
>>>>> On 11/6/2009 at 12:00 PM, in message
>> <[hidden email]>, Christian
> Jauvin
>> <[hidden email]> wrote:
>>> Hi everyone,
>>>
>>> I am currently developing a Python-MapScript based web-mapping
>>> framework (http://dracones.surveillance.mcgill.ca) that worked fairly
>>> well with earlier versions of MS (MS4W < 3 on Windows, and
>>> package-based MS ~ 5.2 on Linux). This week I started playing with
>>> Python 2.6 (looking, among other things, to port my framework from
>>> mod_python to WSGI), and so it lead me to the latest beta of MS4W,
>>> which I read has a version of Python-MS built for it. I am currently
>>> using the Beta 7 of MS4W 3. I originally posted this to the MS4W-users
>>> list only, suspecting that my problem was specific to it, but I was
>>> then advised to post here as well, as it could point to a deeper MS
>>> issue.
>>>
>>> I have noticed a strange behavior with the queryByRect function,
>>> different than what was before: when I programmatically add features
>>> to a point layer and then try to retrieve a subset of them with
>>> queryByRect, getNumResults gives the correct number of retrieved
>>> features, but then the set of shapes returned by
>>> layer.getFeature(layer.getResult(i).shapeindex) is not right. The best
>>> way to explain the problem is this example: when I query for three
>>> very distinct features, what I get is this:
>>>
>>>  [<mapscript.shapeObj; proxy of <Swig Object of type 'shapeObj *' at
>>> 0x01EC71E0> >,
>>>   <mapscript.shapeObj; proxy of <Swig Object of type 'shapeObj *' at
>>> 0x01EC71C0> >,
>>>   <mapscript.shapeObj; proxy of <Swig Object of type 'shapeObj *' at
>>> 0x01EC71E0> >]
>>>
>>> The first and third objects seem to be the same, according to their
>>> pointers. No matter what query I try to perform, there is always a
>>> similar problem occurring: some pointers seem to be pointing to shared
>>> features, whereas they shouldn't (at least from what I understand).
>>>
>>> I understand that this problem description may not be terribly helpful
>>> since it may be hard to reproduce, but given that it would take time
>>> to abstract away the suspicious code in my framework, I thought that I
>>> would go for the high-level first, in case I am missing something
>>> obvious. I am ready to try building a more thorough test case and file
>>> it, if needed however.
>>>
>>> Thanks in advance for any help,
>>>
>>> Christian
>>> _______________________________________________
>>> mapserver-dev mailing list
>>> [hidden email]
>>> http://lists.osgeo.org/mailman/listinfo/mapserver-dev 
>>
>>

_______________________________________________
mapserver-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapserver-dev