[mapserver-dev] MS 5.4 - Python-MS - queryByRect strange behavior
Steve Lime
Steve.Lime at dnr.state.mn.us
Mon Nov 9 14:14:06 EST 2009
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
<aa5471510911091108v41d85d9fid2cabd33f9c457dc at mail.gmail.com>, Christian Jauvin
<cjauvin at gmail.com> 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 <Steve.Lime at dnr.state.mn.us> 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
>> <aa5471510911061000v380ab8fbld95a294e4b784496 at mail.gmail.com>, Christian
> Jauvin
>> <cjauvin at gmail.com> 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
>>> mapserver-dev at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/mapserver-dev
>>
>>
More information about the mapserver-dev
mailing list