숫자로 시작하는 이름이 잘못된 데이터 명명 규칙입니까?


17

우리 회사는 ArcGIS를 사용하며 프로젝트 및 데이터 파일 이름 지정 표준을 갖추고 있으며 대부분을 따릅니다. 표준 명명에 대해 항상 귀찮은 점은 모든 프로젝트 및 데이터 파일 이름을 프로젝트 번호 (8 자리 숫자)로 시작해야한다는 것 입니다. 나는 항상 숫자로 시작하는 GIS 파일의 이름을 짓는 것은 나쁜 일이며 파일 이름 때문에 (특히 GRIDS를 사용하여) 프로세스가 실패했다는 신념을 항상 가지고 있습니다.

프로젝트 번호 요구 사항을 줄이기 위해 회사 표준을 수정하려고하지만 파일 이름의 "첫 번째 문자로 숫자"가 왜 나쁜지에 대한 문서화 방법을 많이 찾을 수 없습니다.

이 논쟁을 뒷받침 할 수있는 자료가 있다면 누구든지 올바른 방향으로 나를 가리킬 수 있습니까?


나는 문서화를 위해 파기를 할 것이지만 일반적으로 db 테이블 이름과 폴더 구조의 첫 번째 문자는 숫자가 완전히 불법 (유효하지 않은) 경우 나쁜 생각입니다. 많은 도구들도 그에 부응합니다. 이것은 단지 이전부터입니다. gis.stackexchange.com/questions/3571/…
브래드

2
@ 사이트에 오신 것을 환영합니다! 귀하의 질문을 훌륭하게 구성했기 때문에 독자가 귀하의 질문에 즉시 들어갈 수 있도록 초기 단락을 제거 할 자유를 얻었습니다.
whuber

1
파일 이름의 숫자는 문제가되지 않지만 숫자로 피쳐 클래스 이름을 시작할 수 없습니다. gis.stackexchange.com/questions/6686/…
Derek Swingley

답변:


10

이 컨벤션은 나쁜 명령 해석기에서 버그를 가져 오기 위해 애원하고 있습니다. (초기 숫자를 숫자와 혼동하기가 너무 쉽습니다.)

이러한 버그를 피하는 데있어 소프트웨어의 성공 여부는 향후 릴리스에서 해당 버그가 나타나지 않을 것이라는 보장은 없습니다. 이는 ESRI의 GIS 소프트웨어를 통해 수십 년에 걸쳐 여러 번 발생했습니다. 이 동작은 광범위하게보고되고 문서화되어 있습니다. 10 년 전의 ESRI 자체 사용자 포럼 이상을 보지 않아도됩니다. (이전 목록 서버 아카이브를 더 오래 검색하면 1995 년 무렵에 다시 검색 할 수 있습니다.) 흥미로운 Google 검색에는 다음이 포함됩니다.

"GRD ERROR"사이트 : forums.esri.com

파일 이름 8.3 site : forums.esri.com

이 둘은 파일 이름으로 인해 잠재적으로 다시 발생할 수있는 문제에 대한 약 100 개의 실제 예를 제공합니다.


1
나쁜 명령 해석기 란 무엇을 의미합니까?
Nathanus

2
@Nathanus ArcGIS 8.x 및 9.x 용으로 출시 된 모든 "래스터 계산기"인터페이스. 또 다른 예는 불과 몇 년 전까지 만해도 모든 ESRI 소프트웨어의 모든 래스터 분석의 핵심이었던 GRID 엔진의 내부 해석기입니다. 또한 ArcView 2.x 및 3.x의 Avenue 인터프리터도 약간 있습니다. 이들 모두는 일부 중요한 장소에서 입력 언어를 올바르게 구문 분석하지 못합니다.
whuber

@ whuber .. 감사합니다. Mapperz JET 참조 블로우와 함께 이것은 표준 변경에 영향을 미치는 희망을주는 훌륭한 빌딩 블록 / 시험을 얻었습니다.
hgil

오. 이름 지정 규칙이 아니라 현재 관행을 참조하는 규칙을 의미했습니다. 나는 내 마음을 조금 섞어 놓았다.
Nathanus

9

가능하면 숫자를 피하십시오-

지구 과학은 좋은 예제를 가지고 http://library.oceanteacher.org/OTMediawiki/index.php/General_File-Naming_Convention_for_Earth_Science_Datasets#Filename_Sections_in_the_Order_They_Should_Appear

공간은 당신을 여행 할 수 있습니다-공간이 관련되어 있으면 파일을 이동하는 오래된 DOS 기반 명령이 끊어집니다- "_"(밑줄)를 사용하는 것이 현명한 생각입니다-이것은 ArcInfo 워크 스테이션으로 돌아옵니다-8.3 (8 문자 및 파일 형식) . 요즘에는 더 많이 가질 수 있지만 사람이 읽을 수 있도록 전달할 수 있습니다. 날짜를 피하십시오 (대부분의 파일은 타임 스탬프됩니다)

* 기본적으로이 문장으로 이동 예 :

ArcMap과 같은 Windows 응용 프로그램에서 다양한 테이블 형식을 읽을 수 있도록하는 Microsoft JET 엔진의 지시에 따른 명명 규칙은 다음과 같습니다.

  • 이름은 숫자가 아닌 문자로 시작해야합니다.
  • 이름에는 공백이 없어야합니다.
  • 허용되는 유일한 특수 문자는 밑줄입니다.

아크 맵

여기에 이미지 설명을 입력하십시오


4

"Open"또는 "Select"파일 대화 상자는 파일 이름이 문자를 사용한다고 가정하면 정렬을 수행합니다. 따라서 모든 프로젝트 파일 정렬에 8 자리 고유 번호를 사용하면 신속하게 비논리적으로됩니다. 예 :

1
10
2
20
3 etc. 

게다가 MS DOS 8.3 파일 이름 형식 을 따르는 파일을 가정하는 GIS 도구가 많이 있습니다 .

파일 이름 자체를 프로젝트의 핵심으로 사용하는 것은 번거로운 요구 사항입니다. 모든 파일 을 관련 프로젝트 리포지토리의 일종의 버전 제어 로 저장하는 것이 훨씬 좋습니다 .


나는 동의한다. 기존 표준을 변경하려는 이유 중 하나입니다. 전체 파일 경로의 다른 부분에 프로젝트 번호가 포함되어있어 번거로울뿐만 아니라 중복되는 경우도 있습니다.
hgil

+1 정렬에 대한 좋은 지적과 대안에 대한 좋은 제안. (그러나이 규칙은 초기 0을 강제로 표시하므로 정렬은 어쨌든 작동 할 수 있습니다 ...).
whuber

2

NPS 규칙에서 제외하고 첫 문자 숫자에 대한 제한이없는 것으로 보입니다.

파일 및 속성 테이블 이름
A. GIS 최종 제품 – 적용 범위, 모양 파일 및 기타 형식은 10.3 파일 명명 구조 (즉, "c"는 영문자이고 "x"는 영숫자) 인 cxxxxxxxxx.ext를 준수해야합니다. 파일 이름을 확장자에서 분리하는 총 13 자 및 한 마침표). 파일 이름을 생성하려면 다음 규칙을 사용해야합니다. ccccccc99c.ext
i. 파크 코드의 4 자리 접두사입니다 (표 1 참조).
ii. NCCN 프로젝트 추적 데이터베이스에 표시된 5 자리 프로젝트 코드. NCCN 추적 프로젝트 정보 (개발중인 NCCN 2005b)를 참조하십시오.
iii. 동일한 프로젝트 내에서 GIS 레이어를 차별화하는 단일 문자. 이 단일 문자를 GIS 프로젝트 제품 코드라고하며 NCCN 프로젝트 추적 데이터베이스에서 유지 보수됩니다. 이는 더 많은 GIS 레이어가 프로젝트에 생성되거나 프로젝트에 추가 될 때 순서대로 선택된 알파 문자 여야합니다 (즉, a, b, c 등으로 시작). 예를 들어,이 프로젝트에 대해 두 개의 다른 GIS 레이어가 이미 있다고 가정하면 NOCA Landbird Inventory 프로젝트의 ESRI Arc / Info 내보내기 파일이 시작점을 통과하는 파일 이름은 "nocabda02c.e00"입니다.
iv. 확장명. ESRI shapefile은 이름이 같고 확장자가 .shp, .shx, .dbf, .shp, shp.xml 및 .prj 인 최소 5 개의 파일로 구성됩니다. <<

위 단락에 대해 죄송합니다.
저의 경험은
1. 표준의 불충분 한 명명 규칙이있을 때 사람들은 준수의 어려움으로 인해 그것을 깨뜨렸다는 것입니다.
2. 사람들은 다른 표준 명명 규칙을 준수하기 위해 그것을 깨뜨립니다.

사실은 숫자로 된 첫 문자 파일 및 필드 이름을 허용하지 않는 도구가 있으며 RDBMS 이름 지정은 거의 항상 동일한 규칙을 따릅니다.

인디애나 문서
오레곤 문서
Jason Birch 문서
Nat Park Serv 문서
공공 안전 다중 기관 문서
강 도달 코드는 모범 사례를 무시하는 것으로 보입니다.
샌 안토니오 문서
기타 NPS 문서

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