jeffersonheard / ga_bigboard Goto Github PK

When setting the baselayer for a room to OSM there is a javascript error:

Uncaught TypeError: Cannot read property 'div' of undefined OpenLayers.js:935

And the baselayer is not loaded.

There was an issue I found with using a WMS overlay as a baselayer where, in bigboard_mobile when it was calling eval on the default creation options it would throw errors. I changed it to be more like in overlay.js and it seems to work fine now.

Fix will be in next pull request.

This is an idea for a new feature of the Bigboard, which is the ability to publish notifications for certain roles (or all) in a given room. Notifications would have an originator, subject, body, location/zoom and importance (severity) level. This would be tied into the notifications system I have been working on at the CRC, but only if it is installed in the site. I am working on this feature now.

I created a WMS overlay for noaa radar with the following options:

{
    url:'http://nowcoast.noaa.gov/wms/com.esri.wms.Esrimap/obs',
    layers:'RAS_RIDGE_NEXRAD',
    transparent:true
}

This overlay works fine as an overlay, but if I try to make it the base layer for a room I get 404 errors because it is trying to request relative to ga_bigboard. Here is the url it tries:

http://geoanalytics.crc.nd.edu/ga_bigboard/%7B%20%20%20%20url:'http://nowcoast.noaa.gov/wms/com.esri.wms.Esrimap/obs',%20%20%20%20layers:'RAS_RIDGE_NEXRAD',%20%20%20%20transparent:true%7D?SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&STYLES=&FORMAT=image%2Fjpeg&SRS=EPSG%3A3857&BBOX=-11.25,-2.8125,-8.4375,0&WIDTH=256&HEIGHT=256

or

ga_bigboard/{ url:'http://nowcoast.noaa.gov/wms/com.esri.wms.Esrimap/obs', layers:'RAS_RIDGE_NEXRAD', transparent:true}

The options are not being evaluated like they are for an overlay and it is looking for the baselayer WMS at the ga_bigboard url.

When a room's baselayer is set to Google Terrain, the baselayer is not able to zoom in past level 15. This is what was causing the issues with the participant locations and annotations not sticking to the correct place on the map at close zoom levels. I believe the other layers are still zooming closer, but the baselayer is stuck at 15.

This may not exactly be a bug, but selecting several annotations, one after another then clicking delete deletes them all rather than just the last one selected.

If I select one or more annotations, then click any other mode, do some actions, then click delete selected it deletes all the previously selected ones regardless of whether I am in select mode when clicking delete.

If I select one or more annotations, then go to some other mode, do stuff, then come back to select and select more then click delete it deletes all the initially selected annotations as well as the more recently selected ones.

After being away from this project for a while, I tried to set up bigboard in a new VM and got an error while trying to migrate. The error is a result of 0001_initial.py line 389. I remember this had something to do with the incorrect representation of a geodjango point object, but I can't remember exactly what the correct solution was. Could you shed some light on this if you remember? Thanks.

The zoom buttons in the main application do not zoom in/out at the same rate as scrolling or double clicking.

When there is a user with multiple roles in a room attempting to share an overlay that is available to two or more of the roles to which the user belongs it fails to create the shared overlay saying:

MultipleObjectsReturned: More than 'Overlay' matched 'pk=2'.

Doing an api request on an overlay object gives this error:

More than one resource is found at this URI.

And fetching them all has multiple copies for each overlay that meets the above criteria.

The issue is somewhat related to issue #16 and is caused by line 30 inside ReadOnlyMyRoleAutorization in api.py. The filter is causing duplicates to appear.

There are calls to a global variable bb in overlay.js. This does not work for Dashboard and the overlay should be given a reference to the bb instance as a parameter.

When entering a bb room, if a participant has expired and has been removed from the room, it causes a js error

Uncaught TypeError: Cannot read property 'user' of undefined                  bigboard_mobile.js:94

since the user that submitted the chat originally is not in the participants dictionary.

I don't know if this was intentional, but I noticed that clicking the "Center all here" button changes the room's center location to the new view so that subsequent logins start from that view, not the original center.

Clicking the 'Center all here' button once keeps re-centering participants to the original view, including the clicker. It seems like it should focus them to the clicker's view one time then allow them to browse as before. If this is not the intended functionality, perhaps the button should be changed to a toggle switch to release the other participants when the clicker is done demonstrating.

Portability of error holds between Firefox and Chrome, at least. Test in both to determine if it's fixed. Recreate simply by logging into the room. Does not appear to affect functionality in any meaningful way, though it would be interesting to see if position updates from a mobile device with this bug.

When selecting an annotation then viewing its info, everything works fine the first time. But subsequently viewing info for that or other selected annotations displays an unformatted list.

I am having overlays associated with all the users. when 3 different users login to 3 different rooms and one user hits on share button of the overlay associated with all users. It gets shared among all the other rooms. I am not sure if that's the right way?

I have added the ability for the bigboard room to parse the room url and look for parameters that specify a center and zoom level. This means that users would be able to share a url that automatically takes anyone with access to the room to a given center/zoom upon entering the room. If the parameters are not present, it defaults to the set room center.

This is useful for sharing a view of interest regardless of what the room center is set to. Also, when creating site-wide notifications this url can be included in the notification to automatically direct users to the location of interest when the click the link.

It uses the purl jquery plugin. I have added a button and textbox to the discussions tab for users to get the url of the current view if desired. It will be in the next pull request.

This needs discussion right now, but the idea is to support a visual spatial join grammar, where a user can draw a polygon, point, or line, and perform some kind of spatial analysis on the collection of supported layers being displayed.

Selecting the link type for annotations data displays the file upload input. Shouldn't it be a text input?

I have two overlays enabled for bigboard. I noticed that the up and down arrows don't always work as expected. Pushing the down arrow on the top one pretty much always toggled their position. But doing something like pushing the down arrow on the bottom one then it's up arrow will cause it to be reordered with the other OL layers (Annotations & Participants) which can be seen by enabling the layer switcher.

Currently bb uses the session variable 'participant' to determine if a user is logged into a room which is set in 'JoinView'. What if a user wishes to have multiple rooms open in separate windows or in my case within the same Dashboard? Seems to me like there should a session object per participant per room and the room to be operated on should be passed in the request when a user leaves a room, sends a heartbeat, and sends a new room center (Join already passes the room name). Otherwise (I noticed) things like re-centering in one room will only affect the last room joined, not necessarily the room for which the center was set.

Pinching in and out works for touch devices to zoom in and out, but it would be nice if the scroll wheel was enabled to zoom. Also enabling the zoom bar and panning buttons would be nice.

I'm not sure how much this would improve efficiency, but as I've been developing, I've noticed that the cpu usage increases considerably with the number of annotations in a room. I have the bigboard running in a Centos 6 VM with apache/mod_wsgi running in virtualbox with 2 cores available at 100% cap on my macbook pro. I'm using postgis for the db.

When I first started working with a room I had very few annotations, maybe 10 or less which would take about 30% cpu for a second each time the mainloop was run with django debug on. Now I have 58 annotations being returned with every api request. The content size returned is ~78KB and takes ~1.4s to return for me in these circumstances. Now it regularly runs at 130% with just one instance open for a couple seconds until the next round starts again.

On the server, load drops dramatically with django debug turned off from ~120% to ~12% every few secs.

I know that django debug is responsible for a lot of the load in my development case, but I wonder if it might be worth it to improve the loop efficiency since 12% can quickly add up when you have users doing real things, especially if they have multiple rooms open at the same time.

For annotations I think we could adopt a method like you've done with chat where only the annotations since the last request are retrieved and sent. This obviously causes issues with telling if an annotation has been deleted, but I think we could come up with some scheme where bool and timestamp fields are added to the annotations model that tells whether the annotation has been deleted and when it should expire (probably a few minutes after it is marked deleted to make sure open rooms have a chance to get the delete notice). Then the select statement would be modified to retrieve all since last request or any that are marked deleted and have the js callbacks check the flag. There would be a periodic celery task to clean up deleted annotations that have expired, after which point they would no longer be returned.

Noticed that when I create an annotation, when the mainloop next runs there are two of the annotation right on top of each other. Then if I want to delete that annotation without refreshing, it deletes the shared annotation but not (I assume) the one I originally drew. Deleting annotations not drawn in the current session works fine.

I want to add custom controls to the Annotations tab that are associated with an Overlay instance, so that if certain overlays are present, certain queries can be performed on that overlay. They would be shown / hidden based on whether or not the overlay itself is shown / hidden. This will require some database changes, but I think it's doable for the next version

Features in OpenLayers can be styled as described here: http://docs.openlayers.org/library/feature_styling.html

Perhaps it would useful to extend annotations to store their style as well, even if the user isn't given an interface to adjust that right away. Other apps that create annotations in the BB room could use styles to enhance their effect.

We have a tilecache instance that caches a mapserver wms at certain resolutions (powers of 2). Adding this as an overlay causes a 404 (Tile not found) error with the following text:

An error occurred: can't find resolution index for 38.218514. Available resolutions are: 
[1.0, 2.0, 4.0, 8.0, 16.0, 32.0, 64.0, 128.0, 256.0, 512.0, 1024.0, 2048.0, 4096.0, 8192.0, 16384.0, 32768.0, 65536.0]

Any way to have open layers request the closest resolution and scale appropriately?

If a user is a member of multiple roles and a room allows 2 or more of those roles, the room name will show up in the room list (bb root url) 2 or more times. Comes from views.py line 52, but I haven't figured out the right operation yet to solve it.

Browsing to the bb root, if no rooms exist (perhaps no rooms for the user too, haven't tested that) it throws a 500 error.

This is a new feature idea to let users store locations of interest in a personalized list. They can click a button that pops up a small dialog asking for a brief name and description of the current view which, along with the current map center/zoom is sent to the server and added to a list of views which would be a widget in the dashboard or a new tab in the main application. Then users can edit and delete these entries.

It would be just like setting a new map center, except it is a list per user of locations they would like to be able to easily jump back to later.

The timestamps for heartbeat and chats do not match each other's timezone. They are off by 4 hours for me.

We need ways for users to manage their roles, rooms, overlays, personal views, notifications, etc outside of the django admin.