Settings/Map Display adjust by problem type

[rssidlowski]

Request from COB personnel: The request is to be able to turn on and off “Problem Type” investigations, so that the map is not crowded with too many sampling and investigation points. Settings -Pollution Source Tracking -Problem Type -Ammonia (turn on/off) -Chlorine (turn on/off) -Sewage (turn on/off) -Etc. (turn on/off)

The problem type is in the investigations table which is NOT a feature class, but each sample is associated with an investigation.

[JMurk]

The problem type in a related table throws a wrench in the gears. While this would work fine for a regular map service, the PST_Samples service is a feature service. That does not support having objects in the map outside of the editable feature class.

The work around here would be to create a new, regular map service that will be used for the display, while the feature service will be hidden from the sisplay, but still accessed by the app to allow feature creation.

We will want to discuss with @gerrykelly (a.k.a @gjmkelly)

[gerrykelly]

More so, we have a 1:M relationship of sample to investigations (though I still have my doubts that will really happen). What I could do is add the problem type field to the PST_Samples FC and maintain that value that so when a sample is created a trigger inserts the problem type for the investigation it is being created for AND another trigger so when problem type is updated for an investigation it is updated for all related samples. So that gives us the field in the feature class table, but then we need to decide how we give them the toggle by problem type: do we have a separate layer for each type (and I'd still say we would have a new map service for this and then not display the existing feature service)? Or do I need to create a new form that let's them toggle and then in code applies definition queries on the service?)

[JMurk]

I think that having the toggles in the map service should be fine, especially if the problem type attribute will be store in the feature class.

[gerrykelly]

I added the fields PROBLEM_TYPE & PROBLEM_DESC to PST_SAMPLES in dev (probably always best to recreate the existing services with any such change).
If you have a better approach, please suggest it, but I think what you should do is create a new map service with a layer for each [PROBLEM_DESC] value from [GIS_ADMIN].[PST_ProblemCodes] by definition query on each. Plus a layer for "Other" (to cover nulls and if they add new PROBLEM_DESC values) where the def query is something like ... [PROBLEM_ID] is null or [PROBLEM_ID] > 11. Have all the layers visible in the map service. The symbology would just be the same for all layers by [LOCATION_TYPE_ID] as is now. Then I can handle things on the web side, but the layers should just automatically show up in the app with toggles so they can turn off what they want.

(SQL below is just for my reference for prod later)

UPDATE S SET S.PROBLEM_TYPE = N.[PROBLEM_ID] from [GIS_ADMIN].[PST_SAMPLES] S inner join [GIS_ADMIN].[PST_Investigations] N on S.[INVESTIGATION_1_ID] = N.INVESTIGATION_ID;

UPDATE S SET S.PROBLEM_TYPE_DESC = N.[PROBLEM_DESC] from [GIS_ADMIN].[PST_SAMPLES] S inner join [GIS_ADMIN].[PST_ProblemCodes] N on S.PROBLEM_TYPE = N.PROBLEM_ID;

USE [Pollution_Source_Tracking] GO

/\ Object: View [GIS_ADMIN].[V_SAMPLES] Script Date: 5/22/2015 2:07:25 PM **/ DROP VIEW [GIS_ADMIN].[V_SAMPLES] GO

/\ Object: View [GIS_ADMIN].[V_SAMPLES] Script Date: 5/22/2015 2:07:25 PM **/ SET ANSI_NULLS ON GO

SET QUOTED_IDENTIFIER ON GO

CREATE view [GIS_ADMIN].[V_SAMPLES] as SELECT [SAMPLE_ID] ,[AMMONIA] ,[BENTHIC_COMMENTS]

  ,[CHLORINE]

  ,[COLOR_COMMENTS]

  ,[COMMENTS]
  ,[CONDUCTIVITY]
  ,[DISS_OXYGEN]
  ,[DYE_COLOR_ID]
  ,[DYE_COMMENT]
  ,[DYE_TEST_ID]
  ,[ENTEROCOCCI]
  ,[FL_BOTTLE_SIZE]
  ,[FL_DEPTH]
  ,[FL_FILLTIME]
  ,[FL_LENGTH]
  ,[FL_TRAVEL_TIME]
  ,[FL_VOLUME_CFS]
  ,[FL_VOLUME_GPM]
  ,[FL_WIDTH]
  ,[FLOAT_COMMENT]

  ,[FLOW_RATE_ID]
  ,[FOLLOW_UP]
  ,[ODOR_COMMENT]

  ,[PH]
  ,[RESOLVED]
  ,[SAMPLE_DATE]
  ,[SAMPLE_LABEL]
  ,[SDUO]
  ,[STATUS_ID]
  ,[SURFACTANTS]
  ,[SYS_TYPE_ID]
  ,[SYSTEM_COMMENT]
  ,[TEMPERATURE]

  ,[TURB_COMMENT]

  ,[VIDEO_NEEDED]
  ,[VOL_CALC_METHOD_ID]
  ,[CHLORINE_RELATIVE_OPERATOR]
  ,[AMMONIA_RELATIVE_OPERATOR]
  ,[ENTEROCOCCI_RELATIVE_OPERATOR]
  ,[MAPPING_METHOD]
  ,[STUCTURE_TYPE]
  ,[STUCTURE_IDENTIFIER]
  ,[COLOR_OTHER]
  ,[INVESTIGATION_1_ID]
  ,[LOCATION_TYPE_ID]
  ,[DYE_DURATION]
  ,[Contractors_participated_YN]
  ,[CONTRACTOR_PERSONNEL]
  ,[LAT]
  ,[LONGI], PROBLEM_TYPE, PROBLEM_TYPE_DESC

FROM [Pollution_Source_Tracking].[GIS_ADMIN].[PST_SAMPLES]

GO

[gerrykelly]

I added the triggers to dev that insert/update the values for PROBLEM_TYPE, PROBLEM_TYPE_DESC [PST_SAMPLES](works with my testing)

[JMurk]

I have created a new map service in dev called PST_Problems. Let me know if that is what you were thinking.

[gerrykelly]

Just noting that when we have this functionality, the click to select from the map will still return all samples at that location, not just what is visible. (the spatial query runs against another layer in a another service). Adding code that would would get the visible problem types and filter the results would take some effort.

[JMurk]

The new PST_Problem symbology has been published on dev. Before moving to production, the triggers should be tested, then implemented in prod. Once they are in place, I can push this map service up to production.

[rssidlowski]

Verified in COBDEV. Can you have the layer "Pollution Source Tracking" off by default and have the later "Pollution Source Problems" on by default?

[gerrykelly]

done in dev. Let's try to find a chance to move this to prod ASAP

[rssidlowski]

Verified.

[rssidlowski]

Verified in prod.