Merge branch 'indexes' into 'main'

Adding categorical summaries, glossary

See merge request astrogeology/asc-public-docs!19

README.md

@@ -27,6 +27,8 @@ git push origin your-branch-name
 
 ### Adding your files
 
+> See [mkdocs material docs](https://squidfunk.github.io/mkdocs-material/getting-started/) for information on how to work with mkdoc's material theme and it's features. 
+
 1. Determine what category your docs belong to by reading [the summary on the README](#understanding-the-doc-system). 
 2. Write your either in Markdown or as a Jupyter notebook and add it under the directory for that category. 
 3. Update `mkdocs.yml`, add a new file somewhere appropriate under `nav:` 
@@ -84,9 +86,16 @@ Good getting started docs should:
 1. Include minimum explanation; the focus is on "learning by doing"
 1. Focus on the steps required to complete the goal. 
 
+Concrete things your tutorial needs: 
+
+- If your tutorial requires installing software, list what software and their versions and clear instructions on how to install them. Feel free to point to other points of the doc that already have boilerplate info like "Go here to read on how to set up a custom ISISPreferences file". 
+- If your tutorial has data, use generative data or data that is in the repo. Avoid external data dependencies. Before data is committed into the repo, check if [existing data can be re-used](./data/). If new data needs to be committed, make sure it is small so as not to increase the data burden.   
+- Make sure to make the lesson clear in the title. Also, make it clear in the tutorial with something like "Lessons learned in this tutorial:". 
+
+
 Examples: 
 * Getting Started: ISIS image ingestion to map projected image, ingesting, bundling, and projecting an image list 
-* Getting Started: generating an ISD and CSM camera model
+* Getting Started: Generating an ISD and CSM camera model
 * Getting Started: Generate a control network with an image matcher 
 
 ### How-to Guides 
@@ -97,12 +106,11 @@ Similar to getting started guides in that they explain to users how to perform s
 
 1. Solve practical problems for more experienced users
 1. Offer more ambiguous starting points; they should be re-usable in many different contexts 
-1. Provide little explanation, mostly showing steps on how to accomplish the task
-1. Are generally much shorter than getting started docs
+1. Can be much shorter than getting started docs
 
 Examples: 
-* How-to: generate an ISD via loads with specific kernels
-* How-to: get GEOJSON from ISIS footprints
+* How-to: Generate an ISD via loads with specific kernels
+* How-to: Get GEOJSON from ISIS footprints
 
 ### Concepts 
 
@@ -128,5 +136,5 @@ Examples:
 Software manuals centered on the code of the library. These are generally links to the library's programmatically generated API docs. Think Sphinx docs and/or Doxygen-generated docs. 
 
 Examples: 
-* Programatically generated Python/C++ API docs from inline doc strings
+* Programatically Generated Python/C++ API docs from inline doc strings
 * RESTful API docs from an OpenAPI spec file 

definitions.md

+*[Adjusted]: The term, Adjusted, refers to the output pixel coordinate or output geographic location within a control network. Applications such as pointreg or jigsaw report and update the "Adjusted" output pixel coordinate (pointreg) or geographic location (jigsaw) in the output control network. 
+*[Band]: A 3rd dimensional layer of pixels in an image, typically representing spectral information. The number of bands indicates the depth of an image in terms of these layers. 
+*[Bit]: Short for binary digit, which in a computer is the smallest unit of storage. Bits are either "0" or "1". 
+*[Byte]: Short for binary term. A byte is a collection of computer bits. On most modern computers, a byte is a group of eight bits. Typically, computers handle and store information in binary (base-2), and a group of eight bits represents an eight digit binary number.
+*[CSM]: Community Sensor Model. A standard for sensor models USGS uses for interoperability. 
+*[SPICE]: Spacecraft & Planetary ephemerides, Instrument C-matrix and Event kernels. SPICE refers to all the information required by ISIS in order to compute and map each image pixel onto a surface with reference to spacecraft position, sun position, instrument, and mission activities. ISIS uses software (ToolKit) supplied by the Navigation and Ancillary Information Facility (NAIF) for SPICE access and kernel management (Refer to spiceinit). 
+*[NAIF]: Navigation and Ancillary Information Facility. They engineered and support the SPICE observation geometry information system. 
+*[NULL]: NULL is a Special Pixel value that is tracked and reported to the user. NULL represents "No Data". NULL is set in all 8, 16, 32-bit type image data. 
+*[LRS]: LRS [Low Representation Saturation] is a representation special pixel value that is tracked and reported to the user. LRS is set when an ISIS application causes the output DN pixel to fall 'below' the possible range of valid values. 
+*[HRS]: HRS [High Representation Saturation] is a representation special pixel value that is tracked and reported to the user. HRS is set when an ISIS application causes the output DN pixel to fall 'above' the possible range of valid values. 
+*[LIS]: LIS [Low Instrument Saturation] is an instrument special pixel value that is tracked and reported to the user. LIS is set during the ingestion of the image data into ISIS. The input image sensor acquired a value too low to be measured accurately. 
+*[HIS]: HIS [High Instrument Saturation] is an instrument special pixel value that is tracked and reported to the user. HIS is set during the ingestion of the image data into ISIS. The input image sensor acquired a value too high to be measured accurately. 
+*[Cube]: A cube is a 3-dimensional image with axis: samples, lines, and bands. The physical dimensions of a cube are called the number of samples (NS), number of lines (NL), and number of bands (NB). 
+*[Line]: A row of pixels in an image, typically representing spatial information. The number of lines indicates the total height of an image in pixels. 
+*[Sample]: A column of pixels in an image, typically representing spatial information. The number of samples indicates the total width of an image in pixels. 
+*[Level0]: Level0 is a standard cartographic processing phase that describes an image has been ingested into ISIS (PDS EDR) and will often have SPICE information loaded on the ISIS cube labels (spiceinit). Level0 image cubes are often the input to mission specific radiometric calibration applications if supported in ISIS. 
+*[Level1]: Level1 is a standard cartographic processing phase that describes an image has been radiometrically calibrated (PDS CDR or the ISIS output of a mission specific calibration application) with SPICE information loaded on the ISIS cube labels. 
+*[Level2]: Level2 is a standard cartographic processing phase that describes an image has been map projected (PDS RDR). The Level2 image cube labels contain Mapping keywords that describe the projection and all associated map characteristics. 
+*[Elevation]: The height above or below a fixed point on the surface of a body. 
+*[Albedo]: Reflectivity of a surface or particle. Commonly in I/F units for radiometrically calibrated data. 
+*[Emissivity]: A measure describing a substance's ability to absorb and radiate electromagnetic energy. 
+*[Radiance]: A measurement describing the amount of electromagnetic energy emitted from an area of a planet. 
+*[Reflectance]: The ratio of reflected energy to incoming energy. 
+*[Radius]: The distance (vector) value between the center of and a point on a circle, sphere, ellipse or ellipsoid. Refer to qview, camstats, or campt as examples of applications that report radius value at every image pixel location. 
+*[I/F]: Irradiance/SolarFlux. Unit of DN values for a reference distance of target body from the Sun (5.2 AU). The valid values range between 0.0 and 1.0. 
+*[Azimuth]: A clockwise angle from a point of origin to a point of interest. 
+*[Declination]: Declination (Dec) is one of two angles of the North Pole of a target body as a function of time. 
+*[Latitude]: Latitude represents a geographic position and is measured from the equator, with positive longitudes going North and negative values going South. 
+*[Longitude]: Longitude represents a geographic position and is measured from a specified Prime Meridian (default is IAU) for the target body. 
+*[UTC]: Coordinated Universal Time (UTC) is a system of time keeping that gives an understandable name to each instant of time. The names are formed from the calendar date and time of day. UTC format consists of year, month, day, hour, minutes and seconds. 
+*[PVL]: Parameter Value Language (PVL) is used extensively by ISIS as a standard keyword value type language for naming and expressing data values. PVL format in ISIS is compatible with syntax used by the Planetary Data System. 
+*[MAP]: A representation of a three dimensional target such as a sphere, ellipsoid or an irregular shaped body onto a plane 
+*[IAU]: The International Astronomical Union 
+*[Scale]: The map resolution measured in pixels per degree 
\ No newline at end of file

docs/concepts/Camera Geometry and Projections/Camera Geometry.md

@@ -21,12 +21,12 @@ though it does not require radiometric calibration).
 
 !!! Note "Within the ISIS environment, unless otherwise specified, **ALL** applications default (for input and output) to the following geometric reference (regardless of target body):"
 
-      - **Longitude\_Domain = 360** \[Longitudes will be reported in the
-        range of 0 to 360 degrees (not -180 to 180)\]
-      - **Latitude\_System = Ocentric** \[Versus Ographic; Note: there is
-        not difference for a spherical body\]
-      - **Longitude Direction = East** \[Longitude values increase to the
-        east\]
+      - **Longitude Domain = 360** Longitudes will be reported in the
+        range of 0 to 360 degrees (not -180 to 180)
+      - **Latitude System = Ocentric** Versus Ographic; Note: there is
+        not difference for a spherical body
+      - **Longitude Direction = East** Longitude values increase to the
+        east
 
 Definitions for the geometric reference terms can be found in [Learning About Map Projections](../Camera%20Geometry%20and%20Projections/Learning%20About%20Map%20Projections.md)
 

docs/concepts/glossary/glossary.md

+###Adjusted
+ The term, Adjusted, refers to the output pixel coordinate or output geographic location within a control network. Applications such as pointreg or jigsaw report and update the "Adjusted" output pixel coordinate (pointreg) or geographic location (jigsaw) in the output control network. 
+###A Priori
+ The term, "A Priori", refers to the initial or original value of a pixel coordinate or geographic location within a control network. Applications such as pointreg or jigsaw refer to the a priori values for an input pixel coordinate (pointreg) or geographic location (jigsaw) in an input control network. 
+###Band
+ A 3rd dimensional layer of pixels in an image, typically representing spectral information. The number of bands indicates the depth of an image in terms of these layers. 
+###Bit
+ Short for binary digit, which in a computer is the smallest unit of storage. Bits are either "0" or "1". 
+###Bit Type
+ Refers to how many bits there are per single meaningful value in an image cube file. 
+###Byte
+ Short for binary term. A byte is a collection of computer bits. On most modern computers, a byte is a group of eight bits. Typically, computers handle and store information in binary (base-2), and a group of eight bits represents an eight digit binary number. 
+###SPICE
+ Spacecraft & Planetary ephemerides, Instrument C-matrix and Event kernels. SPICE refers to all the information required by ISIS in order to compute and map each image pixel onto a surface with reference to spacecraft position, sun position, instrument, and mission activities. ISIS uses software (ToolKit) supplied by the Navigation and Ancillary Information Facility (NAIF) for SPICE access and kernel management (Refer to spiceinit). 
+###NAIF
+ Navigation and Ancillary Information Facility. 
+###Special Pixels
+ Special Pixels are defined to distinguish valid pixels from non-valid pixels. 
+###Planetary Data System
+ The Planetary Data System (PDS) is an archive of scientific data acquired from NASA planetary missions, astronomical observations, and laboratory measurements. By developing standards for data and archive formats and architectures for use within the archive, the PDS ensures long-term access and usability of NASA planetary data. 
+###NULL
+ NULL is a Special Pixel value that is tracked and reported to the user. NULL represents "No Data". NULL is set in all 8, 16, 32-bit type image data. 
+###LRS
+ LRS [Low Representation Saturation] is a representation special pixel value that is tracked and reported to the user. LRS is set when an ISIS application causes the output DN pixel to fall 'below' the possible range of valid values. 
+###HRS
+ HRS [High Representation Saturation] is a representation special pixel value that is tracked and reported to the user. HRS is set when an ISIS application causes the output DN pixel to fall 'above' the possible range of valid values. 
+###LIS
+ LIS [Low Instrument Saturation] is an instrument special pixel value that is tracked and reported to the user. LIS is set during the ingestion of the image data into ISIS. The input image sensor acquired a value too low to be measured accurately. 
+###HIS
+ HIS [High Instrument Saturation] is an instrument special pixel value that is tracked and reported to the user. HIS is set during the ingestion of the image data into ISIS. The input image sensor acquired a value too high to be measured accurately. 
+###Control Network
+ A network of Control Points. Within the ISIS environment, the control network file is binary file. The network contains multiple fields of information for control points and measures collected between any number of image cubes. 
+###Control Measure
+ The sample and line pixel coordinate (measurement) within a single image cube that has been measured and associated with a Control Point and other overlapping image cubes. 
+###Control Point
+ One or more measurements (image coordinates) that identify the same feature or location in different overlapping images. 
+###Serial Number
+ A unique identifier constructed and assigned to each individual image within a control network. The serial number (SN) is constructed by most of the control network applications "in real time" from specific instrument keywords on the image labels (Instrument keywords are populated by mission specific ingestion applications). 
+###Reference Measure
+ Reference Measure is a fundamental component of the control network. For every point within the network, there is always one and only one associated Reference Measure (Reference=True). The Reference Measure refers to a single image and it's pixel coordinate (measure) that best represents a control point location or feature. 
+###Cube
+ A cube is a 3-dimensional image with axis: samples, lines, and bands. The physical dimensions of a cube are called the number of samples (NS), number of lines (NL), and number of bands (NB). 
+###Line
+ A row of pixels in an image, typically representing spatial information. The number of lines indicates the total height of an image in pixels. 
+###Sample
+ A column of pixels in an image, typically representing spatial information. The number of samples indicates the total width of an image in pixels. 
+###Digital Number
+ The numeric value of a single pixel in an image. The value may represent almost any unit. For example: reflectance (I/F), radiance, elevation, or radius. Digital Numbers (DNs) can be discrete integers or floating point values. 
+###Level0
+ Level0 is a standard cartographic processing phase that describes an image has been ingested into ISIS (PDS EDR) and will often have SPICE information loaded on the ISIS cube labels (spiceinit). Level0 image cubes are often the input to mission specific radiometric calibration applications if supported in ISIS. 
+###Level1
+ Level1 is a standard cartographic processing phase that describes an image has been radiometrically calibrated (PDS CDR or the ISIS output of a mission specific calibration application) with SPICE information loaded on the ISIS cube labels. 
+###Level2
+ Level2 is a standard cartographic processing phase that describes an image has been map projected (PDS RDR). The Level2 image cube labels contain Mapping keywords that describe the projection and all associated map characteristics. 
+###Elevation
+ The height above or below a fixed point on the surface of a body. 
+###Albedo
+ Reflectivity of a surface or particle. Commonly in I/F units for radiometrically calibrated data. 
+###Emissivity
+ A measure describing a substance's ability to absorb and radiate electromagnetic energy. 
+###Radiance
+ A measurement describing the amount of electromagnetic energy emitted from an area of a planet. 
+###Reflectance
+ The ratio of reflected energy to incoming energy. 
+###Radius
+ The distance (vector) value between the center of and a point on a circle, sphere, ellipse or ellipsoid. Refer to qview, camstats, or campt as examples of applications that report radius value at every image pixel location. 
+###Emission Angle
+ The emission angle (EMA) is the angle between the spacecraft and a vector drawn perpendicular to the planet's surface (surface normal). Using SPICE, ISIS applications compute this angle from the ellipsoid. Emission Angle is in degrees. The valid range is between 0 and 90. 
+###Incidence Angle
+ The incidence angle (INC) is the angle between the sun and the surface normal. ISIS applications use SPICE to compute this angle from the ellipsoid or the elevation model (e.g., local slopes) at every pixel. 
+###Phase Angle
+ The phase angle is the angle between the sun and the spacecraft at a point on the surface. ISIS applications will use SPICE to compute this angle from the ellipsoid or the elevation model (e.g., local slopes) at every pixel. 
+###Pixel Resolution
+ The ground distance in meters from the left edge to the right edge of a pixel. 
+###Oblique Pixel Resolution
+ The ground distance (in meters) from the left edge to the right edge of a pixel. This value is based on the 
+###Line Resolution
+ The ground distance (in meters) from the top edge to the bottom edge of a pixel. 
+###Oblique Line Resolution
+ The ground distance (in meters) from the top edge to the bottom edge of a pixel. This value is based on the 
+###Sample Resolution
+ The ground distance (in meters) from the left edge to the right edge of a pixel. 
+###Oblique Sample Resolution
+ The ground distance (in meters) from the left edge to the right edge of a pixel. This value is based on the 
+###Detector Resolution
+ The ground distance in meters from the left edge to the right edge of a detector. If the lines and samples are not being summed and averaged, this value is equal to the pixel resolution. The formula for estimating this value works well if the image is taken near nadir, but the accuracy falls off rapidly the farther off-nadir the image is taken. For an estimate that handles off-nadir images with higher accuracy, one should use 
+###Oblique Detector Resolution
+ This provides an improved estimate to the standard 
+###I/F
+ Irradiance/SolarFlux. Unit of DN values for a reference distance of target body from the Sun (5.2 AU). The valid values range between 0.0 and 1.0. 
+###Polygon Thickness
+ The thickness of a polygon is defined as follows: 
+###Ground Azimuth
+ A clockwise angle between one reference point and another reference point. Each pixel location has a latitude and longitude associated with it (ground point). The only information required to calculate a ground azimuth is to form a spherical triangle from three points on the planet (ground point, North Pole, and point of interest). The point of interest is often the sub-spacecraft or sub-solar point. Spherical trigonometry is then used to calculate the angle. 
+###Azimuth
+ A clockwise angle from a point of origin to a point of interest. 
+###North Azimuth
+ A clockwise angle from a point of origin to true North. 
+###Sun Azimuth
+ A clockwise angle from a point of origin to the direction of the Sun. 
+###Spacecraft Azimuth
+ A clockwise angle from a point of origin to the direction of the Spacecraft. 
+###Off Nadir Angle
+ From the spacecraft, the Off Nadir is the angle between the nadir vector (subspacecraft vector) and the look vector. Every pixel in the image will result in a different Off Nadir Angle. 
+###Slew Angle
+ From the spacecraft, the Slew is the angle between the boresight (i.e., center of framing camera) and the nadir vector (subspacecraft vector). The Slew angle will be a constant value across the image. 
+###SubSpacecraft Ground Azimuth
+ The Ground azimuth to the SubSpacecraft point (where the look vector from the spacecraft intercepts the target body) is obtained by taking true North (90 deg Latitude) and finding the clockwise angle to the subspacecraft latitude and longitude point. 
+###Subsolar Ground Azimuth
+ The Ground azimuth to the SubSolar point is obtained by taking true North (90 deg Latitude) and finding the clockwise angle to the subsolar latitude and longitude point. 
+###Local Emission Angle
+ The local emission angle is the angle between the spacecraft and a vector drawn perpendicular to the planet's surface (surface normal). 
+###Local Incidence Angle
+ The local incidence angle is the angle between the sun and a vector drawn perpendicular to the planet's surface (surface normal). 
+###Control Island
+ Ideally a control network will represent a single island of a list of overlapping images all tied together through a network of control points and image measures (Refer to Control Measures). 
+###Body Fixed Coordinate
+ A planetary coordinate system where the coordinates are not time varying. 
+###Right Ascension
+ Right Ascension (RA) is one of two angles of the North Pole of a target body as a function of time. 
+###Declination
+ Declination (Dec) is one of two angles of the North Pole of a target body as a function of time. 
+###Prime Meridian
+ Prime Meridian (W) location is the third Euler angle which is expressed as a rotation about the North Pole as a function of time. The reference frame is J2000. 
+###Euler Angles
+ All the NAIF orientation models use three Euler angles to describe body orientation. The Euler angles describe the orientation of the coordinate axes of the 'body equator and prime meridian' system with respect to the J2000 system. 
+###Planetocentric Latitude
+ Planetocentric Latitude is the angle between the equatorial plane and a line from the center of the body. 
+###Planetographic Latitude
+ Planetographic Latitude is the angle between the equatorial plane and a line that is normal (perpendicular) to the surface body. 
+###Latitude
+ Latitude represents a geographic position and is measured from the equator, with positive longitudes going North and negative values going South. 
+###Latitude Type
+ Latitudes can be represented either in Planetographic or Planetocentric form. Both latitudes are equivalent on a sphere (i.e., the equatorial radius is equal to the polar radius); however they differ on an ellipsoid body (e.g., Mars, Earth). 
+###Longitude
+ Longitude represents a geographic position and is measured from a specified Prime Meridian (default is IAU) for the target body. 
+###Longitude Direction
+ Longitude direction of a target body indicates whether longitude increases (positive) to the east or the west. 
+###Positive East Longitude
+ The reported longitude values for a target body increase positive to the East. 
+###Positive West Longitude
+ The reported longitude values for a target body increase positive to the West. 
+###Longitude Domain
+ Longitude Domain specifies how longitudes should be interpreted and reported for a target body. 
+###Local Radius
+ The distance from a point on the surface of a body to its geometric center. 
+###Spacecraft Position
+ The Spacecraft Position is the position of the spacecraft (x,y,z) in body-fixed rotating coordinate system. 
+###Slant Distance
+ The distance from the spacecraft to the point of interest on the surface of the planet. 
+###Target Center Distance
+ The distance from the spacecraft to the target body center. 
+###Ephemeris Time
+ Ephemeris Time (ET) as defined by NAIF (Toolkit used by ISIS), is the uniform scale represented by the independent variable in the differential equations that describe the motions of the planets, sun and moon. Ephemeris time is described as a count of ephemeris seconds past the ephemeris reference epoch (J2000). 
+###UTC
+ Coordinated Universal Time (UTC) is a system of time keeping that gives an understandable name to each instant of time. The names are formed from the calendar date and time of day. UTC format consists of year, month, day, hour, minutes and seconds. 
+###Local Solar Time
+ How high the sun is in the sky as seen from a particular site on the surface of a planet. The local solar time at a site on a body is the angular difference between the planetocentric longitude of the site and the planetocentric longitude of the Sun as seen from the center of the body. 
+###Solar Longitude
+ The Solar Longitude is the planetocentric longitude of the sun as seen from a point on a body. It is considered a seasonal angle. 
+###PVL
+ Parameter Value Language (PVL) is used extensively by ISIS as a standard keyword value type language for naming and expressing data values. PVL format in ISIS is compatible with syntax used by the Planetary Data System. 
+###MAP
+ A representation of a three dimensional target such as a sphere, ellipsoid or an irregular shaped body onto a plane 
+###Map Projection
+ A map projection is an algorithm or equation for mapping a three dimensional coordinate (latitude, longitude, radius) into a two dimensional coordinate plane (x,y). 
+###SubSpacecraft Latitude
+ The latitude value of the Subspacecraft Point 
+###SubSpacecraft Longitude
+ The longitude value Subspacecraft Point 
+###SubSpacecraft Point
+ The point on the surface of the target body which lies directly beneath the spacecraft. 
+###SubSolar Latitude
+ The latitude of the subsolar point. 
+###SubSolar Longitude
+ The longitude of the subsolar point. 
+###SubSolar Point
+ The subsolar point is the target surface intercept of the line from the Sun and the target body's center. A triaxial ellipsoid is used to model the surface of the target body. 
+###IAU
+ The International Astronomical Union 
+###Projection X
+ Projection X is the x-coordinate (Easting) for a point on a geographic Cartesian coordinate system 
+###Projection Y
+ Projection Y is the y-coordinate (Northing) for a point on a geographic Cartesian coordinate system 
+###Universal Coordinate
+ The ISIS default coordinate system 
+###Scale
+ The map resolution measured in pixels per degree 
+###Polar Radius
+ The distance from the geometric center of an ellipsoid to either of its poles. 
+###Equatorial Radius
+ The distance from the geometric center of an ellipsoid to its equator. 
+###Look Direction
+ The look direction is the direction that the instrument is pointing. In ISIS, it is represented as a mathematical unit vector. For images that have a body (i.e. not star fields), this vector is parallel to the line from the sensor to the observed point on the surface of the target. The look direction can be represented in any of several coordinate systems, including: 
+###Body-Fixed Coordinate System
+ A body-fixed coordinate system is used to determine positions and directions of objects and vectors with respect to a target body. The origin is at the center of mass for the target and the axes rotate and move through space with the body. These systems are non-inertial, meaning the velocity of the origin is non-constant. Many body-fixed coordinate systems, or reference frames, are defined in NAIF PCK files. 
+###Camera Coordinate System
+ A camera coordinate system is used to determine positions and directions of objects and vectors with respect to a sensor (i.e. camera). The origin is at the center of the sensor and the axes rotate and move through space with the sensor. These systems are non-inertial, meaning the velocity of the origin is non-constant. The location of the center of a spacecraft and its instruments at a given time are defined in NAIF SPK files. Generally, one or more frames are associated with a particular instrument. 
+###J2000 Coordinate System
+ The J2000 coordinate system (also known as EME2000) is based on the earth mean equator and dynamical equinox at midnight January 1, 2000. The origin is at the solar system barycenter. This system is inertial, since it does not rotate with respect to stars and the origin is not accelerating (i.e it has a constant velocity). This coordinate system is the root reference for NAIF's SPICE files and software. 
\ No newline at end of file

docs/concepts/index.md

 # Concepts
+Concept docs are understanding-oriented docs. The focus is on explaining a topic. These expand the user's understanding of a topic without elaborating on particulars of code while providing context or descriptions. Information from concept docs might be among other docs, but getting started docs, how-to guides, or software manuals can reference concept docs that go in-depth on the topic. 
+
+## For Readers 
+[comment]: <> (This is a good place to mention any places for someone to start looking in. Highlight specific docs with high value or we identify readers commonly want to see)
+
+Use the table of contents on the left to browse docs covering different concepts. 
+
+Good place to start is with the [glossary](glossary/glossary.md)
+
+## For Authors 
+
+These docs are predominately abstracts on a particular topic. 
+
+Good concept docs have: 
+
+1. A clear and specific topic of discussion   
+1. Little to no instruction 
+1. Context or descriptions of: 
+    * Historical background of the software and/or why it exists
+    * Engineering of a software tool or component thereof 
+    * Concepts commonly found across software 
+
+??? Info "Examples"
+
+    * Dictionaries or Glossary of terms
+    * Explanation of what control networks are and why we use them
+    * History and explanation of ALE's architecture 
+    * Differences between CSM and ISIS camera models 
+
+See the [git repo](https://code.usgs.gov/astrogeology/asc-public-docs) for more in-depth info on how to contribute new docs. 
\ No newline at end of file

docs/getting-started/CSM Stack/ImageToGroundTutorial.ipynb

@@ -5,7 +5,7 @@
    "id": "a117baed-ab98-4499-832c-8c73a8606cc0",
    "metadata": {},
    "source": [
-    "# Getting Started: Instantiating a CSM Camera Model from Image"
+    "# Tutorial: Instantiating a CSM Camera Model from Image"
    ]
   },
   {
@@ -13,7 +13,13 @@
    "id": "3602c014-53bc-4330-a9b0-0848d4927458",
    "metadata": {},
    "source": [
-    "### 1. Install dependencies\n",
+    "Lessons learned in this tutorial: \n",
+    "* How to generate Image Support Data (ISD) for an image\n",
+    "* instantiate a CSM camera model\n",
+    "* Perform a simple ground to image call \n",
+    "\n",
+    "\n",
+    "### 1. Prerequisites, Install Knoten\n",
     "The `knoten` installation may take a little longer than usual due to the many dependencies (including ALE) involved."
    ]
   },

docs/getting-started/index.md

-# Getting Started
+# Getting Started Tutorials
+
+Getting Started tutorials are *lessons*. Readers should be able to follow these tutorials step-by-step with no external guidance given some reasonable starting point. They are learning-oriented documents designed with the purpose of enabling new users to get started with a particular part of the software portfolio. 
+
+## For Readers 
+[comment]: <> (This is a good place to mention any places for someone to start looking in. Highlight specific docs with high value or that we identify readers commonly want to see. You can also put info for users trying to get notebooks/tutorials running)
+
+Browse tutorials using the table of contents on the left. 
+
+FAQ for readers:
+
+??? Question annotate "If the tutorial has dependencies, how do I install them?"
+	We recommend using [miniforge's instructions](https://github.com/conda-forge/miniforge#install) as the package manager of choice for installing dependencies. This is a lite installation that comes with `mamba`, which is a C++ re-implementation of conda that solves packages much faster than conda. For some dependencies like ISIS, this can save a lot of time. Instructions will assume you are using mamba. (1) 
+
+    Once you have mamba installed, you can create environments with `mamba create -n <env name> <package list>`, activate with `mamba activate <env name>`, and install new packages with `mamba install <package>` (2). 
+    
+1. Alternatively, if mini-forge isn't working (they are in active development and things move fast), you can follow [conda's instructions](https://docs.anaconda.com/free/anaconda/install/). If you are running a conda installation, replace the `mamba` commands with `conda`.
+2. :exclamation::exclamation::exclamation: If you installed conda instead, remember to replace the `mamba` commands with `conda`. So environment creation becomes `conda create -n <env name> <package list>`, and environment activation becomes `conda activate env name`, etc.
+    
+
+??? Question "How do I run jupyter notebooks?" 
+    Jupyter notebook-based tutorials have a download button on the upper right. Use these to download the code if you are already familiar with running notebooks locally. As some tutorials require data, the easiest way to work with tutorials is by cloning the repo.
+    ```shell
+    # Clone the repo and go to the tutorials page
+    git clone git@code.usgs.gov:astrogeology/asc-public-docs.git
+    cd asc-public-docs/docs/getting-started/
+    # install dependencies, tutorials often list dependencies at the top
+    # We recommend a new env for each tutorial unless they happen to use the exact same dependencies. 
+    mamba create -n tutorial-name -c conda-forge jupyter 
+    jupyter notebook
+    ``` 
+
+## For Authors
+
+When creating a new getting-started tutorial, first you need to make sure what you are creating is a tutorial. Ask yourself: 
+
+* What is the lesson? Tutorials should have a lesson that the user is expected to learn. 
+* Does your tutorial have a concrete beginning? Tutorials should always have an obvious start with clear instructions on how to get any lesson examples running. 
+* Does your tutorial have a goal? Tutorials should have a clear goal that the user will accomplish. 
+
+??? Info "Examples"
+    * Getting Started: ISIS image ingestion to map projected image, ingesting, bundling, and projecting an image list 
+    * Getting Started: Generating an ISD and CSM camera model
+    * Getting Started: Generate a control network with an image matcher 
+
+Concrete things your tutorial needs: 
+
+- [ ] If your tutorial requires installing software, list what software and their versions and clear instructions on how to install them. Feel free to point to other points of the doc that already have boilerplate info like "Go here to read on how to set up a custom ISISPreferences file". 
+- [ ] If your tutorial has data, use generative data or data that is in the repo. Avoid external data dependencies. Before data is committed into the repo, check if [existing data can be re-used](./data/). If new data needs to be committed, make sure it is small so as not to increase the data burden.   
+- [ ] Make sure to make the lesson clear in the title. Also, make it clear in the tutorial with something like "Lessons learned in this tutorial:". 
+
+
+See the [git repo](https://code.usgs.gov/astrogeology/asc-public-docs) for more in-depth info on how to contribute new docs. 

docs/how-to-guides/index.md

 # How-To Guides
 
+How-to guides are much like recipes in a recipe book. Write how-to docs to solve specific problems quickly, sometimes copy-pastable. Think of how-to guides as pre-emptive StackOverflow-like problems.
+
+
+# For Readers 
+[comment]: <> (This is a good place to mention any places for someone to start looking in. Highlight specific docs with high value or we identify readers commonly want to see)
+
+Use the table of contents on the left to start browsing guides. 
+
+# For Authors
+
+Before you start writing a new How-To guide. Make sure what you are writing belongs here. These are similar to getting-started guides, in that they explain to users how to perform some valuable tasks with the software, but distinct in that they:
+
+1. Solve practical problems for more experienced users
+1. Offer more ambiguous starting points; they should be reusable in many different contexts 
+1. Can be much shorter than getting-started docs. 
+
+??? Info Examples
+    * How-to: generate an ISD via loads with specific kernels
+    * How-to: get GEOJSON from ISIS footprints
+    * Cookbook of common operations in a library
     

docs/index.md

@@ -6,6 +6,8 @@ hide:
 
 # Where to Look 
 
+If looking for something specific, you can use the search function.
+
 These docs use a simple system of defining software documentation in four categories based on the composition and goal of a particular piece of documentation: 
 
 ::cards:: cols=1 
@@ -14,22 +16,22 @@ These docs use a simple system of defining software documentation in four catego
   {
     "title": "Getting Started",
     "content": "Step-by-step tutorials for beginners to get started with different aspects of the Astro software portfolio; this is the best place to learn new things as a beginner to some of our software or those unfamiliar with particular parts of the code.",
-    "url" : getting-started/index.md
+    "url" : getting-started/index.html
   }, 
   {
     "title": "How-To Guides",
     "content": "Examples on how-to complete common software tasks; for intermediate to advanced users who want examples on how to accomplish a particular task.",
-    "url" : how-to-guides/index.md
+    "url" : how-to-guides/index.html
   },
   {
     "title": "Concepts",
     "content": "Write-ups that define and explain concepts that apply to our software; this is for anyone who wants a better understanding of particular higher-level concepts.",
-    "url" : concepts/index.md
+    "url" : concepts/index.html
 },
   {
     "title": "Software Manuals",
     "content": "Links to in-depth software manuals; contains in-depth references to a particular software project's apps and APIs.",
-    "url" : manuals/index.md
+    "url" : manuals/index.html
   },
 ]
 
@@ -40,7 +42,7 @@ These docs use a simple system of defining software documentation in four catego
 
 We use these four categories to cover the range of potential docs, while clarifying to authors and readers for what kind of documentation goes where. 
 
-|                 | Getting Started       | How-Tos                        | Concepts                   | Manuals                                               |
+|                 | Getting Started Tutorials       | How-Tos                        | Concepts                   | Manuals                                               |
 |-----------------|-----------------------|--------------------------------|----------------------------|-------------------------------------------------------|
 | **Oriented To**     | Learning              | Achieving a Goal               | Understanding              | Referencing                                           |
 | **Composed As**     | Step-by-Step Jupyter or Similar Tutorial | General Purpose Guide          | Written Summary            | Generated Sphinx/Doxygen Site                         |
@@ -55,7 +57,7 @@ Before you consider contributing new documentation, ask yourself what category i
 
 Regarding software manuals, issues or contributions should be addressed to the repository for that specific project. The software manuals should have links to their repositories. 
 
-You can submit any issues (e.g., addressing grammar errors, factual inaccuracies) and find more info on how to contribute new docs through the site's [git repository](https://code.usgs.gov/astrogeology/asc-public-docs).
+You can submit any issues (e.g., addressing grammar errors, factual inacuracies) and find more info on how to contribute new docs through the site's [git repository](https://code.usgs.gov/astrogeology/asc-public-docs). If you find an issue somewhere in the repo, we strongly encourage users to also submit a change to the git repository to be reviewed, merged, and deployed. 
 
 
 

docs/manuals/index.md

+---
+hide:
+  - navigation
+  - toc
+---
+
+
 # Software Manuals
 
 ::cards:: cols=3 image-bg

mkdocs.yml

@@ -3,14 +3,14 @@ site_name: USGS Astrogeology Software Docs
 theme:
     name: material
     custom_dir: custom_theme/
-    
+    icon:
+      annotation: material/chevron-right-circle
     font:
       text: Inter
       code: Roboto Mono
     
     features:
         - navigation.tabs
-        - navigation.expand
         - navigation.path
         - navigation.indexes
         - search.suggest
@@ -53,6 +53,7 @@ nav:
       - Class Requirements For Using Doxygen Tags: "how-to-guides/ISIS Developer Guides/Class Requirements For Using Doxygen Tags.md"
   - Concepts: 
     - Home: concepts/index.md
+    - Glossary: concepts/glossary/glossary.md
     - Camera Geometry and Projections:
       - Camera Geometry: concepts/Camera Geometry and Projections/Camera Geometry.md
       - Learning About Map Projections: concepts/Camera Geometry and Projections/Learning About Map Projections.md
@@ -75,6 +76,7 @@ plugins:
 
 markdown_extensions:
   - neoteroi.cards
+  - abbr
   - tables
   - attr_list
   - md_in_html
@@ -88,3 +90,16 @@ markdown_extensions:
   - toc:
       title: On this page
       permalink: true
+  - pymdownx.highlight:
+      anchor_linenums: true
+      line_spans: __span
+      pygments_lang_class: true
+  - pymdownx.inlinehilite
+  - pymdownx.snippets
+  - pymdownx.superfences
+  - pymdownx.emoji:
+      emoji_index: !!python/name:materialx.emoji.twemoji
+      emoji_generator: !!python/name:materialx.emoji.to_svg
+  - pymdownx.snippets:
+        auto_append:
+          - definitions.md