shapefile을 바꾸려는 시도가 있습니까? [닫은]

최근 저는 DBF의 10 자 필드 이름 제한을 충족시키기 위해 "25 세 이상의 시민 비율이 학사 학위 이상인"과 같은 완벽하게 좋은 필드 이름을 "edbchogtr"과 같은 것으로 변환하는 데 많은 시간을 소비하고 있습니다.

또 다른 스레드 ( Shapefile 기술 사양의 "Oddities" )에서 geospatialpython 은 " Shapefile 형식의 결함, 이상한 점 및 제한 사항에도 불구하고 GIS 분야와 그 주변에서 완고하게 지속됩니다. 교체하려는 모든 시도는 너무 부 풀었습니다. 단순한 벡터 저장 또는 너무 독점적입니다. "

이 활동은 Lawhead 씨의 의견과 함께 다음과 같이 궁금합니다.

• GIS의 유비쿼터스 데이터 저장 및 교환 형식으로 shapefile을 대체하려는 명확한 시도가 있었습니까?
• 경쟁자가 있습니까?
• 경쟁 형식이 있었는데 왜 실패 했습니까?
• Esri는이를지지하지 않았습니까, 아니면 이야기는 단순히 기술적 인 관성 중 하나입니까?
• 시도하지 않은 경우 ... 왜 안됩니까?

GIS 개발자와 사용자 모두 자신을 위해 조금 더 잘할 수있을 것 같습니다.

이것은 항상 나오는 주제입니다. 나는 정답을 얻지 못하지만 개인적인 의견을 줄 수 있습니다 .

그들이 지원하는 이유는 그들에 대한 몇 가지 특성 때문일 수 있으므로 몇 가지를 언급하겠습니다.

• 먼저 spec이 있습니다. 나는 30 대 초반이고 십대 때부터 존재했습니다. 따라서이 사양은 얼마 동안 사용되었다고 말하는 것이 안전합니다. 물론 몇 가지 다른 형식도 게시되어 있지만이 형식과 다른 점은 ...

• 비교적 간단합니다! 그것은 이미 존재하고 여러 플랫폼 / OS에서 광범위하게 지원되었던 DBF 형식 위에 구축되었습니다 . 이 형식 (DBF 부분)의 절반을 읽을 수있는 구문 분석기가 이미 있으므로 추가를 더 쉽게 지원할 수 있습니다. 당신은 기하학이 있습니까? 물론 직렬화하여 작성하십시오. 끝났습니다. 이것을 커버리지 와 대조하십시오 ! 토폴로지 정리가하는 일을 간단한 용어로 누군가에게 설명해보십시오 . 위상 적으로 깨끗한 커버리지를 작성하는 것은 쉽지 않습니다.

• 가장 중요한 것은 shapefile이 여전히 인기있는 이유 중 하나는 오픈 소스와 독점 시스템 모두에서 지원되기 때문 입니다. shapefile을 지원하지 않는 GIS는 무엇입니까?!? 들어 본 적이 없습니다.

대체, 우리는 듣고 파일 지오 데이터베이스 및 Spatialite . 두 가지 형식 모두 Shapefile과 비교할 때 기능, 유연성, 속도 등의 측면에서 매우 우수합니다. 그들 자신의 방식으로, 그들은 서로 다른 영역에서 서로보다 더 나은 것들을 가지고 있지만 공간적 공간과 FileGDB의 비교는 분명히이 질문의 범위를 벗어납니다.

이 형식 중 하나가 Shapefile을 대체 할 것이라고 생각합니까? 그들의 현재 화신에는 없습니다 .

왜?

기술적 인 주장 때문이 아니라 (결국 그 측면에서 우월하다고 말 했음) 라이센싱이라는 다른 이유 때문이었습니다.

그래서 그들의 문제는 무엇입니까?

FileGDB :

FileGDB는 새로운 FileGDB API를 통해 상호 운용성을 제공합니다. 그럼에도 불구하고이 API는 이진 형식으로 제공 됩니다.ESRI에 의해. 이것은 사양이 아닙니다. 과거 GeoDatabase 팀에서 일한 결과, 모든 주석 호일 모자를 쓴 음모 이론가와는 달리 이것은 악의적이지 않습니다. GeoDatabase의 내부는 매번 릴리스마다 변경되기 때문입니다. 전체 사양을 게시하려면 기본적으로 모든 내용을 유지 관리하는 방법에 대한 모든 세부 정보를 제공 한 다음 매년 릴리스마다 형식 변경 사항을 신중하게 문서화해야합니다. 말이되지 않습니다. 따라서 FileGDB API는 사양이 아니지만 작은 변경 사항을 모두 추상화합니다. 이제 크로스 플랫폼으로 사용할 수 있습니다! 당신을 염두에 두십시오, 이것은 중대한 전진입니다! ESRI의 보수적 인 특성을 고려할 때 이것은 올바른 방향으로의 반응입니다.

그러나 바이너리 전용 지원은 오픈 소스 세계의 어느 누구도 너무 행복하게 만들지 않습니다. ESRI가 지원하지 않는 경우 일부 코드를 이식하여 다른 Linux 버전에 적용하는 방법을 어떻게 활용할 수 있습니까? 당신은 할 수 없습니다. 이것이 오픈 소스를 강력하게 만드는 이유이며 이제는 이것을 이용할 수 없습니다. ESRI가 데비안 지원을 중단하기로 결정했다면 바로 그 것입니다. 끝났습니다. 그리고 그것을 바꾸기 위해 할 수있는 일은 없습니다.

스파 티아 라이트 :

Spatialite는 SQLite 에서 모든 무료 기능을 가져 오기 때문에 훌륭합니다 . SQLite는 모든 곳에서 사용됩니다. Android 전화, iPhone / iPad, Firefox, Chrome, 여러 상용 임베디드 장치에 있으며 영원히 사용할 수 있습니다. 바보 경계 상자 작업뿐만 아니라 Geoformat으로 진정으로 만들려면 PostGIS가 사용하는 것과 동일한 지오메트리 라이브러리를 사용해야합니다. GEOS . 안타깝게도 GEOS는 JTS로 알려진 또 다른 멋진 지오메트리 라이브러리를 기반으로 합니다. JTS의 모든 알고리즘은 매우 강력하므로 어떤 문제가 있습니까?

JTS는 오픈 소스 LGPL로 라이센스 가 있고 LGPL은 바이러스 라이센스 입니다. JTS는 LGPL, GEOS는 LGPL, GEOS와 정적으로 연결된 공간적 공간은 LGPL임을 의미 합니다. 짜증나 왜? 오픈 소스 라이센스를 너무 많이 설명 하지 않으면 , 예를 들어, 전체 앱을 자동으로 오픈 소스로 만들 수 있기 때문에 iPhone 앱에서 공간 라이트를 사용할 수 없다고 말할 수 있습니다 (iOS는 정적 링크 만 허용). 모든 유형의 GPL 라이센스는 (합리적으로) ESRI의 허풍을 두려워하므로 10 피트 폴로 터치하지 않습니다. 따라서 세계에서 가장 인기있는 GIS 시스템 인 ArcGIS는 기본적으로 공간을 지원하지 않습니다. 이것은 자동으로 실행 가능한 형식으로 종료합니다.

따라서 우리는 모든 곳에서 지원되는 엉뚱한 shapefile로 돌아갑니다.

업데이트 :

분명히 내 대답은 논란의 여지가 있었으므로 누군가 내 견해를 바꾸기 위해 내 대답의 전체 의미 를 자유롭게 편집하고 변경할 수 있다고 결정했습니다 . 그렇게하지 마십시오. 당신이 나에게 동의하지 않는다면, 그것은 완전히 괜찮습니다. 당신의 의견을 다른 답변에 게시하고 커뮤니티가 결정하게하십시오. 원래 의미를 나타 내기 위해 편집 내용을 내 답변으로 롤백했습니다. sqlite가 실행 가능한 형식이라고 주장하는 편집 된 답변을 읽는 경우이 업데이트를 추가하고 있습니다.

SHP + SHX 부분 자체는 그렇게 나쁘지 않습니다. 실제 문제는 DBF 부분에 있습니다. 그것은 유니 코드와 모든 종류의 최신 필드 유형을 지원하는 새로운 형식으로 할 수 있습니다. 문제는 모든 소프트웨어가 잘 지원하고 있다는 것입니다.

GeoPackage 는 유망한 후속 제품입니다. Spatialite와 비슷하지만 OGC에서 왔으며 ArcGIS 및 OGR을 포함하여 많은 소프트웨어에서 채택되었습니다.

공식 홈페이지 http://www.geopackage.org/ 와이 프리젠 테이션을 참조하십시오 : http://www.slideshare.net/JeffYutzler/geopackage-swg-overview

적어도 공간적 의도는 의도가 있습니다. 예를 들어이 프리젠 테이션을 참조하십시오 http://www.sourcepole.ch/assets/2010/9/10/foss4g2010_spatialite.pdf

반면에, 실패한 주된 이유는 shp가 많은 응용 프로그램에서 잘 지원되고 약간의 결함 만 있기 때문이라고 생각합니다.

다른 사람들도이 의견을 공유합니다.

이는 SpatiaLite 프로젝트가 구현할 도구를 제공하지 않았기 때문에 커뮤니티가 관심을 덜 가질 수있는 도구였습니다. SHP는 그들에게 효과가 있으며 변경할 이유가 없습니다.

http://www.spatiallyadjusted.com/2010/09/16/spatialite-is-not-the-shapefile-of-the-future/

Esri 파일 지오 데이터베이스, 공간 및 오토 데스크 sdf에 대한 자세한 내용은 여기를 참조 하십시오 : http://www.spatialdbadvisor.com/blog/121/the-shapefile-manifesto

Esri 는 쉐이프 파일을 대체하기 위해 몇 년 동안 파일 지오 데이터베이스 를 홍보하고 있습니다.

더 최근에는 이상한 점을 숨기는 API 를 제공 했습니다 .

GML과 같은 XML 언어는 거대한 데이터 세트를 운영하도록 최적화되지 않았지만 소프트웨어 간 또는 플랫폼 간 교환 형식으로 사용될 수 있습니다.

라이센스에 문제가 있다고 생각하지 않으며 (Spatialite의 바이러스 특성에 대한 Ragi Yaser Burhum의 게시물 참조) 필요한 경우 기존 파서를 쉽게 조정할 수 있습니다.

다른 관점에서이 문제를 해결하기 위해 "25 세 이상의 시민 비율이 학사 학위 이상인 경우" 를 사용하는 것이 완벽한 필드 이름 인지 확실하지 않습니다 . 공백과 아포스트로피를 혼합 할 수는 있지만 코드 나 쿼리를 작성하는 경우 버그가 발생할 가능성이 높습니다.

제 생각에 공간 데이터 배포의 미래는 웹 및 웹 서비스에 중점을 두어야 하며 GML을 사용 하는 WFS 사양이 공개되어 확립되어 있습니다. GeoJSON 은 더 작으며 JavaScript에서 작업하기가 더 쉽습니다. 그러나 압축시 크기는 비슷합니다.

또한 ESRI의 개인 지오 데이터베이스 에 대한 투표를하고 싶습니다 . 종종 Microsoft 형식으로 정렬 될 수 있지만 ODBC, SQL 쿼리,보기를 지원하고 개발자가 아닌 사용자도 쉬운 데이터 입력 양식을 만들 수 있으며 데이터 무결성 검사 수준 (데이터 유형, 길이, 고유 값)을 최소한 포함해야합니다. .