Show HN: Dovepass – can I legally fly a drone along this exact path in SF? | Hacker News Reader

Show HN: Dovepass – can I legally fly a drone along this exact path in SF?

dovepass.com

33 pointsnimitmehra10 comments

Dovepass answers one question for drone operators: given two points, can a drone legally fly between the two points?

I build route planning for delivery drivers and wanted to check what it would look like if the vehicle flies. Drone navigation is different from land-based vehicle navigation. In addition to road and traffic data, it requires data on buildings, building height, wind speed and direction, and total load, including the payload a drone might carry. It is also governed by a set of rules; depending on the area, federal, state, or county rules may apply.

The decision point becomes whether, at each point on the route the drone can fly based upon whether regulations permit, the wind direction favours it and whether it flying over a road or people? Depending on when the drone flies, the same path valid two hours ago may no longer be valid.

For example a trip from 24th & Valencia ( Mission) to 19th Ave & Irving (Inner Sunset) and back is 5.1 km each way. A DJI mini 4 Pro would take 19 min on 7 mph winds from the west and use 92% of its usable battery and give a Go signal with warning. But at 11mph wind from the same direction would become No-Go because it would use 111% of its usable battery. Or whenever there is a Giants game at Oracle Park, this route is unusable because it is 2.5miles from the stadium. FAA bars all drones within 3 nautical miles from a stadium from 1 hour before the game to one hour after it ends.

I chose San Francisco as the first city to build this because there is enough data about the buildings (92% coverage), wind data is easily available at the drone flying height, and the city has a mix of slopes, water bodies, buildings and airport-related airspace restrictions all in one city. The city also has local rules regarding drone flights in parks - both operated by the city as well as by Golden Gate National recreational areas ( National Park Service).

I used kimi to build it and claude acted a sa judge. To understand more about the challenges faced during the build and the tradeoffs made please read - https://dovepass.com/how-it-was-built/"

Open articleView on HN

A couple thoughts:

> Your landing point is 7 ft (2 m) from a 164 ft (50 m)-tall building — taller than drones may fly, so we keep at least 80 ft (25 m) from it.

The numbers are from just clicking a random spot, but I'm kind of confused about how you're interpreting the regulations. In the US, the maximum allowable altitude is 400 feet AGL per § 107.51(b), albeit with a structure exemption for Part 107 pilots. Within a 400 foot radius around a structure, you can fly 400 feet above said structure's maximum height. That drops down to 400 feet AGL the moment you go beyond that radius, however.

Setting aside both the math error with the building height and the structure exemption, what's the basis for the exclusion zone that's being referenced? Granted, you absolutely want horizontal separation near buildings to account for winds that can easily slam a drone into a window, but the error message could imply that your 80 foot clearance is a nonexistent regulatory rule. I'm guessing that's just a conservative safety margin to make flight planning easier, but you should explicitly identify it as such so as to avoid ambiguity or the implication that it's a prescriptive FAA regulation. There's a reason why clarity and precision are so critical in pretty much any aviation document.

Anyhow, it's an interesting concept, one that I could see it being useful in planning but I'd double check some of the altitude logic. I'd also add references to error messages that point to the relevant regulations that trigger the warnings.

0. https://www.ecfr.gov/current/title-14/chapter-I/subchapter-F...

1. https://pilotinstitute.com/drone-altitute/

Thank you. You are right. The 80ft buffer is our own buffer not FAA buffer. The message should say so, I will change it.

"Taller than drones may fly" is wrong for 164ft building. What tripped it is, at that spot the local LAANC facility map ceiling which is below 400ft and on top of that, we have kept 50ft clearance over buildings. I would change it so the full calculation is shown.

About the exception for §107.51(b) - I kept the stricter 400 feet AGL cap because of how data is collected. Currently, the building heights are based on OpenStreetMap (some are estimated from floor count from the ground) and Data SF 2010 LiDAR. If the height is wrong or approximated, it may say Go for a flight that is over the legal limit.

I will cite which regulation applies for each route. That is a good idea I will add it.

One could go crazy trying to understand the inner workings that caused the reply to be flagged/dead. A user makes a Show HN, another user asks a direction question, the OP user makes a reply. How does that get flagged when it's a direct answer the question. Maddening. So yeah, I vouched

What math error with the building's height? Assuming it's what you quoted, 164 ft converts to 49.9872 m so "50 m" seems excellent as the value to present?

I'm assuming that the application first compares building heights to the nominal 400-foot AGL altitude limit: 400-164 equals 236 feet of vertical airspace in which it's legal to fly even before you consider the structure exemption that would permit 564 foot AGL within a 400-foot radius of the building. Calling it a math error was a bit of a misnomer on my part.

I'm still not quite sure what calculation would have a marked location like that as a "no-go," and re-reading the error messages doesn't really clarify the logic. When it says "too tall to clear safely from there" I'm reading that as the building is too tall and thus you can't fly above it, but that's clearly wrong on two levels. Likewise, the building height + 400 feet was still well below the floors of the relevant Class B and Class C airspace shelves around SFO and OAK. Best guess is that the 80 foot exclusion zone around a building the program applies is probably to blame.

There are some other problems I noticed, but I'll send those to the OP via the feedback form on the site.

Oh you have to hit edit flight to get access to the button. Cool project. Bad UI.

Thank you for the feedback. I corrected it. I had built the project with desktop in mind and never checked how it looks on mobile ( my mistake). Now it asks for takeoff and landing points on the mobile screen by default. I would still suggest putting the pins on the map, since the address search uses OpenStreetMap's free service, which isn't very detailed or extensive.

I would like to work with you if possible, I made https://san-francisco.ca.us.codify.city

I would like to integrate this w/ the agentic state, my email is on profile, please LMK if we can chat.

- TY Arion

How do you keep the airspace data current? Temporary flight restrictions change daily, so I'm curious whether you pull them live from the FAA and how you handle short-notice ones like stadium events.

TFRs come from the FAA's own TFR site, tfr.faa.gov. I have set up a scheduled job to get it. It runs every 4-7 hours.

Planned TFRs like the fleet week are handled like this. Short notice TFRs are a weak spot if one lands after the last job. For commercial applications, the schedule would need checks at shorter intervals.

Stadiums are different. There is a standing FAA rule ( mentioned in the post). So each time a route crosses Oracle Park, a check is made to see if a game is present on that particular day and its starting time. Since we do not know when the match will end, we have made the assumption of 3.5 hours from the first pitch/start.

Reply on news.ycombinator.com