Re: GeoDjango: e o problema do 25D [RESOLVIDO]
Fernando
BHte - MG
cel: +55 31 9119 8814
-------------------------
MSN e Gtalk # fno...@gmail.com
Valeu Roberto,Isso eu identifiquei e achei legal a sua sugestão dos utils.Porém eu tenho um problema nesse caso, pois os utilitários do gdal/ogr rodam no shell, e eu estou construindo um sistema web que irá receber de qualquer pessoa, o interessante seria ter alguma forma de conversão dessas dimensões dentro do próprio geodjango.Isso é que eu não estou conseguindo. O estranho é que o LayerMapping faz isso usando essa biblioteca, só não consegui encontrar aonde.Att,
Fernando G. Norte
BHte - MG
cel: +55 31 9119 8814
-------------------------
MSN e Gtalk # fno...@gmail.com
Em 30 de setembro de 2011 18:18, Roberto Santos <rob...@geodev.com.br> escreveu:Olá Fernando,
O problema é exatamente este que você comentou. Quando você cria uma coluna geometry no PostGIS, é definido a dimensão das geometrias que podem ser armazenadas nela. No seu caso, parece que a coluna foi criada com dimensão 2. Se você tentar importar um shapefile com dimensão diferente (3 ou 4), ocorrerá um erro.
Minha sugestão é:
Utilize os utilitários que estão no pacote gdal-bin/ogr-bin para converter o seu shapefile para dimensão 2 antes da importação. Acho que o utilitário mais adequado é o ogr2ogr.
Ex.: ogr2ogr shapefile_novo_2d shapefile_antigo_3d
Boa sorte,
Roberto--On 9/30/11 3:48 PM, Fernando wrote:--Pessoal,
Eu coloquei um post no meu blog para explicar o problema que eu tenho no GeoDjango.Pesquisando no grupo vi que tem algumas pessoas que tiverem experiências com ele e talvez possam me dar uma luz.Tá osso achar grupos de discussões ativos e/ou pessoas com facilidade/disponibilidade que usem o GeoDjango.Se quiserem trocar figurinhas para grupo de estudos, me avisem tbm.
O post está aqui: http://fnorte.org/2011/09/geodjango-e-o-problema-do-25d/
Mas colo aqui depois do email.
Grato desde já,
Fernando G. Norte
BHte - MG
cel: +55 31 9119 8814
-------------------------
MSN e Gtalk # fno...@gmail.com
POST:GEODJANGO: E o problema do 25D
Como estou começando a enveredar no Django, GeoDjango e GeoCoisas a fim, estou tomando uma surra danada com um monte de coisas, por pura inexperiência. Mas até que as coisas estão começando a encaixar muito bem, tanto a forma de trabalho do framework (Django) e como ele lida com o tratamento de dados com o PostGIS, como também o tratamento das diferentes formas “geométricas” que existem (pontos, linhas, polígonos etc). Até que esbarrei com o famigerado 25D, que ao meu entender (chute) seria como um 2,5 (dois e meio) D, ou seja não é nem 2D nem 3D. O que na verdade é uma terceira coordenada além do x,y (lat, lon), que seria talvez um ponto altimétrico.
Vamos ao problema.
Atualmente estou tentando fazer um sistema para receber arquivos (upload) com poligonos para armazenar no banco e adicionar outras informações. A princípio para não complicar nessa versão “pré-alfa”, eu estou tratando somente com arquivos do tipo ESRI ShapeFile.
Para tal eu gerei alguns polygonos de teste, desenhando através do Google Earth, gerando um KML e convertendo para um ESRI ShapeFile através do Quantum GIS (por enquanto é o único que tenho instalado aqui com o meu Ubuntu).
Eu estava encontrando problemas na importação do arquivo para o banco de dados que me dava erros diferentes em cada tentativa.
Segundo o tutorial do GeoDjango uma forma simples de fazer isso seria através do LayerMapping, que serve exatamente para isso, converter um ShapeFile para o banco PostGis. Porém não seria uma forma adequada para mim, pois o LayerMapping encontrarei dois problemas.
- O LayerMapping apenas insere os dados que estão no ShapeFile, não permitindo que eu insira nenhum dado diferente do que há no shape.
- O LayerMapping não me retorna quais foram os IDs gerados no banco.
Só que eu preciso relacionar os poligonos enviados e gerados com o usuário que está fazendo. Apesar do LayerMapping funcionar perfeitamente.
Então parti para tentar usar a GDAL API diretamente, trazendo a informação que ele encontra no shapefile, através do método DataSources(). Só que isso estava me gerando diversos erros diferentes, que informavam ser TYPE ERRORS, ou seja, o tipo de dado que eu estava tentando não condizia com o que eu tinha no sistema.
Até que eu resolvi usar a função com o GEOSGeometry habilitado que pelo que eu entendi ele transforma em padrões do GEOS, ainda um mistério para mim a diferença dele para o OGR e outros padrões(standards), e eu cheguei a um erro de restrição:ERRO: novo registro da relação "TABELA_DO_BANCO(MODEL)" viola restrição de verificação "enforce_dims_NOMEDOCAMPO"Esse erro eu cheguei através do seguinte script:
ds = DataSource(SHAPE_FILE) // leitura do shape for layer in ds: # Laço para cada polígono usando o método get_geoms # com o uso do GEOSGeometry for polyg in layer.get_geoms(geos=True): # Model: Grava a session do usuário e o polígono orc = MODEL(session_id = session_id, NOMEDOCAMPO_GEOMETRICO = polyg) orc.save()Obs: Caso eu não use o parâmetro geos=True no método .get_geoms(), ele me retorna sempre o erro no proxy do model:
cannot set NOME_DA_TABELA(MODEL) GeometryProxy with value of type: <class 'django.contrib.gis.gdal.geometries.Polygon'>/django/contrib/gis/db/models/proxy.py in __set__Pesquisando sobre esse erro consegui achar uma discussão interessante em que explicavam que esse erro era um restrição do banco como a tabela foi criada, e esse enforce_dims_CAMPO foi um restrição das dimensões que existia na geração automática das tabelas pelo Django:
CONSTRAINT enforce_dims_CAMPO CHECK (st_ndims(CAMPO) = 2)O que eu consegui entender disso é que ele coloca essa restrição para o número de coordenadas espaciais restritas a 2, ou seja, x e y (lat e lon), as coordenadas de cada ponto, sem a necessidade da altimetria.
Mudando esse CONSTRAINT para 3 eu consigui resolver o problema do 25D, mas ele também dá o mesmo erro de restrição para quando o polygono é gerado “corretamente” sem o 25D.
Retirei esse CONSTRAINT completamente, mas aí fica a dúvida da real necessidade dele existir visto que o próprio sistema, o framework no caso, cuida da validação dos dados.A solução que eu preciso encontrar para esse problema é converter o 25D para um vetor ‘normal’. O que ainda não consegui encontrar.
Lendo o código do LayerMapping me perdi em vários testes e validações que ele passa para gerar os dados, pois através dele, não importa se é 25D ou não, que ele grava sem problemas. Portanto existe alguma forma, só que ainda não sei como.A grande dificuldade é realmente encontrar alguma coisa na internet. Antigamente, nas minhas aventuras com interface web e php, tudo era mais fácil, muita gente fazendo e compartilhando informações. Agora com a decisão do GeoDjango, tudo fica mais difícil, existem poucas pessoas e poucas experiências compartilhadas nessa mundo digital sem porteira. Quando o Google lhe informa que não encontra resultados para a sua pesquisa, dá para travar. Estar sozinho nessa luta, é difícl.
Chega de mimimi e de volta aos estudos. Antes que o POG comece a rolar.
Django Brasil em Google Groups <http://groups.google.com.br/group/django-brasil>
Associe-se à Python Brasil e suporte nossa comunidade! <http://associacao.python.org.br/>
Django Brasil em Google Groups <http://groups.google.com.br/group/django-brasil>
Associe-se à Python Brasil e suporte nossa comunidade! <http://associacao.python.org.br/>