{{body}}

this PUT:
https://kb-dsp-server-dev.herokuapp.com/api/v1/drones/584adbcfaebc030004a68a8d

{  
  "lat": 40.1, 
   "lng": -81.1, 
   "status": "idel-busy"
}

returns status not allowed. 400

drone should be able to change their status with lat and lng

{{body}}

similar table views like for the Service Providers

Client can rate the service quality (1-to-5 star) plus submitting a comment/feedback to the Service Provider.

{{body}}

DO characteristics can be qualified service types, flights, flight hours, certificates, operated drones, …

{{body}}

similar table views like for the Service Providers

In our drone series we have two types of maps: (1) in the mission planner a pilot can plan where a drone will fly on a map and (2) the drone map which shows where all the current drones are located. For both of these types of maps we want to add multiple polygons in the map via the api. What we are asking is for you to develop the model and endpoint service for these new polygons. There are actually two use cases for the polygon and we think it is best to keep them in the same collection but we want to hear from you. Below is a list of requirements for the two types of polygons you should consider those and build out the api to support them. In addition you will find two demo submissions in the forum from TCO where Sky_ and cjalmeida (screenshots inline below) which a quick examples of showing how to draw polygons on a map. You should take one of those and wire to your solution. This challenge is focused on the backend so you should need to worry too much about the client, that will be a follow up.

Polygon type 1: No Fly Zone

1. One type of polygon that needs to be stored is a no fly zone (nfz) this should be accessible by all users and non registered guests. It will be created by admins or authorized users. It is intended to designate zones where no drone should fly or represent the outer-most flight boundary of a single drone (with a start and stop time) and no other drone should fly in that zone.
2. This should act exatly like a Temporary Flight Restriction -TFR and it maybe in the shape of polygon or it maybe a circle with a set radius. This would be used to set up a nfz around a tower or a landmark.
3. The most important aspect of these zone is that they are queryable such that you can make a call and pass a lat and lng and time and know if you are inside a region. For example a drone use the PUT /drone/{id} endpoint to update it location, and if this location update falls inside one of these no fly zones we want to send of a notification to that user.
4. The NFZ region should also support meta data like description, start_time, end_time, and isActive to name a few. You will also need to think about a convention for start and end time if the no fly zone is permanent.

Polygon type 2: Region to Fly Zone
5. The second type of polygon is what we used for the tco drone overlay challenge and it is articulated but a customer who wants to look at a map and draw a shape around the region that they want imagery and will be able to annotate it like 'I want infared video of this area from 100'. They should also be able to select and annotate a single point. For example 'at this point is a cellular tower, I need a close up of all three of the Harris Microwave dishes'
6. Polygons and points are a must for this type and circles and rectangles would be a nice to have.

As you can tell it seems like these to regions could use the same model and api and just flag a type field, However you can assume the number of these types of regions will be in the millions so you may want to use the same model but different endpoints and/or collection please address that in your solution. You should also assume that all the maps will show the type 1 NFZ but only user who are authorized for a particular request / mission will see the Region to Fly Zone (RTFZ). The zone should also be set the color ideally from the payload. This way we can create different subsets of these two zone by reading the value.

For now we would like to stick with Mongo so we can take advantage of the geo spatial queries.

Although this challenge is not about the UI you still need to show you features on one of the two provided demo maps or supply your own.

{{body}}

Drone Services for Drone Service Providers, Drone Operators and Authorities shall cover

• Link to EPIC ID 002, 003, 004, ...
• Tools & Support for Drone Service Providers
  • Tools for Fleet Mgmt, Mission Planning, ...
  • Tools & Services for Drone Safety & Compliance
  • Professional Network (e.g. search for pilots)
  • Data Processing & Analytics Tools
• Tools & Support for Drone Operators(Pilots)
  • Tools & Checklists for Flight Safety & Drone Ops
  • Training programs for Pilots
  • ...
• Tools & Support for ATM authorities

The DSP shall provide the capability to add a drone entry to the DSP.

{{body}}

Edit Drone Service Provider details which includes at least but is not limited to

• SP contact information (addresses, locations, email, phone, ...)
• SP operation area/regions
• SP qualification & certification (operated drone types, drone licences, drone service applications)
• SP service & price catalogue
• SP references
• SP marketing information (e.g. sample reports, success stories, ...)

This will also trigger the Clients procurement/accounting system (not for the demo).

Provide Client Dashboard to organise service request/orders, deliverables, …

Somewhere in the process of updating a api we broke the feature that kept the historic positions of the drones every time they were updated. We had this working at the begining of the month and somehow it was unmerge or is not working and I can't seem to figure it out.

For example the following call will update the position of a drone:

curl -X PUT -H "Accept: application/json" -H "Content-Type: application/json" -H "Cache-Control: no-cache" -H "Postman-Token: ee27f405-dd72-f60f-c563-082f2edb7763" -d '{  
  "lat": 40.1, "lng": -73.1
}
' "http://kb-dsp-server-dev.herokuapp.com/api/v1/drones/584adbcfaebc030004a68a8d"

and if everything is working properly we can use this call to query that specific drones history of locations.

curl -X GET -H "Accept: application/json" -H "Content-Type: application/json" -H "Cache-Control: no-cache" -H "Postman-Token: 708fdf56-3a63-354b-cacb-e648733784e4" "http://kb-dsp-server-dev.herokuapp.com/api/v1/droneposition/584adbcfaebc030004a68a8d?limit=10"

I will drop the .env file in the forum so you don't have to run mongo local.

Other notable challenges in this series

Maps React and REST
React Map Mission Plan
Mission Plan fixes part 1
WEBAPI - Consumer to DSP API Product Catalog - swagger API design

Links

front end src: topcoderinc/dsp-frontend
back end src: topcoderinc/dsp-server

CRUD service catalogue; Release service catalogue

{{body}}

{{body}}

Guide and promote usage of the DSP for the various roles offered;

B2B application market providing promotion, service concepts, readings and success stories for a specific drone application.

in the swagger UI the GET /drones is missing the limit form.

The DSP shall provide the capability to manage drone operational readiness & maintenance needs

{{body}}

B2B applications/market places for Customers shall cover- Agriculture

• Construction / Pre-Construction
• Inspection

for details see Edit Service Request details #102

The DSP shall provide the capability to create and maintain the qualification/cerification record of the Drone Operator. Based on the Drone Operator's qualification requirements and the qualification record the DSP shall provide a notification and messaging system for the DO's periodic qualification/certification renewal.

The DSP shall provide the capability to add a drone service provider entry to the DSP.

Provide DSP Owner Dashboard to organise the work environment.

The current registration api creates only the User object, but provider endpoints require user.provider object to be filled in. In this challenge, you should do the following:

1. Modify the api to require provider data when role is 'provider' and to create the Provider object for the new user. This needs to be done for form registration only, social login should always register 'consumer' role. Update the swagger.yaml file too
2. Update the registration page in dsp-app (frontend) - add a choice for registering as consumer or provider. In case provider is selected, allow the user to enter the fields for the Provider data model. You can add only the required fields for now.

Verify that provider endpoints can be called with a new provider user (for example POST /provider/drones). Postman api calls can be used for verification.

Upon technical acceptance the Client can trigger through the DSP the Client's accounting system to release the payment.

Will receive the confirmation of the SR (accepted, rejected) plus a possible comment and/or pdf as attachment from SP.

The DSP shall provide the capability to add a drone operator entry to the DSP.

{{body}}

{{body}}

Provide Service Provider Dashboard to organise orders, tasks, missions, fleet, …

B2B applications/market places for Customers shall cover

• Agriculture
• Construction / Pre-Construction
• Inspection
• Mining
• Oil & Gas
• Disaster Response
• Cargo Delivery
• City / Governmental Applications
• Insurance (active use case)
• Maritime Surveillance

Smart select (use default from previous service requests; or based on region of interest, based on service type selected)

Edit Drone Operator details which includes at least but is not limited to

• DO contact information (address, location, email, phone, ...)
• DO operation area/region
• DO qualification & certification (operated drone types, drone licences, drone service applications)
• DO references

The DSP shall provide a notification with the DSP URL link where the delivery can be downloaded by the Client. (If explicitly requested by the Client in the Service Request delivery can also be via attachment in the notification. —not for the demo)

{{body}}

{{body}}

n/a for Phase 2

Client can delete a Service Request if it is in a draft state (not yet submitted) or in the state “submitted (pending acceptance)”. A Service Request in another (later) state can not be deleted by the Client.

Edit Drone details which includes at least but is not limited to:

• Drone Name
• Drone Type/Model
• Drone Performance (Range, Endurance, Speed, Operating Altitude, Payload Capacity)
• Supported/Available Drone Sensor Types
• Supported Mission Types
• Supported Applications vs Sensor Types (matrix)

{{body}}

{{body}}

{{body}}