Changes between Version 5 and Version 6 of Grass7/RPCInterface

Timestamp:

Apr 23, 2014, 2:08:42 AM (10 years ago)

Author:

huhabla

Comment:

--

Grass7/RPCInterface

@@ -26 +26 @@
  * Map metadata read access as single client function will do on the server side: open map; read metadata; close map; send data
 
- * fast raster and vector map read access as single client function will do on server side: open map; read requested map into memory based on bounding box and render resolution; close map; send data
+ * Fast raster and vector map read access as single client function will do on server side: open map; read requested map into memory based on bounding box and render resolution; close map; send data
 
- * vector editing: keep a single vector map in update state open in a dedicated grass vector editing process. In case of a fatal error, this map may be lost or corrupted. It is important that this process will not be used for other purposes than single vector map editing.
+ * Vector editing: keep a single vector map in update state open in a dedicated grass vector editing process. In case of a fatal error, this map may be lost or corrupted. It is important that this process will not be used for other purposes than single vector map editing.
 
- * vector analysis functionality that need to keep vector maps open in read only state for fast topological access. Information's about the open vector maps (i. e. the position of the next line to be read) may be lost in case the server process terminates.
+ * Vector analysis functionality that need to keep vector maps open in read only state for fast topological access. Information's about the open vector maps (i. e. the position of the next line to be read) may be lost in case the server process terminates.
 
  * Same for raster map analysis
@@ -41 +41 @@
 pool of GRASS server processes.
 
-=== Data Exchange ==
+ 
+[1] https://thrift.apache.org/
 
-First it must be determinate what data structures should be exchanged between server and client applications (this proposal is thrift specific):
+
+=== Data Exchange ===
+
+First we must determinate what data structures should be exchanged between server and client applications (this proposal is thrift specific):
 
  * Strings, integer, double and boolean types as argument for functions and return values
  * Map metadata (raster, vector, voxel), region information, projection information as specific thrift structures using strings internally
  * Time stamps as specific thrift  structure using integers, strings and double types
- * Raster data (single row and whole map) as byte array (RGB map), integer array (CELL type), double array (FCELL and DCELL)
+ * Raster data (single row and whole map) as byte array (RGB map), integer array (CELL type) and double array (FCELL and DCELL)
  * Vector data (single line/feature) as specific thrift structure with metadata (line type, ...), integer array for line_cats and double array for line_points
  * Several vector lines as ordered list using the specific thrift structure
@@ -56 +60 @@
  * A hash table (map) structure with internal string, integer and double arrays that represent single columns of a database table
 
-== Higher level API ==
+=== Higher level API ===
 
 The server process should be able to keep maps open in read only mode, to allow fast access to raster and vector data for analysis. Maps are identified by their name@mapset id, hence a hash table will be used to store the file descriptors and map structures in the server process. Hence open and close map functions must be provided by the RPC interface.
@@ -69 +73 @@
  * Call a GRASS module, using the server process specific location/mapset and region settings
  * List all available maps (raster, vector and voxel)
-
- 
-[1] https://thrift.apache.org/