A geographic knowledge graph construction method and device, and a storage medium

Abstract

A kind of construction method, equipment and storage medium of geographic knowledge graph, obtain the data of geographic data source, convert regional data into WKT format and export relevant attribute, carry out entity alignment and attribute fusion to entity in geographic data source data, then add corresponding natural geographical attribute to entity, and geographic knowledge graph is obtained by construction.The present application is not limited to a few large range of place entity, and most common geographic entity is added with regional type data;The rule method of multi-data source entity alignment is improved, some original errors are corrected, different geographic entities are merged, and the same geographic entity is not merged;For the few attributes corresponding to geographic entity, natural geographical attributes such as soil type and monthly average wind direction, as well as human geographical attributes such as human development index and per capita electricity consumption are added.

Description

TECHNICAL FIELD

[0001] The present application belongs to the technical field of computer information processing, and relates to a knowledge graph, in particular to a method and device for constructing a geographic knowledge graph and a storage medium. BACKGROUND

[0002] Knowledge is complex, and each concept entity has many levels and is associated with many other entities. Due to the complexity of knowledge, it is almost impossible to obtain knowledge in a machine-readable format without appropriate tools. A knowledge graph is specially constructed to achieve this goal, which is a semantic network that reveals the relationship between entities and represents a collection of interlinked descriptions between entities. A knowledge graph usually describes structured knowledge in the form of triples, and each element of a triple is composed of an entity, a property, a property value, or a head entity, a relationship between entities, and a tail entity. Large knowledge graphs are usually established based on the Resource Description Framework (RDF) standard, such as DBpedia, Wikidata, GeoNames, and WordNet.

[0003] In the field of geography, the existing knowledge graphs in the field of geography include GeoNames, LinkedGeoData, and CKGG. GeoNames is a global geographic database that contains a large number of geographic entities, but it has fewer attributes, and in addition to latitude and longitude coordinates and upper geographic entities, it lacks geographic knowledge required by geographic science. LinkedGeoData is an RDF format knowledge base converted from open map data OpenStreetMap, which is convenient for fusion with other graphs. However, it does not convert the geographic area data of OpenStreetMap entities of the Relation type, and also lacks the geographic attributes required by geographic science.

[0004] The Chinese Knowledge Graph for High-School Geography (CKGG) integrates geographic entities from GeoNames and Wikidata, and collects and organizes multiple other geographic data sources to add attributes such as temperature, precipitation, and light intensity related to high school geography to the geographic entities. However, it has the following defects: only a few large-scale place entities such as countries and first-level administrative regions have region type data; the rule method for aligning multiple data source entities is relatively simple, and there are cases of incorrect merging of different geographic entities and cases of the same geographic entity not being merged; the attributes corresponding to the entities are insufficient, resulting in a lack of some application scenarios.

[0005] For geographical area data, WKT format is commonly used in knowledge graph. Currently, there are geoBoundries, gADM, OpenStreetMap and other data sources of geographical area data. geoBoundries and gADM both use ESRIShapefile format to represent geographical areas, which can be converted into WKT format through GDAL tool. However, compared with OpenStreetMap, it contains less geographical entities. geoBoundries and gADM only contain administrative units divided by political division, i.e. countries, first-level administrative regions (provinces), second-level administrative regions (prefecture-level cities), etc., and lack natural geographical entities such as mountains, rivers, etc. In addition, these two data sources only have the administrative level and English name label of a geographical entity in addition to the area information, and there is no direct link to other data sources, so it is also a challenge to align with the geographical entities in other data sources. In addition, the spot check of Chinese place names shows that there is a certain deficiency in the accuracy rate, such as Shaoyang, which should be Shaoyang, but is incorrectly marked as Zhaoyang.

[0006] OpenStreetMap uses its unique osm.pbf format to store geographical entity area data, which can be parsed and processed using libosmium library. OpenStreetMap has three different types of data, namely Node type, Way type and Relation type. The entity of Node type is a point on the earth's surface represented by latitude and longitude coordinates. The entity of Way type is composed of multiple ordered Node type entities, which constitutes a directed polyline segment. The entity of Relation type is more complex, which is a recursive structure, and contains multiple Node, Way or Relation type entities. Moreover, for each included substructure, there is a corresponding label. A most naive example is that a relationship contains multiple paths, which constitutes a closed graph, i.e. a polygon. And the label of each path is outer (external) or inner (internal). The existing entity connection data set of OpenStreetMap and Wikidata shows that due to the complex WKT format of Relation and the existence of a large amount of missing geographical information, it is currently impossible to perfect the geographical information (http: / / www.openkg.cn / dataset / openstreetmap-wikidata). SUMMARY

[0007] The technical problem to be solved by the present application is to design a method for constructing a geographical knowledge graph in view of the deficiencies of the existing geographical field knowledge graph.

[0008] The technical scheme of the present application is a method for constructing a geographic knowledge graph, obtaining data of a geographic data source, converting regional data into WKT format and exporting related attributes, performing entity alignment and attribute fusion on entities in the geographic data source data, and then adding corresponding natural geographic attributes to the entities to construct a geographic knowledge graph, including the following steps:

[0009] Step one, obtain data from the three data sources of GeoNames, Wikidata, and OpenStreetMap: for the GeoNames geographic knowledge base, obtain tab-delimited data files and store them in a relational database for subsequent processing; for the Wikidata knowledge base, store the data in triple format; for the OpenStreetMap public map data, obtain the binary osm.pbf format file, use the osmium tool to export the required geographic entities, and then store them for subsequent processing;

[0010] Step two: use the libosmium library to parse the geographic entities obtained from OpenStreetMap in step one, model the recursively nested Relation type entities in OpenStreetMap as a directed acyclic graph structure, and convert them into WKT type data for storing geographic region data according to their topological order. The geographic location types represented are divided into two types: polygons and polyline segments.

[0011] Step three: export related attributes from the WKT format region data, use the obtained region data, i.e., the two WKT type data of polygon region and polyline segment region, to calculate the attributes of geographic entities through data calculation. For polygon data, calculate its land area, and for polyline segment data, calculate its length. In addition, calculate attribute data, including distance from the sea, distance along the river, adjacent locations, and belonging relationships.

[0012] Step four: align and fuse the geographic entities from the three data sources of GeoNames, Wikidata, and OpenStreetMap, and use the common attributes between different data sources to determine whether two geographic entities are equivalent.

[0013] Step five: obtain grid data from natural geographic related data sources, including soil type and monthly average wind direction. For grid data type, store it in the PostgreSQL database using the raster data format for subsequent processing. For each geographic entity in the graph, find the corresponding grid data based on its represented region range or its represented latitude and longitude coordinates to represent the corresponding attribute values of the geographic entity.

[0014] Step six: obtain the table data in the human geography related data source, for this type of data, use the string similarity algorithm, and then combine the bipartite graph matching to find the corresponding geographical entity according to the place name;

[0015] The constructed graph is in the form of Wherein E represents a set of geographical entities, P represents a set of different relations and attributes, L represents a set of various enumerated attributes and numerical attributes, R represents a set of triples constituting the graph, and satisfies Whether the tail entity is a geographical entity or a value type depends on the specific attribute. When the attribute is soil type or precipitation, the tail entity corresponds to the enumerated value type and the numerical type, respectively. When the attribute is the upper and lower level place, the tail entity is a geographical entity.

[0016] The present application also proposes an electronic device comprising a storage medium and a processor, the storage medium is used for storing a computer program, and the processor is used for executing the computer program. When the computer program is executed, the construction method of the geographical knowledge graph is realized.

[0017] The present application also proposes a computer readable storage medium, the computer readable storage medium stores a computer program, and the computer program is executed to realize the construction method of the geographical knowledge graph.

[0018] The present application proposes a new scheme for converting the existing data source into the WKT format supported by the knowledge graph, especially the processing method of the Relation entity, which realizes the effective acquisition of the available information of the knowledge graph from the complex data source.

[0019] The construction method of the geographical knowledge graph of the present application improves the defects existing in the CKGG, is not limited to a small number of large range place entities, adds the data of the region type to most common geographical entities, improves the rule method of the entity alignment of the multiple data sources, corrects some errors, combines different geographical entities, and does not combine the same geographical entities. In view of the fact that the attributes corresponding to the geographical entities are few, the natural geographical attributes such as soil type and monthly average wind direction are added, and the human geographical attributes such as human development index and per capita electricity consumption are added. BRIEF DESCRIPTION OF DRAWINGS

[0020] Figure 1 The flowchart of the present application.

[0021] Figure 2 The geographical knowledge graph constructed by the present application is an entity example. DETAILED DESCRIPTION

[0022] The present application aims at the deficiency of the existing geographical field knowledge graph, designs a construction method of geographical knowledge graph, and fuses the knowledge of multiple heterogeneous data sources, which can not only more conveniently and uniformly obtain the related geographical attributes and relations of a certain geographical place, but also provide external knowledge support for some downstream tasks (such as geographical field knowledge question answering). The method flow chart of the present application is shown in Figure 1 The method flow chart of the present application is shown in

[0023] Step one: firstly, all data in the three data sources of GeoNames, Wikidata and OpenStreetMap is obtained.

[0024] For the GeoNames geographical knowledge base, the tab-delimited data file is obtained, and is stored in a relational database for subsequent processing. Because the PostgreSQL database contains the PostGIS plug-in, it is convenient to store the regional data, so as an embodiment, the tab-delimited data file is stored in the PostgreSQL database. For the Wikidata knowledge base, the data in the triple format is obtained, and because the data quantity is large, only the geographical related entities are retained during processing. Through testing, the processing efficiency is significantly improved by removing the geographical irrelevant entities before loading into the database, rather than loading into the database first and then filtering. Because it uses triples for representation, it is not convenient to store in a relational database, so as an embodiment, the Virtuoso graph database is selected for storage. For the OpenStreetMap public map data, the osm.pbf format file in binary format is obtained, because it contains too many irrelevant entities, the osmium tool is used to export the required geographical entities, and the libosmium library is used for subsequent processing.

[0025] Step two: introducing regional data from the OpenStreetMap data source.

[0026] In the real world, a geographical entity, such as a country, a province or a city, cannot be exactly reflected in the specific position on the earth by a single longitude and latitude coordinate point. In the graph, the area occupied by a geographical place is often represented in WKT format, such as the previous CKGG. When the area in the geographical graph is represented in WKT format, the common forms are point (POINT), line segment (LINESTRING, MULTILINESTRING), and polygon (POLYGON, MULTIPOLYGON). The line segment and the polygon are composed of multiple points. Each point corresponds to a longitude and latitude coordinate on the earth.

[0027] In order to store the area data in OpenStreetMap into the graph, it is necessary to convert the specific storage format thereof into the WKT format. Some existing methods, such as the method in LinkedGeoData, only consider the case of Node type entities and Way type entities, and do not include Relation type entities. The processing of Relation type entities only expresses which OpenStreetMap entities are included, and does not convert them into polygons in the WKT format.

[0028] For entities of the Node type or the Way type in the OpenStreetMap data source, because the scope expressed thereby is too small and the information is insufficient, the present application uses the osmium tool and the libosmium library to only export entities of the Relation type containing a name label in the OpenStreetMap data source and entities recursively contained thereby, so that the subsequent processing of the OpenStreetMap data can also be accelerated. The following particularly describes entities of the Relation type in OpenStreetMap containing a name label.

[0029] The present application abstracts the problem of obtaining the area data of the Relation type entity into a graph problem, abstracts each Relation type entity as a point in the graph, and considers that there is an edge from point B to point A in the graph for the case of recursive containing entity B by entity A. The recursive containing relationship of the Relation type entity constitutes a directed acyclic graph, so that the WKT format corresponding to each recursive containing relationship can be constructed in turn according to its topological order. The geographical entities in the OpenStreetMap data are converted into POINT for the contained Node type entity, converted into LINESTRING for the contained Way type entity, and converted into a directed acyclic graph for the recursively contained Relation type entity according to the above abstraction conversion. Therefore, we only need to consider the case that the Relation type entity only contains Node type entities and Way type entities. The contained entities of various types are taken as sub-elements, and the label refers to the label of the entity in the OpenStreetMap data, such as inner, outer indicating the inner and outer boundaries, or main_stream, side_stream indicating the main stream and tributaries of a river, etc. These can be obtained by processing through the libosmium library. In fact, the Node type entity is usually negligible, and is generally only a point or a center point of an administrative region as a marker. For the case of containing Way type entities, it is usually divided into two cases: one is to constitute a closed figure or multiple closed figures, and the other is to constitute one or more polyline segments. First, the label can be used to distinguish the area represented, that is, whether it is a polygon or a polyline. For the case of polygon, the first and last points are connected. If the first and last points have been connected but there are still subsequent Way type entities, it indicates that the polygon has an inner ring, or the geographical entity has multiple polygons. These two cases can be distinguished by the label of the Way type entity, and the label of the former is inner, and the label of the latter is outer.

[0030] The present application notes that a path is often contained in multiple relations. For example, a coastal city's boundary path with the sea is part of the city's own boundary, and also part of the province's and country's boundaries. In this way, an intermediate Way type entity can be used to store the intersection path, and the city and province corresponding Relation type entities contain this intermediate Way type entity. In fact, OpenStreetMap uses this way to store regional data in layers of nesting. Using this method, a more complete regional information can be constructed using less storage space. However, for the WKT format commonly used in knowledge graphs, each vertex in the polygon must be completely represented. For the resulting polygon, if the number of edges is too large and too complex, there will be a great demand for storage space, and such precision is often unnecessary. At this time, the Douglas-Peucker algorithm can be used for simplification. The algorithm approximates some nearly straight line segments to line segments, and uses fewer coordinate points to describe the original polygon and the original line segment as much as possible.

[0031] Step three: Calculate the area export attribute of the region.

[0032] After the regional data is obtained, more attributes can be introduced. Here, the area of administrative division, the length of the river, and the belonging relation are used as examples.

[0033] It is relatively simple to calculate the area of a polygon by taking a random point on the earth's surface. For each edge of the polygon, the directed area is calculated using the cross product, and the sum is finally obtained.

[0034] For the length of a river, it is not simply equal to the sum of the length of each polyline segment, because a river has main stream and side stream. In some rivers, the main stream and side stream are marked by the label of main_stream and side_stream. In other rivers, the information is not marked, and usually, the main stream is the branch with more water flow and longer path. Therefore, for a river composed of several connected polyline segments, the longest polyline segment can be found by the following dynamic programming algorithm, and it is considered as the main stream of the river. Similarly, it can be converted into a graph model. Each polyline segment is considered as a vertex in the graph. If the end coordinate of polyline segment C is the same as the start coordinate of polyline segment D, let u be the vertex corresponding to C in the graph, and v be the vertex corresponding to D in the graph, then a directed edge is added from C to D. The graph is denoted as G, V(G) is the vertex set of G, and E(G) is the edge set of G. Then, for any vertex v in the graph, the maximum length that can be obtained from the start of the river to the end of the polyline segment corresponding to v can be calculated by the following dynamic programming algorithm.

[0035]

[0036] Length(D) represents the length of the polyline segment D, and f(u) represents the maximum length that can be obtained from the start of the river to vertex u. According to the definition, the length of the river is max v∈V(G) f(v).

[0037] The relationship between entities and the corresponding superior and inferior places can be derived using the inclusion relationship between polygon regions. If the polygon region corresponding to entity A contains the polygon region corresponding to entity B, it means that entity B belongs to entity A.

[0038] Step four: entity alignment and fusion of multiple data sources.

[0039] The alignment and fusion of multi-data sources is also a problem to be solved. Firstly, there are some interrelated properties between these data sources, which correspond to owl:sameAs. Generally, these properties are added manually rather than automatically, so the quality is guaranteed. However, there are two problems. One is that the quality is still affected by subjective factors because of manual addition. The other is that the coverage is insufficient. The insufficient coverage can be easily verified from one perspective. For example, there are mutual equivalent relationships between OpenStreetMap and Wikidata, and between GeoNames and Wikidata. However, a considerable proportion of them is one-way, that is, there is only one direction of equivalent link relationship. Therefore, we need some other methods to dig out more equivalent relationships. A common method is to use the properties to assist in judgment. For example, the corresponding Wikipedia link. The corresponding relationship between the Wikipedia link and the Wikidata entity is obtained by using WikiMapper. Both GeoNames and OpenStreetMap have properties that correspond directly to the Wikipedia link. However, because the same page corresponds to multiple forms of links, such as pages in different languages, and some links are URL encoded, the links need to be processed uniformly. First, all links are uniformly decoded, and then the multi-language function module of WikiMapper is used for correspondence.

[0040] In the same data source, there are also cases where a geographic area corresponds to multiple entities. This situation exists in different data sources and is caused by various reasons. In GeoNames, it is because different types are involved. For example, the names of both Nanjing are "Nanjing", which are used as a second-level administrative district and a population settlement, respectively, forming two different entities, but the corresponding geographic area is the same. In OpenStreetMap, there are also Node type entities and Relation type entities corresponding to a location. However, since OpenStreetMap only considers Relation type entities with name tags, only the alignment of entities within GeoNames needs to be considered.

[0041] If there is at least one one-way direct equivalent link or indirect equivalent link by relying on the association to the same Wikipedia link between the entities of different data sources, it is considered that the two entities have an equivalent link relationship. The entity fusion of the three data sources is performed. Because the properties owned by different data sources are different, the rules used for alignment between two data sources are also different. The following methods are used:

[0042] For pairs of entities in OpenStreetMap and Wikidata: if there exists an equivalence link from one entity to another, the distance between them should be checked. If the following conditions are not met, the equivalence link is considered incorrect. The geographic entities in Wikidata only have latitude and longitude coordinate point data, while the geographic entities in OpenStreetMap use area data. For polyline data in OpenStreetMap, check if it exceeds 5km; for polygon data in OpenStreetMap, check if it exceeds 10km, and if the latitude and longitude coordinate point in Wikidata is within the polygon, the distance is 0. If there is no equivalence link, two geographic entities are considered equivalent only when the following conditions are met: the standardized name (i.e. without suffixes such as province, city, district, etc.) is the same, the upper-level place is the same, and for the distance between them, when the area type in OpenStreetMap is a polyline, the distance should not exceed 1km; when the area type in OpenStreetMap is a polygon, the distance should not exceed 2km.

[0043] For pairs of entities in OpenStreetMap and Wikidata: if there exists an equivalence link from one entity to another, the distance between them should be checked. If the following conditions are not met, the equivalence link is considered incorrect. The geographic entities in Wikidata only have latitude and longitude coordinate point data, while the geographic entities in OpenStreetMap use area data. For polyline data in OpenStreetMap, check if it exceeds 5km; for polygon data in OpenStreetMap, check if it exceeds 10km, and if the latitude and longitude coordinate point in Wikidata is within the polygon, the distance is 0. If there is no equivalence link, two geographic entities are considered equivalent only when the following conditions are met: the standardized name (i.e. without suffixes such as province, city, district, etc.) is the same, the upper-level place is the same, and for the distance between them, when the area type in OpenStreetMap is a polyline, the distance should not exceed 1km; when the area type in OpenStreetMap is a polygon, the distance should not exceed 2km.

[0044] For pairs of entities in OpenStreetMap and Wikidata: if there exists an equivalence link from one entity to another, the distance between them should be checked. If the following conditions are not met, the equivalence link is considered incorrect. The geographic entities in Wikidata only have latitude and longitude coordinate point data, while the geographic entities in OpenStreetMap use area data. For polyline data in OpenStreetMap, check if it exceeds 5km; for polygon data in OpenStreetMap, check if it exceeds 10km, and if the latitude and longitude coordinate point in Wikidata is within the polygon, the distance is 0. If there is no equivalence link, two geographic entities are considered equivalent only when the following conditions are met: the standardized name (i.e. without suffixes such as province, city, district, etc.) is the same, the upper-level place is the same, and for the distance between them, when the area type in OpenStreetMap is a polyline, the distance should not exceed 1km; when the area type in OpenStreetMap is a polygon, the distance should not exceed 2km.

[0045] For pairs of entities within GeoNames: For pairs of entities with the same name, the same type (or one is an administrative region and the other is a populated place), and whose latitude and longitude coordinates are within 10 km of each other, we consider them to be equivalent.

[0046] We abstract each entity from a data source as a node in the graph, and if two entities are equivalent, we add an edge between them. Then each equivalence class corresponds to a connected component in the graph, and each equivalence class corresponds to an entity in the local geographic knowledge graph.

[0047] For the selection of entity attributes, that is, when multiple data sources contain different attribute values for the same attribute, different strategies are used for different attributes. When there are multiple value choices, for latitude and longitude coordinates, we choose the coordinate with the smallest distance to all candidate coordinates; for population data that changes over time, Wikidata and OpenStreetMap use additional attributes to record the update time of the data, and we choose the latest data as the attribute value in the graph.

[0048] Step five: Add natural geographical related attributes.

[0049] The soil type data is obtained from World Soil Information. The original data is in ArcGIS corresponding format raster data, which can be converted to ESRI Shapefile format through ArcGIS or QGIS, and then converted to PostGIS through GDAL tool and imported into PostgreSQL database.

[0050] Because of the different size ranges and accuracy of geographic locations, for a geographic location, it is a coordinate point or a region polygon, different methods are used to determine its soil type and monthly wind direction data. For the case of a coordinate point, find its corresponding grid to get its data; for the case of a polygon region, it may intersect with multiple grids. For each intersecting grid, calculate the ratio of the intersection area to the original polygon area as the weight of the grid. For each soil type, calculate the proportion of this soil type in this polygon region according to the following formula. Where s i is the i-th soil type, G is all enumerated grid regions, and A is the polygon region of the geographic entity. For each soil type with a proportion of no less than 25%, we consider that the region has this soil type.

[0051]

[0052] In the above formula, Soil(G) represents the soil type corresponding to grid region G, Area(·) represents the area occupied by a region, and f(A, si ) represents the soil type s i The proportion of the area occupied by region A.

[0053] The monthly wind direction data is obtained from the Climate Data Library, which is in netCDF format. GDAL tools can be used to convert it directly to PostGIS.

[0054] For monthly wind direction data, the processing method is similar, but the weighting method is slightly different. For polygon regions, if the corresponding grid has a monthly average wind direction difference greater than 90°, the region is ignored. Because this situation indicates that the area is large, and the wind direction of different parts of the region is significantly different, an average wind direction value cannot well describe the situation of the large region, so this situation needs to be discarded. Otherwise, the wind direction can be weighted and averaged. It should be noted that the wind direction should be considered as a vector, i.e. calculated according to the following formula. G is all the enumerated grid regions, and A is the polygon region of the geographical entity. The direction of the final result W is the average wind direction. The wind direction is reduced to [-180°, 180°), where -180° is the west direction, -90° is the south direction, 0° is the east direction, and 90° is the north direction.

[0055]

[0056] where wind(G) is the wind direction and speed data corresponding to grid G, which is a vector, the direction represents the wind direction, and the size represents the wind speed.

[0057] Step six: Add human geography related attributes.

[0058] Obtain human geography related table data and integrate it into the atlas. Human geography attributes include human development index, per capita electricity consumption, etc. These data can be obtained from websites such as Our World in Data in the form of tables. These human geography data usually only contain place names and do not have any correspondence to the geographical entities of existing data sources. Therefore, string similarity algorithms such as Jaro-Whikler distance are used to calculate the similarity between the place name and the entity name in the geographical atlas. Here, it cannot be directly matched accurately because some places have multiple expressions, such as d'Ivoire and Cote D'Ivoire, etc. All the places in the table are regarded as a set of nodes, and all the country and first-level administrative region entities in the local geographical knowledge graph are regarded as another set of nodes. An edge is added between any pair of nodes in the Cartesian product of the two sets, and the similarity of the name strings of the pair is calculated and normalized to serve as the weight of the edge. The maximum matching of the bipartite complete graph is performed, and the matching result is the correspondence between the places in the table and the entities in the graph. Thus, the geographical knowledge graph can be added with human geography-related attributes.

[0059] The constructed graph is in the form of wherein E represents a set of geographical entities, P represents a set of different relationships and attributes, and L represents a set of various enumerated attributes and numerical attributes. R represents a set of triples that constitute the graph, and satisfies The tail entity is a geographical entity or a value type, depending on the specific attribute. For example, when the attribute is soil type or precipitation, the tail entity corresponds to the enumerated value type and the numerical type, respectively. When the attribute is an upper or lower level place, the tail entity is a geographical entity.

[0060] Through the above steps, the deficiencies of the existing geographical knowledge graph can be improved. The final geographical knowledge graph is shown in the table. Figure 2 Compared with the existing various geographical knowledge bases such as GeoNames, the application introduces natural geographical attributes such as soil type, wind direction in each month, and area, as well as human geographical attributes such as human development index. In addition, regional attributes are introduced, which can more accurately represent a geographical entity than latitude and longitude coordinates. At the same time, the upper and lower level places and the area attribute can be calculated according to the regional attribute, which makes up for the lack of the existing geographical knowledge graph in various geographical attributes and relationships.

Claims

1. A method for constructing a geographic knowledge graph, characterized in that The data of the geographic data source is acquired, the regional data is converted into WKT format and the related attributes are exported, the entities in the geographic data source data are aligned and fused, and the corresponding natural geographic attributes are added to the entities to construct a geographic knowledge graph, including the following steps: Step one, acquiring data in three data sources of GeoNames, Wikidata and OpenStreetMap: for the GeoNames geographic knowledge base, a tab-delimited data file is acquired and stored in a relational database for subsequent processing; for the Wikidata knowledge base, triple format data is acquired and stored; for the OpenStreetMap public map data, an osm.pbf format file in binary format is acquired, and the required geographic entities are exported using the osmium tool for subsequent processing; Step two: using the libosmium library to parse the geographic entities obtained from OpenStreetMap in step one, the recursively nested Relation type entities in OpenStreetMap are modeled as a directed acyclic graph structure, which is converted into WKT type data of the knowledge graph according to the topological order, for storing geographic regional data, and the geographic location types represented are divided into two types, one is polygon, and the other is polyline segment; Step three: exporting related attributes of WKT format regional data, using the obtained regional data, i.e. polygon region and polyline segment region WKT type data, calculating the attributes of geographic entities through data, for polygon data, calculating its land area, for polyline segment data, calculating its length, in addition, calculating attribute data, including distance from the sea, distance along the river, adjacent place and belonging relationship; Step four: aligning and fusing the geographic entities of the three data sources of GeoNames, Wikidata and OpenStreetMap, using the common attributes between different data sources to determine whether two geographic entities are equivalent; Step five: acquiring grid data in natural geographic related data sources, including soil type and monthly average wind direction, for grid data type, storing it in PostgreSQL database using raster data format for subsequent processing; for each entity in the graph, according to its represented regional range or according to its represented latitude and longitude coordinates, finding out the corresponding grid data to represent the corresponding attribute value of the geographic entity; Step six: acquiring table data in human geography related data sources, for this type of data, using string similarity algorithm, and combining bipartite graph matching to find the corresponding geographic entity according to the place name; The constructed atlas is in the form of Wherein E represents a set of geographic entities, P represents a set of different relations and attributes, L represents a set of various enumerated attributes and numerical attributes, and R represents a set of triples constituting the atlas, satisfying Wherein whether the tail entity is a geographic entity or a value type depends on the specific attribute. When the attribute is soil type or precipitation, the tail entity corresponds to the enumerated value type and the numerical value type respectively; and when the attribute is a superior and inferior place, the tail entity is a geographic entity.

2. The method of claim 1, wherein the geographic knowledge graph is constructed by In step one, for the Wikidata knowledge base, only the entities with the property of geographic location are retained, and the remaining triples are imported into the graph database; for the entities of Node type or Way type in the OpenStreetMap data source, only the entities of Relation type containing the name label and the recursively contained entities are exported using the osmium tool.

3. The method of claim 1, wherein the geographic knowledge graph is constructed by In step two, the Relation type entity data in OpenStreetMap is converted into WKT type area data, specifically: Node type entities are converted into POINT, Way type entities are converted into LINESTRING, and for recursively contained Relation type entities, each Relation type entity is abstracted as a point in the graph. For the case where entity A contains entity B, it is considered that there is an edge from point B to point A in the graph, and the recursive inclusion relationship forms a directed acyclic graph. According to the topological order, the WKT format corresponding to each recursive inclusion relationship is constructed in turn. For Way type entities in Relation type entities, they are treated as sub-elements. According to the entity label, it is determined whether to convert them into polygons or polyline segments in WKT format. For polygon data, the sub-elements are connected end-to-end. If the connection has been completed but there are still subsequent Way type entities, it indicates that the polygon has an inner ring or that the geographic entity has multiple polygons. According to the label of the sub-element, it is determined whether each sub-element is part of an outer ring or an inner ring, and the corresponding end-to-end connection is performed. For polyline segment data, the sub-polyline segment structure connected end-to-end is combined into a whole segment as much as possible. Whether it is polygon data or polyline segment data, both are further simplified in storage format by the Douglas-Peucker algorithm.

4. The method of claim 1, wherein the calculating of the related attributes of the geographic entity in step three is specifically: for the area attribute, the closed area formed by the outer ring is regarded as a positive area, and the closed area formed by the inner ring is regarded as a negative area; for the length attribute, the length attribute is calculated by summing the lengths of the line segments of a road, a railway or a river trunk; for a river formed by multiple connected line segments, the trunk and branches are distinguished by the label data, and if the label data exists, the length attribute is defined as the sum of the lengths of the line segments corresponding to the trunk, and if the label data does not exist, the branch with the largest water flow and the longest path is taken as the trunk, and the length attribute is calculated by using the following dynamic programming idea: each line segment is regarded as a vertex in a graph, if the tail coordinates of a line segment C and the head coordinates of a line segment D are the same, a directed edge is connected from the vertex of C to the vertex of D, let u be the vertex corresponding to C in the graph, v be the vertex corresponding to D in the graph, the entire graph is denoted as G, V(G) be the point set of the graph G, E(G) be the edge set of the graph G, for any point v in the graph corresponding to a line segment D in the river, the maximum length that can be obtained to the end of the current line segment is: f(v) = Length(D) + max ＜u,v＞∈E(G) f(u) Length(D) represents the length of the broken line segment D, f(u) represents the maximum length that can be formed from the vertex corresponding to any one river source to vertex u, according to the definition, the length of the river is max v∈V(G) f(v).

5. The method for constructing a geographic knowledge graph according to claim 1, wherein In step four, the entity fusion is performed on the three data sources, and for the two geographic entities that have direct equivalent links or equivalent links introduced by the Wikipedia links, a relatively loose rule is used to verify the correctness of whether the two entities are equivalent and can be fused, and the judgment thresholds for the latitude and longitude coordinate points, the polygon region and the line segment region are 70km, 10km and 5km respectively; and for the two geographic entities that do not have the equivalent links, a relatively strict rule is used to determine whether the two entities are equivalent, and the judgment thresholds for the latitude and longitude coordinate points, the polygon region and the line segment region are 10km, 2km and 1km respectively.

6. The method of claim 1, wherein in step five, the grid data of the natural geographic related data sources is obtained and integrated into the graph, and different methods are used to process the geographic entities with or without region data: for the geographic entity with only coordinate points and without region information, the latitude and longitude grid where the geographic entity is located is found, and the attribute value is obtained; for the geographic entity with region information, the region information is processed by weighting, and the processing methods for the enumeration type and the value type are different: for the soil type data of the enumeration type, the proportion of each soil in the region is calculated, and the soil type with a proportion not less than 25% is considered to exist in the region; for the monthly average wind direction data of the value type, the average wind direction range of the region is not more than 90°, and the weighted wind direction is calculated according to the wind direction and wind speed of the region.

7. An electronic device, characterized by A computer readable storage medium and a processor, the computer readable storage medium is used to store a computer program, and the processor is used to execute the computer program, when the computer program is executed, the method of constructing the geographic knowledge graph according to any one of claims 1-6 is realized.

8. A computer readable storage medium characterized by The computer readable storage medium stores a computer program, and the computer program, when executed, implements the method for constructing the geographic knowledge graph according to any one of claims 1-6.

Images