BACKGROUND Many assets, such as utility lines (e.g., power, gas, water, sewage, communication, military/security, etc.) and other infrastructure assets owned by both government and private enterprises, are buried underground. When excavating (e.g., digging, grading, demolishing, cultivating, augering, blasting, boring, and the like), excavation equipment and underground assets that the excavator may not know were present can be damaged. Such damage may cause a disruption of service to customers, expensive repairs, and costly litigation, all of which can additionally lead to loss of reputation for the excavator. In extreme cases, such accidents may even lead to injury or death. Before excavating, in some areas an excavator may submit a dig ticket to a call center requesting clearance to excavate at a specific location. Indeed, in many regions, excavators are required by law to submit dig tickets and receive approval before excavating. The call center receiving the dig tickets is generally in communication with various asset owners and must contact the asset owners to determine if there are underground assets at each excavation location. If there are no underground assets within a determined proximity of each excavation location, the dig ticket may simply be approved, thereby allowing the excavator to excavate at the excavation location. However, if there are underground assets proximate (e.g., within a determined buffer zone) of the excavation location, a locator may need to travel to the excavation location and mark the location of the underground assets to allow the excavator to avoid excavating within a buffer zone of any underground asset. Generally, implementations employ one of two variants of this system. In the first variant, the call centers employ Geographic Information System ("GIS") systems that include land based data (e.g., map information) and underground asset data mapped to each other. Each call center generally employs an independent GIS system. However, underground asset data is often not up to date even though each call center may frequently check with the several underground asset owners (e.g., utilities and government offices) for record maintenance. Additionally, land based data in GIS systems may be out of date if not constantly updated. Thus, even though a call center may try to keep their GIS system current, conventional GIS systems may fail to reflect recent changes in either land based data or underground assets data, leading to excavators damaging underground assets. In the second variant, a GIS system may be individually maintained by each asset owner (utilities, etc.) and a call center may only dispatch the excavation request to these asset overs who in turn will determine if the excavation affects their assets. Thus, in the second variant, the call center only acts as a conduit between the excavator and asset owners. Further, in much of the world, addressing of parcels of land is inconsistent or nonexistent and many excavators may not have access to sophisticated sensing equipment such as Global Positioning System ("GPS") sensors. This often makes it difficult for a call center to locate an excavation location indicated on a dig ticket even on their GIS system. Even if the excavation location can be found on the GIS system, it may be difficult for a locator to travel to the excavation location to manually expect the excavation location or to mark the location of underground assets. BRIEF DESCRIPTION OF THE DRAWINGS FIG. 1 shows a functional block diagram of an exemplary system including a central Underground Asset Management System operatively coupled to one or more excavators, one or more locators, one or more underground asset owners, and one or more regulatory agencies. FIG. 2 shows an exemplary computer architecture configured to use online services to centrally maintain land based and underground asset data for distribution to one or more computing devices over a network. FIG. 3 shows an exemplary process that may be performed by an Underground Asset Management System. FIGs. 4A-4E show screenshots of an exemplary user interface for a device accessing an Underground Asset Management System. FIG. 5 shows an exemplary computing device useful for implementing systems and performing methods disclosed herein. While systems and methods are described herein by way of example and embodiments, those skilled in the art recognize that systems and methods for managing underground assets are not limited to the embodiments or drawings described. It should be understood that the drawings and description are not intended to be limiting to the particular form disclosed. Rather, the intention is to cover all modifications, equivalents and alternatives falling within the spirit and scope of the appended claims. Any headings used herein are for organizational purposes only and are not meant to limit the scope of the description or the claims. As used herein, the word "may" is used in a permissive sense (i.e., meaning having the potential to), rather than the mandatory sense (i.e., meaning must). Similarly, the words "include", "including", and "includes" mean including, but not limited to. DETAILED DESCRIPTION Disclosed embodiments provide computer-implemented methods and systems for managing underground assets. These methods and systems may improve accuracy, correctness, and vintage of map, address, and asset location data. By reducing the number of dig tickets which require a locator to travel to the excavation location, the majority of the tickets can be resolved automatically without requiring a field visit, which may reduce the overall cost of ownership and maintenance of these systems. FIG. 1 shows a functional block diagram of system 100 including a central Underground Asset Management System ("UAMS") 101 operatively coupled to one or more excavators 102, one or more locators 104, one or more underground asset owners 103, one or more regulatory agencies 105, and one or more land based data sources 106. Of course, in embodiments, UAMS 101 may be operatively coupled to greater or fewer entities. For example, in countries where there are no regulations relating to excavation, UAMS 101 may not be operatively coupled to any regulatory agencies 105. UAMS 101 may receive asset location information from one or more asset owners 103. The asset location information may include geographic location coordinates of the asset (e.g., latitude and longitude of one or more points on the asset), geometric reference of line assets (like telecom lines, power lines, gas pipes, etc), burial depth (e.g., depth below the ground level or altitude in relation to mean sea level), type of asset (e.g., gas line, telecommunication cable, septic tank, etc.), area to be buffered surrounding the asset, and the like. UAMS 101 may then map the underground assets to current land based data. UAMS 101 may maintain current asset location information by periodically (e.g., hourly, daily, weekly, etc.) sending a request to asset owners 103 requesting updates of asset location information that has changed. For example, each one of asset owners 103 may provide an Application Programming Interface ("API") to allow UAMS 101 to directly request updated asset location information. Of course, data may be transmitted via interfaces other than APIs. Alternatively, each one of asset owners 103 may automatically send updates to asset location information as the asset location information changes. Asset owners 103 may be motivated to keep all asset location information stored by UAMS 101 current to ensure that newly buried asserts are not damaged by excavation. UAMS 101 may also maintain current land based information. UAMS 101 may periodically receive current land based data from one or more land based data sources 106, such as ESRI^**, GOOGLE™, NASA™, and others. UAMS 101 may, for example, store land based data in a central database and update the land based data as one or more providers of land based data update their data. UAMS 101 may further be configured to determine the most accurate land based data provided by various sources. For example, if land based data from plural sources are inconsistent, UAMS 101 may include a set of rules to determine the accuracy of the various sources. A set of rules may include, for example, a consistency check based on metadata provided by data provider. Through custom built algorithms, UAMS 101 may check data formats, coordinate systems, coordinate numbers of features and feature classes, and the like in addition to visual checking (e.g., edge matching) on different data sources. For example, if land based data from three sources are consistent with each other and a fourth source is anomalous, UAMS 101 may determine that only the consistent land based data should be used. Alternatively, if land based data from one data source has been updated more recently than others, the most recently updated land based data should be used. Of course, other rules may also be applied. UAMS 101 may also be configured to alert a user of potential inconsistencies between data sources so that the user can confirm the correct data. Alternatively, rather than maintaining current land based information UAMS 101 may be configured to request land based information for an area from land based sources 106 and for assets from asset owners 103 in response to receipt of a dig ticket. Such embodiments may require UAMS 101 to store less data, but may require additional processing in response to receipt of a dig request. UAMS 101 may map the underground assets to the land based data. Because both the underground asset locations and the land based data may be maintained up-to-date, UAMS 101 may always maintain an up-to-date mapping of the underground assets to the land based data. UAMS 101 may receive a dig request from an excavator 102 specifying an excavation location at which the excavator would like to excavate. An excavator 102 may provide an excavation location in various ways, as described in detail below. UAMS 101 may determine if there are any underground assets within a determined proximate distance of the excavation location. If no underground assets are found to be proximate the excavation location, UAMS 101 may confirm to the excavator that there are no underground assets proximate the excavation location. Alternatively, if there are underground assets proximate the excavation location, UAMS 101 may automatically generate a locate ticket for a locator 104 to travel to the excavation location to manually determine if there are underground assets and/or to mark the location of underground assets. A locator 104 may provide information back to UAMS 101 relating to the excavation location, for example if a locator 104 uses a sensor to confirm the location of an asset and also finds an additional asset that UAMS 101 was not aware of, for example due to delays in updating data, due to unauthorized burying, or due to classified governmental activities, a locator 104 may provide location information to UAMS 101 about the additional asset and UAMS 101 may add the additional assets to their mapped land based and underground asset data. UAMS 101 may additionally be operatively coupled to one or more regulatory agencies 105. For example, regulatory agencies 105 may restrict excavation in some regions or may be required to preauthorize excavation. Thus, UAMS 101 may request permission to excavate in the excavation location indicated in a dig ticket before granting the dig ticket. Alternatively, UAMS 101 may provide periodic information to a regulatory agency 105 for record keeping purposes. Thus, system 100 provides a single centralized UAMS 101. Beneficially, asset owners may rely on the centralized UAMS 101 by simply transmitting their updated asset data rather than having to maintain their own costly independent systems. Additionally, system 100 may be much less expensive to maintain in general because economy of scale distributes the cost of a singe centralized UAMS 101 unlike several individual call in centers. FIG. 2 shows an exemplary computer architecture configured to use online services to centrally maintain land based and underground asset data for distribution to one or more computing devices over a network. For example, a web server 201 may be configured to provide an interface to UAMS 101 (shown in FIG. 1) via a network 210, such as the internet, a wide-area-network ("WAN"), a local-area-network ("LAN"), a wireless data network, or any other network. Client devices (e.g., devices used by asset ovraers, excavators, locators, regulatory agencies, and the like) may be used to place dig tickets, receive or respond to locate tickets, access the land based and underground asset data, and the like. A client device may be, for example, a computer 121, a laptop 122, a tablet 123 (e.g., an IPAD'^'^), a smartphone 124 (e.g., an IPHONETM, a BLACKBERRYTM, or an ANDROID™ based phone), or any other computing device. Web server 201 may provide the underground asset data through an application executed on the web server 201 and accessed by a client device (e.g.. Software as a Service ("SaaS")), may provide a website interface to allow a client to view and interact with land based and underground asset data through a web browser, may provide an Application Programming Interface ("API") to allow external devices and systems to access land based and underground asset data, may provide data to proprietary programs executed on each client device, and the like. Wab server 201 may be one or more computing devices. Web server 201 may store land based data and underground asset data on a local storage device or may be operatively coupled to one or more database server 202 configured for storing and/or mapping land based data with underground asset data. One or more additional computing devices 203 may perform additional as web server 201, database server 202, and additional computing devices 203 may provide an Underground Asset Management System as shown in the architecture of FIG. 2, in alternative embodiments the system may be provided by a single computing device, a cloud computing architecture, or any other computing architecture. Server computing devices 203 may be separated from other networked computing devices by a firewall 211, threby increasing the integrity of the system. One or more data sources 231 may transmit land based data or underground asset data to web server 201. Data sources 231 may include companies providing land based data (e.g., maps and other geographic data), such as ESRITM GOOGLETM, NASATM, as well as others. For example, UAMS 101 may use ArcGISTM JavaScript API version 1.3 for displaying the address, and querying the buffered area given address on the base map, buffering a specific area around the address, and querying the buffered area to check of any underground asset is present and may use GOOGLETM MAPS JavaScript API version 2 for displaying the GOOGLETM STREETVIEW for the given address. Of course, other combinations of data sources 231 may b e implemented. Data sources 231 may also include asset owners or other entities providing underground asset data, such as utilities or government entities. Data sources 231 may periodically update their data and may send updated data to web server 201 after each update. For example, a utility may transmit updated date the location of the line. Alternatively, web server 201 may request updated information from data sources 231 periodically, for example on a regular schedule or in response to a dig request for a particular location. Requests may be in a proprietary format dictated by each data source 231, may be in a format compatible with an API for each data source 231, or may be in any other format. As shown, data sources 231 transmit data to web server 201 via network 210, however in alternative architectures data sources 231 may transmit data to web server 201 via other routes, for example by physically transmitting storage media (e.g., DVDs or other non-transitory media) having the data stored thereon. Data sources 231 may provide complete land based and asset data to web server 201 or may transmit only updated land based and/or asset data as the data changes over time. Data sources 231 may thus provide dynamic and live updates to web server 201. Web server 201 may be configured to map the asset data to the land based data. Thus, web server 201 may provide a consolidated mapping of underground assets from plural asset owners to land based data. Additionally, by receiving periodic updates, web server 201 may maintain up-to-date mapping of underground assets to land based data. Web server 201 may provide a unified view of both the land based data and the asset data, such as a map showing all underground assets in an area. For example, a program accessing data from web server 201 may display a user navigable map showing all underground assets in an area. Alternatively, a browser may access a website hosted by web server 201 for displaying a user navigable map showing all underground assets in an area. Of course, these user interfaces may additionally provide for receipt of dig tickets from excavators, transmission of locate tickets for display to locators, receipt of various asset location information from locators, updates to land based data sources or asset owners, and the like. In addition to mapping underground assets to land based data, embodiments may also map landmark data to the land based data and underground asset data. Landmark data may include any distinguishable structure on a map or landscape. Thus, landmarks do not need to be famous, such as the Eifel Tower, but may be any structure with distinguishable features, such as a house or a tree. For example, landmark data may be received by web server 101 that indicates where various landmarks are in a region. The landmark data may be mapped to the land based data. Because the underground assets are also mapped to the land based data, the location of underground assets may also be mapped in relation to various landmarks. Thus, a dig ticket may be received indicating an excavation location in relation to one or more landmarks rather than, or in addition to, the geographic coordinates (e.g., latitude and longitude) and the system may determine whether there are underground assets in the excavation location. Thus, dig tickets may be more reliably processed for excavators who do not have ready access to survey equipment, such as GPS sensors, and may not have address information for the excavation location, for example in developing countries. Alternatively, asset owners may transmit underground asset data giving the location of an asset relative to a landmark rather than, or in addition to, other location information (e.g., geographic coordinates) and the system may map the underground assets to the land based data based on the mapping of landmarks to the land based data. This may improve the accuracy of mapping of assets, especially in areas or countries where sophisticated surveying equipment, such as equipment using GPS sensors, may not be readily available. In addition to transmitting landmark information, basic location information, such as a town or other geographic region, may be transmitted to web server 101 as well. By reducing the size of the geographic region (i.e., by specifying a town or other geographic region), web server 101 may reduce the number of potential landmarks to recognize, thus increasing accuracy of landmark recognition and decreasing resource usage. Web server 101 may also provide various geocoding and reverse geocoding services. For example, web server 101 may resolve a geographic coordinate (e.g., latitude and longitude) from information such as an address, a reference to one or more landmarks (e.g., distance from and position relative to a single landmark), imagery, and the like. This may be useful for receiving dig tickets when an excavator can provide an address for an excavation location but cannot provide geographic coordinates. Web server 101 may also provide information relating to addresses, landmarks, imagery, and the like when provided with a geographic coordinate. This may be useful for a locator to travel to an excavation location to inspect or to mark the location of underground assets. Embodiments may provide geocoding services to match the address of either an asset's location or a dig request to a geographic coordinate. For example, web server 101 may include address data cross-referenced with locations on the land based data. Thus, when web server 101 receives address information, web server 101 may resolve the geographic coordinates for the address. Alternatively, web server 101 may query a separate service to resolve an address location. For example, an API request may be made to a geocoding API, such as those provided by YAHOO or GOOGLE, to resolve the geographical coordinates associated with an address. Of course, web server 101 may be configured to receive addresses in varying forms according to country and custom. For example, an address in the United States may be provided in the format of an address line, a county and/or city, and state, or in the format of an address line and a ZIP code. Embodiments may also provide their own database to provide geocoding services. For example, a custom locate function may invoke a method for locating an address on a map. The custom locate function may search a received address in one or more candidate search engines, for example those provided by GOOGLETM MAPS, MICROSOFT™ BING™ MAPS, ArcGIS''"'^ online services, and the like. For example, if a user inputs an address having a house number along with a street name, a custom locate function may be configured to show the address on the map if the exact address is found. The following is exemplary pseudo code for displaying a location on the map using a symbol if the address is found (i.e., the address has a candidate score of 100). if (candidate.attributes.Loc_name == "Street_Address") { if (candidate.score == 100) { var infoTemplate = new esri.InfoTemplate("Location", "Address: ${address}
Score: ${score}
Sourcelocator: ${locatorName}"); var attributes = { address: candidate.address, score:candidate.score, locatorName:candidate.attributes.Loc_name }; points.addPoint(candidate.location); myMap.graphics.add(graphic); map. setExtent(points. getExtent(). expand(3)); } } In other instances, an address may include a street name but not house number. In such instances, a custom locate function may be configured to show the entire street on the map. To do this, the fiinction may get the returned addresses having a location name attribute as the street address and parse through a results array until the minimum and maximum house numbers on the street are retrieved from the array list. The function may then geocode the address of the minimum house number and of every twentieth house member thereafter until 100 house numbers more than the maximum house number is reached. This may ensure that house numbers after the maximum house number are retrieved from the array and included in case they are present. A polyline may then be created using the location of the first two addresses and the location of each address after that may be appended to the polyline. The following is exemplary pseudo code for displaying the location on the map. if(candidate.attributes.Loc_name== "Street_Address") { if(!(isNaN(candidate.address.substring(0,candidate.address.indexOf(" "))))) { hNol = candidate.address.substring(0,candidate.address.indexOf(" ")); var temp = parselnt(hNol); if(high = 0){ high - temp; } if(low = 0){ low = temp; } if(high