이언배 연구노트

네이버 API 검색이 끝났다. import pandas as pdfrom sqlalchemy import create_enginefrom glob import globfilenames = glob('./api_crawl_1/*.csv')dfs = []for file in filenames: t = pd.read_csv(file) dfs.append(t)filenames = glob('./api_crawl_2/*.csv')for file in filenames: t = pd.read_csv(file) dfs.append(t)df_concat = pd.concat(dfs)engine = create_engine('postgresql+psycopg2://???:???@???:5432/??..

NAVER web crawling 결과로 도무지 파악할 수 없었던 인허가 데이터를NAVER API 를 활용해 하나하나 쿼리해본 결과를 csv로 저장해뒀다. 이제 이 결과물을 PostGRES 로 옮겨서 SQL로 다시 한 번 매칭해볼 것이다. 폴더에 저장된 csv 들을 불러들여 PostGRES로 이동시키는 건 간단하다. import pandas as pdfrom sqlalchemy import create_engine #Dataframe -> SQL 에는 sqlalchemy 를 불러오자from glob import glob# csv 파일들 불러오기filenames = glob('./폴더이름이뭐에요/*.csv') #glob 함수에서 '*.csv' 는 모든 csv 파일을 불러준다. 이 결과물은 'text의 리스..

이번에 해야할 태스크는 크게 1. PostGRES 에서 Third Place 정보를 불러온다2. Python 으로 Third Place 를 검색한 NAVER API 결과물을 JSON 형태로 얻는다3. 기존 검색 결과와 일치 여부를 확인한다4. 데이터베이스에 저장한다 로 이루어져있다. 여기서 고민해야할 부분은 3번과 4번.JSON 에서 정보를 추출하는 건 python 이 편할 것 같지만,추출한 정보와 기존 정보의 비교 및 저장을Python - csv 로 할지, Python - Postgres - Database 의 형태로 할지가 고민이다.내가 편하고 다루기 좋은 건 csv지만, 용량이 너무 아깝고, 시간도 느리다.Database 는 부가적인 작업이 필요 없지만 업데이트가 까다로운 경우가 있다. 그래, 기왕..

이제 손수 하나하나 검색하기 이전,내가 쓸 수 있는 마지막 재료를 넣을 차례다...이전, NDTP 들을 네이버에 손수 검색하는 크롤링 코드를 짜뒀던 나, 칭찬한다. 일단,전체 인허가 데이터: 208,664개전체 NAVER 데이터: 158,249개 1. 같은 건물에 비슷한 이름을 가진 데이터셋 (text similarity > 0.15): (VIEW: buld_match)1:1 매칭으로 105,338개(남은 인허가 데이터는 103,320개 (왜 합이 안맞냐면, 나도 몰라. 아니 왜 query 할때마다 숫자가 다른건데 미친거 아니야?) 2. 같은 도로에 비슷한 이름을 가진 데이터셋 (text similarity > 0.3):1:1 매칭으로 1,370개.(왜 이렇게 적나? 해서 QGIS로 확인해봤더니 진짜로 ..

나의 웹 크롤링 데이터는 어떻게 될 것인가...일단 이전에 크롤링해두었던 나에게 칭찬하며, 18,486개의 크롤링 데이터를 얻을 수 있었다. (파이썬에서 PostGRES로 옮겼다.)그 중에서 similarity 가 0.15이상인 녀석들은 아래와 같다 SELECT title, naver_check, similarity(title, naver_check) FROM overflow_resultWHERE similarity(title, naver_check) > 0.2 ORDER BY similarity ; 사실 네이버에서 매우 러프하게 검색한 결과물이어서 text similarity 를 더욱 보수적으로 잡아야하나 했지만,어차피 걸러낼 수 있는 가능성이 별로 없어보인다. 사실 이번 단계에서는 "네이버에서 검색된..

앞에서 같은 주소를 가진 인허가와 NAVER Place 의 매칭을 완료했다. 이제 남은 건 매칭에 실패한 인허가 103325개, 매칭에 실패한 NAVER place 52907 개를 매칭하는 것.베스트 시나리오는 저 NAVER Place 가 모두 인허가 데이터에 붙어 약 50000개만 손수 검색하면 되게 만들어주는 것 (하 진짜) 이지만,인생은 그렇게 호락호락하지 않다.  쓸 수 있는 전략은 2개다.1. x, y 포인트 좌표 사용하기인허가 데이터에는 5179 기준의 x, y 좌표가, NAVER 데이터에는 4326 기준의 x, y 좌표가 있다.다만, 인허가 데이터 중 학원 데이터 일부는 x, y좌표가 없고, 누락되어있는 경우도 상당하다. 2. 건축물 데이터 사용하기모든 데이터에는 건물 본번과 부번이 있다. ..

소스가 다른 두 데이터를 주소 기반으로 병합해서 표기해보자. naver_place 의 데이터는포인트 geom, 이름, (도로명) 주소 등. permit_place 의 데이터는title, (도로명) 주소 + (동), (손실이 많은) 포인트 geom, 개업일 등.  우선,1. 지난번에 고생했던 인덱싱을 개선하기 위해 두 데이터 소스에 각기 다른 id column 이름과 id 를 부여한다.2. 주소를 기반으로 같은 건물에 있는 장소들을 분류한다.3. 이름이 비슷한 녀석이 있으면, 인허가 데이터를 DTP로 분류한다. 일단, id 먼저 부여하자.naver_place 의 아이디는 nid 로, permit_place 의 아이디는 pmid 로 column 을 지정하겠다.--------------------------S..

Task:특정 도로가 어떠한 공간적 속성을 가지고 있는지 구분할 때, 인접한 건축물의 용도가 중요하다.도로에 인접한 건축물들을 용도별로 구분하여 Join 시키자.  오후 2시에 북촌 어느 골목에는 몇 명이 지나갈까.이 물음에 답하려면, "그 골목은 어디에 있습니까?" 와 같이,"그 골목은 뭐하는 골목입니까?" 에 대한 질문도 답해야 한다. 뭐하는 골목인지 아는 데에 가장 좋은 방법은 어떤 건물이 주변에 있습니까? 와도 같은 질문일 터. 1. Data Preprocessing필요한 준비물은 2개. 도로 중심선 데이터와 건축물 데이터다.경험 상, 도로 중심선 데이터와 건축물 데이터 모두 juso.go.kr 에서 제공하는 주소를 받는 것이 가장 정밀하다.제공하는 주소 (juso.go.kr) 도로데이터는 연구하..