PantherView
PantherView copied to clipboard
pittcsc
Pin location error: no location or outside boundary
We should collect the pins that don't have a location given in datasets that do provide locations. By default they are set to something like 0,0, putting them somewhere in Ghana. Also, some pins fall outside the boundary, so we want to put them in Cathy, too, probably. In our WPRDC data collection function (#17), we should have a check for the lat and long data, and default the location to the cathedral of learning.
I agree with collecting the "unmapped" pins (i.e. ones with garbage location data) onto Cathy, probably with a faded icon or other indication that their map location is not accurate. I'm hesitant to do that to pins that are merely outside of Oakland but still in reasonable locations in Pittsburgh. Some of them are certainly miscoded in the WPRDC data, but others indicate cases where the crime occurred within Oakland but the arrest was made elsewhere. I think that's reasonable to display as-is, but if we really want them mapped in Oakland I think it would be the least disingenuous to place them on the closest point of the Oakland border.
Also we should consider broadening the bounds to include at least a couple of blocks around Oakland (once we have GIS up and running instead of just filtering by reported neighborhood) so we're not cutting off points that are just on the wrong side of the street or the like.
I don't think we should put them into Cathy, it would confuse a person not familiar with the details. I think we should just discard them since they don't really matter.
Do they really not matter, though? I'd rather report everything, even if some have (clearly marked) incorrect locations, than simply ignore a report because the location was incorrectly coded.
^ same. I think we might need to have something like a little pocket in the bottom left corner that could expand to show all the pins without data information.
As for pins that start outside of Oakland and manage to make it in--this really stretches the boundary of our map. We want to limit it the Oakland area: to pretend that's the only neighborhood that exists. My vote would be to either collect them with the unlabelled pins, or to, as you suggested, map them on the border such that it was clear it spawned outside Oakland (rather than that spot on the border).
And, yeah, we'll keep track of GIS edge cases, but that's also on the WPRDC
@vonbearshark I was thinking less edge cases and more a feathered border. For example, right now if someone was mugged at the bus stop outside Seoul Mart (at 5th and Neville, NE corner) we wouldn't be reporting it because that's technically Shadyside according to the data, but if they were mugged at the bus stop on the opposite corner (5th and Neville, SW corner) we would report it as an Oakland incident, and that seems counterintuitive (and actually disagrees with the neighborhood labels on the street signs, which say Oakland stops at Morewood.
Look, we just need to make it more illegal to mug people in those locations.
If we set a sort of padding around the Oakland neighborhood, wouldn't that fix the zoom problem and this problem? Also for this problem specifically, wouldn't we still report it, it just wouldn't be mapped (would be in our limbo tab thing proposed)? Or are you talking about how we get the Oakland data from the WPRDC server? Because that could be trickier?
It's more forward thinking for our plan to use GIS instead of relying on the NEIGHBORHOOD field, in that our GIS boundaries should be padded slightly. It doesn't matter in the meantime.
Right now we run a light check for null at least and default to Cathy. We could check for out of bounds and null in the same place and do something with these pins (put in some kind of UI container, maybe a pin aggregation?) instead: https://github.com/Pitt-CSC/club_project_2017/blob/master/main.js#L215
@mbilker do you think you could tackle this one? Would fit right into that awesome function you whipped up
Right now my data call function branch just maps nulls or 0,0 coordinates to Cathy's location. Though, I only encountered 4 records with null locations.
Right, instead of mapping to Cathy, we'd want to have some kind of UI container (maybe a scollable box in the top-right corner?) for all the pins without a proper home. We also want to check if the pins fall within Oakland, and map the ones that don't to this as well (should be able to use our map bounding box for this somehow). Else we could add the pins to the map as normal.
I think once they're removed from the map it makes less sense to have them be pins at all. Perhaps we could turn them into an accordion list or something instead? It would be pretty trivial to turn the divIcon pins into standard icons to associate with the text entries.
@mbilker I'm walking back on having the null coordinates in the separate array. We're setting up a Data tab that will display text representations of all the data, and it's so much simpler to have one array. What if we just gave it a .isMapped property, so we can use it for conditionals when filtering, etc.? What do you think? Does that set you back?
That is perfectly fine.
On Sun, Jan 29, 2017 at 12:07 PM, JJ Naughton [email protected] wrote:
@mbilker https://github.com/mbilker I'm walking back on having the null coordinates in the separate array. We're setting up a Data tab that will display text representations of all the data, and it's so much simpler to have one array. What if we just gave it a .isMapped property, so we can use it for conditionals when filtering, etc.? What do you think? Does that set you back?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Pitt-CSC/club_project_2017/issues/61#issuecomment-275928423, or mute the thread https://github.com/notifications/unsubscribe-auth/ABNTbaxKwpLx0QOCcdekw1bBQGyOEQucks5rXMdlgaJpZM4Ltf9h .
I am not familiar with how I should put the box in the top right. Should I just make a separate div and use CSS to position it up there. Should I put the list below the filter list in a separate scrollable table?
I think the former would be best. We can change it later, but I think that makes the most sense.
Another thought: the same way we have .popup maybe we should have .table, or something. We will need it for when we have a tab that just displays text results (#18), and we could probably have it visualised the same way here, too. The style would need to accommodate both, but I think that shouldn't be too bad. Then we just need to either add to map with popup or append to this UI, or whatever.
Ok. I will work on this later. Currently trying to finish an English essay.
Update: We will have a .table, which you should utilize like .popup, but @GavinFreud will work out the actual implementation of converting the relevant fields to a table in HTML in #46 . You'll just need to provide a mechanism for adding this generated HTML into the non-mapped UI table (for now, just generate some easy HTML yourself)
I am generating the HTML and putting a list in the sidebar. Is that alright?
Each dataset will have a .table prop, the same way it has .popup now. That hasn't been implemented yet. But we will need a mechanism for UI itself. We need some kind of object that can take the result of calling .table() on the records that aren't mapped and adding them to that UI. We should also provide a way of filtering them out, just like we do with the map.
@vonbearshark I am wondering if I should do it something like mbilker@13af60d2664392981db32d3f49693f72d81400d2
Two things: 1. I think this should be it's own UI, aligned on the right of the screen, opposite the current sidebar. 2. I think it should be a little more complicated than that--for example, how would we apply filters to this? We should be able to newUI.add(marker) and newUI.remove(marker). add can just append, but remove might be a little trickier. We'll want to add and remove at the record or marker level. The actual HTML creation is great, though
If more data sources are added in separate constant objects (e.g. WPRDC_DATA_SOURCES) then another reference so determine which object the marker belongs to so the display function can call the right .table method (or .title as I have it right now for testing).
That looks great. Try and make the var names a little more appropriate, but the approach looks exactly like what we need