7. EV Infrastructure Designer (evides)¶

The EV Infrastructure Designer is the user-interface (UI) for inputting the location, type, count etc. details about the prospective charging stations. The video shows a demonstrative use of evides.

7.1. Live Demo¶

Click here to access the live demo of EVI Designer.

7.2. UI Details¶

After logging in by providing email-id and password, the user is greeted with Fig. 7.1.

Fig. 7.1 EV Infrastructure Designer

The key elements of the EV Infrastructure Designer are as under:

7.2.1. Washington State DCFC Network¶

The “Washington State DCFC Network” card shows the WSDOT road network overlayed with the infeasibility metric for CHAdeMO and COMBO charging alongwith the as-built EV DCFC infrastructure - selectable from the radio buttons on the upper right corner as in Fig. 7.2 . Besides the infeasibility overlay, the radio buttons also show the relevant type of charging stations on the road network. These locations are consistent with the database table built_evse.

Fig. 7.2 Washington State DCFC Network with overlay

7.2.1.1. Trip Infeasibility¶

7.2.1.1.1. Concept¶

The infeasibility metric is an indication of sparsity of EV infrastrastructure on a path. A count is calculated for the total vehicle trips passing over a road segment belonging to a shortest path between an OD pair if the spacing between charging stations on the segment is greater than 70 miles (critical limit specified by WSDOT). The line weight of the overlay is directly proportional to the trip count passing over a segment. So, a thick overlay can mean that a high count of vehicles are passing over the segment. The low line weight indicates light traffic on the segment. The former indicates that the road segment is used by several OD pairs in the state, whereas the later indicates the vice-versa. No line weight on the roads mean that the charging station spacing on the segment is less than 70 miles. There are separate overlays for CHAdeMO and COMBO charging stations as not all charging stations feature both types of plugs.

7.2.1.1.2. Algorithm¶

The script for calculating the trip infeasibility is here. The basic algorithm is as follows:

For each zip code combination in the state, find the shortest path on the WA road network. This utilizes the SQL function sp_od2() shown here.
Then all the charging stations within 10 miles of the shortest path are found using PostGIS function ST_DWithin().
Ratios are found between 0 and 1, where the point closest to these charging stations lie on the shortest path using PostGIS function ST_LineLocatePoint(). This means the origin has ratio 0.0 and destination has ratio 1.0, and charging stations along the route have ratios between 0 and 1 depending on whether they are near origin or destination respectively.
After sorting the ratios, the successive differences in ratios are found using SQL function lag().
Multiplying the lags with the length of the shortest path, gets us (on-route) spacings between successive charging stations.
We then filter out, all the ratios for which the spacings are less than 70 miles, since that is the critical distance between charging stations. Spacings greater than 70 miles represent the infeasible sections of the shortest path.
Then we find the geometry for these spacings, using PostGIS function ST_LineSubString() using the shortest path as the line, and (ratio - lag), ratio as the start and end fraction for the substring respectively. 0 and 1 are added to ensure that we get the first and last segment as well.
All these geometries, that are longer than 70 miles in length, are inserted in the trip_infeasibility table in the database. If the geometry already exists, then the corresponding trip_count is added to the new trip_count. To figure whether geometry already exists in the database, a unique index is added on the md5() encoded value of geometry, as per the recommendation here. This can be upgraded to SHA512 for a better uniqueness guarantee.
This process is repeated for all the OD pairs in our dataset and for both COMBO and CHAdeMO plug-type.
It currently takes around 12 hours for this algorithm to calculate trip infeasibility with over 300k+ OD pairs.

7.2.1.1.3. Plotting¶

The above algorithm resulted in a geometry table with 6000+ rows and size 700 MB+. While this data is not too much for the database, it is pretty large to load on a web-page in a reasonable amount of time. Therefore, the vector dataset was converted to vector tilesets, a MapBox open specification. The following methodology was used to generate a fast loading map showing this data:

The geometry table(s) was used to generate the dataset in the GeoJSON format, using a GDAL utility ogr2ogr, like so :

ogr2ogr -f GeoJSON <name_output_file.json> "PG:host=<db_host> dbname=<db_name> user=<db_user> password=<db_password>"  -sql "select trip_count, geom from trip_infeasibility"

The resulting GeoJSON file, still around 800MB is too big for Mapbox dataset limit. Therefore, Mapbox utility tippecanoe is used to convert the GeoJSON dataset to Mapbox tileset, like so:

tippecanoe -o <output_filename.mbtiles> <input_geojson_file.json>

The resulting tileset is significantly small (~12 MB) and can be uploaded to the Mapbox tileset repository with ease using the mapbox studio tilesets page.
This tileset is then used to create a custom style. To create a custom style, start with a blank style, and add the uploaded tileset as layer and change the line width of the resulting line “Style across data range”, data being trip_count. A line width of 0 is chosen when trip_count is 0 and line with of 10px is chosen for the maximum value of trip_count and default linear transition in between.
The above method is used to generate trip infeasibility overlays for both COMBO and CHAdeMO plug types. The styles are transparent and therefore need to be overlaid on other tiles for context.

7.2.1.1.4. Trip Infeasibility - CHAdeMO¶

The trip infeasibility for the CHAdeMO network can be seen in Fig. 7.3.

Fig. 7.3 Trip Infeasibility for CHAdeMO Network

7.2.1.1.5. Trip Infeasibility - COMBO¶

The trip infeasibility for the COMBO network can be seen in Fig. 7.4.

Fig. 7.4 Trip Infeasibility for COMBO Network

7.2.1.2. Buffer¶

The checkbox called “Buffer” toggles the display of a buffer around the road network. This buffer spans a length of 10 miles around the roads, and represent the feasible area for the location of prospective charging stations. The length of 10 miles is an indicator of the willing of an EV driver to divert from the road to charge.

Fig. 7.2 shows a selected charger location with a marker. The UI will only allow charger placement in the buffer region around the roads and the successful click results in a marker as shown. As many charging station locations can be picked as desired.

7.2.2. Parameters¶

It is now also possible to set the simulation parameters from the EVIDES UI from the “Parameters” tab by adjusting the sliders as can be seen from Fig. 7.5.

Fig. 7.5 Parameters Tab

7.2.3. New Site List¶

The New Site List card lists all the chosen sites with options to configure or cancel the selection as shown in Fig. 7.6.

Fig. 7.6 New Site List

For all the selected locations, configuration can be done as shown in Fig. 7.7.

Fig. 7.7 Station Configuration

The station configuration modal allows the setting of number of plugs for DCFC and Level-2 as well as the corresponding power per plug and pricing structure. Total price can include charging price and parking price. For both parking and charging, there could be a fixed component (per session) and variable (per minute) component.

Once satisfactory counts of charging stations with appropriate configuration have been selected, the selection can be submitted for analysis by clicking the “Submit for analysis” button. This will insert a record in the database table analysis_record, which will trigger an analysis request to the simulation manager. A successful analysis submission will also insert rows in the table new_evses for the respective analysis_id. As many rows as the number of charging sites selected will be entered with the columns like plug count, power, price etc. as per the individual configuration.

Note

The user can bring down the count of plugs all the way to zero. When DCFC plug count is set to zero for all new charging stations, the analysis is equivalent to the as-built scenario. This, therefore, is the way to get to the base-case analysis and the new charging station deployment scenarios can be compared against the base-case.

The New Site List card then displays a successful analysis submission message with the submission date time as shown in Fig. 7.8. Since the analysis process involving re-calculation of destination chargers, charging distances, EV trips and subsequent agent-based simulation is a computationally-intensive long process, taking several hours at the time of this writing, the user is informed about the successful completion of analysis via an email at the registered email address. The results can then be viewed for the particular simulation date time of interest.

Fig. 7.8 Analysis Submission View

7.3. Implementation Details¶

The EV Infrastructure Designer is a web-app with an R Shiny backend. The code is hosted in the Github repo - ev_infrastructure_designer.

7.3.1. User Identity¶

Auth0 is used for user-identity management. It allows for authentication across devices and browsers using custom email/password as well as several external authentication services like Google, Github etc. allowing of easy sign-on. The integration of Auth0 with the R Shiny app was facilitated by the R package auth0 that implements the Auth0 API in R.