dfo-ocean-navigator / ocean-data-map-project Goto Github PK

Eg. Left map controls would have a button to apply the variable range to right map, and vice versa.

Production server gets Giops Daily forecast data one day late.

Details:
Related to bug: #27
When it was realized that bug #27 was not actually a bug it was realized that the production server should be getting the GIOPS Daily data sooner than it does. To fix this the Cron Job will need to be updated to call more often or to call every hour if they data for today has not been pulled down yet.

• There should be a separate graph for the left and right side views.
• If it makes sense, there should be a difference-graph between the two views.

So with 1 dataset, 1 graph. 2 datasets, at least 2 graphs, or 3 if a difference makes sense.

plot button behavior is erratic and is often not usable. It's intended use is not clear but it certainly is not constant for when it is can be used.

Version: 2ae745d

Some drifters provide the sad computer PNG when pressed. No pattern to which are broken has been found.
example: Drifter 300234063614000

• The presence of the Plot button appears to be redundant since the CTRL + Click-ing the drawn shape on the map re-opens the data window.
• Also, the behaviour of the Plot button is rather erratic, sometimes enabling/disabling itself in bizarre situations.
• Do we need to keep it, now that we know to simply CTRL + click on the drawn region (which has no issues).

When a Point/Line/Area is drawn/entered manually, only the primary/left map-view displays the new geometry in compare mode. The right view should render the geometry.

• In an "advanced" option, allow the user to switch between available data interpolation options.
• Interpolation should be done in nemo.py.

• Revamp the Share Link modal to allow permalink customization (select site states that the user wishes to preserve).
• As the side-by-side feature becomes more complete, encoded links will become rather large.

In the default view, the GIOPS daily data is not actually the data from the listed day. It is data from the prior day.

Details: this issue is related to the #25 issue. It seems that when the Ocean Navigator says that the date is YYYY/MM/DD it is actually showing data from YYYY/MM/DD-1 (i.e the data is one day behind).

While this problem is probably a bug in Python some fixes to the Linux scripts will need to be fixed as well because of issue #25

Found in Commit: 2ae745d

At areas where there is a high gradient on the map there is sometimes some blotchiness that can be seen.

Details
This needs to be investigated further but at times it can be seen that the colors in the map seem to be many overlaying circles where the centers of the circles are a darker color and there is a color gradient that comes out from the center. The fix to the problem may be as simple as to turn the resolution up but it should be determined and documented how the pixel rendering is done.

little dots from far out

close zome problem

circle problem 1

circle problem 2

and where the offset problem in the southern hemisphere (issue #4 ) is present there cycles are more clear.
circle problem 3

note: you must press auto and or play with the range settings to see the effect since the range settings are not saved by the link.

On both the test server and the production server there is a cron job that tries to get files from pegasus that have "2017" in the name. This will fail in 2018 onward.

Details:
The cron job that runs rsync at 9:15 am to get the GIOPS data, looks for files named "2017??" because of the references to 2017 this will presumably fail in 2018. The cron job should be updated so that it doesn't reference a particular year.

• Investigate applying a different Bootstrap theme.
• Centering the MapToolbar controls.

• This would redirect to the Github pages.

When the side-by-side view is enabled, map interaction is only supported by the left view.

On both the test server and the production server there is a cron job that tries to get a file from pegasus that have class4_2017 in the name. This will fail in 2018 onward.

Details:
The cron job that runs rsync at 10 am to get the class 4 data looks into a folder called "2017" and looks for files named "class4_2017*_profile.nc" because of the references to 2017 this will presumably fail in 2018. The cron job should be updated so that it doesn't reference a particular year.

When drawing a point on the map, a 3-component array [lat, long, null] is passed to the generatePermlink function, thus generating a bad url. When manually entering a point, there is no problem. Also no problems with Line, Area, Class4, or Drifters.

Since this is a very large implementation, we need to make a list of the desired features + fixes so I can prioritize which one to tackle first.

It's basically the runtime version of C++ type-traits AND the closest thing to making javascript a strongly-typed language 🎉!!!!

https://www.npmjs.com/package/prop-types

Runtime type checking for React props and similar objects.

You can use prop-types to document the intended types of properties passed to components. React (and potentially other libraries—see the checkPropTypes() reference below) will check props passed to your components against those definitions, and warn in development if they don’t match.

This is an awesome method for code validation, and will really help with documentation. Also, it will drastically reduce the chance of dynamically-typed errors cropping up..

This issue only seems to be on the test server. The default page the loads shows The date and map for tomorrow despite "GIOPS Daily" being selected.

Details:
The default settings for the ocean navigator shows data for one day ahead of the current date. In this case, on July 13th 2017 at ~5:50 pm the date in the time selection box was the July 14th 2017. The map that was being displayed was also not the same as the map for the 13th (which could be viewed by going back a day). The next morning at ~ 9AM, when ocean navigator was opened it showed the correct day (ie the 14th) but by 11:39 am this had changed (this was after a reboot). The date and data that was being displayed were for the following day again (ie the 15th).

All of this is only occurring on the test server. On the deployment server, the correct day is shown.

trouble shooting:
There is a cron job that gets run on the test server at 9:15 AM to pull down any new GIOPS files that it does not have. it is possible that this is related to the problem, however, a quick check found that the folder the cron job put the files in only includes files up to the current date so the source of the data that is being displayed is still unknown.

next step:
Point at the test server and then at the production server with the head of the master to pin the problem down further.

Version: 2ae745d assuming Geff had that version of code in Trinity also known to exist on 9532be3 when running on a local computer and pointed at the test server for data.

Major Bug: The view and the data are offset from each other in the main map view for the Southern Hemisphere.

Details:
The details of this bug are a little strange. The problem only seems to exist at the max zoom. It is most visible when a point near the equator is viewed with the Basemap of "Esri world Imagery" is selected.

At max zoom, the view seems to be shifted about 70Km West from the data in the southern hemisphere. For the Basemaps of "Esri world Imagery" and "Esri Ocean Basemap" the problem is more visible since the basemap is in the correct location but the data and the Bathymetry maps are shifted. for the "ETOPO1 Topography" Basemap the problem is harder to see since the basemap is shifted the same amount as the layers on top.

The problem only exists in the global view map projection (the pole projections are fine)

Proving that the data is shifted from the view can be done using the "line" drawing tool.

In the above image the red rectangle shows where the map was displaying the land but the green rectangle shows where the land was accorading to the data. link

shift near the equator
url

Problem first noticed in Verson: 2ae745d

Arctic view tripolar lines

• When clicking somewhere on the map, a white balloon pops up. There should be a small button in that balloon that will open the Point window for that given location.

Distortion can only be reset upon panning or zooming the map. Due to how OpenLayers does its rendering, its not really possible to "fix" this, unless sidebar toggling is disabled in compare mode, or another UI solution is discussed (maybe each map would get it's own floating/draggable toolbar).

there is a time conflict in a thredds aggregated netCDF file where it says the same thing should update every hour and every 4 hours. This is present in several places.

The way the colors are displayed can cause the data to be picked up across land boundaries when they are thin.

This can lead to problems in areas such as the Panama canal where there is hot water on one side of the land and cold water on the other. But because the only thing that is done to pick the color is to look at all the data within a certain radius and to average based on the weight of how close they are. If the land is thinner than the specified radius the data can be accessed across it leading to misleading results (ex, hot looking water on the side of the land where the water is cold).

to fix this the colour selection tools need to know when they are next to land instead of just being covered by a mask.

Discovered when talking to Geoff about bug #7

• There needs to be a discussion about how we want to organize the documentation for the navigator, and how will make contributions to various areas (usage, reporting bugs, keyboard commands, etc.).

there exists a script to generate GIOPS Monthly but it needs some work so that the input can be automated.

the main map view copy button is broken.

Details:
Once the link button is pressed on the main map a popup window appairs. The copy button on this window does not actually copy the displayed link to the clipboard. The link can be copied with Ctrl-c or by right clicking.

version
The problem is known to exist in Commit: 2ae745d

Needs to have the same layout as the primary permalink window.

On some computer monitor sizes, the Arctic/Antarctic map views flicker badly when trying to pan.

Details: If a computer screen is a mid to high-resolution screen the default map the Arctic and Antarctic map views are not large enough to fill the window. If this happens and the user tries to click and drag the map (e.x. to view further down the map) the map starts flicking like crazy. The problem only exists if the map does not fill the browser's window, so if the user zooms in the problem fixes it's self until they zoom back out.

Arctic view

Version: This bug was discovered in commit 2ae745d

the Ocean Navigator is not very discoverable by Google at the moment. SEO should be completed

• List all major changes completed.

The Giops monthly allows for the selection of months that there is no data for.

If there is a month (or months) missing in the files it is still displayed as an option for selection so long as there is a file that is for a month for some point before and after it. It will show data for that previous selected month if picked.

the picture is from trinity for which there is no data for 2016

In the Select Drifter, or Point Observations modal, each select box could have a search bar above it to filter the list in real-time.

the points, lines, and shapes are not saved by the link button.

Details
The link button that is used for both the main map and the more detailed views in the popup window does not have the shape or drawing that the user has made on the main map. This would probably be good to have.

Verson: 2ae745d

All components are using legacy React syntax. Following current guides on React best practices would reduce code bloat, make the components easier to maintain, and reduce the likelihood of bugs.

As per https://engineering.musefind.com/our-best-practices-for-writing-react-components-dec3eb5c3fc8

• Any modals should be draggable.
• This is also in preparation for removing the sidebar in favour of map-specific controls (this would help with screen real-estate, and solve the map distortion issue).

Just to make things look fancier, and enhance legibility.

• Not really a big deal, but this is something that needs to be examined.