Recentemente, passo muito tempo convertendo perfeitamente bons nomes de campos como "Porcentagem de cidadãos com 25 anos ou mais com um diploma de bacharel ou superior" em coisas como "edbchogtr" para atender ao limite de 10 caracteres do DBF no campo.
Em outro tópico ( "Oddities" na especificação técnica Shapefile ), o geospatialpython comentou que "Apesar das falhas, esquisitices e limitações do formato shapefile, ele persiste teimosamente dentro e ao redor do campo de GIS. Todas as outras tentativas de substituí-lo foram inchadas demais para armazenamento vetorial simples ou muito proprietário ".
Esta atividade, juntamente com o comentário do Sr. Lawhead, me fez pensar:
- alguma tentativa explícita foi feita para substituir o shapefile como o onipresente formato de armazenamento e intercâmbio de dados do GIS?
- Existem concorrentes?
- Se houve formatos concorrentes, por que eles falharam?
- Esri se recusou a apoiá-los ou a história é simplesmente uma inércia tecnológica?
- Se não houve tentativas ... por que não?
Parece que poderíamos fazer um pouco melhor para nós mesmos, como desenvolvedores e usuários de GIS.
Respostas:
Este é um tópico que sempre aparece. Talvez eu não tenha a resposta certa, mas posso lhe dar minha opinião pessoal .
A razão pela qual eles são suportados pode ser atribuída a várias características sobre eles, então deixe-me mencionar algumas.
Primeiro, há uma especificação . Quero dizer, eu tenho trinta e poucos anos e isso existe desde que eu era adolescente. Portanto, é seguro dizer que essa especificação existe há algum tempo. Claro, existem vários outros formatos que também são publicados, mas a diferença sobre este é que ...
É relativamente simples! Ele é construído sobre o formato DBF , que na época já existia e era amplamente suportado em várias plataformas / sistemas operacionais. Já havia analisadores que podiam ler metade desse formato (a parte DBF), facilitando o suporte à adição extra. Você tem uma geometria? Claro, apenas serialize e escreva. Você terminou. Compare isso com uma cobertura ! Tente explicar a alguém em termos simples o que uma topologia limpa faz . Não é trivial escrever uma cobertura topologicamente limpa.
Mais importante, acho que o principal motivo para os shapefiles ainda serem populares é que eles são suportados nos sistemas Open Source e Proprietary . Que SIG você sabe que não suporta shapefiles?!? Desconhecido de.
Como substituição, ouvimos falar de File GeoDatabases e Spatialite . Ambos os formatos são muito superiores em termos de funcionalidade, flexibilidade, velocidade, etc., quando comparados aos Shapefiles. A seu modo, eles têm certas coisas que os tornam melhores em áreas diferentes, mas uma comparação de spatialite e FileGDB certamente está fora do escopo desta questão.
Eu acho que um desses formatos substituirá os Shapefiles? Não em suas encarnações atuais .
Por quê?
Não por causa de um argumento tecnológico (eu disse que eles eram superiores nesse aspecto, afinal), mas por causa de outra coisa: licenciamento.
Então, quais são os problemas deles?
ArquivoGDB :
O FileGDB fornece interoperabilidade por meio da nova API FileGDB. No entanto, essa API é fornecida em formato bináriopela ESRI. Esta não é uma especificação. Tendo trabalhado na equipe do GeoDatabase no passado, posso dizer que, ao contrário de todos os teóricos da conspiração que usam chapas de alumínio, isso não é nada malicioso. Isso ocorre porque os elementos internos do GeoDatabase mudam a cada versão. A publicação de uma especificação completa implicaria basicamente fornecer todos os detalhes de como tudo deve ser mantido e, em seguida, documentar cuidadosamente as alterações no formato a cada lançamento anual. Isso não faz sentido. Portanto, a API FileGDB, mesmo que não seja uma especificação, abstrai todas essas pequenas alterações. E agora ele pode ser usado em várias plataformas! Lembre-se, este é um grande passo em frente! Considerando a natureza conservadora das ESRI, essa é definitivamente uma reação na direção certa.
E, no entanto, o suporte apenas binário não deixa ninguém feliz no mundo do código aberto. Como você tira vantagem de portar algum código para dizer outro sabor do Linux, se o ESRI não o suportar. Você não pode. É isso que torna o código aberto poderoso e, agora, você não pode tirar proveito disso. Se a ESRI decide parar de apoiar o Debian, é isso. Você terminou. E não há nada que você possa fazer para mudar isso.
Spatialite :
O Spatialite é incrível porque obtém todas as funcionalidades gratuitas do SQLite . SQLite é usado em qualquer lugar. Está no seu telefone Android, no seu iPhone / iPad, no Firefox, no Google Chrome, em vários dispositivos comerciais incorporados - pode durar para sempre. Para realmente transformá-lo em um Geoformat (e não apenas fazer operações estúpidas com caixas delimitadoras), ele precisa aproveitar a mesma biblioteca de geometria que o PostGIS usa: GEOS . Infelizmente, o GEOS é baseado em outra biblioteca de geometria ainda mais impressionante, conhecida como JTS . Todos os algoritmos no JTS são extremamente poderosos, então qual é o problema?
Bem, a JTS é licenciada como Open Source LGPL , e a LGPL é uma licença viral . JTS é LGPL, significa GEOS é LGPL, significa espacialidade vinculada estaticamente com GEOS é LGPL. Isso é péssimo. Por quê? Sem explicar muito as licenças de código aberto , posso dizer-lhe que, por exemplo, não posso usar espacial em um aplicativo para iPhone, por exemplo, porque isso tornaria todo o meu aplicativo automaticamente aberto (o iOS só permite vinculação estática). Qualquer tipo de licença GPL (razoavelmente) assusta a ESRI e, portanto, não a toca com um bastão de três metros. Portanto, o ArcGIS, o sistema GIS mais popular do mundo, não (e provavelmente nunca) suporta espacialmente nativamente. Isso mata automaticamente como um formato viável.
E assim voltamos aos shapefiles ruins que são suportados em todos os lugares.
Atualização :
Aparentemente, minha resposta foi controversa o suficiente para que alguém decidisse que não havia problema em editar e alterar livremente todo o significado da minha resposta para colocar seu ponto de vista. Por favor, não faça isso. Se você não concorda comigo, tudo bem, basta postar sua opinião em uma resposta diferente e deixar a comunidade decidir. Eu rolei apoiando as edições na minha resposta para mostrar o significado original. Estou adicionando esta atualização caso você leia a resposta editada que afirmava que o sqlite era um formato viável.
fonte
A parte SHP + SHX em si não é tão ruim. O verdadeiro problema está na parte DBF. Isso pode ser feito com um novo formato, que suporta unicode e todos os tipos de campos modernos. O problema está sendo bem suportado por todo o software disponível.
fonte
O GeoPackage é um sucessor promissor. É semelhante ao Spatialite, mas do OGC e foi adotado por muitos softwares, incluindo ArcGIS e OGR.
Veja a página oficial http://www.geopackage.org/ e, por exemplo, esta apresentação: http://www.slideshare.net/JeffYutzler/geopackage-swg-overview
fonte
Pelo menos spatialite tem a intenção, veja, por exemplo, esta apresentação http://www.sourcepole.ch/assets/2010/9/10/foss4g2010_spatialite.pdf
Por outro lado, acredito que a principal razão pela qual ele falhou é que o shp é bem suportado por muitos aplicativos e possui apenas pequenas deficiências.
Outros compartilham essa opinião também:
http://www.spatiallyadjusted.com/2010/09/16/spatialite-is-not-the-shapefile-of-the-future/
Mais informações sobre o geodatabase do arquivo Esri, spatialite e autodesk sdf aqui: http://www.spatialdbadvisor.com/blog/121/the-shapefile-manifesto
fonte
A Esri promove os Geodatabases de arquivos há vários anos como um substituto para os shapefiles.
Mais recentemente, eles forneceram uma API que oculta qualquer esquisitice.
fonte
Um dialeto XML, como o GML, definitivamente não é otimizado para operar grandes conjuntos de dados, mas pode ser usado como um formato de troca entre software ou entre plataformas.
Não acredito que haja nenhum problema com o licenciamento (consulte o post de Ragi Yaser Burhum sobre as características virais do Spatialite) e é bastante fácil adaptar os analisadores existentes, se necessário.
fonte
Só para entender isso de uma perspectiva diferente, não tenho certeza de que o uso de "Porcentagem de cidadãos com 25 anos ou mais com um diploma de bacharel ou superior" seja um nome de campo perfeitamente bom. Embora a mistura de espaços e apóstrofos possa ser manipulada, se você estiver escrevendo código ou consultas, é mais provável que haja erros.
Na minha opinião, o futuro da distribuição de dados espaciais deve se concentrar na web e nos serviços da web, e a especificação WFS (que usa GML) é aberta e estabelecida. O GeoJSON é menor e pode ser mais fácil trabalhar com JavaScript. No entanto, com a compressão, os tamanhos são comparáveis.
Eu também gostaria de votar nos Geodatabases pessoais da ESRI . Pode ser um formato da Microsoft frequentemente difamado, mas suporta consultas ODBC, SQL, visualizações e permite que não desenvolvedores criem formulários fáceis de entrada de dados e inclua pelo menos algum nível de verificações de integridade de dados (tipos de dados, comprimentos, valores exclusivos) .
fonte