CN113610341A

CN113610341A - Planning service method, device, equipment and medium for remote sensing satellite sensor

Info

Publication number: CN113610341A
Application number: CN202110712106.4A
Authority: CN
Inventors: 万伟; 杨振坤; 杜兴强; 赵新伟; 郝雪涛
Original assignee: China Center for Resource Satellite Data and Applications CRESDA
Current assignee: China Center for Resource Satellite Data and Applications CRESDA
Priority date: 2021-06-25
Filing date: 2021-06-25
Publication date: 2021-11-05
Anticipated expiration: 2041-06-25
Also published as: CN113610341B

Abstract

The invention provides a planning service method, a device, equipment and a medium for a remote sensing satellite sensor, wherein the method comprises the following steps: a client acquires an observation task feasibility request form initiated by a user; sending the observation task feasibility request form to a server, so that the server carries out feasibility analysis on an observation task according to the feasibility request form; sending a request for obtaining the feasibility analysis result of the observation task to a server; acquiring a feasibility analysis result of an observation task sent by a server; and acquiring at least one observation subtask selected after the feasibility analysis result of the user is evaluated, and sending the at least one observation subtask to the server to complete the observation task planning service. Compared with the traditional demand planning system and method, the method and the device of the invention greatly reduce the working time of observation demand planning.

Description

Planning service method, device, equipment and medium for remote sensing satellite sensor

Technical Field

The invention belongs to the technical field of sensor planning service, and particularly relates to a method, a device, equipment and a medium for planning service of a remote sensing satellite sensor.

Background

With the dramatic increase of the number of remote sensing satellites and the improvement of the arrangement requirement of user observation tasks, the technical research on the aspect of user demand planning is strengthened in all countries. The foreign research starts early and the result is obvious, and the United states and the European and air Bureau develop a multi-satellite combined observation demand planning system, but the relevant technical details are difficult to obtain.

Most of traditional satellite observation demand planning systems rely on file modes to transfer information such as satellite observation task demands and planning analysis results. For general task requirements, the user is required to fill out an Order Form (Order Form). For long-term observation requirements such as weekly, monthly and yearly, the requirements need to be saved into files, and detailed parameter information needs to be edited and filled in manually and sent to a requirement accepting department. For emergency observation, it is also necessary to use telephone, mail, fax or instant communication tools. And the satellite planning management department performs subsequent processing links such as requirement conflict reduction and the like according to the received requirements.

At present, some satellite task planning management systems provide an online order accepting module function, and are mainly responsible for receiving acquisition orders from clients such as PCs, ioss and Android, and performing simple format verification, validity verification and acquirability verification on the acquisition orders. For example, the european air passenger defense and space company (AIRBUS Defence) developed a web-based satellite acquisition mission ordering system, and the data sources include SPOT, Pleiades, RapidEye, and TerraSAR satellites. The China resource satellite application center provides a satellite acquisition task sheet submission page on the basis of a terrestrial observation satellite ground system distribution service system.

However, the existing service system generally has the following problems: first, the user interface is a single form submission interface, lacking interactivity. Second, the interface lacks standardization. The form filling format, structure and content of each system are different, even the randomness is large, and the unified acquisition requirement is formed after standardization is carried out according to the task characteristics of various satellites. Finally, response timeliness is poor, and planning feasibility and task state of user acquisition requirements cannot be fed back quickly. When meeting the relatively complex requirement of multi-target task analysis, the off-line communication and confirmation with the planning operation management department are still inevitable.

Because observation requirement planning is a work with extremely strong pertinence and timeliness, multiple observations of multiple targets are often needed to complete a specific observation task, especially user requirement feasibility analysis, and follow-up of unfulfilled requirements is further followed. The problem caused by the deficiency of the existing system is that tracking analysis is difficult to perform between observation plans generated by observing demands in a real-time manner, namely, the fact that which of the proposed observation demands is formed and is real as the observation plan cannot be confirmed, the observation plans can be shot by going up to a satellite, and the fact that the real observation plans are derived from which observation demands and which need to be subjected to complementary shooting cannot be confirmed. Therefore, a highly targeted sensor planning service method needs to be designed to solve the problems.

Disclosure of Invention

In order to overcome the defects in the prior art, the inventor of the invention carries out keen research, and provides a remote sensing satellite sensor planning service method, a device, equipment and a medium by combining with an Open Geospatial alliance (OGC) sensor planning service standard (SPS) earth observation satellite task expansion specification.

The technical scheme provided by the invention is as follows:

in a first aspect, a remote sensing satellite sensor planning service method is applied to a client, and includes:

a client acquires an observation task feasibility request form initiated by a user;

the client sends the observation task feasibility request form to a server, so that the server performs feasibility analysis of an observation task according to the feasibility request form;

the client sends a request for obtaining the feasibility analysis result of the observation task to the server;

the client side obtains the feasibility analysis result of the observation task sent by the server side;

if the observation task request falls into the observable category of the target satellite and does not conflict with the planned observation task or the observation task with high priority in the same time period, at least one observation subtask is given in the feasibility analysis result, and all the at least one observation subtasks are options meeting the given observation task and belong to the same observation task;

and the client acquires at least one observation subtask selected after the feasibility analysis result is evaluated by the user, and sends the at least one observation subtask to the server to complete the observation task planning service.

In a second aspect, a remote sensing satellite sensor planning service method is applied to a server, and includes:

the server receives an observation task feasibility request form sent by the client;

the server side carries out feasibility analysis of observation tasks according to the feasibility request form; if the observation task request falls into the observable category of the target satellite and does not conflict with the planned observation task or the observation task with high priority in the same time period, at least one observation subtask is given in the feasibility analysis result, and the at least one observation subtask is an option meeting the given observation task; if the observation task request does not fall into the observable category of the target satellite, or conflicts with the planned observation task, or conflicts with the observation task with high priority in the same time period, the reason and the reason for the infeasible conclusion are given in the feasibility analysis result;

the server receives a request for acquiring the feasibility analysis result of the observation task, which is sent by the client;

the server side sends an observation task feasibility analysis result to the client side;

the server receives at least one observation subtask sent by the client, implements observation task planning, stores observation task planning results, feeds back the results when the client inquires, generates a receiving plan file and a processing plan file, sends the receiving plan file and the processing plan file to the plan file server, and is used for being called by the ground system regularly to implement receiving and processing of satellite downloading data.

In a third aspect, a remote sensing satellite sensor planning service device applied to a client includes:

the system comprises a first acquisition unit, a second acquisition unit and a third acquisition unit, wherein the first acquisition unit is used for acquiring an observation task feasibility request form initiated by a user;

the first sending unit is used for sending the observation task feasibility request form to a server so that the server can carry out feasibility analysis on the observation task according to the feasibility request form;

the second sending unit is used for sending a request for obtaining the observation task feasibility analysis result to the server;

the second acquisition unit is used for acquiring the feasibility analysis result of the observation task sent by the server; if the observation task request falls into the observable category of the target satellite and does not conflict with the planned observation task or the observation task with high priority in the same time period, at least one observation subtask is given in the feasibility analysis result, and the at least one observation subtask is an option meeting the given observation task; if the observation task request is not feasible, the feasibility analysis result gives an infeasible conclusion and an infeasible reason;

the third acquisition unit is used for acquiring at least one observation subtask selected after the feasibility analysis result is evaluated by the user;

and the third sending unit is used for sending the at least one observation subtask to the server side.

In a fourth aspect, a remote sensing satellite sensor planning service device is applied to a server, and includes:

the sensor planning service unit is used for receiving and storing a request file sent by a client, wherein the request file comprises an observation task feasibility request form, a request for obtaining an observation task feasibility analysis result and at least one observation subtask, converting the request file into a type which can be identified by the satellite task planning unit, sending the type to the satellite task planning unit and receiving a result fed back by the satellite task planning unit;

the satellite task planning unit is used for carrying out feasibility analysis according to the request parameters in the observation task feasibility request form and generating an observation task feasibility analysis result;

sending the observation task feasibility analysis result to a sensor planning service unit according to the parameters in the observation task feasibility analysis result request;

and planning each observation subtask according to the request parameter of at least one observation subtask, generating an observation plan, sending the observation plan to a sensor planning service unit, generating a receiving plan file and a processing plan file, sending the receiving plan file and the processing plan file to a plan file server, and using the receiving plan file and the processing plan file to be called by a ground system regularly to receive and process satellite downloading data.

In a fifth aspect, a remote sensing satellite sensor planning service apparatus includes:

one or more processors;

a storage device for storing one or more programs,

when executed by the one or more processors, cause the one or more processors to implement the telemetry satellite sensor planning service method of the first aspect or the second aspect.

In a sixth aspect, a readable storage device has stored thereon a computer program which, when executed by a processor, implements the telemetry satellite sensor planning service method of the first or second aspect.

According to the method, the device, the equipment and the medium for planning the service of the remote sensing satellite sensor, provided by the invention, the following beneficial effects are achieved:

(1) the method and the device of the invention apply a sensor planning service framework, can greatly improve the efficiency of satellite observation demand planning, and can greatly improve the automation degree due to the modes of standardized request structure, interactive flow and the like. The time consumption of observation demand planning is greatly reduced, and compared with the traditional demand planning system and method, the time consumption of work can be reduced by about 70%;

(2) the invention provides the concept of observation tasks, organizes and divides observation requirements and the like according to the tasks, and is convenient for management, tracking and query of various information;

(3) the invention designs the standardized description of the satellite observation task and the satellite-ground resources, has good expandability, can adapt to the future satellite expansion and supports the task planning of the newly added satellite.

Drawings

FIG. 1 is a feedback flow diagram of a client and a server of a remote sensing satellite sensor planning service method;

FIG. 2 is a flow chart of intent order query;

FIG. 3 is a flowchart of GetFeasibility requirement application processing;

FIG. 4 is a GetTask preplanning task list processing flow diagram;

FIG. 5 is a flow chart of submitsegmentById submitting planning tasks according to pre-planning tasks;

FIG. 6 is a task flow diagram of a List Feasibility requirement task List;

FIG. 7 is a flowchart of GetStatus demand task state processing;

FIG. 8 is a ListTasks planning task List processing flow diagram;

FIG. 9 is a flowchart of GetTask query planning task processing;

FIG. 10 is a flowchart of GetStatus query planning task state processing;

FIG. 11 is a flow chart of a Cancel planning task cancellation process.

Detailed Description

The features and advantages of the present invention will become more apparent and appreciated from the following detailed description of the invention.

The word "exemplary" is used exclusively herein to mean "serving as an example, embodiment, or illustration. Any embodiment described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other embodiments. While the various aspects of the embodiments are presented in drawings, the drawings are not necessarily drawn to scale unless specifically indicated.

According to a first aspect of the present invention, as shown in fig. 1 and fig. 2, there is provided a remote sensing satellite sensor planning service method applied to a client, including:

if the observation task request falls into the observable category of the target satellite and does not conflict with the planned observation task or the observation task with high priority in the same time period, at least one observation subtask (arc segment) is given in the feasibility analysis result, and all the at least one observation subtasks are options meeting the given observation task and belong to the same observation task; for example, for a given observation task in the observation task feasibility request form:

the user name is as follows: european office of maritime affairs

Item name: testing

Standard/High/Emergency priority

Priority to test

The latest response time is 2021-06-0112: 00:00.000000

Acquisition time range: 2021-06-0308: 30:00.000000 (beginning, Beijing time)

2021-06-0418: 30:00.000000 (end, Beijing time)

Acquisition area range: north China area polygon

TABLE 1

Collecting parameters:

satellite: superview-1 high view satellite SV-1A/B/C/D

A sensor: PMS (panchromatic multispectral camera)

Resolution ratio: greater than 2 m

Side view angle: less than 30 degrees

Norwegian station as download station

The downloading time is 2021-06-0420: 20: 20.000000.

If the observation task request is feasible, the observation subtasks given in the feasibility analysis result are given as follows:

TABLE 2 Observation subtask example

The client acquires at least one observation subtask selected after the user evaluates the feasibility analysis result, and sends the at least one observation subtask to the server to complete the observation task planning service;

if the observation task request does not fall into the observable category of the target satellite (such as the transit time of the target satellite does not meet the observation time requirement) or conflicts with the planned observation task or conflicts with the observation task with high priority in the same time period, the feasibility analysis result gives the infeasible conclusion and the infeasible reason;

the client will not send the observation task information to the server, and the observation task planning service is finished.

In a preferred embodiment, the method comprises the step of obtaining an observation task feasibility request form initiated by a user at the client, wherein the observation task feasibility request form comprises requirement options such as requirement names, shooting time ranges, regions of interest, imaging modes, polarization modes, shooting frequencies, surface feature requirements or shooting angle requirements and the like. Preferably, the observation task feasibility request form is pre-configured with detailed information about an imaging mode, a polarization mode, a shooting frequency and the like, and is embedded with a formula simulating the occupied area of the region of interest. The requirement name is customized according to a user or is given by options in a form; the shooting time range includes dates and clocks, such as 2021-01-0109: 00 to 2021-01-0121: 00; the position of the target is expressed by longitude and latitude of a geographic coordinate system of the target; the imaging mode is a load working mode, and comprises a single shooting mode, a stereo shooting mode, a multi-target shooting mode, a strip splicing shooting mode and the like if the imaging mode is an optical camera load, and comprises modes such as beam bunching, hyperfine strips, fine strips, standard strips, narrow scanning, wide scanning, fully polarized strips, wave imaging, global observation, extended incidence angle (low or high) and the like if the imaging mode is an SAR (synthetic aperture radar) load; the polarization mode refers to the polarization of electromagnetic beams transmitted and received by the radar, and generally has horizontal polarization and vertical polarization; the shooting frequency is the requirement on the shooting frequency of the space camera, and the shooting frequency of the space camera is not less than the required shooting frequency; the land feature refers to the type of main land surface objects in the shooting area, such as land surfaces, cities, ships, sea surfaces, islands, farmlands, forests, mountainous areas, plains and the like; the shooting angle requirement refers to an included angle between the image acquisition time of the sensor and the satellite subsatellite point. When the roll angle is 0, the satellite shoots vertically, and when the roll angle is 30 degrees, the satellite shoots with 30 degrees of inclination. .

In a preferred embodiment, after the client sends the observation task feasibility request form to a server, the sensor planning service method further includes:

the client sends a request for acquiring a feasibility analysis task list of the current activity to a server;

the client side obtains a feasibility analysis task list of the current activity sent by the server side. Since the user can send a plurality of observation task feasibility request forms at one time, the feasibility analysis task and the state thereof in operation can be known by acquiring the feasibility analysis task list of the current activity. The feasibility analysis task list of the current activity comprises information such as a requirement identification number and a task state, wherein the requirement identification number is an ID number of an observation task feasibility request form and can be used for tracking an observation task in the request form; the task status includes Accepted, Pending, Rejected, etc.

In a preferred embodiment, before the client sends a request for obtaining an observation task feasibility analysis result to the server, the sensor planning service method further includes:

the client sends an acceptance state request of a feasibility request form to the server;

the client side obtains the acceptance state result of the feasibility request form sent by the server side, the acceptance state result comprises received, unreceived, processing and other state information, and the acceptance state result is received, so that the client side can implement subsequent requests for obtaining the feasibility analysis result of the observation task.

In a preferred embodiment, before the client obtains an observation task feasibility request form initiated by a user, or after the client sends at least one observation subtask to a server, the sensor planning service method further includes:

the client sends a request for acquiring a list of the implemented observation plans to a server;

and the client receives a list of the implemented observation plans sent by the server. The list of the implemented observation plans includes information identifying the observation tasks, such as the names of the observation tasks, the submission times of the tasks, and the like. The observation tasks submitted and implemented by the client in the past and the observation tasks submitted and implemented this time are listed in the list of the implemented observation plans.

the client sends a request for acquiring detailed information of a plurality of observation tasks in the observation plan to the server;

the client receives detailed information of the plurality of observation tasks in the observation plan sent by the server, wherein the detailed information includes information for identifying the observation tasks, such as a task identification number and task submission time, information corresponding to requirement options related in an observation task feasibility request form (such as a user name, a Project name Project, priority, latest response time, a shooting time range, a position of a target or a target area range, optical camera acquisition parameters (an imaging mode, a side sway angle, cloud cover and the like), radar acquisition parameters (an imaging mode, a polarization mode, surface feature and the like, product parameters, and observation subtask information (arc segment information, such as a real shooting time range, an observation target area, a selected satellite, a load and the like).

the client sends a request for acquiring the state of the implemented observation task to the server;

the client receives state information of the implemented observation tasks sent by the server, wherein the state information of the implemented observation tasks is used for indicating states of the observation tasks which are completed or not completed but implemented as the observation plans, and the states comprise completed, not completed, implementing, cancelled and the like.

In a preferred embodiment, after the client sends at least one observation subtask to the server, the sensor planning service method further includes:

the client sends an acceptance state request of an observation subtask to the server;

and the client acquires the acceptance state result of the observation subtask sent by the server, wherein the acceptance state result comprises received, unreceived, processed and other state information.

and the client sends an observation task canceling request to the server to cancel the submitted observation subtasks.

As shown in fig. 2, the planning service API functions required for the above communication scenario are as follows:

(1) in the above scenario, the client implements a ListTasks (Get/planning) interface operation to obtain a list of all historical plan task ids, which range from a very short time span to a limited area. This allows the client to retrieve observation plans that have been implemented within a certain period of time.

(2) The client can request the update status of all tasks that have been implemented as observation plans through GetStatus (Get/planning/{ tasking }).

(3) And the client acquires the detailed information of the planned task segment through GetTask.

(4) The client fills out a feasibility request form allowing the user to select areas of interest, times of interest, and other parameters such as sensor mode, etc.

(5) The feasibility request form is sent to the server's service interface (via POST/feasility) as part of the getfeasility request.

(6) If the GET feasibility request is asynchronous, the client must wait for the feasibility analysis to complete and go to the ready state, and send out GetStatus (GET/robustness/{ tasking }. finally, GET the returned result of the feasibility analysis by requesting GetTask (GET/robustness/{ task id }/segments).

(7) The user will then evaluate these returned results in order to select candidate arc segments, requiring formal submission as an acquisition task. These arc segments will then be submitted using SubmitSegmentByID (POST/feasility/{ taskID }/segments). This operation will create a new planning task (i.e., no longer managed under the resources of the feasibility analysis) based on the arc segment ID submitted. In principle, the feasibility analysis task does not exist after the operation.

Note: the sensor planning service unit is not obligated to maintain information for arc segments not included in the submitted ID list.

(8) The client cancels the task using a Cancel operation (DELETE/planning/{ tasKID }).

(9) The client may also request a currently active Feasibility analysis task List through List feasility (Get/feasility).

According to a second aspect of the present invention, as shown in fig. 1 and fig. 2, there is provided a remote sensing satellite sensor planning service method, applied to a server, including:

the server side carries out feasibility analysis of observation tasks according to the feasibility request form; if the observation task request falls into the observable category of the target satellite and does not conflict with the planned observation task or the observation task with high priority in the same time period, at least one observation subtask (arc segment) is given in the feasibility analysis result, and the at least one observation subtask is an option meeting the given observation task; if the observation task request does not fall into the observable category of the target satellite (such as the transit time of the target satellite does not meet the observation time requirement) or conflicts with the planned observation task or conflicts with the observation task with high priority in the same time period, an infeasible conclusion and reason are given in the feasibility analysis result;

In a preferred embodiment, after the server receives an observed task feasibility request form sent by a client, the sensor planning service method further includes:

the server receives a request for acquiring a feasibility analysis task list of a current activity sent by a client;

the server side sends a feasibility analysis task list of the current activity to the client side, the feasibility analysis task list of the current activity comprises information such as a demand identification number and a task state, the demand identification number is an ID number of an observation task feasibility request form and can be used for tracking an observation task in the request form; the task status includes Accepted, Pending, Rejected, etc.

In a preferred embodiment, before the server receives a request sent by a client to obtain an observation task feasibility analysis result, the sensor planning service method further includes:

the server receives an acceptance state request of a feasibility request form sent by a client;

and if the acceptance state result of the feasibility request form sent to the client by the server comprises received, unreceived, processed and other state information, and is received, the server can implement subsequent requests for obtaining the feasibility analysis result of the observation task.

In a preferred embodiment, before the server receives an observation task feasibility request form sent by a client, or after the server receives at least one observation subtask sent by the client, the sensor planning service method further includes:

the server receives a request for acquiring a list of implemented observation plans, which is sent by a client;

and the server side sends a list of the implemented observation plans to the client side. The list of the implemented observation plans includes information identifying the observation tasks, such as the names of the observation tasks, the submission times of the tasks, and the like. The observation tasks submitted and implemented by the user in the past and the observation tasks submitted and implemented this time are listed in the list of the implemented observation plans.

the server receives a request sent by a client for acquiring detailed information of a plurality of observation tasks in an observation plan;

the server side sends detailed information of the plurality of observation tasks in the observation plan to the client side, wherein the detailed information comprises information for identifying the observation tasks, such as task identification numbers, task submission time and the like, information corresponding to requirement options related in an observation task feasibility request form, and observation subtask information.

the server receives a request for acquiring the state of the implemented observation task, which is sent by the client;

the server side sends state information of the implemented observation tasks to the client side, the state information of the implemented observation tasks is used for indicating states of the observation tasks which are completed or not completed but implemented as the observation plans, and the states comprise completed, not completed, implementing, cancelled and the like.

In a preferred embodiment, after the server receives at least one observation subtask sent by a client, the sensor planning service method further includes:

the server receives an acceptance state request of an observation subtask sent by the client;

and the server side sends the acceptance state result of the observation subtask to the client side, wherein the acceptance state result comprises the received, unreceived, processed and other state information.

and the server receives an observation task canceling request sent by the client and cancels a plurality of observation subtasks submitted by the client.

the server sends the implementation process information of the observation subtask to the client or to the user through the mail service, such as the Notify process indicated in fig. 2.

According to a third aspect of the present invention, there is provided a remote sensing satellite sensor planning service device, applied to a client, including:

the second acquisition unit is used for acquiring the feasibility analysis result of the observation task sent by the server; if the observation task request falls into the observable category of the target satellite and does not conflict with the planned observation task or the observation task with high priority in the same time period, at least one observation subtask (arc segment) is given in the feasibility analysis result, and the at least one observation subtask is an option meeting the given observation task; if the observation task request is not feasible, the feasibility analysis result gives an infeasible conclusion and an infeasible reason;

In a preferred embodiment, the remote sensing satellite sensor planning service device further includes:

the fourth sending unit is used for sending a request for acquiring a feasibility analysis task list of the current activity to the server after the first sending unit sends the observation task feasibility request form to the server;

and the fourth acquiring unit is used for acquiring the feasibility analysis task list of the current activity sent by the server.

the fifth sending unit is used for sending the acceptance state request of the feasibility request form to the server before the second sending unit sends the request for obtaining the feasibility analysis result of the observation task to the server;

and the fifth acquiring unit is used for acquiring the acceptance state result of the feasibility request form sent by the server.

a sixth sending unit, configured to send, to the server, a request to obtain a list of implemented observation plans before the first obtaining unit obtains the observation task feasibility request form initiated by the user, or after the third sending unit sends at least one observation subtask to the server;

and the sixth acquisition unit is used for receiving the list of the implemented observation plans sent by the server.

the seventh sending unit is used for sending a request for acquiring detailed information of a plurality of observation tasks in the observation plan to the server before the first acquiring unit acquires the observation task feasibility request form initiated by the user or after the third sending unit sends at least one observation subtask to the server;

and the seventh acquisition unit is used for receiving the detailed information of the plurality of observation tasks in the observation plan sent by the server.

the eighth sending unit is used for sending a request for acquiring the state of the implemented observation task to the server before the first acquiring unit acquires the observation task feasibility request form initiated by the user or after the third sending unit sends at least one observation subtask to the server;

and the eighth acquiring unit is used for receiving the state information of the implemented observation task sent by the server, and the state information of the implemented observation task is used for indicating the state of the observation task which is completed or not completed but implemented as the observation plan.

a ninth sending unit, configured to send a request for a receiving status of the observation subtask to the server after the third sending unit sends the at least one observation subtask to the server;

and the ninth acquisition unit is used for acquiring the acceptance state result of the observation subtask sent by the server.

and the tenth sending unit is used for sending an observation task canceling request to the server side after the third sending unit sends at least one observation subtask to the server side, and requesting to cancel the submitted observation subtasks.

According to a fourth aspect of the present invention, there is provided a remote sensing satellite sensor planning service device, which is applied to a server side, and includes:

In a preferred embodiment, the sensor planning service unit comprises:

(i) the system comprises a demand task receiving interface, a satellite task planning unit and a data processing unit, wherein the demand task receiving interface is used for receiving an observation task feasibility request form, converting the request file into a type which can be identified by the satellite task planning unit and sending the type to the satellite task planning unit;

the parameters of the requirement task receiving interface are as follows:

the interface application is as follows: and receiving the application of the required task and storing the application in a database.

Interface types are as follows: REST (representational State transfer)

Calling frequency: and calling as required.

Calling mode: POST (positive position transducer)

High-score satellite URL: http: IP: Port/gaofen 3/1.0/feasility

Merchant and remote satellite URL: http: IP: Port/super view/1.0/feasility

Ginseng introduction: the caller's username (String user), String-type XML information (String XML).

Returning parameters: XML information of the string type.

The treatment process comprises the following steps: and analyzing the received demand task, storing the content of the demand task into a demand task table, and returning character string type XML information whether the application is successful or not.

The processing flow chart is as follows: fig. 3.

(ii) The system comprises a query pre-planning task list interface, a satellite task planning unit and a query pre-planning task list interface, wherein the query pre-planning task list interface is used for receiving a request for obtaining a feasibility analysis result of an observation task, converting the request file into a type which can be identified by the satellite task planning unit and sending the type to the satellite task planning unit; returning an observation task feasibility analysis result to the client;

the parameters for querying the pre-planned task list interface are exemplified as follows:

the interface application is as follows: the pre-planning information under the requirement can be inquired according to the requirement identification number.

Interface types are as follows: REST (representational State transfer)

Calling frequency: and calling as required.

Calling mode: GET (GET tool)

High-score satellite URL: http: IP: Port/gaofen 3/1.0/feasility/requirement identification number/segments

Merchant and remote satellite URL: http: IP: Port superview/1.0/feasility/requirement identification number/segments

Ginseng introduction: demand identification number (String taskid)

Returning parameters: XML information of the string type.

The treatment process comprises the following steps: and after receiving the requirement identification number, inquiring the pre-planning task table according to the condition and returning the result.

The processing flow chart is as follows: fig. 4.

(iii) Submitting a planning task interface according to a pre-planning task, receiving at least one observation subtask request, converting the request file into a type which can be identified by a satellite task planning unit, and sending the request file to the satellite task planning unit;

the following are examples of parameters of the interface for submitting the planning task according to the pre-planning task:

the interface application is as follows: the pre-planning task can be determined according to the requirement identification number and the pre-planning identification number.

Interface types are as follows: REST (representational State transfer)

Calling frequency: and calling as required.

Calling mode: POST (positive position transducer)

Merchant and remote satellite URL: http: IP: Port/super view/1.0/feasility/requirement identification number/segments

Ginseng introduction: string type XML information (String XML)

Returning parameters: XML information of the string type.

The treatment process comprises the following steps: and receiving XML content, inquiring according to the requirement identification number and the pre-planning identification number, and inserting the XML content into the planning task table to modify the state.

A service flow chart: fig. 5.

In a preferred embodiment, the sensor planning service unit further comprises:

(iv) and the query demand task list interface is used for receiving a request for acquiring the feasibility analysis task list of the current activity sent by the client and returning the feasibility analysis task list of the current activity to the client.

The parameters of the query requirement task list interface are exemplified as follows:

the interface application is as follows: the interface types of the required tasks can be inquired according to the acquisition starting time, the acquisition ending time and the acquisition range: REST (representational State transfer)

Calling frequency: and calling as required.

Calling mode: GET (GET tool)

High-score satellite URL: http: IP: Port/gaofen 3/1.0/feasility

Merchant and remote satellite URL: http: IP: Port/super view/1.0/feasility

Ginseng introduction: acquisition Start time, end time (String period), acquisition Range (String bounding box)

Returning parameters: XML information of the string type.

The treatment process comprises the following steps: and after receiving the acquisition starting time, the acquisition ending time and the acquisition range, inquiring the requirement task table according to the conditions and returning the result.

The processing flow chart is as follows: fig. 6.

(v) And the query requirement task state interface is used for receiving a acceptance state request of the feasibility request form sent by the client and returning an acceptance state result of the feasibility request form to the client.

The parameters of the query requirement task state interface are exemplified as follows:

the interface application is as follows: the status of the demand task can be queried according to the demand identification number.

Interface types are as follows: REST (representational State transfer)

Calling frequency: and calling as required.

Calling mode: GET (GET tool)

High-score satellite URL: http: IP: Port/gaofen 3/1.0/feasility/requirement identification number

Merchant and remote satellite URL: http: IP: Port/super view/1.0/feasility/requirement identification number

Ginseng introduction: demand identification number (String taskid)

Returning parameters: XML information of the string type.

The treatment process comprises the following steps: and after receiving the requirement identification number, inquiring the requirement task table according to the condition and returning the result.

The processing flow chart is as follows: fig. 7.

(vi) And the planning task list interface is used for receiving a request sent by the client to acquire the list of the implemented observation plans and sending the list of the implemented observation plans to the client.

The parameters of the planning task list interface are exemplified as follows:

the interface application is as follows: the interface types can be queried according to the acquisition starting time, the ending time and the acquisition range of the planning task: REST (representational State transfer)

Calling frequency: and calling as required.

Calling mode: GET (GET tool)

High-score satellite URL: http: IP: Port/gaofen 3/1.0/plating

Merchant and remote satellite URL: http: IP: Port/super view/1.0/planning

Returning parameters: XML information of the string type.

The treatment process comprises the following steps: and after receiving the acquisition starting time, the acquisition ending time and the acquisition range, inquiring the planning task table according to the conditions and returning the result.

The processing flow chart is as follows: fig. 8.

(vii) And the query planning task interface is used for receiving a request sent by the client for acquiring the detailed information of the plurality of observation tasks in the observation plan and sending the detailed information of the plurality of observation tasks in the observation plan to the client.

The parameters of the query plan task interface are exemplified as follows:

the interface application is as follows: the sub-planning information under the plan can be inquired according to the planning task identification number.

Interface types are as follows: REST (representational State transfer)

Calling frequency: and calling as required.

Calling mode: GET (GET tool)

High-score satellite URL: http: IP Port/gaofen 3/1.0/planning task identification number/segments

Merchant and remote satellite URL: http: IP: Port/super view/1.0/planning task identification number/segments

Ginseng introduction: planning task identification number (String taskid)

Returning parameters: XML information of the string type.

The treatment process comprises the following steps: and after receiving the planning task identification number, inquiring a planning task table according to the condition and returning a result.

The processing flow chart is as follows: fig. 9.

(viii) And the query planning task state interface is used for receiving a request sent by the client to acquire the state of the implemented observation task and sending the state information of the implemented observation task to the client.

The following are examples of parameters of the query plan task state interface:

the interface application is as follows: the status of the planning task can be queried according to the planning task identification number.

Interface types are as follows: REST (representational State transfer)

Calling frequency: and calling as required.

Calling mode: GET (GET tool)

High-score satellite URL: http: IP port/gaofen 3/1.0/planning task identification number

Merchant and remote satellite URL: http: IP port/superview/1.0/planning task identification number see: planning task identification number (String taskid)

Returning parameters: XML information of the string type.

The treatment process comprises the following steps: and after receiving the planning task identification number, inquiring the planning task state according to the condition and returning the result.

The processing flow chart is as follows: fig. 10.

(ix) And the acceptance state interface is used for inquiring the acceptance state interface of the observation subtask, receiving an acceptance state request of the observation subtask sent by the client and sending an acceptance state result of the observation subtask to the client.

And the planning task canceling interface is used for receiving an observation task canceling request sent by the client and feeding back a canceling result to the client.

The parameters of the planning task cancellation interface are exemplified as follows:

the interface application is as follows: the cancellation operation of the planning task can be performed according to the planning task identification number.

Interface types are as follows: REST (representational State transfer)

Calling frequency: and calling as required.

Calling mode: DELETE

Returning parameters: XML information of the string type.

The treatment process comprises the following steps: and after receiving the planning task identification number, modifying the state of the planning task in the planning task table into cancellation according to the condition.

The processing flow chart is as follows: fig. 11.

(x) And the observation subtask notification service interface is used for sending the implementation process of the observation subtask to the client or the user through the mail service.

The interface in the sensor planning service unit, which is set according to the sensor planning service standard (SPS), allows some imaging observation satellite parameters to be set, such as observation area, observation time, azimuth, elevation, ground resolution, and the like. According to the emergency requirement of the user and the observation requirement of a large area, the efficient coverage and the quick response of various complex tasks of the user, particularly the observation task of the large area target are realized through a standardized flow.

According to a fifth aspect of the present invention, there is provided a remote sensing satellite sensor planning service apparatus, comprising:

one or more processors;

a storage device for storing one or more programs,

According to a sixth aspect of the invention, there is provided a readable storage medium having stored thereon a computer program which, when executed by a processor, implements the telemetry satellite sensor planning service method of the first or second aspect.

The terms "first," "second," "third," "fourth," and the like in the description and in the claims, if any, are used for distinguishing between similar elements and not necessarily for describing a particular sequential or chronological order. It should be understood that the data so used may be interchanged under appropriate circumstances such that the embodiments described herein may be practiced in sequences other than those described. Furthermore, the terms "comprises," "comprising," and "having," and any variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, system, article, or apparatus that comprises a list of steps or elements is not necessarily limited to those steps or elements expressly listed, but may include other steps or elements not expressly listed or inherent to such process, method, article, or apparatus.

It is clear to those skilled in the art that, for convenience and brevity of description, the specific working processes of the above-described systems, apparatuses and units may refer to the corresponding processes in the foregoing method embodiments, and are not described herein again.

In the several embodiments provided in the present application, it should be understood that the disclosed system, apparatus and method may be implemented in other manners. For example, the above-described apparatus embodiments are merely illustrative, and for example, the division of the units is only one logical division, and other divisions may be realized in practice, for example, a plurality of units or components may be combined or integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or units, and may be in an electrical, mechanical or other form.

The units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment.

In addition, functional units in the embodiments of the present application may be integrated into one processing unit, or each unit may exist alone physically, or two or more units are integrated into one unit. The integrated unit can be realized in a form of hardware, and can also be realized in a form of a software functional unit.

The integrated unit, if implemented in the form of a software functional unit and sold or used as a stand-alone product, may be stored in a computer readable storage medium. Based on such understanding, the technical solution of the present application may be substantially implemented or contributed to by the prior art, or all or part of the technical solution may be embodied in a software product, which is stored in a storage medium and includes instructions for causing a computer device (which may be a personal computer, a server, or a network device) to execute all or part of the steps of the method according to the embodiments of the present application. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a Read-only Memory (ROM), a Random Access Memory (RAM), a magnetic disk or an optical disk, and other various media capable of storing program codes.

Those skilled in the art will recognize that, in one or more of the examples described above, the functions described in this invention may be implemented in hardware, software, firmware, or any combination thereof. When implemented in software, the functions may be stored on or transmitted over as one or more instructions or code on a computer-readable medium. Computer-readable media includes both computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. A storage media may be any available media that can be accessed by a general purpose or special purpose computer.

The above-described embodiments are intended to explain the objects, aspects and advantages of the present invention in further detail, and it should be understood that the above-described embodiments are merely exemplary embodiments of the present invention.

The invention has been described in detail with reference to specific embodiments and illustrative examples, but the description is not intended to be construed in a limiting sense. Those skilled in the art will appreciate that various equivalent substitutions, modifications or improvements may be made to the technical solution of the present invention and its embodiments without departing from the spirit and scope of the present invention, which fall within the scope of the present invention. The scope of the invention is defined by the appended claims.

Those skilled in the art will appreciate that those matters not described in detail in the present specification are well known in the art.

Claims

1. A remote sensing satellite sensor planning service method is applied to a client side and comprises the following steps:

2. The remote sensing satellite sensor planning service method of claim 1, wherein after the client sends the observation task feasibility request form to a server, the sensor planning service method further comprises:

the client side obtains a feasibility analysis task list of the current activity sent by the server side.

3. The remote sensing satellite sensor planning service method of claim 1, wherein before the client sends a request to a server for obtaining observation task feasibility analysis results, the sensor planning service method further comprises:

and the client acquires the acceptance state result of the feasibility request form sent by the server.

4. The remote sensing satellite sensor planning service method of claim 1, wherein before the client obtains a user-initiated observation task feasibility request form, or after the client sends at least one observation subtask to a server, the sensor planning service method further comprises:

the client receives a list of the implemented observation plans sent by the server, and the observation tasks submitted and implemented by the client in the past and the observation tasks submitted and implemented this time are listed in the list of the implemented observation plans.

5. The remote sensing satellite sensor planning service method of claim 1, wherein before the client obtains a user-initiated observation task feasibility request form, or after the client sends at least one observation subtask to a server, the sensor planning service method further comprises:

and the client receives the detailed information of the plurality of observation tasks in the observation plan sent by the server.

6. The remote sensing satellite sensor planning service method of claim 1, wherein before the client obtains a user-initiated observation task feasibility request form, or after the client sends at least one observation subtask to a server, the sensor planning service method further comprises:

the client receives state information of the implemented observation tasks sent by the server, wherein the state information of the implemented observation tasks is used for indicating the states of the observation tasks which are completed or not completed but implemented as the observation plans.

7. The remote sensing satellite sensor planning service method of claim 1, wherein after the client sends at least one observation subtask to a server, the sensor planning service method further comprises:

and the client acquires the acceptance state result of the observation subtask sent by the server.

8. The remote sensing satellite sensor planning service method of claim 1, wherein after the client sends at least one observation subtask to a server, the sensor planning service method further comprises:

9. A remote sensing satellite sensor planning service method is applied to a server side and comprises the following steps:

10. The remote sensing satellite sensor planning service method of claim 9, wherein after the server receives an observation task feasibility request form sent by a client, the sensor planning service method further comprises:

and the server side sends a feasibility analysis task list of the current activity to the client side.

11. The remote sensing satellite sensor planning service method of claim 9, wherein before the server receives a request sent by a client to obtain observation task feasibility analysis results, the sensor planning service method further comprises:

and the server sends the acceptance state result of the feasibility request form to the client.

12. The telemetry satellite sensor planning service method of claim 9, wherein prior to the server receiving an observation task feasibility request form sent by a client, or after the server receiving at least one observation subtask sent by a client, the sensor planning service method further comprises:

and the server side sends a list of the implemented observation plans to the client side, wherein the list of the implemented observation plans comprises information for identifying observation tasks, such as observation task names, task submission time and the like.

13. The telemetry satellite sensor planning service method of claim 9, wherein prior to the server receiving an observation task feasibility request form sent by a client, or after the server receiving at least one observation subtask sent by a client, the sensor planning service method further comprises:

and the server side sends the detailed information of the observation tasks in the observation plan to the client side.

14. The telemetry satellite sensor planning service method of claim 9, wherein prior to the server receiving an observation task feasibility request form sent by a client, or after the server receiving at least one observation subtask sent by a client, the sensor planning service method further comprises:

and the server side sends the state information of the implemented observation task to the client side, wherein the state information of the implemented observation task is used for indicating the state of the observation task which is completed or not completed but implemented as the observation plan.

15. The telemetry satellite sensor planning service method of claim 9, wherein after the server receives at least one observation subtask sent by a client, the sensor planning service method further comprises:

and the server side sends the acceptance state result of the observation subtask to the client side.

16. The telemetry satellite sensor planning service method of claim 9, wherein after the server receives at least one observation subtask sent by a client, the sensor planning service method further comprises:

17. The telemetry satellite sensor planning service method of claim 9, wherein after the server receives at least one observation subtask sent by a client, the sensor planning service method further comprises:

and the server side sends implementation process information of the observation subtasks to the client side or the user through the mail service.

18. A remote sensing satellite sensor planning service device is characterized in that the device is applied to a client and comprises:

19. The remote sensing satellite sensor planning service apparatus of claim 18, further comprising:

the fourth acquiring unit is used for acquiring a feasibility analysis task list of the current activity sent by the server; and/or

a fifth acquiring unit, configured to acquire a result of an acceptance state of the feasibility request form sent by the server; and/or

a sixth obtaining unit, configured to receive a list of implemented observation plans sent by a server; and/or

the seventh acquisition unit is used for receiving the detailed information of the plurality of observation tasks in the observation plan sent by the server; and/or

the eighth acquiring unit is used for receiving the state information of the implemented observation task sent by the server, wherein the state information of the implemented observation task is used for indicating the state of the observation task which is completed or not completed but implemented as the observation plan; and/or

a ninth acquiring unit, configured to acquire a result of a receiving state of the observation subtask sent by the server; and/or

20. A remote sensing satellite sensor planning service device is characterized in that the device is applied to a server side and comprises:

21. The telemetry satellite sensor planning service of claim 20, wherein the sensor planning service comprises:

the system comprises a demand task receiving interface, a satellite task planning unit and a data processing unit, wherein the demand task receiving interface is used for receiving an observation task feasibility request form, converting the request file into a type which can be identified by the satellite task planning unit and sending the type to the satellite task planning unit;

the system comprises a query pre-planning task list interface, a satellite task planning unit and a query pre-planning task list interface, wherein the query pre-planning task list interface is used for receiving a request for obtaining a feasibility analysis result of an observation task, converting the request file into a type which can be identified by the satellite task planning unit and sending the type to the satellite task planning unit; returning an observation task feasibility analysis result to the client;

and submitting a planning task interface according to the pre-planning task, receiving at least one observation subtask request, converting the request file into a type which can be identified by the satellite task planning unit, and sending the type to the satellite task planning unit.

22. The telemetry satellite sensor planning service of claim 20, wherein the sensor planning service further comprises:

the system comprises a query demand task list interface, a client side and a service server, wherein the query demand task list interface is used for receiving a request for acquiring a feasibility analysis task list of a current activity sent by the client side and returning the feasibility analysis task list of the current activity to the client side;

the system comprises a query requirement task state interface, a request processing module and a request processing module, wherein the query requirement task state interface is used for receiving a received state request of a feasibility request form sent by a client and returning a received state result of the feasibility request form to the client;

the planning task list interface is used for receiving a request sent by a client for acquiring a list of the implemented observation plans and sending the list of the implemented observation plans to the client;

the query planning task interface is used for receiving a request sent by a client for acquiring detailed information of a plurality of observation tasks in an observation plan and sending the detailed information of the plurality of observation tasks in the observation plan to the client;

the query planning task state interface is used for receiving a request for acquiring the state of the implemented observation task sent by the client and sending the state information of the implemented observation task to the client;

the system comprises an observation subtask acceptance state interface, a client side and a client side, wherein the observation subtask acceptance state interface is used for inquiring the acceptance state interface of the observation subtask, receiving an acceptance state request of the observation subtask sent by the client side and sending an acceptance state result of the observation subtask to the client side;

and the observation subtask notification service interface is used for sending the implementation process of the observation subtask to the client or the user through the mail service.

23. A remote sensing satellite sensor planning service apparatus, comprising:

one or more processors;

a storage device for storing one or more programs,

when executed by the one or more processors, cause the one or more processors to implement the telemetry satellite sensor planning service method of one of claims 1 to 8 or one of claims 9 to 17.

24. A readable storage medium, characterized in that a computer program is stored thereon, which program, when being executed by a processor, carries out the method of remote sensing satellite sensor planning service of one of claims 1 to 8 or of one of claims 9 to 17.