The copyright of the article is shared by the author Li Xiaohui and the blog garden. If reprinting, please indicate the source in an obvious place: http://www.cnblogs.com/naaoveGIS/

1. Background

In the last blog I mentioned two advantages of grid coding:

Turns a query of two integer (geographic) fields into a query of one integer field
Through reasonable grid division, multiple conditional queries (four query conditions formed by upper left and lower right) can be optimized into one query condition in most cases (equal to one grid code)

However, in actual projects, is this optimization effect obvious?

2. Actual test

2.1 Test with tables of different sizes

Query SQL by constructing a range

select * from tc_geo_address a where a.coordinate_x>504625 and a.coordinate_x<504825 and a.coordinate_y>309858 and a.coordinate_y<310058

Querying SQL by Geocoding

select * from tc_geo_address a where a.grid_code=3300000110

The index comparison results are established on coordinate_x, coordinate_y and grid_code:

table size	range query	single encoded query
2K bars	0.002S	0.002S
17W strips	1.08S	0.84S

2.2 Summary

Single-encoded queries are only advantageous if the table is large enough
May be less efficient than range queries when multiple geocodes make up a combined query

3. Cache optimization (when the content of the query table is fixed, such as point of interest query)

3.1 Why can query cache be enabled?

The principle of grid coding: the map is divided into grids, and the number of grids is fixed when the map range and cutting size are certain.
The principle of grid query: All grid codes covered by the query are constructed for the XY and range of the query, and finally it becomes a grid-coded query.
Conclusion: Although the XY coordinates cannot be cached (constantly changing), the grid code corresponding to its resolution is fixed, and the query result corresponding to each grid code is also fixed. So we can cache the results of grid-encoded queries.

3.2 Implementation of the scheme

3.2.1 Grid query result cache

To improve cache hits, we cache with a single grid encoding as the primary key:

/***
     * 通过传入网格编码进行搜索，提供缓存功能
 * @param gridcodefield  * @param gridcode  * @return  */ @Cacheable(value="cacheOneHour",key="'getaddcode'+#gridcode+#gridcodefield") public List<GeoAddress> getAddressBySingleCode(String gridcodefield,String gridcode){ try{ if(gridcodefield.equals("")){ gridcodefield="Grid_Code"; } String sql=gisConfigManager.getSQL("GeoCode.GeoCodeReverseGridCode"); sql+=" where "+gridcodefield+"="+gridcode; return jdbcTemplate.query(sql,new Object[]{},new DataRowMapper(GeoAddress.class)); }catch(Exception e){ return null; } }

3.2.2 Query range block grid request

List<Long> searchResult=GridCodeUtils.GridCodeSearch(OperConst.MapBounds.get(0),
    			OperConst.MapBounds.get(1), x, y, gridsize, gridsize, radius); if(searchResult==null){ LogUtils.error("查询地理编码结果为空！", logger,null); return null; } //分开利用code查询是为了充分制造缓存命中 for(int i=0;i<searchResult.size();i++){ List<GeoAddress> temAddList=cacheManager.getAddressBySingleCode(gridHashField,searchResult.get(i).toString()); if(temAddList!=null&&temAddList.size()>0){ list.addAll(temAddList); } }

4. If there is an attribute query condition attached? (when table content is fixed)

The above is just to filter the query according to the coordinates. What if it is accompanied by further conditional filtering of the query results? Such situations are discussed in several cases.

4.1 The filter conditions are very fixed - included in the cache

For example, the query condition is always a video that is 500M away from the current range.
Then it can also be included in the caching mechanism for encoded queries.

4.2 Normalized changes in filter conditions

4.2.1 There are not many query results corresponding to grid (without attribute filtering) - first grid query cache, and then filter results

For example: the query conditions will change constantly, it may be a video within 500M, it may be a manhole cover within 500M, and so on. You can query and cache the grid code first, and then filter the query results according to the query conditions:

//因为address经常变化，不利于缓存，所以用代码进行过滤
    	if(address!=""){//查询条件过滤
    		List<GeoAddress> addlist=new ArrayList<GeoAddress>(); for(int i=0;i<list.size();i++){ GeoAddress addressObj=list.get(i); if(addressObj.getAddress().contains(address)){ addlist.add(addressObj); } } }

4.2.1 There are many query results corresponding to grids (without attribute filtering)

The query table can be reconstructed: change the large table to a small table, so that the grid query results are less, then the above solutions are still available.
Query table cannot be reconstructed: live sql query.

5. When the content of the query table is constantly updated

At this time, the caching mechanism may cause the data to be not up-to-date, and sql is still required to query.

6. Auxiliary coding tools

When we want to use the encoding mechanism and the data stored is only XY without encoding values, here we have developed a geocoding assignment tool:

　　　　　　　　　　　　　　　　　　　　-----Welcome to reprint, but retain the copyright, please indicate the source in the obvious place: http://www.cnblogs.com/naaoveGIS/

If you think this article really helped you, you can scan WeChat for a small reward and encouragement, thank you ^_^

Further exploration of grid coding query scheme in practical projects