File: api.dox

package info (click to toggle)
gdal 1.10.1+dfsg-8
  • links: PTS, VCS
  • area: main
  • in suites: jessie, jessie-kfreebsd
  • size: 84,320 kB
  • ctags: 74,726
  • sloc: cpp: 677,199; ansic: 162,820; python: 13,816; cs: 11,163; sh: 10,446; java: 5,279; perl: 4,429; php: 2,971; xml: 1,500; yacc: 934; makefile: 494; sql: 112
file content (86 lines) | stat: -rw-r--r-- 3,256 bytes parent folder | download | duplicates (2)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
/*!

\typedef int (*GDALProgressFunc)(double dfComplete, const char *pszMessage, void *pProgressArg)

\brief Callback progress definition for long operations.

GDALProcessFunc is a typedef defining the signature of functions to be
used with GDAL as callbacks to report the progress of long running processes.
Typically these are functions that would update a GUI progress bar showing how
much of a process is done. 

A number of GDAL functions and methods accept GDALProcessFunc arguments along
with an opaque application supplied data item (pProgressArg) which are then 
used to implement progress reporting.  The GDALDataset::BuildOverviews(), and
GDALDriver::CreateCopy() methods are examples of two methods that utilize
the progress semantics.

\code
  int (*GDALProgressFunc)(double dfComplete, const char *pszMessage, 
		          void *pProgressArg);
\endcode

@param dfComplete The ratio of completness of the process from 0.0 for just
started to 1.0 for completed.

@param pszMessage An optional message string to display.  This is usually NULL.

@param pProgressArg Application supplied opaque data normally used by the 
callback to display the result. 

@return TRUE if the operation should continue or FALSE if the user has
requested a cancel.

For example, an application might implement the following simple
text progress reporting mechanism, using pData to pass a default message:

\code
 int MyTextProgress( double dfComplete, const char *pszMessage, void *pData)
 {
     if( pszMessage != NULL )
         printf( "%d%% complete: %s\n", (int) (dfComplete*100), pszMessage );
     else if( pData != NULL )
         printf( "%d%% complete:%s\n", (int) (dfComplete*100),
                 (char) pData );
     else
         printf( "%d%% complete.\n", (int) (dfComplete*100) );
     
     return TRUE;
 }
\endcode

This could be utilized with the GDALDataset::BuildOverviews() method like
this:

\code
      int       anOverviewList[3] = {2, 4, 8};

      poDataset->BuildOverviews( "NEAREST", 3, anOverviewList, 0, NULL, 
                                 MyTextProgress, "building overviews" );
\endcode

In addition to reporting progress to the user, the GDALProcessFunc mechanism
also provides a mechanism for a user interface to return a request from the
user to cancel the operation to the algorithm via the return value.  If FALSE
is returned, the algorithm should terminate the operation and return as 
quickly as possible.
 
More often that implementing custom progress functions, applications 
will just use existing progress functions like GDALDummyProgress(), 
GDALTermProgress() and GDALScaledProgress().  Python scripts also can pass 
progress functions.

Application code implementing GDALProgressFunc semantics should remember 
a few things:
<ol>
<li> Be wary of NULL progress functions being passed in.  The pfnProgress
argument can be set to GDALDummyProgress() in this case for simplicity.

<li> Always check the return value to watch for a FALSE indicating the
operation should be terminated.

<li> The ratio of completeness should vary from 0.0 to 1.0.  Please ensure the
exact value 1.0 is always returned at the end of the algorithm as some 
gui display mechanisms use this as a clue to popdown the progress monitor. 

*/