*Obj. Visibility SAP & Obs. Locator TAP
*(Wednesday May 8 - 4:30 UTC)
Participants: 24

Introduction slides: https://wiki.ivoa.net/internal/IVOA/InterOpMay2020DAL/VisibilityObsLoc-IVOA-May2020.pptx

*Session notes:
Use cases
	* Increasing interest to simultaneously observe the same target at different wavelengths.
	* More coordinated observations in many observatories
	* Many observatories have their own visibilty services/web sites
		* Calculations internally quite different
		* Results are generally the same - visibility charts
	* Many observatories have their own planned observations services
    
Standard Solution
	* Considered a hips with a visibility value but too complex
	* ObVisSAP
		* simplest protocol for visibility for point by observatory during interval
		* Optional output fields which may be more or less important depending on the observatory
	* ObsLocTap
		* Observations Life cycle
		* Discovery of observations scheduled for a certain observatory
		* Follow-up of Target of Opportunities
		* TAP based - Similar to ObsCoreTAP but in ivoa.obsplan table

Reference Implementations
	* ObsVisSAP
		* Five implementations based on standardised output from existing services
		* Initialive to provide simple example implementation for other missions
	* ObsLocTAP
		* Two implemented
		* Two in development
		* Implementation notes based on IVOA toolkits and docker
	* Reference ObsLocTAP integrated services client - TOBY
		* http://integral.esa.int/toby/
Roadmap
	* ObsLocTAP - to PR after this meeting
	* ObsVisSAP - prep 1.0 WD for DAL review

*Questions:
	1. [JD] ObjVisSAP - Is there a sun seperation output field? Useful for radio
		2. different separations are important - moon is just one example
	1. [Alberto] Little comment about min/max_moon_sep: it seems to be the only param with min/max as suffix, all others have min/max at the end (elevation_min/max t_min/max etc), worth changing?
		2. [JS] Yes will change to be consistent
		2. [Pat] These could all be single "interval" params, eg MOON_SEP=20.0 +inf  aka "20.0 or more"
	1. [JD] Registry support?
		2. ObsLocTAP - have guide on registry, help from MD
		2. ObVisTAP - needs to be identified
	1. [MM] validator(s)?
		2. [JS] Not yet, but simple for ObsLocTAP, harder for ObsVisSAP
		2. [CA] ObsLocTAP - already one, but recall there is already a client, so a default validator?
	1. [AN] Most implementators have been high energy observatories, why is that? [PK] High energy sky is very variable, so need quick response, thus more motivated to get involved. Other observatories have constraints which may not allow fast follow-up.
	1. [IC] Visibility service - 
		2. use cases to schedule multi-wavelength observations
		2. who will implement if observatory does not (e.g. HST tool by SSTI)
		2. Also can you add extra observatory constraints like roll angle of telescope (e.g. HST)
			3. Supported as an optional param, in response(?)
	1. [JE] Feedback from session at SciOps meeting - one of the things discussed was only using proposal tool to show visibilites- too hard to predict more accurately than proposal tool; the agreement at Scips was to recommend a 'fidelity' keyword to show that one implementer used 'predictive' tools while another may have used 'actuals' .  For Chandra their are complexities like pitch angle constraints, thermal contraints, off nominal roll contraints that cannot be modeled in a long term approach.  Thermal constraints in particular depend on the immediate past time-history of the spacecraft pitch and can only be determined when the week is being scheduled.  I'm adding these details to put in perspective what different missions/telescopes have to offer and why.  Our underlying predictive tool uses predicted ephemeris designed to support peoposal planning and is updated annually.
		2. [JS] New verison of ObjVisLOC planned based on feedback from that meeting
		2. [JE] Space telescope are more constrained so another motivation for them to publish this info.
	1. [AN] How has the response been from different groups?
		2. [JS] Often different groups to archives doing visibility and scheduling, so will be new to VO - need simple to implement solutions
		2. [AN] How do we help interested groups of smaller missions / telescopes?
		2. [JS] there will be a workshop of the type hands on session to help implement a service. [AN] That would be ofgreat help 
	1. [JE] Excited to have operations involved in the VO - great to get people involved in the ecosystem early in the process
	1. [PD] PyVO noted the different names for similar functions in different protocols - why not follow SIAv2 style in ObsVisSAP -- specifically: POS, BAND, TIME params seem applicable and single "interval" valued params instead of separate min/max params for other numeric fields
		2. [JS] Yes, could adapt to SIA2 approach, would also make it easier for clients
	1. [JD] Pathway to migrate to Latex and github
		2. [JS] Yes will look at migrating from word to latex
	1. [PD] How do records move from ObsPLan to ObsCore - CAOM has a calibration level including planned, which would mean if a record is changed form planned to raw it would jump from ObsPlan to ObsCore.
		2. [JS] Two views aren't really tied together. Concepually ok, to have items disappearing from plan when they go to obs. But doesn't occur in the current implementations as they are separate databases.
	1. 

PaulH - late - I don't like the name Observation Locator TAP - would it not be better to call it Planned Observations TAP ?