Closed kereid closed 11 years ago
Track accurately reflects data in netcdf file. Refer http://thredds.aodn.org.au/thredds/dodsC/IMOS/SOOP/SOOP-SST/HSB3403_MV-Wana-Bhum/2013/IMOS_SOOP-SST_T_20130215T005900Z_HSB3403_FV01_C-20130216T001306Z.nc.ascii?LATITUDE[0:1:23],LONGITUDE[0:1:23]
Note that at time instance 5 to time instance 6 measurement location goes from 151.22, -33.969 to 118.82166, -35.487 i.e. as per track on map.
Will check with project officers whether the data is correct, otherwise I don't think we can 'fix' this.
Well I guess the other option is not showing this as a line as this is not what is really happening. The measurement locations are all in the ocean as expected.
Seb says this is a problem with the data and has asked the provider to update the data file
Closing as this is not a bug.
This has slipped through into production noted by Shavawn at review this morning,
Steps to repeat:
Add IMOS>SOOP>SST>SST-All tracks to map
What should happen:
They are only seen over water
What does happen:
They cut across land mass
When it was reported in Redmine (1420):
Craig: Looks like a style issue in geoserver2 instance used by the new portal. Old geoserver instance has a specific style setup for this layer and this layer is displayed fine there.
2Updated by Philip Bohm 11 months ago
•Status changed from New to Resolved •Assignee set to Kate Reid Thanks to the hint by Craig. The style 'line' which it was using had been overwritten with another polygon example file on Geoserver. I created a dedicated line style for the layer