여러 레이어 사본의 구성 및 정리? [닫은]


28

내가 대학에있을 당시에는 "조직 및 정직성"문제가있었습니다. 나는 조직화되지 않았고 고유 한 이름없이 다른 폴더에 계층을 유지하여 각 계층의 사본이 여러 개있었습니다.

작업을 시작한 이후로 많은 기능이 향상되었습니다. 특수 하위 폴더가있는 특수 폴더를 유지합니다. 좀 더 깔끔하게 만들 수있는 시스템에 따라 레이어의 이름을 지정하지만, 여전히 여러 레이어의 복사본을 관리해야하므로 (라틴어 이외의 언어를 다룰 때 Autocad와 ArcGIS의 차이점이 있으므로 복사본을 유지해야합니다. 각 프로그램에 맞게 조정 됨), 귀하의 경험을 듣고 몇 가지 팁을 배우고 싶습니다.

  1. 레이어를 어떻게 구성합니까? 이름을 어떻게 지정합니까? 이름, 날짜, 내용, 고객별로?
  2. 여러 복사본을 구성하거나 처리하는 방법은 무엇입니까?

참고 : 나는 웹 개발자 / 웹 관리자의 POV가 아닌 분석가 / DBA POV와 이야기하고 있습니다 (저는 자신을 위해 레이어를 구성하는 것에 대해 이야기하고 있습니다.


6
좋은 질문입니다. 사실 그것은 질문이 아니라 퀘스트입니다. 질문은 하나의 답으로 좁아 지거나 일단 정해지면 끝납니다. 퀘스트는 진행중인 일이며, 절대 결말을 가질 수없는 모험이며, 그것이 당신이 여기있는 것입니다. 어떤 협약을 체결하더라도 그것은 완전히 또는 시간이 지나지 않을 것이라는 사실에 자신을 맡기십시오. 즉, 경로를 더 매끄럽고 쉽게 여행 할 수있는 규칙이 있습니다. Kevin의 답변과 의견에 대한 팔로우는 이와 관련하여 매우 좋은 출발입니다.
매트 윌키

답변:


21

이것은 악한 문제 입니다. 우리는 다양한 시스템을 시도해 보았습니다.이 시스템은 모두 한동안 다양한 수준으로 작동했으며 결국에는 성장하지 못했고 점점 더 적합하지 않은 최첨단 사례가 발생함에 따라 부서지기 시작했습니다. 즉, 우리가 사용한 각 시스템은 아무 것도 아닌 것보다 낫기 때문에 어떤 시스템도 시스템이없는 것보다 낫다는 것을 증명합니다 .

현재 실습에 대한 썸네일 개요는 다음과 같습니다.

래스터를 제외한 모든 것을 파일 지오 데이터베이스에 넣으면 더 적을수록 좋습니다. 특정 방식 (예 : 수력> 스트림, 수력> 레이크, 수력> 습지 등)과 관련이없는 경우 기능 데이터 세트 아래에 기능 클래스를 중첩하지 마십시오. 이것은 fgdb의 맨 위에 큰 목록이 있지만 허용되는 악입니다.

모든 피쳐 클래스에 대한 도면층 파일 을 작성 하고 대신 지원되지 않는 문자 등을 사용하여 필요에 따라 이름을 자유롭게 지정할 수 있으며 상황이 변함에 따라 이동하고 이름을 바꿀 수 있습니다. 예를 들어 공칭 스케일 (50k, 250k ...)에 따라 그룹화 된 한 세트의 레이어, 지역 (AK, YT ...)에 따라 다른 레이어, 테마별 (캐리 보어, 토지 사용, 운송 등)에 따라 중복없이 복제 할 수 있습니다. ...) 및 클라이언트에 의한 네 번째이며 데이터 저장소 자체는 변경되지 않습니다.

복제의 경우 레이어 파일 대신 바로 가기를 사용합니다. 그렇지 않으면 변경 될 때 업데이트 할 항목이 너무 많습니다. 단축키를 표시하도록 ArcCatalog를 구성하십시오. * 도구> 옵션> 파일 유형 : .lnk (제한 사항 : 미리보기 및 메타 데이터가 작동하지 않습니다. ArcCatalog에서 해당 소스에 대한 단축키를 따를 수 없습니다. 단축키 대신 기호 링크를 사용하여 해결할 수 있습니다. 링크 쉘 확장 참조 )

* (팁 : 레이어 폴더를 시작 메뉴 도구 모음으로 추가하여 항상 손끝에 배치하십시오.)

Z : \ 레이어 \
          베이스\
          어간 형성 모음\
          참고\
          모든 옷차림 (250k) .lyr
          관리 경계 (1000k) .lyr
          ...
Z : \ 래스터 \
          Landsat \
          직교 \
Z : \ 데이터 \
        Foo_50k.gdb
        Foo_250k.gdb
        NoScale.gdb

본질적으로 더 역동적이고 가변적 인 맵 구성 및 출력 (인쇄 파일, PDF, 내보내기 등)은 다른 곳에서 다르게 저장되고 구성됩니다. 이것은 우리에게 더 어려운 부분입니다. 우리는 현재 Job #에 따라 이름이 지정된 폴더가있는 전용 드라이브 (다시 날짜 대신 '2010-10-26'사용 )와 프로젝트 특정 데이터 및 결과 / 전달 가능 항목에 대한 하위 폴더를 사용합니다. 스프레드 시트 색인에는 모든 작업 번호 (폴더 이름), 해당 맵 제목 및 클라이언트가 나열됩니다. 전의:

W : \ Foo_0123 \
            Foobarmap_001.mxd
            문서 \
                 ReadMe.doc
            데이터\
                 buffers_2000m.shp
                 gps_tracks.csv
            산출\
                   Foobarmap_001.pdf
            산출물

인덱스를 최신 상태로 유지하는 것이 마찰 점이며 사람들은 싫어하고 피하고 이름 지정과 일치하지 않습니다 (스프레드 시트 대신 데이터베이스를 사용하는 것이 좋습니다). 숫자로 된 폴더 이름 규칙을 사용하면 또 다른 눈에 띄는 마찰 원인 인 인덱스없이 프로젝트 X에 대한 맵을 작성하는 것이 매우 어렵습니다. 이상적으로 인덱스는 클릭 가능한 html 페이지이며 DB 응용 프로그램에서 자동으로 생성됩니다. 그것은 전체 '다른 프로젝트입니다.

주요 원칙 :

  • 느리게 변화하고 자주 재사용하는 물건을 동적 및 변수와 분리하고 다르게 취급
  • 불필요하게 복제하지 말고 가능한 경우 레이어 파일과 바로 가기 / 링크를 사용하십시오.
  • 시스템을 너무 자주 바꾸지 말고 각각의 시도를 확고히하십시오.

나는 우리가 가진 것에 만족하지 않는다고 말하면서 다른 구조의 예를 대단히 환영합니다. :)


나는 어제 너무 크고 길었던 것을 게시 한 것에 대해 누군가를 가볍게 비난했고, 여기에서는 그림없이 바로 같은 일을합니다. 당신은 어떻게 생각할까요? 응집력있는 전체를 제시하거나 물건을 모듈 형 조각으로 나누는 것이 더 낫습니다. 각 조각은 각자 자신의 장점에 따라 투표를 할 수 있지만 다른 사람들과의 통합을 깨뜨 리거나 숨길 수 있습니까? 메타에 관해 이야기하기 : 길고 응집력이 있거나 짧고 모듈 식
matt wilkie

와우. 무슨 서류 정리 시스템 (이미 그것을 네 번 읽었지만 여전히 모든 것을 얻었는지 확실하지 않습니다). 바인드 AutoCAD 및 ArcGIS 사용자로서 나에게 두드러진 두 가지 의견 : 1.이 시스템에 DWG 스토리지를 어떻게 적용 할 수 있습니까? 2. GeoDatabase는 체계적으로 관리 할 수있는 좋은 방법입니다. 내가 가진 유일한 문제는 AutoCAD 맵에 GDB가 아니라 shapefile 만 있다는 것입니다. 그러나 감사합니다. 여러분의 철저한 시스템에서 팁을 얻을 것입니다 ...
jonatr

이 시스템은 15 년 동안 이와 같이 성장했으며 우리의 작업 방식에 맞춰져 있습니다. 그래도 휴대용 요소가 있어야합니다. CAD와의 상호 운용성 에 대해서는 파일 API에 공개 API를 게시하겠다는 공약을 지키기 위해 ESRI의 사례를 유지 하십시오 .
matt wilkie 7:30에

1
피처 데이터 셋을 구분합니다. ArcCatalog를 제외하고는 쓸모없는 기능입니다. 공통 사용 및 공간 참조의 계층을 그룹화해야하지만 프로그래머는 작업 영역에서 계층을 반복하는 방식으로 전환 될 때까지 기능 데이터 세트를 보지 못합니다. 다른 예측을 사용하는 경우 별도의 데이터베이스가 기능 데이터 세트보다 더 나은 것처럼 보입니다.
Tim Rourke

1
@Tim 저는 Feature Datasets가 ArcInfo 커버리지의 개념적인 후손이라고 생각합니다. 즉, 공통 "사물"을 설명하는 이종 지오메트리 유형을 단일 바스켓에 그룹화하는 수단입니다. 따라서 예를 들어 수로 (라인), 수역 (다각형) 및 수중 암석 (점)을 함께 가질 수 있습니다. 왜 그들이 프로그래머에게 더 직접적으로 제공되지 않는지 모르겠습니다.
매트 윌키

6

다른 사람이 시스템의 데이터에 액세스 할 경우 조직 스키마를 자신에게만 의미있게 만들 수는 없습니다. 시스템 사용을 염두에 두어야합니다. 이를 고려하지 않으면 "토지 데이터는 어디에 있습니까?"와 "[insert dataset here]를 찾을 수없는 이유"와 같은 질문에 대답하는 데 많은 시간을 소비하게됩니다.

수년 동안 이러한 시스템을 유지, 나는이 처음 소스, 예를 들면 주최 경우 사람들이 데이터를 찾을 수 있다는 것을 발견 c:\CensusBureau\Roads하고 c:\ESRI\Countries. 대신 데이터를 주제별로 먼저 나열한 다음 여러 소스가있는 경우 소스별로 데이터를 나열하는 것이 좋습니다 (예 : c:\Roads\CensusBureau및) c:\Roads\LocalGovt.

마찬가지로 래스터와 벡터를 다른 디렉토리로 분리하지 않습니다. 그러나 하나의 드라이브에 맞지 않는 많은 래스터 데이터가있는 경우 다른 물리 또는 논리 드라이브로 분할해야 할 수도 있습니다.

다음 디렉토리 구조를 권장합니다. Theme \ SourceYear. 여기서 Theme는 주제별 레이어, Source는 데이터 소스의 약칭 이름, Year는 데이터가 지상에서 나타내는 연도입니다. 이 시나리오에서는 인구 조사국에서 TIGER 도로가에 위치 할 것입니다 \Roads\Census00\Roads\Census10(또는 '호랑이'와 '인구 조사'를 대체).

ArcGIS의 특정 확장자는 13 자보다 긴 파일 이름에서는 작동하지 않습니다. 나는 어떤 확장을 기억할 수 없다. 나는 이것이 문제라는 것을 기억한다.


감사합니다 Kevin, 파일 이름 규칙은 어떻습니까? <Object> _ <Location> _ <Range> _ <Date> _ <FileFormat> _ <Resolution>. <ext> coast_eu_340509.76N0080201.23E_350509.76N_0090201.23E_2011_shp.zip box_eu_340509.76N0080201.23E_350509와 같은 솔루션을 생각하고 있습니다. .76N_0090201.23E_2011_tiff.zip. 당신은 그것이 유효한 아이디어라고 생각합니까?
Jade

5
이러한 파일 이름은 명령 줄이나 프로그램에서 사용하기에 매우 번거로울 수 있습니다. 또한 ArcMap에서 매우 넓은 목차 및 / 또는 범례로 이어집니다 (기본적으로). 객체 또는 객체 및 날짜와 같은 짧은 파일 이름을 선택하고 표준 메타 데이터 또는 최소한 readme 파일을 사용하여 나머지 정보를 릴레이합니다. 그냥 내 의견.

4
나는 케빈에 동의합니다. 현재 회사에는 기존 파일 이름 규칙 (변경 중임)이있어 loooong 파일 이름을 요구하며 케빈이 언급 한 이유 때문에 매우 번거 롭습니다. 두 가지 추가 생각 1) 파일 이름에있는 대부분의 내용은 파일 이름이 아닌 폴더로 나뉘어 파일 구조로 정렬 될 수 있습니다. 2) 파일 이름에 여러 마침표 (.)가 있으면 특정 소프트웨어 및 / 또는 프로그래밍 방식으로 파일에 액세스하는 데 문제가 발생할 수 있습니다. 일반적으로 (.) 뒤의 문자는 파일 확장자이며 추가 파일 이름 구성 요소가 아닙니다.
hgil

2

우리는 cad 파일의 프로젝트 레벨에서 작업합니다. 특정 워크 플로우가 어떻게 설정되어 있는지에 달려 있다고 생각합니다. 마스터 작업 프로젝트가 있고 편집 세션이 끝나면 내보내기 스크립트에서 추가 데이터 저장소를 준비합니다.

datadir \ cad \
cadastre.dgn datadir \ srv \ fuel.dgn
datadir \ srv \ sewerage.dgn
datadir \ map \ base.dgn
datadir \ map \ printsets.dgn
...

그런 다음 각 파일에는 식별자
sewPipe
sewManhole
sewPit
...로 명명 된 레벨 / 레이어 / 기능이 있습니다 ...

그런 다음 Mapguide 또는 Gflav 앱을 통해 사용자에게 표시되는 작업 프로젝트 파일을 읽는 대신 SQL 공간으로 모두 내 보냅니다.

GIS 레이어는 기능 이름별로 식별자와 유사한 폴더 레이아웃으로 정렬되어 정렬 할 수 있습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.