Changeset 3060

Timestamp:

Jun 2, 2006, 4:26:32 PM (18 years ago)

Author:

duncan

Message:

moving text to the correct document

Location:

documentation/requirements

Files:

• anuga_API_requirements.tex (modified) (1 diff)
• thoughts.txt (modified) (1 diff)

documentation/requirements/anuga_API_requirements.tex

@@ -79 +79 @@
   \item Any component that needs coordinates to be relative to a particular point shall be responsible for deriving that origin. Examples are meshes where absolute coordinates may cause numerical problems. An example of a derived origin would be using the South-West most point on the boundary.
 
-  \item Coordinates must be passed around as either geospatial objects or absolute UTM unless there is a compelling reason to use relative coordinates on grounds of efficiency or numerical stability.
+  \item Coordinates must be passed around as either geospatial objects
+  or absolute UTM unless there is a compelling reason to use relative
+  coordinates on grounds of efficiency or numerical stability.
+  
+  \item Passing Geo_reference's as a keyword should not be done  Where
+  it is currently done, it doesn't have to be
+  changed as a matter of priority, but don't document this 'feature'
+  in the user manual.  If you are refactoring this API, then plase
+  remove geo_reference as a keyword.
   
 \end{itemize}   

documentation/requirements/thoughts.txt

@@ -75 +75 @@
 mesh. How does the alpha value get scaled?
 
-
-
-SCRIPTING INTERFACE DESIGN PRINCIPALS (2/6/6) -as agreed to by Duncan and Ole
-(This is regarding the API that people use when writing run_??.py
-files)
-
-- The API's don't have geo_reference as a keyword.
-- When points are entered, a geo_spatial instance can also be entered. 
-
-- Current API's that have geo_reference as a keyword don't have to be
-  changed as a matter of priority, but don't document this 'feature'
-  in the user manual.  If you are refactoring an API, then plase
-  remove geo_reference as a keyword.