Common Questions

The most common questions are:

• If the system tells people where they cannot fly (privacy requests, no-fly zones), it’s easy to circumvent it by not using the service.
  • Yes, but people will want to use the system for the benefits of avoiding damage or loss, or liability. It’s not meant to limit drones, but to protect them.
• Can’t you just specify where there are safe flying zones and corridors instead?
  • A big benefit of a drone is that it can go in any direction, and is smaller than a piloted vehicle. If safe zones were provided, it would be more limiting than helpful, and not assist in deliveries, surveys and other uses of drones.
• You will be tracking my location, I don’t want that.
  • The PROWL system can be accessed from anywhere, and look up any location. You could be physically in Australia and looking up information from Japan.
  • The record of where you have requested a lookup to start from is not part of the hazard database, the position of a drone/user is not part of PROWL. Have a look at what it will not do.
• This already exists with some drone vendors
  • Some drones have control for mandatory exclusion zones such as airports, but not every object and hazard in the world, and are not updated constantly.
• The information already exists in other sources
  • Yes, but they don’t provide it in a way that is easily used for route planning. Without the PROWL system, you would need to look up airports and privacy requests and buildings and trees and schools/hospitals – and work out the combination of hazards for yourself.
  • There are other providers such as Google, OpenStreetMap, Esri – which can be used as additional data sources to augment or validate information, but they do not have the information about no-fly zones, privacy requests, overhead power lines, temporary hazards such as construction cranes, etc. Only PROWL offers this.
• Can’t I just get all the data downloaded for me to keep on a database of my own?
  • That would be out of date as soon as it is downloaded, not able to be improved by users from around the world, and not include the whole planet of data!
• GPS is not accurate enough
  • It doesn’t need to be – the PROWL data helps in planning a route, and your chosen planning software can take into account any requirement for error acceptance. Your software is planning a route around hazards, trying to avoid them by as much distance as practical.
  • GPS technology, augmented with accelerometer and motion detection, will improve GPS accuracy in the future.

More questions? Post them in the Contact box below.

Multi-object simplification

Multi-object simplification is the core to the accuracy of user-submitted content in the PROWL system. Using this approach, poor data submissions can be corrected or rejected, leading to a higher quality of data content.

Using AI, polygons are enumerated based on a number of variables to ensure that invalid polygons are excluded, and that outlying datapoints are pruned. The variables that are used to inform the AI in it’s evaluation of polygons and datapoints include;

• The trust level of the source user – how many valid objects they have submitted in the past
• The trust level of the source data – such as from a mapping company vs a council
• The number of correlations between existing user-submitted polygons
• The potential for GPS inaccuracies that may skew data consistently in one direction
• Relationships between the submitted data and external sources of data – such as topography or 3rd party 3D model data sources
• The source of the user-submitted data; was it from a drone’s sensors, through flight planning software, through the web form, through 3D modelling software etc.
• Extrapolation of the polygon model shape based on the categorisation type – a long, thin object used to represent a wire type, as opposed to a block object representing a building type.
• AI interpretation of interpolations and extrapolations of the likely location of objects and data
• Other patent-pending approaches and analysis methods

Investors

The drone PROWL project is just coming out of Stealth mode at the moment. However, help and advice is always appreciated.

If you are interested in any of the following, please get in touch with the Contact Us form below;

• Investment in PROWL
• Offer to work with us for a great solution (we need web developers, ESB experience, NoSQL developers, GeoJSON architects, and many more)
• Ideas and suggestions on how we can be better
• Offers of donations :) or referral to grants, angel investors or seed funding
• Offering of free services, advice and assistance to make PROWL great

Object Categorisation

The PROWL system uses a simple categorisation system to identify what real-world objects are. The category is assigned as a single letter to each polygon object, and groups objects into a type that indicates how it should be handled.

Stationary objects such as buildings are grouped together – these objects are unlikely to move, and so a drone can get relatively close to them. When the database is cleansed, small differences are tolerated between user-submitted objects and the existing data in the PROWL database.

Objects such as wires and trees can be moved by the wind, and so a wider recommended distance is given. When object simplification is performed, a larger tolerance of differences between crowd-sourced data is allowed.

Some objects are categorised as having an expiry date – such as requests for privacy. This expiry date limits data corruption or injection problems, and issues related to temporary changes.

Object categorisation techniques also assist with object simplification; where a stationary object – such as a bridge – and a corridor object – such as a rail line – can be interpreted as not being able to intersect. In this example, if there were multiple user submissions of the bridge object, then the polygons submitted can be simplified to make the bridge model more accurate, but would not be combined with the rail corridor object.

Each object is also assigned a unique ID, the submission date and the submitter username (or source) is recorded as the object owner. This allows the object to be removed by the owner, external data ownership to be retained, and trends in invalid data submissions to be tracked.