search

MapServer / MapServer-import

3 stars 2 forks source link

Merge msDrawMap() and msDrawQueryMap()? #774

Open tbonfort opened 12 years ago

tbonfort commented 12 years ago

Reporter: dmorissette Date: 2004/07/14 - 04:17

I spent several hours today trying to reproduce/isolate/debug the problem
described in bug 773.  It turns out at the end that this bug is probbaly caused
by some things that aren't properly initialized in msDrawQueryMap() and that
were implemented only in msDrawMap().

When I look at both functions, it seems that it would really make sense to merge
them into a single function with a querymode true/false flag. The only
difference between the two should be that in one case we hilight the layers that
have query results and in the other case we don't, correct?  At the moment the
two functions are completely out of sync with respect to WMS, WFS, and other
custom rendering stuff that's been added only to one of the two, I think that's
just a source of potential bugs.

Does anyone know of any reason why both functions could not be merged into a
single function?  For backwards compatibility we would maintain the same
separate calls in MapScript. We would only change the core functions.
tbonfort commented 12 years ago

Author: sdlime Date: 2004/07/14 - 06:27

I would actually like to do away with the QUERYMAP object altogether. It was and
still is a kludge. Rather I would like to be able define some sort of a drawing
"state" like NORMAL/SELECTED/HILITE and tie that "state" to specific STYLEs.
That way a developer could define one set of STYLEs for a state=SELECTED and
another for state=NORMAL or whatever. That would allow a great deal more
flexability in displaying the results of a query. This change would probably not
be more difficult than merging, but would be a big change for the end user,
although a change for the better.

Steve
tbonfort commented 12 years ago

Author: dmorissette Date: 2004/07/14 - 18:19

I like the idea, but does this mean that there would have to be multiple styles
for every class that's queryable? In most cases all we want to do is hilight
selected shapes in red, so it would be a pain if we had to repeat the same
hilite style with "COLOR 255 0 0" everywhere in the mapfile. 

Could there still be a default behavior (using a default style somewhere) for
the cases where there is no explicit style set?
tbonfort commented 12 years ago

Author: sgillies@frii.com Date: 2004/07/14 - 18:52

Default styles: i second that.

And couldn't selected/highlighted states be built-in classes for queryable
layers?  I think this could help to collapse the map and query map into
one object.
tbonfort commented 12 years ago

Author: sdlime Date: 2004/07/19 - 17:29

Built in styles, not built in classes.
tbonfort commented 12 years ago

Author: dmorissette Date: 2004/11/22 - 19:38

*** Bug 1078 has been marked as a duplicate of this bug. ***
tbonfort commented 12 years ago

Author: dmorissette Date: 2004/11/22 - 19:39

Copying comment from Steve in bug 1078:

> I'm thinking we may want to abandon msDrawQueryMap and just use the presence or 
> absence of search results to trigger query map production in msDrawMap. 
> Wouldn't be too hard.
> 
> Steve

Note that it's too late for this in 4.4, but that should be a priority for 4.6
tbonfort commented 12 years ago

Author: sdlime Date: 2007/03/29 - 18:05

Fixed in 5.0... There still may be other merging to do, or better optimization 
but that can be tracked with new bugs.

Steve