Add ALRS site

From PTAGISWiki

Contents 1 How to add a new site to the ALRS database 1.1 Overview 1.2 Location 1.3 Location in segment 1.4 Activity location 1.5 Known bugs

How to add a new site to the ALRS database

Overview

Adding a site involves creating relevant entries in the following tables:

• location (physical coordinates)
• location_in_segment (location description and context)
• activity_location (description of the activities that take place there)

The tool for making these changes is the ALRS webapp constructed by Doug Clough.
http://www.ptagis.org/alrs

Here is a description of the old process for adding a site using QBF. This is the old way of manipulating the ALRS data, used before the webapp was built.

Location

Enter values for the Location table.

• published latitude and longitude
• estimated latitude and longitude, used for internal calculations only
• x,y coordinate on our web map of sites (use script on sockeye to convert lat/lon to pixels)
• source of coordinate info

After creating the location, you'll need to view the created record in order to determine the Location ID that was assigned to it.

The wildcard for searches is "%".

Location in segment

• site ID
• location ID
• segment ID (get segment ID by looking up a HUC code in the RiverSegment table)
• site type
• site description
• RKM
• category (where to put the site within the web site)

Activity location

Create one of these records for each type of activity at the site

• activity category (hands on or remote)
• activity type (interrogation, tagging, release)

Known bugs

If you get a java stack trace when trying to use the ALRS web app you probably need to redeploy the application through the Weblogic admin console. The stack trace looks like this:

Error 500--Internal Server Error

javax.servlet.ServletException: Could not resolve view with name 'dataAccessFailure' in servlet with name 'alrs'
	at org.springframework.web.servlet.DispatcherServlet.render(DispatcherServlet.java:911)
	at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:705)
	at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:625)
	at org.springframework.web.servlet.FrameworkServlet.serviceWrapper(FrameworkServlet.java:386)
	at org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:346)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
	at weblogic.servlet.internal.ServletStubImpl$ServletInvocationAction.run(ServletStubImpl.java:1053)
	at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:387)
	at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:305)
	at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:6291)
	at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:317)
	at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:97)
	at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:3575)
	at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2573)
	at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:178)
	at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:151)

The bug is caused by the disruption of the datasource by the checkpoint and backup process. The webapp will lose contact with the datasource after a checkpoint and the only known fix is to redeploy.