: Using Google My Maps as a Geospatial

-The need to ensure the long-term ability of power distribution systems to meet demands means that upgrades and alterations/expansions, as well as inspection and maintenance works, are constantly necessary. This paper presents an approach to use custom Google Maps as a ticket management system for scheduling and monitoring such works. A geospatial representation is rather useful in networks that are great in length and follow irregular routes (which is typically the case for power distribution networks). However, acquiring a representation of such networks, especially for the Low Voltage side, is an enormous task. This paper presents a cost-free and easy-to-implement approach that can be used in the absence of a full geospatial representation of the network. This approach utilizes an assign-to-the-feeding-transformer (for all Low Voltage issues) and assign-one-indicating-point (for each Middle Voltage issue) scheme, thus, requiring a minimum amount of data easily retrieved from the network. This approach provides a georeferenced ticket management system that can be employed for improved monitoring and scheduling through a user-friendly and free-to-use web-based application which use requires no additional costs or training. The presented approach has been applied in the area of Patras, Greece and initial results, showing a significant improvement in productivity, ranging from 10% to 42%, are further presented and discussed in this paper along with background information.


INTRODUCTION
Electrical networks and installations are generally divided in three main categories: production, transmission and distribution [1]. The distribution system (network) includes all Medium Voltage (MV) and Low Voltage (LV) equipment used to carry electricity to the final consumer whereas the transmission system includes all HV equipment used to carry HV between HV substations [1]. A Distribution System Operator (DSO) is an entity responsible for operating, maintaining and developing the power distribution system in a given area [2]. The number of DSOs within a specific country as well as their exact nature, their inner structure, the level of involvement of outside contractors and their general mode of operation varies from country to country [3][4][5][6]. In Greece, HEDNO [7] is currently the sole DSO for the whole distribution network throughout the country with over 7.5 million customers and a network length that exceeds 240.000 km (with the low voltage network holding a marginal majority of this sum) and over 163.000 installed medium/low voltage transformers [8]. To measure the reliability and quality of services provided by DSOs, two values are widely used: SAIFI and SAIDI. The System Average Interruption Frequency Index (SAIFI) is the average number of interruptions that a customer would experience within one year whereas the System Average Interruption Duration Index (SAIDI) is the average interruption duration within one year for each customer served [6]. In SAIFI and SAIDI terms, HEDNO scores rather low in comparison with other European DSOs [4] but well better than the median world value [9]. Although there is always room for improvement, it should be noted that comparing such values between different areas and countries may be misleading as local conditions vary (e.g. the weather, the landscape, the age of the network etc.).
Network expansions and upgrades as long as the initial network design have a significant impact on the performance of a network (and thus of its operator) [10][11]. The followed inspection and maintenance strategies are also key factors [12][13][14][15]. This paper presents and discusses an approach to improve ticket managing, and thus scheduling and monitoring of works, using geospatial data. The use of geospatial data has proven a rather useful tool in a variety of cases [16] including various applications in the power network industry [17][18][19][20][21][22]. However, the ticket-management aspect is often neglected. At the moment, HEDNO is running a major project aiming to incorporate GIS technology in the core of its functions, expected to be completed in late 2022 [23]. This paper presents an intermediate step undertaken meanwhile from the HEDNO's Network Engineering & Construction Section (NECS) of Patras Area, Greece in an effort to increase the section's productivity and to familiarize its personnel with the use of digitized and geospatial data. A major initial goal was that no additional cost (in terms of software, equipment, personnel or training) should be required at any time. The proposed approach does not require a detailed geospatial representation of the network either. Thus, it can easily be followed by other organizations under similar conditions.

A. Traditional Naming Scheme for Network Components
Traditionally, in the absence of GIS systems and of geospatial data, simple naming rules had to be employed in order for the personnel to be able to navigate and work on the network. For example, in this particular case, MV lines were named after the High Voltage Substation they are connected to, along with an arithmetic value. If a line splits, then each subsection was named adding a dash and another arithmetic value. MV poles are also numbered and thus a third dash and arithmetic value was added to the naming scheme. These data were maintained in numerous hard copy maps and sheets depicting the network in various zoom scales. Of course, the network changes over time (e.g. MV poles may be added or removed at any time), which creates similar issues with the ones mentioned in [20]. However, unlike what happens with transmission towers [20], pole numbering is not indicated on the actual poles in the field. Only key network components (e.g. MV/LV transformers) are equipped with indicating signs. MV/LV substations are traditionally named using local toponyms (city areas, village names or general location names), although not always accurately, followed by an arithmetic value. Substations were then used as starting points to pin-point other LV network components such as LV poles or spans, that do not bear a specific name tag. However, the traditional naming scheme for key network components such as MV/LV transformers is soon to be abandoned since jurisdiction areas are gradually merging and this means that components with the same name would ultimately be found in the same jurisdiction (as there are numerous places and villages with identical toponyms throughout Greece).

B. Area and Network Data
The case study area covers over 1,500 km 2 and includes more than 200,000 customers connected to over 3,000 MV/LV transformers. The area is depicted in Figure 1 (in red) and, in more detail, in Figure 2 with the MV lines shown in solid green color. It should be noted that MV lines are mostly overhead, with small parts (mostly within major cities) being underground. In comparison, larger parts of the LV network are underground, but again these are to be found mostly within major cities (mostly in the city of Patras). This means that the larger part of the network is subjected to open-air environmental stress and thus its inspection and maintenance is essential for the system's reliability.

C. Inspection and Ticketing
Standard procedure within HEDNO is for the area's Network Operation & Maintenance Section (NOMS) to perform yearly inspections of the network and note down all potential issues, including potential upgrade works, as judged by them on site. Issues that fall under the NECS's jurisdiction are forwarded in the form of hard-copy notes (tickets) for further consideration. These tickets are given a unique number for all future reference. Each ticket describes the issue and its location by using the traditional naming schemes previously described. The NECS is then expected to prioritize the received tickets and schedule on-site visits and consequent studies. Finally, the studies are handed to an outside contractor and the NECS is then responsible for inspecting and monitoring the contractor's works. It should be noted however that all HEDNO personnel is allowed (and expected) to report any potential issues they spot at any time (e.g. when working on other projects or even when not on duty). HEDNO also receive reports from citizens about potential issues. Needless to say that these reports do not use the internal naming scheme described earlier to provide location information.

D. Network Expansions and Alterations
The NECS has to study and perform network expansions and alterations that are requested by network customers and land owners. This is because according to Greek legislation (e.g. laws 1468/50, 1672/51, 2941/2001, 4001/2011), the DSO is allowed to install MV and LV installations in private and public properties. However, contrary to the legislation in effect for transmission installations [24], no expropriation or easement is applied on the properties. Thus, any land owner can receive a building permit without informing or consulting the DSO, regardless of the existence of MV and LV on the property. After acquiring the permit, the land owner notifies the DSO who is then required to alter the network in a fashion that would allow the safe construction (and continuing existence) of the building. Land owners can also quote a variety of reasons (e.g. works that do not require specific permits) to request network alterations. Connecting new customers to the grid may also demand extended works as there are no limitations regarding the distance/position etc. Finally, NECS receives guidelines from within the DSO regarding standard desired upgrades, strategic expansions etc. The result of the above is that there is a constant flow of requests to the NECS for network alterations and expansions.

E. Weaknesses and Effects on Scheduling 1) Trying to Cope with Hard Copy Tickets
As explained earlier, after receiving the tickets/notes, the NECS has to schedule on-site visits and network studies, if needed, as a follow up. During scheduling, one has to consider the distance and routes between different locations, the nature and importance of each issue, general guidelines, deadlines etc. In an attempt to achieve this, hard copy tickets and notes were kept in different stacks related to their priority status and their general location. The personnel would then have to go through the stacks in an attempt to formalize a schedule. As new requests were received almost daily, this meant that the time consuming, and prone to errors process of going through the hard-copy stacks also had to be repeated almost daily.

2) Multiple Tickets and Narrow Data View
A significant weakness in the scheme described above, is the inability to identify multiple tickets and/or requests on the same issue. HEDNO is currently equipped with different software to monitor the progress of studies and the finances/logistics of construction works but none of them can be used effectively for managing the prior stage (ticketmonitoring and assigning), i.e. they are not designed to keep track of tickets/requests that do not ultimately result to a study or construction work. The available software is also unfitting to provide a wider view of the data. Instead, they are more oriented towards a case by case approach, i.e. they are rather useful when the user searches for a specific information but tend to be rather time consuming and not user friendly when the user tries to acquire a wider view of the data. Simple queries can be submitted but the return time is significant and their functions are not easily (or at all) customized. A user often has to use multiple software, perform multiple queries, go through several entries and move between multiple screens to actually get the needed information.

3) Naming Scheme Issues
The naming approach for MV/LV transformers described in previous sections, suffers from the fact that toponyms may provide a rough idea of the approximate location of a given group and its proximity to other groups but not of the proximity of specific group members to others. This means that e.g. two transformers belonging in the same group may actually have a greater distance between them compared to the distance each of them has with neighboring substations belonging to different groups. The issue worsens if one considers that the overall shape of a group following a toponym is bound to be irregular. This means that even though e.g. group A may be closer to group B in general, and this can be understood by the respected toponyms, a specific transformer belonging to group A may actually be closer to a transformer from another group instead. A simple example is depicted in Figure 3. A simple example of the traditional naming convention scheme. The image shows six different groups (A-E) of MV/LV transformers, with each group using the same toponym for all transformers in the group. Group A is adjacent to groups B, C, E and F. However, the far right transformer of Group A is closer to a transformer of Group D than to any of the transformers in Groups B, F and E. Further, certain transformers within all groups are closer to transformers of adjacent groups than to transhormers in their own group. (screenshot from Google Earth, map data: Google Earth)

4) Other Issues
Other obvious issues caused by the lack of geospatial representation is not considering the actual routes between different points (a minor issue for distribution networks however compared to transmission systems [20]), having a lengthier learning curve for new personnel and being unable to easily correlate outside reports (e.g. when they use street addresses) with specific network works and components.

III. UTLIZING THE AVAILABLE GEOSPATIAL DATA
During a process similar to the one described in [20], geospatial data (i.e. coordinates) for all MV/LV transformers as well as the route of MV lines had been acquired previously. These data could then be utilized to provide a geospatial representation of all tickets, studies and works that should improve overall scheduling and, thus, productivity. However, a key goal that was set was that no additional cost (in terms of software, equipment, personnel and even additional training) should be required at any time. An approach similar to [20] was judged unsuitable due to the nature of the application and of the available data. Free to use software such as Google Earth, Maps.me and MantisBT previously used by the author in transmission applications [20,25] were also found unsuitable.
A ticketing system without a geospatial representation, such as MantisBT, could solve the multiple-ticketing issue but would do little to improve scheduling whereas geospatial representation software that had to function locally, such as Google Earth, was also found to be unsuitable as several different employees needed to have access to the information. Thus, it was decided to use custom Google Maps (Google My Maps) [26] instead and try to work within its restrictions.

A. Restrictions and Solutions
Google My Maps enforces certain limitations to custom maps created by users. These are related to the number of layers, the number of Points-Of-Interest (POIs) per layer and per map, the size of imported files etc. Also, unlike Google Earth, Google My Maps does not provide a pop-up function when two POIs superimpose one on top of the other. Regarding the discussed case study, the routes of MV lines had to be redrawn and different line sections or parts had to be united (e.g. at the bus of the High Voltage substation or before and after a MV component) in order to follow the restrictions (Figure 4). It should be noted however that the actual route of MV lines is not necessary for the system's function and it is only added as a visual aid. The spreadsheet with all MV/LV transformers and their coordinates also had to be split into smaller spreadsheets to comply with Google My Maps restrictions.

B. POIs, Custom Icons and Representation
For the MV network, it was decided that one POI would be created for each ticket, even if the ticket referred to a line section (in such a case, the POI would be inserted in the approximate middle of the section). For the LV network, each ticket is assigned to the POI depicting the MV/LV transformer that feeds the corresponding circuit (one POI for all tickets fed by the same transformer). It was decided to import POIs for all transformers in the map, even for the ones with no active tickets. This way, map editing would be easily conducted within Google Maps, the maps would present a better view of the network and they could also be used for navigation purposes. Custom made icons were developed for the POIs with different icons representing different types of issues and with different colors representing a different status and/or prioritization. Examples of custom made icons and of map parts are depicted in Table I

C. Additional POIs
In general, additional icons can be created and used to depict different types of tickets, depending on the application. For example, in this case, tickets related to street addresses (and not feeding transformers) such as tickets related to the urban underground network and tickets reported by people outside the DSO are depicted with different icons. To avoid overpopulating the map, such POIs can be deleted when

A. Split into Two Maps
It was decided to construct two custom made maps: one for onsite visits/studies (the so-called "studies map") and one for construction (the so-called "constructions map"). This was done to comply with the internal structure of the NECS and the overall organization scheme but also in order to avoid internal confusion and to avoid showing redundant data to employees (as different employees work in the respected subsections).

B. Create New POIs, Edit Existing POIs, Monitor Past Tickets
In order for POIs to have the desired number of metadata categories, they were created by importing spreadsheets to the custom maps. New POIs however can then be created from within Google My Maps and inherit the structure of a given group. Each POI in a certain group was equipped with several metadata fields (description, comments, alphanumeric codes, styling etc). Using the styling option, a user can link the appearance of a POI with a certain metadata field and just edit this field to alter the way the POI appears ( Figure 6). By editing a POI's metadata, the user can also move a ticket's description/number from an active field to an inactive one. It should be noted that the built-in search function considers all text within all fields. Thus, the maps retain a list of past works/tickets, with all data being easily searchable and retrievable. This feature is then used to identify redundant or overlapping tickets.

C. Removing Duplicates
The first group of tickets to be inserted into the studies map was consisted of 489 tickets. 327 tickets out of the 489 were part of the 2021 yearly inspection whereas the remaining 162 were low-priority tickets left over from previous years (17 tickets from 2018, 79 tickets from 2019 and 67 tickets 2020). A total of 33 tickets were removed as duplicates. 14 of these, were tickets that were identical with other tickets from the same yearly inspection whereas 19 were identical with tickets from previous years. An additional 13 were tickets referring to issues that had been solved since (studied or declined) without reaching the construction stage. An additional 4 tickets were found to be identical with works in the construction stage (and map). Thus, through the process of entering the data in the two maps, the number of tickets was reduced from 489 to 439.

D. Scheduling
For scheduling, one has to consider the priority status, the location, the available routes, the proximity with other tickets and customer requests, the weather in each area etc. The user can see the geospatial representation of issues and click on POIs ( Figure 6) to acquire more information in order to construct an optimal working schedule. Figure 7 shows a part of the map in an urban location (an area with a significantly larger network and issue density compared to Figure 5). An important additional function is that tthe search function can be employed to identify all the POIs that fall under the same MV line (or subsection) as shown in Figure 8. This way the user can also consider electrical connections when scheduling works (e.g. a construction work at a certain section of a MV line can be combined with works at the LV circuits of MV/LV transformers that are fed by this MV line section). This also means that depicting the actual lines is of no particular importance for this system's functionality (provided that the correct and full data for each POI are used).

V. RESULTS
Assessing (and documenting) the effect in productivity is not an easy task as there are a number of outside factors that may have an impact on the final results. The main question regarding this case study, is if the proposed scheme will help the NECS cope with yearly inspection tickets faster (before the next yearly inspection and ideally within 6 months) while not causing any delays to any of its other works. So, one has to consider not only the trend regarding the inspection tickets but also the overall numbers. These should be considered not only in terms of their absolute value but also in terms of their total cost (as some tickets may require far more work than others) in order to acquire a correct view of the effect of the proposed approach.

A. Inspection Tickets
The first results regarding inspection tickets show a rather significant improvement as depicted in Figure 9. A week after the application, a new group of 58 tickets (corresponding to a certain MV line section that had just been inspected) were submitted to the NECS increasing the total number of initial tickets to 497. Considering the studies map, the actual initial number of active POIs was 473 (24 of the 497 tickets were assigned to the same MV/LV transformers). This number fell to 371 after a month (a reduction of 102 active POIs per month). This means that, with this rate, the number of active POIs (and thus inspection tickets), should be expected to fall to zero within 5 months since the application of the custom maps (and within 3 months for each following year, as this group of tickets included 163 tickets from previous years). Fig. 9.
A summary of the results regarding inspection tickets and POIs.

B. Number of Studies and Respective Costs
The number of studies and their total cost also increased significantly in the first month of the application of the proposed scheme. The average number of cases studied per month for the previous 36 months were 82 with an average total predicted cost per month of 376 thousand euros. The first month after the application of the proposed scheme, these numbers increased to 108 cases studied with a total cost of 414 thousand euros, an increase of 31.71% and 10.11% respectively. In terms of construction, the average number of constructed studies for the past 36 months was 74 and the average total final cost per month was 133 thousand euros. These numbers also increased the first month of the application of the proposed scheme to a total of 96 constructed studies with a total cost of 190 thousand euros, an increase of 29.73% and 42.86% respectively. It should be stated that the constructed studies of each month are not necessarily the same studies studied within this month or even the month before. Apart from this, the gap between the predicted costs and the actual final costs should be largely attributed to the bidding procedure followed in Greece (the cost of public works is generally calculated using standard prices whereas outside contractors bid by proposing discount rates on the standard prices and the works are assigned to the bidder offering the largest discount). A summary of the results is shown in Table II.

VI. DISCUSSION
The initial results presented in the previous section show a significant improvement in all fronts. However, there are several limitations regarding this approach that should be stated. First of all, there is no easy way to extract the POIs and edit their structure (e.g. to a spreadsheet), as only kmz and kml exportation is supported. This means that to add an extra category in the metadata of POIs or to change the name of a metadata category, one has to actually work with the exported kml/kmz files, which requires specialized software and/or knowledge. Performing any type of statistical or meta-analysis is also an issue. Backing up is also not user-friendly as the user can either extract the data in kml/kmz files or save a copy of the entire map. Neither option is suitable to monitor the progress of works in the long term. Saving copies of the maps does not allow easy comparisons between them. Reimporting a previously exported kml/kmz file as a new layer to an existing map could solve this but the limit to the number of layers per map and the limit to the size of kml/kmz files to be imported, means that the user would eventually have to extract and reimport one kml/kmz file per layer, which is rather time consuming and would result to a vast number of locally kept files. Another significant disadvantage is that Google My Maps is a rather unforgiving application with limited "undo" capabilities, which means that a human error is not easily spotted or fixed. Finally, it should be noted that although the custom maps are easily viewed by multiple users, a refresh of the web page is needed to acquire the latest edition of the map. So, a no-simultaneous editing policy is required to avoid overlapping between different users.
On the other hand, if the map developer maintains a strategy that considers all limitations (both of the software and of a specific case study), it is possible to produce a scheme with significantly more pros than cons. Google My Maps is currently a free application that is designed for the ordinary user, which means that no extra software, staff or specialized training of any kind is required to develop or maintain the maps. Also, following the proposed approach, map editing is rather fast and requires minimum effort and time in terms of everyday work. It should be noted that although geospatial representations have been incorporated in various applications, the proposed approach differs in that it provides a geospatial ticket-managing approach which is cost-free, easy to implement/maintain, and does not require a detailed geospatial representation of the network. Thus, it can be implemented in a variety of cases with similar characteristics, especially in the absence of a more sophisticated GIS system or in case the installed GIS system does not offer a ticket-management capability (which is often the case with specialized GIS software).

VII. CONCLUSION
This paper presents the approach followed by the Patras Area's Distribution Network Engineering & Construction Section in an attempt to acquire a free and user-friendly geospatial representation of works related to the power distribution network of the area. The presented scheme uses Google My Maps effectively as a geospatial ticket management system to monitor and schedule works. Given the rather userfriendly nature of Google Maps, this scheme requires no additional training to develop or maintain. Gathering the data also requires a minimum effort, as LV issues are assigned to the transformer that feeds the corresponding circuits and a single indication point is used for each MV issue. The bulk of points (i.e. the LV/MV transformers) are imported from available spreadsheets that are customized to suit the needs of the users. Custom icons are used to depict POIs of different categories and different colors to depict their condition or priority. Adding new points and editing existing ones is easily conducted within Google My Maps. The main initial goal for this approach was to improve the speed with which the Section coped with issues recorded during network inspections. Initial results showed a significant improvement to this but at the same time also showed a significant increase in overall productivity, ranging from 10% to 42% depending on the aspect considered each time. This approach can easily be implemented by other utilities in the absence of a GIS system and of detailed geospatial data of the network, as it is rather easy to implement and maintain, requires no additional cost at any level and offers a significant improvement to traditional hard copy based approaches or to ticket management systems that do not incorporate a geospatial representation.