프로젝트_랜드마크 - 8일차

관광지 데이터 - 데이터 검증.

결측치 처리에 대한 고민

• missing data를 처리하는 과정에서 처리 방식에 대한 고민이 발생했다.

  • missing data를 전부 제거하는 경우.
    • 서울시 인허가 데이터까지 써가며 최대한 많은 정보를 제공하고자 했던 본래의 의도가 상실됨.
  • missing data를 발생시키지 않는 코드를 재 생성 후, 한번 더 크롤링 하는 경우.
    • 문서 전체에 대한 크롤링 시간이 상당한 편이라, 이것만으로도 상당한 시간적 압박이 예상됨.
    • 코드를 새로 작성하는 시간적 비용 역시 상당할것으로 보임.
  • missing data를 일일이 검색을 통해 채워넣는 경우
    • 코드를 통한 재현이 힘듬.
    • 결측치 데이터를 검색하는데 약간의 시간적 비용이 소모됨
  • 시간적 비용과 본래의 의도 사이에서 타협하여, 다음과 같은 결론을 도출했다.
    1. 프로젝트 완성 시기까지는 일단 손으로 검색해서 데이터를 채워넣고
    2. 프로젝트 완성 후에 크롤링 코드를 재작성하여 완성도를 올리자.
  • 결측 데이터 검증 코드의 제작을 중단하고, 손으로 데이터를 정제하는 작업에 들어갔다.

구글 지도와 네이버 지도의 차이점

• 확실히, 네이버 지도가 국내 지역 검색에 한해서는 조금 더 우위에 있는 느낌을 받았다.
  • 크롤링 코드를 재작성하게 된다면 네이버 지도에서 검색하는쪽도 괜찮겠다는 느낌을 받았다.

• 다만, 이름이 일부 다르게 기재되어 있거나 데이터에 적힌 이름과 완전히 다른 이름으로 지도에 등록된 경우에는 구글지도 쪽에서 조금 더 잘 찾아내는 느낌이었다.

• 데이터가 정확히 작성되어 있다는 확신이 있다면 네이버가, 데이터의 정확성이 의심된다면 구글을 사용하는것이 낫겠다는 결론이 들었다.

유적지 데이터 처리

• 유적지 데이터의 경우, 유독 missing-data가 많았다.
  • 이는 크게 둘중 하나의 경우에 속해있었다.
    1. 유적지의 이름 자체가 애매하게 적혀있어 검색이 안되는 경우(ex. 호국지장사 -> 서울 지장사 또는 국립서울현충원호국지장사 로 검색해야 결과 출력됨)
    2. 부속 건물이어서. (ex. 홍례문 -> 경복궁 홍례문)
  • 1번의 경우에는 최대한 검색을 통해 데이터를 살리는 방향으로 진행.
    (ex. 호국지장사 -> 국립서울현충원호국지장사 로 데이터를 변경 및 보존)
  • 2번의 경우에는 잘라내고 주가 되는 문화재 하나만 남기는 방향으로 진행.
    (ex. 경복궁 홍례문 -> 제거, 경복궁만 유지)

그 외 잡설

• 리눅스마스터 시험이 내일인데, 이번에 잘 볼수 있었으면 좋겠다.
  • 내용정리 해둔 곳에서 나오길 부지런히 빌어야겠다..