shp2mysql 을 개발하여 GIS 데이터를 가져올 수 있게 되었으므로, 다시 MySQL의 GIS 기능에 대한 요망을 정리해 보았다.

shp2mysql에 대해서는 이쪽
htps : // 코 m / 미야 치 / ms / b4 810b3

대상 MySQL은 8.0.16 시점. 최신 8.0.18에서도 아마 같은 상황.

개요

대응하고 싶은 우선순위.

ST_Intersects의 속도 향상

ST_Union과 같은 집계 함수 버전 구현

ST_Transform 개선

그 밖에도 세세한 것은 있지만, 최소한 이 3개는 해결해 주지 않으면 GIS의 백엔드로서 사용하는 것은 어렵다.

자세한 것은 이후에 기술하지만, 정리하면 아래와 같다.

ST_Intersects의 속도 개선

「폴리곤 A가 폴리곤 B에 교차하는가?」를 판정하는 ST_Intersects()등을 비롯한 함수로 인덱스가 효과가 없고 속도적으로 실용에 견딜 수 없다.

다각형(지오메트리형)에서 판정 함수가 제대로 움직이지 않는다는 것은, 극론, 다른 형태로 말하면 비교 연산자(=<>, BETWEEN등)가 제대로 움직이지 않는 것과 동의이다. 너무 치명적입니다.

ST_Union 등의 집계 함수판의 구현

다른 형태로 말하면 SUM(), MAX()가 존재하지 않는 RDB라고 생각해 주면 괴로움을 알 수 있을까.

ST_Transform 개선

이것은 어쩌면 일본 고유일지도 모르지만, 특히 기업, 행정에 있어서 투영 좌표의 데이터가 많다. 행정에 있어서는 투영 좌표 쪽이 많지 않을까 하는 인상.

이들 투영 좌표의 데이터를 MySQL에 투입해 WEB 시스템을 만들려고 했을 때에, 지리 좌표로의 변환을 할 수 없는 것은 매우 괴롭다.

3에 대해서는 shp2mysql 측에서 변환한다고 하는 손도 사용할 수 없는 것은 아니지만, 장당적이므로 할 수 있으면 하고 싶지 않다.

1. ST_Intersects의 속도 개선

ST_Intersects와 같은 공간 검색 함수가 느립니다. 색인이 사용되지 않는 것 같습니다.

ST_Intersects를 사용할 수 없으면, 예를 들면 화면에 표시하는 만큼의 데이터를 추출할 수 없기 때문에 GIS를 개발할 때에 매우 모인다. 라고 할까 MySQL8. 0을 사실상 사용할 수 없다.

2. ST_Union 등의 집계 함수판의 구현

PostGIS에서는 독자적으로 ST_Union의 집계 함수판을 구현하고 있다.
이것은 꼭 MySQL에서도 갖고 싶다.

3. ST_Transform 개선

하기 기사에서도 사카이씨가 쓰고 있듯이 ST_Transform이 「지리 좌표계끼리의 변환의 일부에만 대응하고 있다」라고 하는 유감스러운 상황.

shp2mysql에서도 측지계 변환은 ST_Transform을 사용하므로, 예를 들어 평면 직각 좌표계에서 위도 경도로의 변환을 할 수 없다.

INSERT INTO `h27ka23` (`key_code`,`pref`,`city`,`s_area`,`pref_name`,`city_name`,`s_name`,`kigo_e`,`hcode`,`area`,`perimeter`,`h27kaxx_`,`h27kaxx_id`,`ken`,`ken_name`,`sityo_name`,`gst_name`,`css_name`,`kihon1`,`dummy1`,`kihon2`,`keycode1`,`keycode2`,`area_max_f`,`kigo_d`,`n_ken`,`n_city`,`kigo_i`,`moji`,`kbsum`,`jinko`,`setai`,`x_code`,`y_code`,`kcode1`,geom) VALUES ('23101001005','23','101','001005','愛知県','千種区','青柳町５丁目',NULL,'8101','15584.212','549.915','2005','2004','23','愛知県',NULL,'名古屋市','千種区','0010','-','05','101001005','101001005','M',NULL,NULL,NULL,NULL,'青柳町５丁目','7','106','48','136.93901','35.16151','0010-05',ST_Transform(ST_GeomFromText('MULTIPOLYGON(((-20754.8652865945 -93080.3907545561,-20792.9170054861 -93073.7809801786,-20801.0945861811 -93071.5464888813,-20797.7526499984 -93049.7109680534,-20793.5163543657 -93049.8828324357,-20789.1198896364 -93032.5472658343,-20783.1762441217 -92992.930770668,-20780.7818079772 -92993.4464037642,-20776.8214177434 -92973.2759786547,-20781.3388232127 -92972.7446392541,-20779.1850981796 -92953.8240600531,-20783.6050128758 -92953.1209365438,-20775.9618820959 -92910.0145830367,-20766.3740435754 -92912.0536876898,-20723.9511436358 -92918.2492093462,-20674.3757353179 -92927.8431351506,-20684.3549408095 -92973.7695915831,-20689.6810410617 -92972.6289769808,-20694.7508015533 -93002.1587260088,-20691.7020383399 -93008.8070613068,-20706.9427248768 -93089.4148234653,-20754.8652865945 -93080.3907545561)))', 2449, 'axis-order=long-lat'), 4326));

위와 같은 SQL을 실행하면 에러가 된다.

 Transformation from SRID 2459 is not supported.

※SRID 2459는 JGD2000의 평면 직각 좌표 7계(아이치현 등)

이 기사의 라이센스

이 문서는 CC BY 4.0(크리에이티브 커먼즈 표시 4.0 국제 라이센스)에 게시됩니다.