This is related to removing event listeners the first time it is clicked.

This depends on upstream mapbox/mapbox-gl-js#2716

It would be good to add custom fields which are derived from existing fields. Could use some kind of simple variable substitution like: Location: {{village}}, {{region}}, {{country}}

We need a settings dialog for deciding which fields are visible in the detail / report views, with also the option to rename the field names to something more human-readable.

Should be a list view with toggle switch and text field for entering new name.

should be easy to use redux-persist to persist some of the state to localstorage - the main thing is keeping config between sessions.

something is weird with the css for the print view.

Currently filtered markers appear as faded transparent markers in print view like they do in the regular view.

Feature Request:

Currently, it seems that the FilterPane can only be populated using a best guess algorithm or by explicit user selection via settings. Allow the MapFilter props for filterFields and filters to be controllable. The idea behind this would be to:

• Supply the MapFilter component with a set of filters that initially appear in the FilterPane
• This set of initial filters should be able to take an initial value as well, i.e. checked or not checked for discrete filters, or a date range (value and min/max) for date filters.
• Consumers should be able to listen for changes to these filters.

The info bar across the top should update to describe the currently filter. Currently the text is always the same.

ODK Collect returns data from multi-select fields as space-delimited fields, e.g.

{impacts: 'deforestation contamination loss_of_biodiversity'}

This is a little tricky to use heuristics to recognize, so short-term we will probably need to manually define which fields are space-delimited.

They are also tricky to filter. We are restricted in this new version by Mapbox's filter language which only does exact matches on fields - for performance reasons I assume.

I think the solution is to flatten these fields into multiple fields e.g.:

{
  'impacts.0': 'deforestation',
  'impacts.1': 'contamination',
  'impacts.2': 'loss_of_biodiversity'
}

Then set the same filter on each of those fields. With datasets when many options are selected in a multi-select this might be a performance issue, but we will have to see. In many datasets there will only be max 3-4 options selected - in our field analysis we can track the max number so we only need ot set that number of filters.

The map starts acting weirdly when you click cancel from print view.

Spotted so far:

• Roboto (Google Fonts) in #54
• Intl polyfill
• resizer.digital-democracy.org
• Mapbox style mapbox://styles/gmaclennan/cio7mcryg0015akm9b6wur5ic
• Vector tiles (source defined in style)

Feature Request:

Allow the following map properties to be controlled (i.e. being able to supply initial values for these and subscribe to the map to listen for changes to these properties)

• Map Center Point (lat/lng) (listen for move changes)
• Map Zoom (listen for zoom changes)

This is critical for users where a small set of custom tiles is being used and not all zoom levels are provided with the tile set.

Displaying images could be more efficient. We use our own resizing service which is running on http://resizer.digital-democracy.org/ to get thumbnails and previews. We need an <Image> component that uses [react-dimensions](https://github.com/digidem/react-dimensions] to choose the best size to request. Our resizer currently whitelists certain domains - we should detect 403 errors and just load the original full-size image in that case.

We could speed things up more by keeping track of sizes of image that have been loaded and when requesting a larger image show a smaller one that will be in the browser cache first whilst the larger version loads.

The print view should include the coordinates for each point. Template needs to be updated.

• Replace image with generic icon
• Display loader.gif
• Parse EXIF headers and rotate with CSS
• Block simultaneous download requests

Partially completed in master...spacedogXYZ:8af98e7

We should better fit the left column in detail view so that it auto-fits the contents, rather than both columns being 50% width each.

The map in print view starts zoomed all the way out and in the wrong location, so that you need to zoom in and move the map to see any of the points.

Currently we have no way of showing linked video

Report view should be similar to the print view in the original Mapfilter:

In this new version the report view is going to be live-filterable, so we need to use react-virtualized so we don't render every feature, only the ones in the viewport.

Needs a selector that uses feature-filter to select filtered features to render.

@jlev can you update the CHANGELOG.md with the changes as you go? I've been trying to standardize the CHANGELOG is all our repos to this: http://keepachangelog.com

Let's keep semver, as much as it makes sense for a front-end app like this. I don't know what a breaking change would be, but minor for features added, patch for bug-fixes. I think as you do this work right now we shouldn't call it a release, but probably each PR should include an update to the CHANGELOG with the feature added under "Unreleased" and a link back to the PR.

Currently the sample data is hard coded in. We need to implement async action creators for loading geojson from a url and parsing (dates need to be coerced).

We should use Auth0 to get auth tokens for loading a geojson from Github or other authenticated service.

We need an "empty" page that allows the user to select a local file, enter a URL, or load the sample data.

Clicking on a photo in detail view should show a full-page photo.

Currently you need to print preview first then print.

Currently content scrolls within a card. I think it would be better to scroll the whole card and add a toolbar across the top with some actions e.g. print (a single page) or save as PDF. Like Google Docs:

We should have a settings page for sharing config, which will create a url with the config encoded as json and base64-url as a url parameter, then a user can just click that link and import the configuration settings.

In Google Doc

Right now the marker sprites need to be added to any vector tile style that is used. mapbox-gl-js currently only allows one sprite sheet per style, so you need to use Mapbox Studio to add the marker sprites to the style online. Ideally we want to enable any custom style to be used as a background in MapFilter, without modifying the sprites.

My current strategy for solving this is to concatenate the remote sprite file from the map style with the sprite for the marker sprites, using concat-sprites. This can be done dynamically in the browser, but getting the new merged sprite into mapbox-gl-js is a challenge. We could serve the sprite over an objectURL but mapbox-gl-js currently expects both the json and png to share the same url root. We could serve both using Service Workers, but with limited browser support, or create a fork of mapbox-gl-js and write a custom image_sprite.js. I'm thinking the latter might be the easier (hacky) solution for now. Hopefully Mapbox will support dynamic sprites in the near future.

In Safari (and sometimes in Chrome) the "Select dates" button needs to be clicked twice

We need a settings dialog to change which fields can be filtered. Currently we make a best-guess choice of filters to show.

This should be a dialog that shows a list of all filterable fields with a toggle switch to turn the filter on or off.

Should also have options to define which fields are used for:

• color coding
• titles
• subtitle

To discuss:

I was able to get pictures to show by mapping picture: <string> to picture: { url: <string> }, then using the fieldTypes prop to tell MapFilter that pictures.url was an image. Is there an easier way to do this, or is this THE way?

We can encode the current filter using base64-url and store it as a url parameter, then add a hook in componentDidMount() to load it from the url and update the store. The map state is automatically stored in the url too. URLs will be long, so we should only generate when needed - probably some kind of share button on the app bar. Could also use a link-shortening service.

We can use react-match-media to render the page specifically for printing. This will be necessary since the report view will not render all features by default. react-match-media allows us to hook into the user print event and render the page specifically for that, see: https://www.tjvantoll.com/2012/06/15/detecting-print-requests-with-javascript/

Print view for the map page will be trickier. We probably need to show a modal that allows tweaking the layout on the page before printing. Longer term we will want to tile larger maps onto multiple sheets, using map.getCanvas().toBlob() multiple times to get png tiles and printing one per page.

Writing this app has been a lesson in how quickly a Backbone / MVC app can race out of control and become hard to maintain. v1.0 will be a re-write using React and Flux. By building each part of Mapfilter as an individual component with clearly defined specifications it is much easier for others to contribute without breaking other parts of the app, and it means that we can re-use different components to mix-and-match our own custom builds of Mapfilter for different use cases and integration with a broader "monitoring platform" according to local community / partner needs.

The shortlist I have for a framework for flux architecture:

• Facebook flux which is not really a framework, but an idea for architecture.
• Flummox
• Alt
• Minimal-Flux
• Reflux

A lot of these I think use too much "magic"- especially reflux - and whilst that can minimize typing, it is another thing to learn. Tom MacWright from Mapbox in this talk (terrible quality) explains why they are using just vanilla Flux from Facebook.

For me minimal flux seems the best option right now. It provides some minimal helpers around the core flux ideas, and the source is simple to understand and it is minimal enough that we do not need to become dependent on the framework moving forwards.

There are some helpful React components already built:

• React-Leaflet
• Fixed Data Table which can create fast scrolling lists and image grids (I had previously created this image grid in D3, but this version uses the same concepts but is way more developed)

For filtering I think we should keep using crossfilter because it is still faster than anything else.

We need a way to pass filter definitions through the app. Because of the one-way data flow the filter component (the UI for building the filter) needs to pass the filter query through the dispatcher to crossfilter. Feature-Filter is a simple way of defining features and should meet our needs. I'm not sure if we should follow their approach of building a string and eval'ing, or build a mini language interpreter.

For the UI I have created some mockups in #14 using Google's material UI principles. Without a UX designer on the team right now I think this is the easiest way of us getting some way towards a good UI. We can use material ui which is a collection of material design components implemented in React.

The rough architecture will be, which each being its own self-contained compent:

• Views - which just render the list of data they are passed:
  • Map View (wrap react-leaflet)
  • List View (wrap fixed-data-grid)
  • Photo View (wrap fixed-data-grid)
  • Print View (will need to write our own component)
• Filter - need to be able to choose fields to filter by, and then filter continuous or discrete data as in the current version of Mapfilter
• Layer chooser - need to be able to choose which background tiles to use, and load and choose overlays to filter by
• App bar / toolbar.

We will have a central store wrapping crossfilter which will respond to events from the filter component and return a list of filtered points.

I will start laying down some bare-bone architecture in the v1.0.0 branch soon.

We don't have a filter component for numeric fields yet. Simplest could just be two numeric form fields for min & max, but better would be a slider.

In print view each icon should have a letter on it, so that you can reference the map from the individual pages on each point.

Expected behaviour:

When you open the settings "Change Filter" and turn off a filter for a field, it should be removed from the UI, and any filters that were set for that field should be removed.

Actual behaviour:

Turning off a field with filters set in the filter settings does not remove it from the UI. After turning it off once all the filters are removed it magically disappears.

Possible solution:

Use the UPDATE_FILTER action to reset filters for a field that is removed from the UI.

This seems to be related to the i18n library used for translating strings when there is no translation, but the field contains a .

There should be a map icon with the correct colour in the top left of the info pane:

I have started a redesign following Google's material design principles. The aim is improve the user experience and add new functionality, such as a photos and list view. I am also designing with mobile in mind, so that this app will also work on mobile.

There is still a lot to figure out, but an initial interactive prototype is here:

MapFilter redesign interactive prototype

• Map View
  • Map marker hover
  • Map marker click
  • Map photo zoom
• Photo View
• List View
• Print View
• Filter menu
• Map layer chooser
• Login screen

All feedback welcome. Discussion here. You can also add annotations to the prototype.

Feature Request:

There seems to be a fieldMapping attribute that can be used to declare which fields appear as title, subtitle, etc on feature popups on the MapView and in the ReportView. Can this mapping be exposed as a controllable prop such that one can select which field to use as title, subtitle, etc?

Feature Request:

Allow the options for discrete filters to have custom labels. This would allow for translations or custom formatting to be applied.

Specifically, the issue I am having is with the "Happening" field -- a special field that contains both a label and a color in the format ${label}^${color}. The displayed label shows the full string, where I would want to have the ^${color} portion removed for display purposes. Having the color information is important, though, for correlating the field color with MapFilter settings.

We should have a way to download the data as a SHP file, to be used in other GIS software.

We should support custom tile layers and have initial options that include both satellite tiles and vector tiles. We should store background tile options on state so that we can support dynamically adding new layers and sharing config that has different tilesets.

To do this with the flexibility to accept any style layer we will need to fix #51 first.

Should not be too hard. Will need to flatten and then define appropriate styles for displaying on the map. The latest version of mapbox-gl-js supports data-driven styling of fill-color: mapbox/mapbox-gl-js#2629 so we can change polygon colors according to filter data.

Currently we assume there is a photo linked from each feature. We need to display the feature details with no media, and also show multiple photos in detail view using nuka-carousel

We need to wrap all text in translate fields. Best library for this is react-intl.

Right now we load the full-res image in the info pane every time we hover a point. This can take a while to load since original images are about 2Mb. We should load a thumbnail image. Depends on digidem/wapichanao-data#2