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
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.
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.
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.
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
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'
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.
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
Polygon type 2: Region to Fly Zone
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.