joshuabowers / gun_fail Goto Github PK

The current database contains nearly 1000 recorded incidents. While this is not a terribly significant amount, the server can be slightly unresponsive for a short period if tasked with returning all of them to the UX. Placing markers for each incident (even coalesced) is cumbersome and difficult to properly visualize, which is one of the underlying tenets of this application.

Markers are still desirable at closer zoom levels (though it would be really neat to replace them with custom icons associated with a tag); however, at further zooms, some other display mechanism would be desirable. One idea would be to replace the pins by a series of circles, the radius of which being indicative of the number of incidents collocated. Ideally, the circles would be visible even when fully zoomed out, which suggests that they would also scale based off of the current distance between two points at the current zoom level.

Rather than do wonky math to make crazy circles work, how about some sort of density projection, with transparent overlays? Still would utilize circles, but different colors would represent a different number of collocated incidents. As these would be transparent, as the number of circles increased, the displayed colors would shift. Still might become laggy, though.

Google's APIs for geocoding and timezones is a lot nicer than geonames: cleaner, easier to use, and a hell of a lot more accurate. Shouldn't be terribly difficult to switch over to using them. The usage rates are not bad, and if my searches are accurate, I should be able to cache the results as long as I only use them with google maps. Which is the intent.

These would provide a mechanism for automatically tagging incidents: each template would contain a series of words (possibility: either any of the words is valid, or all of the words must be present) to look for within each incident's description. Matching incidents would then have a tag associated with the template applied to it.

For example: a template on the word "cleaning" could then apply the tag "Cleaning My Gun". A more complex scenario would be to have something like "kid, child, children" map to "Kids do the Darnedest Things".

A particular incident could have multiple tags associated with it.

Hat Trick: allow tag templates to specify a color, and possibly a decal image, to associate with each tag; this would allow for the maps to become much more colorful and interesting.

While the coffeescript is not terribly nasty, it isn't well organized. It could benefit from some small refactoring to better organize the various operations which are being performed.

Well, assuming the Prime; Antimeridian is a certainty. Currently, the boundary coordinates returned by Google's geocoding service for the US define a box whose southwestern vertex is west of the Antimeridian (at about 172 degrees East); the northwestern vertex is on the other side of the world (at about 66 degrees West). While the box thus formed makes sense, it crosses the Antimeridian, and this, apparently, screws up $within queries.

It might be possible to avoid more complicated nonsense if I can figure out how to make the newer geoJSON queries work. However, what appears to be a valid geospatial query is currently claiming to be malformed. Progress stymied.

The nominal way to fix the above is rather unfortunately complicated to do in Mongoid, as there is no good way to chain criteria together. Essentially, on the normal 2d index, any box which crosses an inflection point on the surface would need to be split into two separate searches: from the normal southwestern vertex to the projection of the northeastern vertex on the meridian; and from the projection of the southwestern vertex on the negative meridian to the northeastern vertex. Having two separate queries is troublesome to work with; theoretically, it should be possible to create a way to chain multiple queries into a single enumerator; execute everything from the first until it is exhausted, and then switch to the second. Not sure how to do that in Ruby, though...

Currently, incidents which occur at the same Location (e.g. two incidents which occur in the same city; currently not tracking incidents based on street locations) would get separate markers on the map; however, these get pinned over one another. Google maps is probably showing all of the markers, but only the last one added will be interactive.

A better approach would be to combine all such incidents into a single marker, the info window for which would then display a list of the events. (Eventually, this could then also include TagTemplate icons as part of each entry.)

This would necessitate the following changes:

• More tightly bind Location and Incident. Currently, these are only loosely bound together, as Location was introduced to cache geonames queries The proper Mongoid way would be to have Incident embedded inside Location, and perform searches based off of Location. This would, unfortunately, make searching via other mechanisms --- such as by tags --- more cumbersome. Also would make generic area searches --- say by city, regardless of address within the city --- harder to coalesce. Binding the two through a reference would make these latter cases easier to handle, but would slow lookups.
• The current js I'm using to generate markers would need to first iterate over locations, and then iterate over incidents within each location.
• The info window template would need to change, to provide a list of all incidents, rather than a single instance.

The current methodology for adding incidents to the map is rather slow when presented with more than a handful of incidents at a time. I.e., rendering the entire dataset as it currently exists (only about 1000 items) takes a few seconds. It might be possible to speed this up in a few different ways:

• Break the single AJAX boundary search call into smaller chunks, processing each subset individually, allowing the map to refresh before handling the next chunk.
• Cull already handled markers from the incoming result set; these markers have already been processed on previous calls, so no need to waste extra cycles processing them again. Note, this probably will not work too well with the previous option.