If you are a company looking for newly minted data scientists, become a partner.For the interested, all of the code for this project is posted on Github at: github.com/keithfma/parasol.TL;DRParasol uses high-resolution elevation data to simulate sunshine and constructs routes that keep users in the sun or shade, whichever they prefer..Then, I computed a cost function that incorporates sun/shade as well as distance for each segment of the transportation network..Later sections provide some insight into how I designed and implemented each part of the system.Parasol system overview, showing the input data used to build minimum cost routes that incorporate distance and user sun/shade preference.The input data I used:NOAA LiDAR elevationOpenStreetMap via Overpass APIUser-supplied route endpoints and sun/shade preferenceThe main tools I used:Python with all the usual data science packagesPoint Data Abstraction Library (PDAL)PostgreSQL with PostGIS, pgpointcloud, and pgRouting extentionsGRASS GIS (r.sun for solar simulation)Flask, Leaflet, Geoserver, Apache (for the web app)Gridded Elevation from LiDARTo run a decent shade model, I needed a decent elevation model..There are a few well-established methods for doing so, but it turns out the LiDAR data I used were pre-classified by NOAA..If interested, you can find the code for my nearest-neighbor median filter here — it is quite simple!Example of the input LiDAR point cloud, and the computed upper and lower surface grids (1 meter resolution).Simulating SunshineTo simulate sun and shade, I use the GRASS GIS module r.sun to compute insolation on the upper surface grid for a given date and time..Comparisons like this served as a qualitative “smell test” to make sure the solar simulation worked acceptably well.To account for shade cast by trees, I set the insolation at all pixels where the upper surface is higher than the lower surface (i.e., where the user will be walking below some object) and set it to the minimum observed insolation in the scene..The key requirements for the cost function were:Incorporate both insolation and distanceAllow for routes that prefer sun and well as routes that prefer shadeHave a minimal number of free parameters (ideally one) so that it is easy for users to indicate their preferenceBe non-negativeIt turns out I was able to write the cost as a simple weighted average of a “sun cost” and a “shade cost”:cost = β⋅sun_cost + (1−β)⋅shade_costThe weighting parameter (β) reflects a user’s preference for sun or shade..It ranges from 0 (total preference for shade) to 1 (total preference for sun).The “sun cost” term is the path integral of the insolation along each segment of the OpenStreetMaps transportation network..This is related to the amount of sun avoided by the shade cast on each segment..A single-parameter cost function that allows users to choose sunny or shady routes and still cares about distance.Routing with a Sun/Shade CostThe heavy lifting for computing the route is handled by the wonderful PostgreSQL extension, pgRouting..This extension computes least-cost routes using a variety of algorithms (I used Dijkstra) and allows the user to specify the cost as a function of the columns in an OpenStreetMap database..All I had to do was to store the computed sun and shade cost for each segment of the transport network in my database, choose the right column to use based on the time of day, and apply my simple cost equation.Web AppI won’t go into the details, but I set up the web app using Python and Flask to host an API with endpoints for generating routes, etc., used Leaflet with a few wonderful extensions to build an interactive map, and hosted the sun/shade simulation images using Geoserver.Next StepsMy biggest hope for Parasol is that the idea catches some traction and gets picked up and integrated into one (or more!) of the many wonderful navigation apps out there in the wild..It is definitely possible to identify trees from the LiDAR data, and the shade cast by these trees could be adjusted based on the season.. More details