A geographic coordinate automatic completion method and system based on address variant degradation and four-to-intersection estimation
By using address variant downgrading and boundary intersection estimation methods, the problem of missing or incorrect geographical coordinates in rental housing projects was solved. This enabled the automatic synthesis of candidate intersection queries from unstructured descriptions, improved the coordinate hit rate, filtered out out-of-bounds results, and ensured data quality and traceability.
Patent Information
- Application Number
- CN202611377297.2
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-09-07
- Publication Date
- 2026-11-03
AI Technical Summary
After automated data collection, the geographic coordinates of rental housing projects are often missing or incorrect, especially for planned projects without house numbers. Existing technology makes it difficult to automatically synthesize candidate intersection queries from unstructured boundary descriptions, and the geocoding interface is prone to returning out-of-boundary or empty results. The lack of target city range verification leads to data pollution.
This paper presents an automatic geographic coordinate completion method based on address variant downgrading and boundary intersection estimation. The method includes address variant downgrading, boundary candidate synthesis, geocoding invocation, and regional boundary verification. The method generates reliable coordinates by performing multi-level address variant downgrading and noise reduction, synthesizing candidate intersection queries and performing regional verification, and writing them into a candidate table for review.
It enables automatic inference of available coordinates from unstructured coordinate descriptions, improving the hit rate of operational projects, filtering outbound results, preventing data overwriting, and ensuring coordinate quality and data source traceability.
Smart Images

Figure FT_1 
Figure FT_2
Abstract
Description
Technical Field
[0001] This invention relates to the fields of geographic information processing and geocoding technology, and in particular to a method and system for automatic geographic coordinate completion based on address variant downgrading and boundary intersection calculation for rental housing projects. Background Technology
[0002] The digital collection of information on rental housing (including affordable rental housing, talent apartments, public rental housing, and market-oriented long-term rental apartments) generally relies on the automated extraction of unstructured text from government announcements, housing security sections, and planning notices. The extracted project records usually carry address text or a boundary description such as "east to X road, south to Y road, west to W road, and north to N road," but lack latitude and longitude coordinates that can be directly used for map mapping. Therefore, the automatic geocoding of "address text → geographic coordinates" is a crucial step in mapping this type of data.
[0003] Chinese patent application (publication number: CN121457475A) discloses a geocoding error identification method based on address and coordinates. This method uses a geocoding platform to geocode standard-format text addresses, converts the coordinates, and then identifies the errors. US patent 11,796,339 (Verizon) discloses a road intersection geocoding method that parses a given first and second road in a query, samples road segments, and finds common points as candidate intersections. Both of these methods use either a "standard-format house address" or "two road names explicitly given by the user" as input, but do not disclose how to automatically synthesize candidate intersection queries from unstructured boundary text such as "East to X, South to Y, West to W, North to N".
[0004] Furthermore, the addresses of operational projects actually captured often contain noise such as parenthetical supplementary descriptions and redundant administrative regions and project names, directly leading to transaction failures; geocoding interfaces may return out-of-bounds coordinates or empty results in cases involving boundaries or cross-city locations, and existing solutions do not emphasize verifying the target city range of the returned coordinates during batch autocomplete; if autocomplete directly overwrites the original records, misjudgment by the interface will pollute the data source. The information disclosed in this background art is only used to understand the background of the inventive concept, and therefore may include information that does not constitute prior art. Summary of the Invention
[0005] Technical problems to be solved This invention aims to solve the problem of missing or incorrect geographic coordinates in rental housing projects (especially planning projects and projects without address plates) after automated collection. Specifically, it proposes: (1) a candidate intersection query synthesis and priority fallback method based on the four-way text description, so that planning projects with only boundary road descriptions and no address plates can automatically infer available coordinates; (2) a multi-level address variant downgrade method for dirty addresses, which improves the first hit rate of operational projects by denoising and using administrative district / project name as a fallback; (3) a regional boundary legality verification mechanism, which determines the target city range for the geographic code returned coordinates and filters out out-of-boundary and empty results; (4) a batch verification and completion pipeline with isolated writing, which stores the correction results in the database in the "candidate-review-adoption" manner to avoid accidental overwriting. Technical solution
[0006] This invention provides a method for automatic geographic coordinate completion based on address variant downgrading and boundary intersection calculation, comprising the following steps: Step 1: Obtain rental housing project records. The project records must include at least one of the following: address text, boundary description, administrative district, project name, or plot number. Step 2: Determine the type of the project record: if it already carries non-empty and valid latitude and longitude coordinates, skip it; if it carries address text, enter the address variant channel; if it only carries boundary descriptions, enter the boundary intersection channel. Step 3: In the address variant channel, perform multi-level address variant downgrading on the original address to generate an ordered sequence of candidate query strings and submit geocoding sequentially. The candidate query string sequence includes at least: the original address text, the denoised address after removing parentheses and the description within the parentheses, and the concatenation string of administrative region and project name. Step 4: In the four-way intersection passage, extract the road names ending with road, street, road or village from the four-way description, synthesize an ordered candidate intersection query sequence according to a fixed priority rule and submit the geocode in sequence. The priority includes: East and South, East and West, South and North, single road plus plot number, plot number, administrative region plus project name; Step 5: Perform a regional boundary validity check on the coordinates returned by geocoding, and determine whether the coordinates fall within a reasonable range using the target city's latitude and longitude bounding box. Step six: The verified coordinates are isolated and written into a separate data table in candidate form and the source is marked. The original project records are not directly overwritten. The data is then written back after manual review and adoption.
[0007] The corresponding system includes a type discrimination module, an address variant downgrade module, a four-way candidate synthesis module, a geocoding call module, a region verification module, and a candidate isolation writing module, which are configured to execute steps two through six above. Beneficial effects
[0008] Compared with existing technologies, the beneficial effects of this invention include: for the first time solving the coordinate inference problem of planning projects with "only four boundary texts and no house address", automatically synthesizing candidate intersection queries from unstructured boundary descriptions and backing up according to priority; dirty addresses are downgraded through multiple variants to retain the original address semantics, resulting in a higher first-hit rate; regional boundary verification filters out out-of-bounds and empty results, ensuring controllable coordinate quality; candidate isolation writing plus manual review and adoption prevents accidental overwriting of source data, and retains a list of changed fields and confidence levels for easy traceability. Attached Figure Description
[0009] Figure 1 This is a schematic diagram of the module relationships of the geographic coordinate automatic completion system of the present invention.
[0010] Figure 2 This is a flowchart illustrating the automatic geographic coordinate completion method of the present invention. Detailed Implementation
[0011] The present invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only for explaining the present invention and are not intended to limit the present invention.
[0012] like Figure 1 As shown, the system includes a type discrimination module, an address variant downgrade module, a boundary candidate synthesis module, a geocoding invocation module, a region verification module, and a candidate isolation writing module. The type discrimination module reads project records and distributes them to the address variant channel or the boundary intersection channel; the address variant downgrade module and the boundary candidate synthesis module generate candidate query strings respectively; the geocoding invocation module holds the map service security key (stored in the server-side environment variables and not distributed to the front end) and initiates requests for each variant or each candidate; the region verification module performs bounding box validity determination; and the candidate isolation writing module writes the corrected coordinates into a candidate format to an independent data table.
[0013] like Figure 2 As shown, the method is executed according to steps one through six. The following is a description with reference to an example.
[0014] The first embodiment (planning project, intersection passage): A notice for a "new residential project with supporting affordable housing" specifies "east to Miaojing Road, south to Huaxia East Road, west to plot A05A-06, and north to XX Road". The system extracts the road names E=Miaojing Road, S=Huaxia East Road, W=Plot A05A-06 (excluding those ending with road / street / road / village), and N=XX Road. Candidates are generated according to the priority in step four: ① "Intersection of Miaojing Road and Huaxia East Road, Pudong New Area" → geocoding returns valid coordinates that fall within the Shanghai bounding box → adopted and added to the candidate pool, pending review and adoption before being written back to the original record. This embodiment corresponds to the feature of "prefixed with administrative district name and noise segmentation" described in claim 3.
[0015] The second implementation (operational projects, address variant downgrade): A project address is "No. 58, Innovation West Road (near Metro Line 2)". Step 3: Variant ① "No. 58, Innovation West Road (near Metro Line 2)" fails; Variant ②, after removing parentheses and their descriptions using regular expressions, finds "No. 58, Innovation West Road" and returns the coordinates; the region verification passes and is added to the candidate pool. This implementation corresponds to the feature described in claim 2 where the denoised address is only added as a candidate when it differs from the original address.
[0016] Out-of-boundary branch example: A candidate returns coordinates of latitude 31.2 but longitude 123.1 (exceeding the upper limit of Shanghai's longitude of 122.5). The result of the area verification in step five is false, the system does not accept it, marks the item as entering the manual processing list and retains the original value, without writing the erroneous coordinates. This example corresponds to the verification function and isolation writing feature described in claims 4 and 5.
[0017] The region validity check function is defined as follows: valid(lat, lng) = [lat_min ≤ lat ≤ lat_max] ∧ [lng_min ≤ lng ≤ lng_max]. Proceed to step six if and only if valid is true; otherwise, retain the original value and mark it as out of bounds.
[0018] Table 1 Key Parameters and Value Descriptions: lat_min and lat_max are the lower / upper limits of the target city's latitude, 30.5 / 32.0 (Shanghai) in this example; lng_min and lng_max are the lower / upper limits of the target city's longitude, 120.5 / 122.5 (Shanghai) in this example; E, S, W, and N are the names of roads to the east / south / west / north, taken as text strings; T_geo is the timeout for a single geocoding request, 12 to 15 seconds in this example; valid(lat, lng) is the determination of the validity of the coordinate area, taken as a Boolean value.
[0019] The above values are merely examples and are not intended to limit the scope of protection of the claims of this invention. Those skilled in the art will understand that the bounding box parameters can be adjusted according to the target city, and the priority order of candidate intersections can be dynamically rearranged according to historical hit rates, all of which fall within the scope of this invention.
Claims
1. A method for automatic geographic coordinate completion based on address variant downgrading and boundary intersection calculation, characterized in that, Includes the following steps: Step 1: Obtain rental housing project records. The project records must include at least one of the following: address text, boundary description, administrative district, project name, or plot number. Step 2: Determine the type of the project record: if it already carries non-empty and valid latitude and longitude coordinates, skip it; if it carries address text, enter the address variant channel; if it only carries boundary descriptions, enter the boundary intersection channel. Step 3: In the address variant channel, perform multi-level address variant downgrading on the original address to generate an ordered sequence of candidate query strings and submit geocoding sequentially. The candidate query string sequence includes at least: the original address text, the denoised address after removing parentheses and the description within the parentheses, and the concatenation string of administrative region and project name. Step 4: In the four-way intersection passage, extract the road names ending with road, street, road or village from the four-way description, synthesize an ordered candidate intersection query sequence according to a fixed priority rule and submit the geocode in sequence. The priority includes: East and South, East and West, South and North, single road plus plot number, plot number, administrative region plus project name; Step 5: Perform a regional boundary validity check on the coordinates returned by geocoding, and determine whether the coordinates fall within a reasonable range using the target city's latitude and longitude bounding box. Step six: The verified coordinates are isolated and written into a separate data table as candidates and their sources are marked. The original project records are not directly overwritten. The data is then written back after manual review and adoption.
2. The method according to claim 1, characterized in that, The denoised address in step three is generated by removing parentheses and descriptions within parentheses from the original address using regular expressions, and is appended as a candidate query string only if the denoised address is different from the original address.
3. The method according to claim 1, characterized in that, The synthesis of the candidate intersection query string in step four further includes: prefixing the concatenated road name with the administrative district name and removing noise segments in the boundary description that do not end with road, street, road or village.
4. The method according to claim 1, characterized in that, The area boundary legality verification in step five is as follows: the target city bounding box is enclosed by the lower latitude boundary, the upper latitude boundary, the lower longitude boundary, and the upper longitude boundary. If and only if the latitude of the coordinate is not less than the lower latitude boundary and not greater than the upper latitude boundary, and the longitude of the coordinate is not less than the lower longitude boundary and not greater than the upper longitude boundary, the coordinate is determined to fall within a reasonable range and proceeds to step six; otherwise, the original value is retained and marked as out of bounds.
5. The method according to claim 1, characterized in that, The isolation writing in step six further includes: recording the list of changed fields, confidence level and source identifier, and adding items that fail verification or whose geocoding fails completely to the list of items to be manually processed.
6. A geographic coordinate automatic completion system based on address variant degradation and boundary intersection calculation, characterized in that, include: The type discrimination module is configured to perform step two as described in claim 1; The address variant downgrade module is configured to perform step three as described in claim 1; The candidate synthesis module is configured to perform step four as described in claim 1; The geocoding invocation module is configured to hold a security key for the invoked map service and initiate geocoding requests on a variant or candidate basis. The region verification module is configured to perform step five as described in claim 1; The candidate isolation write module is configured to perform step six as described in claim 1.
7. The system according to claim 6, characterized in that, The address variant degradation module includes a denoising subunit and a splicing subunit, which respectively implement the features described in claims 2 and 3.
8. The system according to claim 6, characterized in that, The region verification module has built-in target city bounding box parameters and calls the region boundary legality verification method described in claim 4 to determine the region.
9. The system according to claim 6, characterized in that, The candidate isolation writing module further includes a change tracking subunit, which records the list of changed fields, confidence level and source identifier, and maintains a list of fields to be manually processed.
10. A computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method of any one of claims 1 to 5.
Citation Information
Patent Citations
Geocoding error identification method based on address and coordinate
CN121457475A
Smart geocoding of road intersections
US11796339B2
