City gui plugin

[amorfinv]

These are some ideas for a gui plugin for cities.

import raw/altered osmnx street networks

osmnx recommends that creating a new environment using conda-forge. To integrate with bluesky, I think we would need to install all the dependencies that osmnx needs. Or maybe get bluesky dependencies inside the osmnx environment.

It should also be possible to import processed graphs. Sometimes we want to change somethings from the original graph (like directionality). Maybe this means that the default option imports an undirected graph.

visualizing street networks

Once street network has been imported there should be several functionalities for visualizing. Most important would be to be able to see which streets were imported. Map tiles should already show the street configuration. However, it would be nice to show which streets are actually in the imported street networks. It would also be nice to see the directionality of the streets (if any).

It will also be good to see a certain path highlighted in the gui. So if the user gives a starting location and end location, the gui would highlight the path in the street netowork

import osmnx building data

It should not be too hard to import building polygons. @andubadea has already done it. However, the data is perhaps too detailed. If we want to simplify, I think there are three approaches:

1. Use QGIS to simplify. They already have a bunch of functionality to simplify geometries. However, the tricky part here would be to find an easy way to link QGIS with bluesky. Maybe this is something we can ask the 3d group.
2. Try and find the relevant functions in QGIS code and use them for bluesky. Unsure if this would be a good idea.
3. Create a new function that uses the osmnx street block to perform this simplification. I think this would be a bit trickier but has the benefit of working without QGIS.

Anther things to consider about building data from OSM is that some information is not so reliable. For example, building height and land-use information may not always be accurate. I have already seen this in Vienna. Perhaps this information will only be available in some places.

generate building heights
Since OSM does not always give building height information, it could good to artificially generate this information. Maybe a random generation or based on some other distribution.

calculate and visualize street widths
This should be possible by using the building and/or road data. Perhaps for each road we can calculate the distances between its nearest buildings. I am quite sure this is possible with QGIS.

do all of the above with non-osm data
Sometimes there is better data available than OSM, say a CityJSON file. So perhaps it should also be possible to do all of the above for non-osm data. Since CityJSON may be it's own plugin, this city plugin can maybe just work with geodataframes for now. So as long as the user converts the data to a gdf, it should be possible to use with bluesky.

This is all I can think of at the moment. Feel free to add anything else.

-Andres

[amorfinv]

I think the main city gui functionalities needed for M2 are:

1. import raw osm street networks
2. import custom osm street networks
3. visualize a path following streets
4. import building polygons with heights
5. splined waypoints or something to reduce number of waypoints when aircraft follows a curved street
6. A city scenario editor in which you can work with 1-5

There are also some that are not as urgent:

7. visualize selected street-network. Map tiles should be fine for now. But in the future perhaps the streets in the imported network could be highlighted.
8. import and process osm building polygons. I think perhaps geopandas or shapely could be used to simplify building polygons. main idea is to combine all buildings in a block into one polygon. Vienna data has already been simplified with QGIS.
9. visualize building polygons. For now it should be enough to see the map tiles. But since we would be performing some simplification it will be nice to see the result.

[andubadea]

We should also have dynamic geofences in there for loitering missions.

A loitering dynamic geofence (polygon) would have two attributes: ACID (the aircraft that requested it) and ActiveTime. When the aircraft is a certain distance away from its location, it activates (thus, aircraft have time to get out of the geofenced area). Then, the arrival time inside the geofence of the loitering mission drone is recorded, and the drone is deleted.

When Simulation Time - Arrival Time > Active Time, then the geofence is deactivated (deleted), and the drone appears again with its destination being its previous origin.