A browser-based GIS vector tile online editing and rendering method

Abstract

The application discloses a kind of browser end GIS vector tile online editing and rendering method, comprising the following steps: step 1: parsing original spatial data, read the graphic element in original spatial data, spatial reference, geometric type and business attribute information, form original element set;Step 2: the data standardization processing is carried out to original element set, and abnormal data, redundant data and empty data are excluded, and coordinate system, element specification, geometric type, attribute field and element unique identification are unified, and form standardization element set;Step 3: the standardization element set is imported into PostgreSQL database in batches, and spatial data table is constructed based on PostGIS, and form standardization database data source;Step 4: spatial index is created to the geometric field in spatial data table, and the association between element unique identification, business attribute field and spatial outer package range is established.

Description

Technical Field

[0001] This invention relates to the field of computer system technology, specifically to a browser-based online editing and rendering method for GIS vector tiles. Background Technology

[0002] Existing WebGIS massive vector data display typically employs GeoJSON, MVT / PBF, or multi-level vector tile pyramid schemes. GeoJSON has a clear structure but is a text format, resulting in large file sizes and high overhead for browser parsing and transmission; MVT / PBF is suitable for map display, but in production processes, it often undergoes geometric thinning, cropping, and cross-tile segmentation, making it unsuitable as a data source for precise editing; multi-level vector tile pyramids, in order to adapt to different zoom levels, need to repeatedly store similar data at multiple zoom levels, leading to complexity in storage space, production tasks, update maintenance, and front-end scheduling logic.

[0003] In online editing scenarios, traditional MVT tiles still suffer from insufficient feature integrity. A line or polygon feature that crosses tile boundaries may be split into multiple tiles, and the browser can only obtain the cropped fragment. If the user performs node editing, topology verification, attribute write-back, or version control on this feature, additional cross-tile stitching and multi-copy synchronization are required, which can easily lead to loss of geometric accuracy, errors in topological relationships, and inconsistent editing status.

[0004] FlatGeobuf is a binary vector data format for geographic features, characterized by its small file size, high parsing efficiency, support for spatial indexing, and suitability for streaming. Using FlatGeobuf for static vector tile production balances the deployment convenience of static file services with the performance advantages of browser-side binary parsing. Furthermore, by organizing other tile formats through a single fixed source tile hierarchy and preserving complete feature geometry and unique feature identifiers within the tiles, it provides a consistent data foundation for high-performance rendering, feature querying, deduplication management, and online editing on the browser side.

[0005] Therefore, to address the aforementioned technical issues, it is necessary to provide a browser-based online editing and rendering method for GIS vector tiles. This method enables the original spatial data to be parsed, standardized, stored in a database, indexed, tiled in PostGIS, stored as static tiles in other formats, and published via an interface. The data can then be efficiently loaded by the browser according to the viewport range, and the browser can complete other format parsing, feature deduplication, memory cleanup, map rendering, and editing interactions. Summary of the Invention

[0006] To address the shortcomings of the existing technologies, the purpose of this invention is to provide a browser-based online editing and rendering method for GIS vector tiles, thereby solving the problems mentioned in the background section.

[0007] To solve the above-mentioned technical problems, the present invention adopts the following technical solution: This invention provides a browser-based online editing and rendering method for GIS vector tiles, comprising the following steps: Step 1: Parse the raw spatial data, read the graphic elements, spatial references, geometric types and business attribute information in the raw spatial data, and form the raw element set; Step 2: Perform data standardization on the original feature set, remove abnormal, redundant and empty data, and unify the coordinate system, feature specifications, geometric types, attribute fields and feature unique identifiers to form a standardized feature set; Step 3: Import the standardized feature set into the PostgreSQL database in batches, and build a spatial data table based on PostGIS to form a standardized database data source; Step 4: Create a spatial index for the geometric fields in the spatial data table, and establish the association between the feature unique identifier, business attribute fields, and spatial outsourcing scope; Step 5: Based on the preset tile scheme, use PostGIS to calculate the range of each tile and query the corresponding features within the spatial data table, and generate static vector tile resources in other formats in batches under the fixed source tile level; Step 6: Store other format static tile files to object storage, static file servers, or other file systems, and organize the storage path according to tile level, row and column numbers, and layer identifier; Step 7: Publish a standardized tile access interface based on other static tile resources, enabling the front end to request corresponding tiles of other formats through layer identifier, fixed source tile level, and tile row and column number; Step 8: The front-end map engine calculates the row and column numbers of the tiles to be loaded based on the current map viewport range and the fixed source tile level, calls the tile access interface to obtain tiles of other formats, and asynchronously parses, deduplicates, caches, and renders them on the browser side; Step 9: The browser manages loaded features based on their unique identifier, source tile, spatial bounding range, and editing status, supporting feature querying, highlighting, selection, editing, and clearing of features outside the viewport; Step 10: When spatial data is added, modified, or deleted, regenerate relevant tiles in other formats based on the tile range corresponding to the affected elements, update static tile resources and version information, and enable the front end to reload the updated tiles.

[0008] In one or more embodiments of the present invention, the specific method for parsing the original spatial data in step 1 includes: Obtain the raw spatial data to be published. The raw spatial data includes Shapefile, GeoJSON, GeoPackage conversion results, database export results, or spatial objects from business systems. Read the data source type, file encoding, spatial reference, layer name, geometry type, and attribute field structure of the raw data; Traverse each spatial record in the original data and extract the geometric objects and business attribute information of the spatial records; Perform basic identification on geometric objects to determine whether they belong to point, line, surface, multi-point, multi-line, multi-surface, or geometric set. Read the business attribute information by field and record the field name, field type, field value, whether it is empty, and business primary key; Read the coordinate reference information from the raw data. If the raw data lacks coordinate references, supplement the coordinate references according to the data source, business area, or user configuration. Generate a unique identifier for each original feature to track the original features during the cleaning, storage, and tiling processes; Data records that cannot be parsed, have empty geometry, have abnormal attribute structures, or have unrecognizable encodings are marked as exceptions.

[0009] In one or more embodiments of the present invention, the specific method for data standardization processing in step 2 includes: Empty data removal is performed on the original feature set, deleting records with empty geometry, empty attribute key fields, or missing business primary keys that cannot generate unique identifiers; Identify and process duplicate data, determine duplicate elements based on business primary key, geometric summary, attribute summary or spatial location, and retain valid versions; Check for abnormal geometry, which includes abnormal point coordinates, insufficient number of line nodes, unclosed surface loops, self-intersecting surfaces, duplicate nodes, and geometry outside the scope of business. Repairable abnormal geometry is repaired, including filling in the closure points of surface loops, removing consecutive duplicate nodes, and repairing invalid surface structures; unrepairable abnormal geometry is removed or transferred to the abnormal data list. Unify the coordinate system by converting the original coordinates into the target tile production coordinate system; Standardize the mapping of attribute fields, mapping field names from different data sources to uniform field names, and converting field values ​​to a uniform data type; The attribute fields are trimmed to retain those needed for tile rendering, feature querying, business display, and editing write-back, while temporary, redundant, and sensitive fields are removed. A globally unique element identifier, unique_id, is generated for each compliant element. For the same element that is redundantly written across tiles, all tile copies of the same element retain the same unique_id.

[0010] In one or more embodiments of the present invention, the specific method for data entry in step 3 includes: Create a spatial data table based on the layer type and field structure. The spatial data table should include at least the feature unique identifier field, geometry field, business attribute field, spatial scope field, data version field, and update time field. Write standardized feature sets into a spatial data table in batches. During the writing process, keep the geometry field consistent with the unique identifier's geometry type and the attribute field consistent with the database field type. Error logs are created for data records that fail to be written. The error logs include reasons such as field type mismatch, invalid geometry format, unique identifier conflict, and coordinate transformation failure. Generate a data batch number or version number for successfully entered data so that subsequent tile generation can be associated with the specific data version; Perform validity checks on the geometric fields after they are entered into the database, and use PostGIS geometric functions for secondary verification or repair. The number of features in the statistical layer, spatial extent, geometric type distribution, and field completeness are used as input parameters for the tile production task.

[0011] In one or more embodiments of the present invention, step 4, the specific method for constructing the spatial index includes: Create GiST or SP-GiST spatial indexes on the geometry fields of the spatial data table; Create a regular index or a unique index on the feature's unique identifier field; Create attribute indexes for commonly used filter attribute fields, which include data category, administrative region, business status, and update time. Perform statistical updates on the spatial data table so that the database query optimizer can correctly select spatial indexes; Pre-calculate the tile production scope, tile level, and data coverage to determine the total number of tiles to be produced and the number of elements that each tile may hit. When incremental updates are required, a reverse mapping table from feature identifiers to tile keys is established to record the tileKey set to which each unique_id belongs.

[0012] In one or more embodiments of the present invention, step 5, specifically the method for fixing hierarchical tiles based on other PostGIS formats, includes: Determine the tile production plan, which includes layer identifiers, fixed source tile level (sourceZoom), tile coordinate system, tile coverage area, reserved attribute fields, tile row and column number calculation rules, output path, and version number; The x and y row and column number ranges of the tiles to be produced are calculated based on the data coverage and the fixed source tile level (sourceZoom). For each tile to be produced, calculate the spatial extent (tileExtent) of the tile in the target coordinate system according to the tile production plan; Based on the PostGIS spatial index, query the features that intersect with tileExtent from the spatial data table; Perform field pruning on the retrieved elements, retaining only the attribute fields needed for front-end rendering, querying, editing, and status management; Instead of writing clipped feature data based on tile boundaries, write the complete geometry and attributes of each hit feature to the current tile. For features that span multiple tile boundaries, the complete geometry and attributes of the features that span multiple tile boundaries are redundantly written to all intersecting tiles, keeping the unique_id unchanged, and adding the tag attribute for repeated writing; Encode the elements within the current tile according to the standard FlatGeobuf structure to form static vector tiles with ". other formats" as the suffix; If the current tile has no features, generate an empty tile tag, an empty file of other format, or do not generate a file, and record the empty tile status in the metadata; Record the tileKey, number of features, file size, data version, generation time, and spatial range of the tile file; If incremental updates are enabled, the relationship between each unique_id within a tile and the current tileKey is written to the reverse mapping table.

[0013] In one or more embodiments of the present invention, step 8, the specific method for loading and parsing other format tiles at the front end includes: When the front-end initializes the map layer, it reads the layer configuration to obtain the tile URL template, fixed source tile level sourceZoom, data projection, map projection, minimum display level, maximum display level, and style rules. When the map is panned, zoomed, or initialized, obtain the current map viewport extent; Based on the map projection and the fixed source tile level sourceZoom, the current viewport extent is converted into a tileRange under the fixed source tile level sourceZoom to obtain the x and y row and column number range of the tiles to be loaded; For each tileKey in the tileRange, determine whether it has been loaded, is being loaded, or has been marked as an empty tile; For unloaded tiles, call the tile access interface to request the corresponding .other format file; Send the requested binary data in other formats to the WebWorker or Worker thread pool for parsing; WebWorker or Worker thread pool parses feature geometry and attributes in other format files, converts feature geometry and attributes into structured feature objects that can be processed by the front end, and performs coordinate projection transformation; WebWorker or Worker thread pool calculates or retains the bounding box for each feature and returns the parsing results to the main thread; The main thread converts the parsed results into Feature objects that the map rendering engine can recognize; The main thread injects unique_id, tileKey, and bbox metadata into the Feature object; The front end removes duplicate features across tiles based on the unique_id and duplicate tag fields, and existing features are not added again. The front end adds new features to the map data source in batches. The front end triggers a map layer redraw, completing the visualization of other vector tiles in the current viewport.

[0014] In one or more embodiments of the present invention, step 9, the specific method for managing loaded elements on the browser side includes: Listen for the map view change completion event; Debouncing is applied to view change events; Calculate the tileExtent or visible space range that should be retained based on the latest viewport extent; Iterate through the loaded Features in the current front-end data source; Read the bounding box of each tile and perform a fast intersection check with the currently visible space. If the bbox of a tile does not intersect with the currently visible space, then the tile is determined to have moved out of the viewport; Remove tiles that have been moved out of the viewport from the front-end data source; Simultaneously clean up the memory records of the featureCodes, featureToTileMap, and tileKey association tables; Tiles that remain within the viewport should be retained; After cleaning, continue loading tiles that have not yet been loaded within the new viewport range.

[0015] In one or more embodiments of the present invention, the specific method for regenerating relevant tiles in other formats when spatial data is added, modified, or deleted in step 10 includes: Capture events related to the addition, modification, or deletion of elements in the business system; For modifying or deleting features, the reverse mapping table from the feature to the tile is queried based on the unique_id to obtain all the tileKeys of the feature; For new features, calculate the set of tileKeys that the new feature should cover based on the bbox of the new feature and the fixed source tile level sourceZoom; Merge the above tileKeys into a set of affected tiles; For each affected tile, recalculate the tileExtent of the affected tile; Re-query all valid features intersecting with tileExtent from the PostGIS spatial data table; Regenerate the tile's other format files according to the full geometric redundancy write rules; Update the corresponding tile file in the object store or static file server; Update the tile version number, layer version number, and the reverse mapping relationship from feature to tile; When the frontend receives a version change, refresh notification, or requests tiles again, it invalidates the corresponding tileKey in the local cache and reloads the updated tiles in other formats.

[0016] In one or more embodiments of the present invention, when an initial release, large-scale data update, field structure change, or periodic maintenance occurs, a new tile production version is created, the range of tiles to be generated is recalculated based on the current PostGIS spatial data table, old version tile files are deleted or archived, all tiles to be produced are traversed by sourceZoom according to a fixed source tile level, PostGIS spatial query and other format encoding are performed on each tile, all generated other format tiles are written to the new version storage path, layer metadata, tile version number, and access address template are updated, and the front end clears the old version cache after detecting the layer version change and re-requests tiles according to the new version.

[0017] The beneficial effects of this invention are as follows: 1. By using a fixed sourceZoom as the production level for other tile formats, the server only produces one set of other tile formats at this level. The front end maps the current viewport range to the tile coordinate range of this sourceZoom level at any map zoom level. This can reduce the problem of duplicate storage and multi-level updates caused by multi-level tile pyramids, and at the same time ensure that editing operations always face the same set of source tile data, reducing the difficulty of cross-level state synchronization. 2. For features that cross tile boundaries, write the complete geometry and attributes of the feature to all intersecting tiles, instead of writing them to the clipped local features. All duplicate features in all tiles retain the unique_id, ensuring that the front end reads complete features from any intersecting tile, which can be directly used for rendering, querying and editing, avoiding geometric incompleteness issues caused by cross-tile splicing and MVT clipping. 3. By adding duplicate marker attributes during generation, the front-end renders features by using unique_id and marker attributes to identify and remove duplicates. The already loaded unique_id will not be added again. The hidden, selected, highlighted and edit states are also maintained in units of unique_id, which solves the problem of repeated rendering caused by redundant writing, while retaining the editing advantages of complete geometry. 4. After the front-end obtains tiles in other formats, the binary parsing, coordinate transformation, and bounding box calculation are handled by WebWorkers. The main thread is only responsible for scheduling, batch adding, and map rendering. This avoids blocking map dragging, zooming, and interactive operations due to other format parsing, thus improving browser smoothness. 5. Based on the intersection of the tile's bounding box with the current visible area, features outside the viewport are cleared from the front-end data source and memory index to prevent the infinite accumulation of loaded features and keep the browser's memory usage stable during the browsing of massive vector data.

[0018] 6. When a feature is modified or deleted, the affected tiles can be quickly located and only those tiles can be regenerated. New features are added by calculating their covering tiles through bbox, which reduces the cost of data updates and enables static tiles of other formats to support daily business data changes. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 This is a flowchart of a browser-based GIS vector tile online editing and rendering method according to an embodiment of the present invention. Detailed Implementation

[0021] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0022] like Figure 1 As shown, an embodiment of the present invention provides a browser-based online editing and rendering method for GIS vector tiles, comprising the following steps: Step 1: Parse the raw spatial data, read the graphic elements, spatial references, geometric types and business attribute information in the raw spatial data, and form the raw element set.

[0023] Step 2: Perform data standardization on the original feature set, remove abnormal, redundant and empty data, and unify the coordinate system, feature specifications, geometric types, attribute fields and feature unique identifiers to form a standardized feature set.

[0024] Step 3: Import the standardized feature set into the PostgreSQL database in batches, and build a spatial data table based on PostGIS to form a standardized database data source.

[0025] Step 4: Create a spatial index for the geometric fields in the spatial data table, and establish the association between the feature unique identifier, business attribute fields, and spatial outsourcing scope.

[0026] Step 5: Based on the preset tile scheme, use PostGIS to calculate the range of each tile and query the corresponding features in the spatial data table, and generate static vector tile resources in other formats in batches under the fixed source tile level.

[0027] Step 6: Store other format static tile files to object storage, static file servers, or other file systems, and organize the storage path according to tile level, row and column numbers, and layer identifier.

[0028] Step 7: Publish a standardized tile access interface based on other static tile resources, enabling the front end to request corresponding tiles of other formats through layer identifier, fixed source tile level, and tile row and column number.

[0029] Step 8: The front-end map engine calculates the row and column numbers of the tiles to be loaded based on the current map viewport range and the fixed source tile level, calls the tile access interface to obtain tiles of other formats, and asynchronously parses, deduplicates, caches, and renders them on the browser side.

[0030] Step 9: The browser manages loaded features based on the feature's unique identifier, source tile, spatial bounding range, and editing status, supporting feature querying, highlighting, selection, editing, and cleanup of features outside the viewport.

[0031] Step 10: When spatial data is added, modified, or deleted, regenerate relevant tiles in other formats based on the tile range corresponding to the affected elements, update static tile resources and version information, and enable the front end to reload the updated tiles.

[0032] Furthermore, in step 1, the specific methods for parsing the original spatial data include: Obtain the raw spatial data to be published. The raw spatial data includes Shapefile, GeoJSON, GeoPackage conversion results, database export results, or spatial objects from business systems.

[0033] Read the data source type, file encoding, spatial reference, layer name, geometry type, and attribute field structure of the raw data.

[0034] Traverse each spatial record in the original data and extract the geometric objects and business attribute information of the spatial records.

[0035] Perform basic identification on geometric objects to determine whether they belong to point, line, surface, multi-point, multi-line, multi-surface, or set geometry.

[0036] Read the business attribute information by field, and record the field name, field type, field value, whether it is empty, and business primary key.

[0037] Read the coordinate reference information from the raw data. If the raw data lacks coordinate references, supplement the coordinate references according to the data source, business area, or user configuration.

[0038] A unique identifier is generated for each original feature to track it during the cleaning, storage, and tiling processes.

[0039] Data records that cannot be parsed, have empty geometry, have abnormal attribute structures, or have unrecognizable encodings are marked as exceptions.

[0040] Furthermore, in step 2, the specific methods for data standardization include: Empty data is removed from the original feature set, including records with empty geometry, empty attribute key fields, or missing business primary keys that cannot generate unique identifiers.

[0041] Identify and process duplicate data, determine duplicate elements based on business primary key, geometric summary, attribute summary or spatial location, and retain valid versions.

[0042] Check for abnormal geometry, including abnormal point coordinates, insufficient number of line nodes, unclosed surface loops, self-intersecting surfaces, duplicate nodes, and geometry outside the scope of business.

[0043] Repairable anomalous geometry is repaired, including filling in closed loop points, removing consecutive duplicate nodes, and repairing invalid surface structures. Unrepairable anomalous geometry is either removed or added to the anomalous data list.

[0044] The coordinate system is unified, and the original coordinates are converted into the target tile production coordinate system.

[0045] Standardize the mapping of attribute fields, mapping field names from different data sources to uniform field names, and converting field values ​​to a uniform data type.

[0046] The attribute fields are trimmed to retain those needed for tile rendering, feature querying, business display, and editing write-back, while temporary, redundant, and sensitive fields are removed.

[0047] A globally unique element identifier, unique_id, is generated for each compliant element. For the same element that is redundantly written across tiles, all tile copies of the same element retain the same unique_id.

[0048] Furthermore, in step 3, the specific methods for data entry include: Create a spatial data table based on the layer type and field structure. The spatial data table should include at least the feature unique identifier field, geometric field, business attribute field, spatial scope field, data version field, and update time field.

[0049] Write standardized feature sets into a spatial data table in batches. During the writing process, ensure that the geometry field and the unique identifier are of the same type, and that the attribute field and the database field are of the same type.

[0050] Error logs are generated for data records that fail to be written. Error logs include reasons such as field type mismatch, invalid geometry format, unique identifier conflict, and coordinate transformation failure.

[0051] Generate a batch number or version number for successfully imported data so that subsequent tile generation can be associated with the specific data version.

[0052] Perform validity checks on the geometric fields after they are entered into the database, and use PostGIS geometric functions for secondary verification or repair.

[0053] The number of features in the statistical layer, spatial extent, geometric type distribution, and field completeness are used as input parameters for the tile production task.

[0054] Furthermore, specific methods for constructing spatial indexes include: Create GiST or SP-GiST spatial indexes on the geometry fields of the spatial data table.

[0055] Create a regular index or a unique index on the feature's unique identifier field.

[0056] Create attribute indexes for commonly used filter attribute fields, which include data category, administrative region, business status, and update time.

[0057] Performing statistical updates on the spatial data table enables the database query optimizer to correctly select spatial indexes.

[0058] Pre-calculate the tile production scope, tile level, and data coverage to determine the total number of tiles to be produced and the number of elements that each tile may hit.

[0059] When incremental updates are required, a reverse mapping table from feature identifiers to tile keys is established to record the tileKey set to which each unique_id belongs.

[0060] Furthermore, in step 5, specific methods for fixing hierarchical tiles in other PostGIS formats include: The tile production scheme is determined, which includes layer identifiers, fixed source tile level (sourceZoom), tile coordinate system, tile coverage area, reserved attribute fields, tile row and column number calculation rules, output path, and version number.

[0061] The x and y row and column number ranges of the tiles to be produced are calculated based on the data coverage and the fixed source tile level (sourceZoom).

[0062] For each tile to be produced, calculate the spatial extent (tileExtent) of the tile in the target coordinate system according to the tile production plan.

[0063] Based on the PostGIS spatial index, query the features that intersect with tileExtent from the spatial data table.

[0064] Perform field pruning on the retrieved elements, retaining only the attribute fields needed for front-end rendering, querying, editing, and status management.

[0065] Instead of writing clipped feature data based on tile boundaries, write the complete geometry and attributes of each hit feature to the current tile.

[0066] For features that span multiple tile boundaries, the complete geometry and attributes of the features that span multiple tile boundaries are redundantly written to all intersecting tiles, keeping the unique_id unchanged, and adding the tag attribute for repeated writing.

[0067] The elements within the current tile are encoded according to the standard FlatGeobuf structure, forming static vector tiles with ". other formats" as the suffix.

[0068] If the current tile has no features, an empty tile tag, an empty file of other format, or no file will be generated, and the empty tile status will be recorded in the metadata.

[0069] Record the tileKey, number of features, file size, data version, generation time, and spatial range of the tile file.

[0070] If incremental updates are enabled, the relationship between each unique_id within a tile and the current tileKey is written to the reverse mapping table.

[0071] Furthermore, in step 8, the specific methods for loading and parsing other format tiles on the front end include: When the front-end initializes the map layer, it reads the layer configuration to obtain the tile URL template, fixed source tile level sourceZoom, data projection, map projection, minimum display level, maximum display level, and style rules.

[0072] When the map is panned, zoomed, or initialized, obtain the current map viewport extent.

[0073] Based on the map projection and the fixed source tile level sourceZoom, the current viewport extent is converted into a tileRange under the fixed source tile level sourceZoom to obtain the x and y row and column number range of the tiles to be loaded.

[0074] For each tileKey in the tileRange, determine whether it has been loaded, is being loaded, or has been marked as an empty tile.

[0075] For unloaded tiles, call the tile access interface to request the corresponding .other format file.

[0076] Send the requested binary data in other formats to a WebWorker or Worker thread pool for parsing.

[0077] WebWorker or Worker thread pool parses feature geometry and attributes in other format files, converts feature geometry and attributes into structured feature objects that can be processed by the front end, and performs coordinate projection transformation.

[0078] WebWorker or Worker thread pool calculates or retains the bounding box for each feature and returns the parsed results to the main thread.

[0079] The main thread converts the parsed results into Feature objects that the map rendering engine can recognize.

[0080] The main thread injects unique_id, tileKey, and bbox metadata into the Feature object.

[0081] The front end removes duplicate features across tiles based on the unique_id and duplicate tag fields, and existing features are not added again.

[0082] The front end adds new features to the map data source in batches.

[0083] The front end triggers a map layer redraw, completing the visualization of other vector tiles in the current viewport.

[0084] Furthermore, in step 9, the specific methods for managing loaded elements on the browser side include: Listen for the map view change completion event.

[0085] Debouncing is applied to view change events.

[0086] Calculate the current tileExtent or visible space extent to be retained based on the latest viewport extent.

[0087] Iterate through the loaded Features in the current front-end data source.

[0088] Read the bounding box of each tile and perform a fast intersection check with the currently visible space.

[0089] If the bbox of a tile does not intersect with the currently visible space, then the tile is determined to have moved out of the viewport.

[0090] Remove tiles that are moved out of the viewport from the front-end data source.

[0091] Simultaneously clean up the memory records of the featureCodes, featureToTileMap, and tileKey association tables.

[0092] Tiles that are still within the viewport are retained.

[0093] After cleaning, continue loading tiles that have not yet been loaded within the new viewport range.

[0094] Furthermore, in step 10, the specific methods for regenerating relevant tiles in other formats when spatial data is added, modified, or deleted include: Capture events related to the addition, modification, or deletion of elements in the business system.

[0095] For modifying or deleting features, the inverse mapping table from the feature to the tile is queried based on the unique_id to obtain all the tile keys of the feature.

[0096] For new features, calculate the set of tileKeys that the new feature should cover based on the new feature's bounding box and the fixed source tile level sourceZoom.

[0097] Merge the above tileKeys into a set of affected tiles.

[0098] For each affected tile, recalculate the tileExtent of the affected tile.

[0099] Re-query the PostGIS spatial data table for all valid features that intersect with tileExtent.

[0100] Regenerate the tile's other format files according to the full geometric redundancy write rule.

[0101] Update the corresponding tile file in object storage or static file server.

[0102] Update the tile version number, layer version number, and the reverse mapping relationship from feature to tile.

[0103] When the frontend receives a version change, refresh notification, or requests tiles again, it invalidates the corresponding tileKey in the local cache and reloads the updated tiles in other formats.

[0104] Furthermore, when an initial release, large-scale data update, field structure change, or periodic maintenance occurs, a new tile production version is created. The required tile range is recalculated based on the current PostGIS spatial data table. Old version tile files are deleted or archived. All tiles to be produced are traversed by sourceZoom according to the fixed source tile level. PostGIS spatial queries and other format encodings are performed on each tile. All generated tiles in other formats are written to the new version storage path. Layer metadata, tile version numbers, and access address templates are updated. After the front end detects a layer version change, the old version cache is cleared, and tiles are re-requested according to the new version.

[0105] Compared with existing technologies, the browser-based GIS vector tile online editing and rendering method of the present invention uses a fixed sourceZoom as the production level for other tile formats. The server only produces one set of other format tiles at this level, and the front end maps the current viewport range to the tile coordinate range of this sourceZoom level at any map zoom level. This reduces the problems of redundant storage and multi-level updates caused by multi-level tile pyramids, while ensuring that editing operations always target the same set of source tile data, reducing the difficulty of cross-level state synchronization.

[0106] For features that cross tile boundaries, this method writes the complete geometry and attributes of the feature to all intersecting tiles, rather than to the clipped local feature. Duplicate features in all tiles retain their unique_id, ensuring that the front-end reads complete features from any intersecting tile, which can be directly used for rendering, querying, and editing, avoiding geometric incompleteness issues caused by cross-tile stitching and MVT clipping.

[0107] Since cross-tile features may exist as complete copies across multiple tiles, a duplicate marker attribute is added during generation. During front-end rendering, features are identified and deduplicated using the unique_id and marker attribute. Already loaded unique_ids are not added again, and the hidden, selected, highlighted, and edit states are also maintained in units of unique_id. This solves the problem of redundant rendering caused by redundant writing, while preserving the editing advantages of complete geometry.

[0108] After the front-end obtains tiles in other formats, the binary parsing, coordinate transformation, and bounding box calculation are handled by WebWorker. The main thread is only responsible for scheduling, batch adding, and map rendering, which avoids blocking map dragging, zooming, and interactive operations by parsing other formats, thus improving the smoothness of the browser.

[0109] When the front-end map viewport changes, this method determines the intersection between the tile's bounding box and the current visible range, and cleans up features outside the viewport from the front-end data source and memory index, preventing the infinite accumulation of loaded features and keeping the browser's memory usage stable during the browsing of massive vector data.

[0110] The server maintains a reverse mapping relationship from unique_id to tileKey. When a feature is modified or deleted, the affected tiles can be quickly located and only these tiles can be regenerated. New features are added by calculating their covering tiles through bounding boxes, reducing data update costs and enabling static tiles of other formats to support daily business data changes.

[0111] Obviously, the above-described embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention. Thus, if these modifications and variations of the present invention fall within the scope of the claims of the present invention and their equivalents, the present invention also intends to include these modifications and variations.

Claims

1. A browser-based online editing and rendering method for GIS vector tiles, characterized in that, Includes the following steps: Step 1: Parse the raw spatial data, read the graphic elements, spatial references, geometric types and business attribute information in the raw spatial data, and form the raw element set; Step 2: Perform data standardization on the original feature set, remove abnormal, redundant and empty data, and unify the coordinate system, feature specifications, geometric types, attribute fields and feature unique identifiers to form a standardized feature set; Step 3: Import the standardized feature set into the PostgreSQL database in batches, and build spatial data tables based on PostGIS to form a standardized database data source; Step 4: Create a spatial index for the geometric fields in the spatial data table, and establish the association between the feature unique identifier, business attribute fields, and spatial outsourcing scope; Step 5: Based on the preset tile scheme, use PostGIS to calculate the range of each tile and query the corresponding features within the spatial data table, and generate static vector tile resources in other formats in batches under the fixed source tile level; Step 6: Store other format static tile files to object storage, static file servers, or other file systems, and organize the storage path according to tile level, row and column numbers, and layer identifier; Step 7: Publish a standardized tile access interface based on other static tile resources, enabling the front end to request corresponding tiles of other formats through layer identifier, fixed source tile level, and tile row and column number; Step 8: The front-end map engine calculates the row and column numbers of the tiles to be loaded based on the current map viewport range and the fixed source tile level, calls the tile access interface to obtain tiles of other formats, and asynchronously parses, deduplicates, caches, and renders them on the browser side; Step 9: The browser manages loaded features based on their unique identifier, source tile, spatial bounding range, and editing status, supporting feature querying, highlighting, selection, editing, and clearing features outside the viewport; Step 10: When spatial data is added, modified, or deleted, regenerate relevant tiles in other formats based on the tile range corresponding to the affected elements, update static tile resources and version information, and enable the front end to reload the updated tiles.

2. The browser-based online editing and rendering method for GIS vector tiles as described in claim 1, characterized in that, In step 1, the specific methods for parsing the raw spatial data include: Obtain the raw spatial data to be published. The raw spatial data includes Shapefile, GeoJSON, GeoPackage conversion results, database export results, or spatial objects from business systems. Read the data source type, file encoding, spatial reference, layer name, geometry type, and attribute field structure of the raw data; Traverse each spatial record in the original data and extract the geometric objects and business attribute information of the spatial records; Perform basic identification on geometric objects to determine whether they belong to point, line, surface, multi-point, multi-line, multi-surface, or geometric set. Read the business attribute information by field and record the field name, field type, field value, whether it is empty, and business primary key; Read the coordinate reference information from the raw data. If the raw data lacks coordinate references, supplement the coordinate references according to the data source, business area, or user configuration. Generate a unique identifier for each original feature to track the original features during the cleaning, storage, and tiling processes; Data records that cannot be parsed, have empty geometry, have abnormal attribute structures, or have unrecognizable encodings are marked as exceptions.

3. The browser-based online editing and rendering method for GIS vector tiles as described in claim 1, characterized in that, In step 2, the specific methods for data standardization include: Empty data removal is performed on the original feature set, deleting records with empty geometry, empty attribute key fields, or missing business primary keys that cannot generate unique identifiers; Identify and process duplicate data, determine duplicate elements based on business primary key, geometric summary, attribute summary or spatial location, and retain valid versions; Check for abnormal geometry, which includes abnormal point coordinates, insufficient number of line nodes, unclosed surface loops, self-intersecting surfaces, duplicate nodes, and geometry outside the scope of business. Repairable abnormal geometry is repaired, including filling in the closure points of surface loops, removing consecutive duplicate nodes, and repairing invalid surface structures; unrepairable abnormal geometry is removed or transferred to the abnormal data list. Unify the coordinate system by converting the original coordinates into the target tile production coordinate system; Standardize the mapping of attribute fields, mapping field names from different data sources to uniform field names, and converting field values ​​to a uniform data type; The attribute fields are trimmed to retain those needed for tile rendering, feature querying, business display, and editing write-back, while temporary, redundant, and sensitive fields are removed. A globally unique element identifier, unique_id, is generated for each compliant element. For the same element that is redundantly written across tiles, all tile copies of the same element retain the same unique_id.

4. The browser-based online editing and rendering method for GIS vector tiles as described in claim 1, characterized in that, In step 3, the specific methods for data entry include: Create a spatial data table based on the layer type and field structure. The spatial data table should include at least the feature unique identifier field, geometry field, business attribute field, spatial scope field, data version field, and update time field. Write standardized feature sets into a spatial data table in batches. During the writing process, keep the geometry field consistent with the unique identifier's geometry type and the attribute field consistent with the database field type. Error logs are created for data records that fail to be written. The error logs include reasons such as field type mismatch, invalid geometry format, unique identifier conflict, and coordinate transformation failure. Generate a data batch number or version number for successfully entered data so that subsequent tile generation can be associated with the specific data version; Perform validity checks on the geometric fields after they are entered into the database, and use PostGIS geometric functions for secondary verification or repair. The number of features in the statistical layer, spatial extent, geometric type distribution, and field completeness are used as input parameters for the tile production task.

5. A browser-based online editing and rendering method for GIS vector tiles as described in claim 3, characterized in that, In step 4, the specific methods for constructing the spatial index include: Create GiST or SP-GiST spatial indexes on the geometry fields of the spatial data table; Create a regular index or a unique index on the feature's unique identifier field; Create attribute indexes for commonly used filter attribute fields, which include data category, administrative region, business status, and update time. Perform statistical updates on the spatial data table so that the database query optimizer can correctly select spatial indexes; Pre-calculate the tile production scope, tile level, and data coverage to determine the total number of tiles to be produced and the number of elements that each tile may hit. When incremental updates are required, a reverse mapping table from feature identifiers to tile keys is established to record the tileKey set to which each unique_id belongs.

6. A browser-based online editing and rendering method for GIS vector tiles as described in claim 3, characterized in that, In step 5, specific methods for fixing hierarchical tiles in other PostGIS formats include: Determine the tile production plan, which includes layer identifiers, fixed source tile level (sourceZoom), tile coordinate system, tile coverage area, reserved attribute fields, tile row and column number calculation rules, output path, and version number; The x and y row and column number ranges of the tiles to be produced are calculated based on the data coverage and the fixed source tile level (sourceZoom). For each tile to be produced, calculate the spatial extent (tileExtent) of the tile in the target coordinate system according to the tile production plan; Based on the PostGIS spatial index, query the features that intersect with tileExtent from the spatial data table; Perform field pruning on the retrieved elements, retaining only the attribute fields needed for front-end rendering, querying, editing, and status management; Instead of writing clipped feature data based on tile boundaries, write the complete geometry and attributes of each hit feature to the current tile. For features that span multiple tile boundaries, the complete geometry and attributes of the features that span multiple tile boundaries are redundantly written to all intersecting tiles, keeping the unique_id unchanged, and adding the tag attribute for repeated writing; Encode the elements within the current tile to form static vector tiles with other format suffixes; If the current tile has no features, generate an empty tile tag, an empty file of other format, or do not generate a file, and record the empty tile status in the metadata; Record the tileKey, number of features, file size, data version, generation time, and spatial range of the tile file; If incremental updates are enabled, the relationship between each unique_id within a tile and the current tileKey is written to the reverse mapping table.

7. A browser-based online editing and rendering method for GIS vector tiles as described in claim 3, characterized in that, In step 8, the specific methods for loading and parsing other format tiles on the front end include: When the front-end initializes the map layer, it reads the layer configuration to obtain the tile URL template, fixed source tile level sourceZoom, data projection, map projection, minimum display level, maximum display level, and style rules. When the map is panned, zoomed, or initialized, obtain the current map viewport extent; Based on the map projection and the fixed source tile level sourceZoom, the current viewport extent is converted into a tileRange under the fixed source tile level sourceZoom to obtain the x and y row and column number range of the tiles to be loaded; For each tileKey in the tileRange, determine whether it has been loaded, is being loaded, or has been marked as an empty tile; For unloaded tiles, call the tile access interface to request the corresponding file in another format. Send the requested binary data in other formats to the WebWorker or Worker thread pool for parsing; WebWorker or Worker thread pool parses feature geometry and attributes in other format files, converts feature geometry and attributes into structured feature objects that can be processed by the front end, and performs coordinate projection transformation; WebWorker or Worker thread pool calculates or retains the bounding box for each feature and returns the parsing results to the main thread; The main thread converts the parsed results into Feature objects that the map rendering engine can recognize; The main thread injects unique_id, tileKey, and bbox metadata into the Feature object; The front end removes duplicate features across tiles based on the unique_id and duplicate tag fields, and existing features are not added again. The front end adds new features to the map data source in batches. The front end triggers a map layer redraw, completing the visualization of other vector tiles in the current viewport.

8. A browser-based online editing and rendering method for GIS vector tiles as described in claim 1, characterized in that, In step 9, the specific methods for managing loaded elements on the browser side include: Listen for map view change completion events; Debouncing is applied to view change events; Calculate the tileExtent or visible space range that should be retained based on the latest viewport extent; Iterate through the loaded Features in the current front-end data source; Read the bounding box of each tile and perform a fast intersection check with the currently visible space. If the bbox of a tile does not intersect with the currently visible space, then the tile is determined to have moved out of the viewport; Remove tiles that have been moved out of the viewport from the front-end data source; Simultaneously clean up the memory records of the featureCodes, featureToTileMap, and tileKey association tables; Tiles that remain within the viewport should be retained; After cleaning, continue loading tiles that have not yet been loaded within the new viewport range.

9. A browser-based online editing and rendering method for GIS vector tiles as described in claim 3, characterized in that, In step 10, the specific methods for regenerating relevant tiles in other formats when spatial data is added, modified, or deleted include: Capture events related to the addition, modification, or deletion of elements in the business system; For modifying or deleting features, the reverse mapping table from the feature to the tile is queried based on the unique_id to obtain all the tileKeys of the feature; For new features, calculate the set of tileKeys that the new feature should cover based on the bbox of the new feature and the fixed source tile level sourceZoom; Merge the above tileKeys into a set of affected tiles; For each affected tile, recalculate the tileExtent of the affected tile; Re-query all valid features intersecting with tileExtent from the PostGIS spatial data table; Regenerate the tile's other format files according to the full geometric redundancy write rules; Update the corresponding tile file in the object store or static file server; Update the tile version number, layer version number, and the reverse mapping relationship from feature to tile; When the frontend receives a version change, refresh notification, or requests tiles again, it invalidates the corresponding tileKey in the local cache and reloads the updated tiles in other formats.

10. A browser-based online editing and rendering method for GIS vector tiles as described in claim 1, characterized in that, When an initial release, large-scale data update, field structure change, or periodic maintenance occurs, a new tile production version is created. The required tile range is recalculated based on the current PostGIS spatial data table. Old version tile files are deleted or archived. All tiles to be produced are traversed by sourceZoom according to the fixed source tile level. PostGIS spatial queries and other format encodings are performed on each tile. All generated tiles in other formats are written to the new version storage path. Layer metadata, tile version number, and access address template are updated. After the front end detects the layer version change, the old version cache is cleared, and tiles are re-requested according to the new version.

Images