response to multiple section selections is inconsistent

[glw]

When selecting multiple "sections" results to not match actual sections clicked.

When selecting a "section" in area 22 (RED) a section in area 23 is highlighted (result in GREEN)

[smcalilly]

this happens when two sections have the same number but exist in a different area, range, or township. right now, the javascript and haystack facets don't connect a section with an area, so it'll just treat the duplicate section number as the only one.

for example, here are two tooltips for two separate sections:

they have the same section number but are in different ranges. you can see the section in the second image isn't highlighted.

this might be a tricky bug to solve because the facets in the query string also don't have knowledge of the section/area relationship (and it looks like the query string is used to highlight the sections on the map). i don't think haystack has knowledge of this either.

there are a couple of things we need to do to fix this:

• hook into django haystack facets to create a relationship between section and area (and maybe range and township?)
• rework the javascript logic to work with that dependency

if only we could send some dictionary-like key/value pair through the query string. maybe like:

• section_exact:31__area_exact:24__township_exact:37__range_exact:13
• section_exact:31__area_exact:22__township_exact:11__range_exact:8

and then parse that on the backend to facet. and then when the page reloads, use the query params to highlight the correct geojson features (this page reload bit is how the js currently works).

[smcalilly]

@fgregg can you take a look at my above comment and let me know if you have any good ideas to solve this?

[fgregg]

what about simply renaming sections to be like {township}-{range}-{section}.

if we felt like the longer names messed up the UI, we could process them to only show the section bit in the ui

[smcalilly]

@fgregg that's a good idea. would we need to rename these sections in the database, or just rename them on the fly? i'm leaning toward the first option, which would require us to change the data in the database and then reindex, then figure out how to work with them in the searching / UI.

[fgregg]

yeah, it think renaming them in the db.

[smcalilly]

@fgregg actually, I don't think we can rename the sections like that because the sections field are an IntegerRangeField type.

Since a section can be a range of integers, I'm not sure how we can create a range of concatenated {township}-{range}-{section} sections.

There might be a way to solve all of this in the javascript logic for the map but not sure yet — I'm still figuring out the code so I'll let you know.

[smcalilly]

@smcalilly double check this isn't a bug with the list view.

potential solution: limit the ability to search / enforce requirements. @jim-z to think more about that.

[jim-z]

Search on section should not be allowed unless a specific area is selected first. Area numbers are unique and sections repeat within each area. Might be easiest to do away with these little interactive maps altogether and instead use dropdowns the enforce the area section relationship (i.e. user selects area and then section drop down produces list of section options within that specific area). Either way, seems like it would likely require creating a new index field that stores the area-section combination for each record...