search

nakijun / morisoliver

Automatically exported from code.google.com/p/morisoliver
0 stars 0 forks source link

Filter needs to be dropped when other identify tools (regular, poly, single or identifyBuffer) are selected #218

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
When putting together a MuniMapper OLIVER viewer that includes both the filter 
tool and the new abutter's tool (identifyBuffer) is was realized that the 
filter once made is never dropped, only replaced with a new filter.  This makes 
the abutter's list tool function differently than intended.  This also affects 
the other 3 types of identify tools. 

I thought about the cases and when it makes sense to drop the filter.  
Currently the filter is never dropped, only replaced with a new filter that the 
user specifies.  This doesn't work well with our abutter's tool and I think is 
an oversight in terms of how it interacts with other identifies.  

I think the only thing that makes sense (and hopefully is simple to do?) is for 
any filter to stay (through print, export, wms, permalink) active UNTIL another 
identify tool is clicked (there are 4 possible - regular, poly, simple or 
identifyBuffer). Currently those 4 act upon the filtered features.  For 
example, if the user does a filter to look for single family homes sold for < 
$100,000 then tries to do an abutter's list the abutter's list tool will only 
act on the filtered featureset.  When another identify tool such as abutter's 
list (identifyBuffer) is clicked the user will wanting logically to start 
without a filter and query on everything. (If they really want a different 
filter they can refine their filter.) 

The alternative to dropping the filter for them is to have a clear filter 
button but the user would need to remember to use this and it would be 
particularly difficult for them to remember in our case of transparent parcels 
polys when they can't easily see the filter affecting the map.  (it does affect 
the map, if we use the change symbology color swatches we can see that).

So, when regular, poly, simple or abutters "identify" tools are activated, the 
filter should be dropped from the filtered layer (only one filtered layer, 
specified in toolConfig_sample_filter.js) and the map should be redrawn to show 
all features in the filtered layer. 

That would mean that in this viewer: 
http://maps.massgis.state.ma.us/map_ol/dor_la3.php after a filter is done for, 
say, only single family homes between 0 and 150,000 and only red dots that fit 
the filter are on the map, when the user clicks regular identify tool "i" the 
map should redraw to show all the dots again.

If that is possible! Does that make sense?  Any other concerns?

Original issue reported on code.google.com by Aleda.Fr...@state.ma.us on 29 May 2013 at 5:32

GoogleCodeExporter commented 9 years ago 
Something else to consider is how the filter builder attempts to populate 
itself w/ any previous filter builder options you may have selected.  I.e. if 
you pick options and hit apply.  Then you close your filter builder.  Then you 
relaunch it.  I *believe* that the filter fields will start up w/ values that 
match what you applied in the filter.

If we were to revert the layer back to its non filtered state as I think you 
are suggesting, we would probably lose this ability.

Original comment by cpl...@gmail.com on 30 May 2013 at 4:28

GoogleCodeExporter commented 9 years ago 
That is how it happens now but I'm willing to lose that and make everyone do a 
filter from scratch each time if that's what's required. 

Otherwise we're into this identify, then identify getting-a-subset thing that 
no one will understand.

Original comment by Aleda.Fr...@state.ma.us on 30 May 2013 at 4:31

GoogleCodeExporter commented 9 years ago 
Let's move our conversation here instead of offline, please.

Original comment by cpl...@gmail.com on 4 Jun 2013 at 7:45

GoogleCodeExporter commented 9 years ago 
Note - Charlton and Aleda made workaround.  I'll mark this won't fix?

Original comment by Aleda.Fr...@state.ma.us on 19 Jun 2013 at 8:07