From israel.ely em sdr.incra.gov.br  Fri May  4 13:00:40 2012
From: israel.ely em sdr.incra.gov.br (Israel Oliveira)
Date: Fri May  4 12:52:13 2012
Subject: [OSGeo-Brasil] Problemas ZipLayer
Message-ID: <9ac78295676235bfaf0a0fbe6af8fe6f@webmail.incra.gov.br>

Estou começando a utilizar o ubuntu 11.1 juntamente com o qgis, e ao
utilizar o plugin ziplayer ocorre a seguinte mensagem de erro:


<style type="text/css">
p, li { white-space: pre-wrap; }
</style>


<span style=" color:#ff0000;">Um erro ocorreu enquanto executava o seguinte
código Python:</span>

Traceback (most recent call last):
  File
"/home/incra/.qgis/python/plugins/ziplayers/logic/ziplayerswidget.py", line
61, in __signal_bbMain_clicked
    self.__createZips(lstIdLayer)
  File
"/home/incra/.qgis/python/plugins/ziplayers/logic/ziplayerswidget.py", line
92, in __createZips
    lstIdLayer, self.ui.textEditStatus.append, self.__pb)
  File "/home/incra/.qgis/python/plugins/ziplayers/logic/cziplayers.py",
line 217, in createZipLayer
    self.__zipShapefile(dirWork, fileInfoShape, nameZip, lyr)
  File "/home/incra/.qgis/python/plugins/ziplayers/logic/cziplayers.py",
line 171, in __zipShapefile
    createPrj()
  File "/home/incra/.qgis/python/plugins/ziplayers/logic/cziplayers.py",
line 163, in createPrj
    fw = open(filePrj, 'w')
IOError: [Errno 84] Multibyte ou caracter largo inválido:
'/media/Arquivos/2012/Territ\xf3rio Quilombola
Maragogipe/Arquivos_Definitivos/QuilomboMaragogipeUso.prj'

Versão do Python:
2.7.2+ (default, Oct  4 2011, 20:41:12) 
[GCC 4.6.1]


Versão do QGIS
1.7.4-Wroclaw Wroclaw, exported

Caminho para o Python: ['/home/incra/.qgis/python/plugins/sextante',
'/usr/share/qgis/python', '/home/incra/.qgis/python',
'/home/incra/.qgis/python/plugins', '/usr/share/qgis/python/plugins',
'/usr/lib/python2.7', '/usr/lib/python2.7/plat-linux2',
'/usr/lib/python2.7/lib-tk', '/usr/lib/python2.7/lib-old',
'/usr/lib/python2.7/lib-dynload', '/usr/local/lib/python2.7/dist-packages',
'/usr/lib/python2.7/dist-packages', '/usr/lib/python2.7/dist-packages/PIL',
'/usr/lib/python2.7/dist-packages/gst-0.10',
'/usr/lib/python2.7/dist-packages/gtk-2.0', '/usr/lib/pymodules/python2.7',
'/usr/lib/python2.7/dist-packages/ubuntu-sso-client',
'/usr/lib/python2.7/dist-packages/ubuntuone-client',
'/usr/lib/python2.7/dist-packages/ubuntuone-control-panel',
'/usr/lib/python2.7/dist-packages/ubuntuone-couch',
'/usr/lib/python2.7/dist-packages/ubuntuone-installer',
'/usr/lib/python2.7/dist-packages/ubuntuone-storage-protocol',
'/usr/lib/python2.7/dist-packages/wx-2.8-gtk2-unicode',
'/home/incra/.qgis/python/plugins/cataloginpecreate/logic',
'/home/incra/.qgis/python/plugins/cataloginpecreate/gui',
'/home/incra/.qgis/python/plugins/ziplayers/logic',
'/home/incra/.qgis/python/plugins/ziplayers/gui',
'/home/incra/.qgis/python/plugins/imgshowhide/logic',
'/home/incra/.qgis/python/plugins/imgshowhide/gui',
'/home/incra/.qgis/python/plugins/cataloginpequicklookorder/logic',
'/home/incra/.qgis/python/plugins/cataloginpequicklookorder/gui',
'/usr/share/qgis/python', '/usr/share/qgis/python/plugins/fTools/tools',
'/media/Arquivos/2012/Territ\xc3\xb3rio Quilombola
Maragogipe/Arquivos_Definitivos']


 


 


Atenciosamente,


 


Israel Ely


Incra-ba


-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: http://lists.osgeo.org/pipermail/brasil/attachments/20120504/6b8ab264/attachment.html
From motta.luiz em gmail.com  Fri May  4 13:16:46 2012
From: motta.luiz em gmail.com (Luiz Motta)
Date: Fri May  4 13:17:03 2012
Subject: [OSGeo-Brasil] Problemas ZipLayer
In-Reply-To: <9ac78295676235bfaf0a0fbe6af8fe6f@webmail.incra.gov.br>
References: <9ac78295676235bfaf0a0fbe6af8fe6f@webmail.incra.gov.br>
Message-ID: <CAC93zU34WYurjpbgQiK5UxzON=DQxdjxyqRJfyQNdAcV4vaGhQ@mail.gmail.com>

Israel,

O Ziplayer cria um shapefile e depois compacta.

O shapefile é composto de 4 arquivos, sendo os três obrigatórios (SHP, DBF
e SHX), o PRJ é gerado quando o layer naão tem projeção.

Ao ler a menssagem de erro, creio que o problema está na codificação dos
caracteres do nome do arquivo a ser gerado.

Favor definir um diretório de saída que não tenha caracteres extendidos,
como exemplo, diretório com acento, teste como exemplo, um diretório
"c:\work".

Para uma maior clareza, procure colocar a fonte do layer original (exemplo
se está num Postgres/Postgis, DXF,....).

Boa sorte,
Luiz




O problema parece ser o nome do  diretório onde vai ser gravado

2012/5/4 Israel Oliveira <israel.ely@sdr.incra.gov.br>

> Estou começando a utilizar o ubuntu 11.1 juntamente com o qgis, e ao
> utilizar o plugin ziplayer ocorre a seguinte mensagem de erro:
>
> Um erro ocorreu enquanto executava o seguinte código Python:
>
> Traceback (most recent call last):
>   File
> "/home/incra/.qgis/python/plugins/ziplayers/logic/ziplayerswidget.py", line
> 61, in __signal_bbMain_clicked
>     self.__createZips(lstIdLayer)
>   File
> "/home/incra/.qgis/python/plugins/ziplayers/logic/ziplayerswidget.py", line
> 92, in __createZips
>     lstIdLayer, self.ui.textEditStatus.append, self.__pb)
>   File "/home/incra/.qgis/python/plugins/ziplayers/logic/cziplayers.py",
> line 217, in createZipLayer
>     self.__zipShapefile(dirWork, fileInfoShape, nameZip, lyr)
>   File "/home/incra/.qgis/python/plugins/ziplayers/logic/cziplayers.py",
> line 171, in __zipShapefile
>     createPrj()
>   File "/home/incra/.qgis/python/plugins/ziplayers/logic/cziplayers.py",
> line 163, in createPrj
>     fw = open(filePrj, 'w')
> IOError: [Errno 84] Multibyte ou caracter largo inválido:
> '/media/Arquivos/2012/Territ\xf3rio Quilombola
> Maragogipe/Arquivos_Definitivos/QuilomboMaragogipeUso.prj'
>
> Versão do Python:
> 2.7.2+ (default, Oct  4 2011, 20:41:12)
> [GCC 4.6.1]
>
>
> Versão do QGIS
> 1.7.4-Wroclaw Wroclaw, exported
>
> Caminho para o Python: ['/home/incra/.qgis/python/plugins/sextante',
> '/usr/share/qgis/python', '/home/incra/.qgis/python',
> '/home/incra/.qgis/python/plugins', '/usr/share/qgis/python/plugins',
> '/usr/lib/python2.7', '/usr/lib/python2.7/plat-linux2',
> '/usr/lib/python2.7/lib-tk', '/usr/lib/python2.7/lib-old',
> '/usr/lib/python2.7/lib-dynload', '/usr/local/lib/python2.7/dist-packages',
> '/usr/lib/python2.7/dist-packages', '/usr/lib/python2.7/dist-packages/PIL',
> '/usr/lib/python2.7/dist-packages/gst-0.10',
> '/usr/lib/python2.7/dist-packages/gtk-2.0', '/usr/lib/pymodules/python2.7',
> '/usr/lib/python2.7/dist-packages/ubuntu-sso-client',
> '/usr/lib/python2.7/dist-packages/ubuntuone-client',
> '/usr/lib/python2.7/dist-packages/ubuntuone-control-panel',
> '/usr/lib/python2.7/dist-packages/ubuntuone-couch',
> '/usr/lib/python2.7/dist-packages/ubuntuone-installer',
> '/usr/lib/python2.7/dist-packages/ubuntuone-storage-protocol',
> '/usr/lib/python2.7/dist-packages/wx-2.8-gtk2-unicode',
> '/home/incra/.qgis/python/plugins/cataloginpecreate/logic',
> '/home/incra/.qgis/python/plugins/cataloginpecreate/gui',
> '/home/incra/.qgis/python/plugins/ziplayers/logic',
> '/home/incra/.qgis/python/plugins/ziplayers/gui',
> '/home/incra/.qgis/python/plugins/imgshowhide/logic',
> '/home/incra/.qgis/python/plugins/imgshowhide/gui',
> '/home/incra/.qgis/python/plugins/cataloginpequicklookorder/logic',
> '/home/incra/.qgis/python/plugins/cataloginpequicklookorder/gui',
> '/usr/share/qgis/python', '/usr/share/qgis/python/plugins/fTools/tools',
> '/media/Arquivos/2012/Territ\xc3\xb3rio Quilombola
> Maragogipe/Arquivos_Definitivos']
>
>
>
>
>
> Atenciosamente,
>
>
>
> Israel Ely
>
> Incra-ba
>
> _______________________________________________
> Brasil mailing list
> Brasil@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/brasil
>
>
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: http://lists.osgeo.org/pipermail/brasil/attachments/20120504/531a1948/attachment.html
From etourigny.dev em gmail.com  Fri May  4 13:37:39 2012
From: etourigny.dev em gmail.com (Etienne Tourigny)
Date: Fri May  4 13:38:24 2012
Subject: =?ISO-8859-1?Q?Re=3A_=5BOSGeo=2DBrasil=5D_Sistemas_de_refer=EAncias_incorret?=
	=?ISO-8859-1?Q?os_no_Proj=2C_GDAL=2FOGR_e_PostGIS?=
In-Reply-To: <4F9968B2.4010905@dpf.gov.br>
References: <4F984A35.2040008@dpf.gov.br>
	<CAC93zU381WNUv-nuR7bz8JXif5tShba20nxCu_3OqCs0uX-ZdA@mail.gmail.com>
	<CA+TxYvNa1uNU2BZSuo2RCnJJPVxN0isn4oaOssT+xBpt_Bnaug@mail.gmail.com>
	<4F9870E2.2090605@dpf.gov.br>
	<CA+TxYvP7BgDh24YLABOuBouaBc8R3bGMEcysjQoNHGAxRU5A3A@mail.gmail.com>
	<4F9968B2.4010905@dpf.gov.br>
Message-ID: <CA+TxYvP22DDdn-uvovOV1eFRjcDf+wJWKqqnQ1vd2EMxr-YVAg@mail.gmail.com>

On Thu, Apr 26, 2012 at 12:24 PM, Daniel Araujo Miranda
<miranda.dam@dpf.gov.br> wrote:
> Realmente, achei o menu que você mencionou:
>
>
>> O EPSG tem entradas de tipo "Coordinate Transformation", voce pode ver
>> no site http://www.epsg-registry.org/ e colocar "Coordinate
>> Transformation"  no campo "Type:" e "sad69" no campo "Name"
>
> Consegui o arquivo SAD96_003.gsb no IBGE (vem junto com o progrid), não
> achei esse arquivo em nenhum outro lugar (inclusive no epsg-registry).

Eu acho que o epsg-registry não tem nenhum "datum shift grids" -
somente parametros towgs84.

O link para os arquivos (junto com progrid) progrid ja esta na pagina
do PROJ.4 http://trac.osgeo.org/proj/

Alguem sabe se podem re-distribuir esses arquivos, ou se tem um link
com os arquivos sem o progid (que é muito pesado e lento para
download)?
Seria interessante (se for legalmente possivel) ter esses arquivos no
site da osgeo junto com os outros de EU, Canada e Australia.

>
> Aparentemente a informação lá está certa, mas o site não fornece os
> parâmetros towgs84 (ou grids).
>
>
>
>
>
> On 04/26/2012 09:55 AM, Etienne Tourigny wrote:
>>
>> On Wed, Apr 25, 2012 at 6:47 PM, Daniel Araujo Miranda
>> <miranda.dam@dpf.gov.br>  wrote:
>>>
>>> Etienne,
>>>  Salvo engano, o spatiareference.org e o epsg.org não têm os parâmetros
>>> de
>>> transformação (dX, dY, dZ, etc.). Você pode confirmar isso? Até baixei a
>>> base de dados em postgresql mas não consegui achar essa informação.
>>>  Se for isso mesmo, não tem como mandar as correções para eles, pois o
>>> problema não é nos elipsóides, é principalmente nos parâmetros de
>>> transformação, e isso eles não têm.
>>>
>>
>> O EPSG tem entradas de tipo "Coordinate Transformation", voce pode ver
>> no site http://www.epsg-registry.org/ e colocar "Coordinate
>> Transformation"  no campo "Type:" e "sad69" no campo "Name"
>>
>> Os dados brutos do EPSG (epsg.org) são a principal fonte de dados para
>> o GDAL/OGR e GeoTIFF.
>>
>>
>> Não se porque spatialreference.org não tem os parametros TOWGS84  ...
>>
>> Na pagina http://spatialreference.org/about/ esta escrito "GDAL and
>> Proj.4 are the backbone of this website", porém o GDAL tem os
>> parametros TOWGS84.
>>
>> O GDAL/OGR tem varios parametros TOWGS84 (no arquivo datum_shift.csv)
>> para cada DATUM, mas usa o "preferred datum" nas consultas:
>>
>> $ gdalsrsinfo EPSG:4618
>>
>> PROJ.4 : '+proj=longlat +ellps=aust_SA +towgs84=-57,1,-41,0,0,0,0 +no_defs
>> '
>>
>> E no arquivo datum_shift.csv:
>>
>> $ grep 4618 /home/soft/share/gdal/datum_shift.csv
>> 13,1864,4618,4326,Derived at 84 stations.,"For military purposes only.
>> Accuracy 15m, 6m and 9m in X, Y and Z
>> axes.",1358,-45,12.51,-81.4,-29.03,1,0,9603,-57,1,-41,,,,,1
>> 14,1865,4618,4326,"Derived at 10 stations. Note: SAD69 not adopted in
>> Argentina: see Campo Inchauspe (CRS code 4221).",For military purposes
>> only. Accuracy 5m in each
>> axis.,3215,-52.43,-21.78,-73.58,-53.65,1,0,9603,-62,-1,-37,,,,,0
>> 15,1866,4618,4326,"Derived at 4 stations. Note: SAD69 not adopted in
>> Bolivia: see PSAD56 (CRS code 4248).",For military purposes. Accuracy
>> 15m in each axis.,1049,-22.9,-9.68,-69.66,-57.52,1,0,9603,-61,2,-48,,,,,0
>> 16,1867,4618,4326,Derived at 22 stations.,"For military purposes only.
>> Accuracy 3m, 5m and 5m in X, Y and Z
>> axes.",3845,-35.71,7.04,-60.57,-29.03,1,0,9603,-60,-2,-41,,,,,0
>> 17,1868,4618,4326,"Derived at 9 stations. Note: SAD69 not adopted in
>> Chile.","For military purposes only. Accuracy 15m, 8m and 11m in X, Y
>> and Z axes.",3227,-45,-17.51,-75.22,-67,1,0,9603,-75,-1,-44,,,,,0
>> 18,1869,4618,4326,"Derived at 7 stations. Note: SAD69 not adopted in
>> Colombia: see Bogota 1975 (CRS code 4218).","For military purposes
>> only. Accuracy 6m, 6m and 5m in X, Y and Z
>> axes.",3229,-4.24,12.51,-79.1,-66.87,1,0,9603,-44,6,-36,,,,,0
>> 19,1870,4618,4326,"Derived at 11 stations. Note: SAD69 not adopted in
>> Ecuador: see PSAD56 (CRS code 4248).",For military purposes. Accuracy
>> 3m in each axis.,3241,-5,1.45,-81.03,-75.22,1,0,9603,-48,3,-44,,,,,0
>> 20,1871,4618,4326,"Derived at 1 station. Note: SAD69 not adopted in
>> Ecuador.",For military purposes. Accuracy 25m in each
>> axis.,2356,-1.41,0.17,-91.71,-89.2,1,0,9603,-47,26,-42,,,,,0
>> 21,1872,4618,4326,"Derived at 5 stations. Note: SAD69 not adopted in
>> Guyana.","For military purposes only. Accuracy 9m, 5m and 5m in X, Y
>> and Z axes.",3259,1.19,8.57,-61.39,-56.47,1,0,9603,-53,3,-47,,,,,0
>> 22,1873,4618,4326,"Derived at 4 stations. Note: SAD69 not adopted in
>> Paraguay.",For military purposes. Accuracy 15m in each
>> axis.,1188,-27.58,-19.3,-62.64,-54.24,1,0,9603,-61,2,-33,,,,,0
>> 23,1874,4618,4326,"Derived at 6 stations. Note: SAD69 not adopted in
>> Peru: see PSAD56 (CRS code 4248).",For military purposes. Accuracy 5m
>> in each axis.,3292,-18.35,-0.04,-81.4,-68.67,1,0,9603,-58,0,-44,,,,,0
>> 24,1875,4618,4326,"Derived at 1 station. Note: SAD69 not adopted in
>> Trinidad and Tobago.",For military purposes only. Accuracy 25m in each
>> axis.,3143,9.99,10.89,-61.97,-60.86,1,0,9603,-45,12,-33,,,,,0
>> 25,1876,4618,4326,"Derived at 5 stations. Note: SAD69 not adopted in
>> Venezuela: see PSAD56 (CRS code 4248).","For military purposes only.
>> Accuracy 3m, 6m and 3m in X, Y and Z
>> axes.",3327,0.65,12.25,-73.38,-59.8,1,0,9603,-45,8,-33,,,,,0
>> 26,1877,4618,4326,"Derived by Brazilian Institute of Geography and
>> Statistics (IBGE) in 1989. Used by ANP. (Note: for historic reasons
>> associated with one-time web url, tfm version uses initials IGBE, not
>> IBGE). Replaced by SAD69 to WGS 84 (15) (tfm code 5528).",Medium and
>> small scale
>> mapping.,3845,-35.71,7.04,-60.57,-29.03,1,0,9603,-66.87,4.37,-38.52,,,,,0
>> 543,1271,4293,4326,"Beware!  Schwarzeck CRS uses German legal metres.
>> Example: Schwarzeck Lat 19d 35m 46.952s S Long 20d 41m 50.649s E;
>> X=5623409.40 Y=2124618.00 Z=-2125847.62 GLM; X=5623485.86 Y=2124646.89
>> Z=-2125876.53 m; WGS84 X=5624101.50 Y=2124748.97 Z=2126132.34
>> m.","?",1169,-31.2,-16.99,8.32,25.28,1,0,9603,615.64,102.08,-255.81,,,,,0
>>
>> abs
>> Etienne
>>
>>> O spatialreference.org tem os parâmetros de alguns. Por exemplo:
>>>  http://spatialreference.org/ref/epsg/4224/
>>> Os parâmetros citados são:
>>>  +proj=longlat +ellps=intl +towgs84=-134,229,-29,0,0,0,0 +no_defs
>>> Se isso for o Astro Chuá mesmo, os parâmetros estão errados.
>>>
>>> No proj4.7 (pacote proj-data):
>>> /usr/share/proj/esri:
>>>  <4224>  +proj=longlat +ellps=intl +towgs84=-134,229,-29,0,0,0,0 +no_defs
>>>  no_defs<>
>>> /usr/share/proj/epsg:
>>>  <4224>  +proj=longlat +ellps=intl +no_defs<>
>>>
>>> Quanto às fontes do proj e postgis: O postgis não especifica (seção 4.3.1
>>> do
>>> manual), e o proj usa diversas fontes. A lista de arquivos do proj dá uma
>>> dica:
>>>
>>> linhas arquivo
>>> 7631   /usr/share/proj/epsg
>>> 5937   /usr/share/proj/esri
>>> 5189   /usr/share/proj/ntv1_can.dat
>>> 2985   /usr/share/proj/alaska
>>>
>>> Por enquanto, estou expondo os parâmetros para o pessoal poder criticar.
>>> Quando tivermos confiança nessas transformações, podemos procurar as
>>> fontes
>>> desse dado para atualizá-lo.
>>>
>>>
>>>
>>> **********************
>>> Aproveito para enviar a primeira errata:
>>> Astro Chuá
>>>       longlat
>>>       4224
>>>       +proj=longlat +a=6378388.0 +rf=297.00
>>> +towgs84=-143.87,+243.37,-33.52
>>>
>>>       http://www.topografia.ufsc.br/Geodesia.pdf (referência não oficial)
>>>
>>> (o sinal do deltaZ estava trocado)
>>> **********************
>>>
>>>
>>>
>>> --Miranda
>>>
>>>
>>>
>>> On 04/25/2012 04:45 PM, Etienne Tourigny wrote:
>>>>
>>>>
>>>> Prezados,
>>>>
>>>> os dados de http://spatialreference.org usam o GDAL/OGR para obter os
>>>> parametros. Eo não tenho certeza sobre a fonte que usam proj.4 e
>>>> postgis.
>>>>
>>>> A fonte de GDAL/OGR é a base EPSG (epgs.org / epsg-registry.org).
>>>> Qualquer erro tem ser ser encaminhado ao EPSG, e esse serà propagado
>>>> ao softwares citados.
>>>>
>>>> Etienne
>>>>
>>>> On Wed, Apr 25, 2012 at 4:24 PM, Luiz Motta<motta.luiz@gmail.com>
>>>>  wrote:
>>>>>
>>>>>
>>>>> Daniel,
>>>>>
>>>>> Vou ver com o Thiago (Terra Legal - MDA/INCRA) como ele está
>>>>> trabalhando
>>>>> com
>>>>> as projeções com Postgis e GDAL/OGR.
>>>>>
>>>>> Os FOSS4G trabalha seguindo a definição da proj4
>>>>> (http://spatialreference.org).
>>>>>
>>>>> Abs
>>>>> Luiz
>>>>>
>>>>> Em 25 de abril de 2012 16:02, Daniel Araujo
>>>>> Miranda<miranda.dam@dpf.gov.br>
>>>>> escreveu:
>>>>>
>>>>>> Caros, fiz uma pesquisa recente e descobri que os parâmetros de
>>>>>> conversão
>>>>>> para diversos sistemas de coordenadas (SRS, CRS) brasileiros estão
>>>>>> incorretos nos seguintes aplicativos:
>>>>>>
>>>>>> Proj4
>>>>>> GDAL/OGR
>>>>>> PostGIS
>>>>>> e talvez outros.
>>>>>>
>>>>>> Eles estão com as mesmas informações que o site
>>>>>> http://spatialreference.org/ (vide a opção proj4 para revelar os
>>>>>> parâmetros
>>>>>> de transformação)
>>>>>>
>>>>>> Levantei os seguintes parâmetros que acredito estarem corretos. Estou
>>>>>> divulgando esses dados aqui para vocês utilizarem se tiverem interesse
>>>>>> e
>>>>>> para criticarem se houver algo errado (Motta, me ajudaria muito se
>>>>>> pelo
>>>>>> menos você desse uma olhada!).
>>>>>>
>>>>>> --Miranda
>>>>>>
>>>>>>
>>>>>> organização:
>>>>>> Datum
>>>>>>        Projeção
>>>>>>        EPSG
>>>>>>        String PROJ
>>>>>>        Referência
>>>>>>
>>>>>>
>>>>>>
>>>>>> sad69 apos 94
>>>>>>        longlat
>>>>>>        4618
>>>>>>        +proj=longlat +a=6378160.0 +rf=298.25
>>>>>> +towgs84=-67.35,+3.88,-38.22
>>>>>>        RPR 01/2005 de 25/02/2005 - IBGE
>>>>>>
>>>>>>
>>>>>> (ftp://geoftp.ibge.gov.br/documentos/geodesia/projeto_mudanca_referencial_geodesico/legislacao/rpr_01_25fev2005.pdf)
>>>>>>
>>>>>> sad69 antes de 94
>>>>>>        longlat
>>>>>>        4291
>>>>>>        +proj=longlat +a=6378160.0 +rf=298.25
>>>>>> +towgs84=-66.87,+4.37,-38.52
>>>>>>        Resolução da Presidência do IBGE n° 23, de 21/02/89 (R.PR
>>>>>> 23/89)
>>>>>> (ftp://geoftp.ibge.gov.br/documentos/geodesia/pdf/rpr_2389.pdf)
>>>>>>
>>>>>> sicad
>>>>>>        longlat
>>>>>>
>>>>>>        +proj=longlat +a=6378388.0 +rf=297.00
>>>>>> +towgs84=-144.35,+242.88,-33.22
>>>>>>        GDF DECRETO 32.575-2010_SICAD-SIRGAS,
>>>>>> www.terracap.df.gov.br/internet/arquivos/0073607515.doc
>>>>>>
>>>>>> sicad
>>>>>>        utm 23s
>>>>>>
>>>>>>        +proj=utm +zone=23 +south +units=m +a=6378388.0 +rf=297.00
>>>>>> +towgs84=-144.35,+242.88,-33.22
>>>>>>        GDF DECRETO 32.575-2010_SICAD-SIRGAS,
>>>>>> www.terracap.df.gov.br/internet/arquivos/0073607515.doc
>>>>>>
>>>>>> Córrego Alegre
>>>>>>        longlat
>>>>>>        4225
>>>>>>        +proj=longlat +a=6378388.0 +rf=297.00
>>>>>> +towgs84=-205.57,+168.77,-4.12
>>>>>>        https://www.mar.mil.br/dhn/chm/download/ita06.pdf, composição
>>>>>> de
>>>>>> ftp://geoftp.ibge.gov.br/documentos/geodesia/pdf/bservico1602.pdf com
>>>>>> ftp://geoftp.ibge.gov.br/documentos/geodesia/pdf/rpr_2389.pdf
>>>>>>
>>>>>> Astro Chuá
>>>>>>        longlat
>>>>>>        4224
>>>>>>        +proj=longlat +a=6378388.0 +rf=297.00
>>>>>> +towgs84=-143.87,+243.37,+33.52
>>>>>>        http://www.topografia.ufsc.br/Geodesia.pdf (referência não
>>>>>> oficial)
From etourigny.dev em gmail.com  Fri May  4 13:43:02 2012
From: etourigny.dev em gmail.com (Etienne Tourigny)
Date: Fri May  4 13:43:11 2012
Subject: =?ISO-8859-1?Q?Re=3A_=5BOSGeo=2DBrasil=5D_Sistemas_de_refer=EAncias_incorret?=
	=?ISO-8859-1?Q?os_no_Proj=2C_GDAL=2FOGR_e_PostGIS?=
In-Reply-To: <4F99BFDE.1070905@dpf.gov.br>
References: <4F984A35.2040008@dpf.gov.br>
	<CAC93zU381WNUv-nuR7bz8JXif5tShba20nxCu_3OqCs0uX-ZdA@mail.gmail.com>
	<CA+TxYvNa1uNU2BZSuo2RCnJJPVxN0isn4oaOssT+xBpt_Bnaug@mail.gmail.com>
	<4F996A42.7030603@dpf.gov.br> <4F99BFDE.1070905@dpf.gov.br>
Message-ID: <CA+TxYvMMin+LcXRU1BpFu-MT9C1t1uJWhpctx602F968FCiRog@mail.gmail.com>

Prezados,

seria muito interessante puder atualizar essas informações nos varios
softwares livres e o registro da EPSG, se realmente está todo
conforme.

Eu sugiro o seguinte:

1) preparar uma wiki com todas as informações (+towgs84 e ntv2 grids),
com referencias ao site da IBGE.
2) consultar a comunidade osgeo (talvez no mailing list de proj4 e
gdal) em Ingles para saber o procedimento. Eu tenho certeza que o F
Warmerdam pode ajudar a gente, entre outros
3) submeter as mudanças para o EPSG e softwares livres como proj.4,
libgeotiff e gdal

abs
Etienne

2012/4/26 Daniel Araujo Miranda <miranda.dam@dpf.gov.br>:
> Caros,
>
> Para adicionar à lista, seguem novas transformações utilizando o método NTv2
> (grids), referentes à dica do Etienne, que indicou onde achar a
> transformação no site epsg-registry.org:
>
>
>> O EPSG tem entradas de tipo "Coordinate Transformation", voce pode ver
>> no site http://www.epsg-registry.org/ e colocar "Coordinate
>> Transformation"  no campo "Type:" e "sad69" no campo "Name"
>
> SAD69 a partir de 95 (EPSG 4618)
>  +proj=longlat +ellps=aust_SA +nadgrids=sad96_003.gsb +nodefs
>
> SAD69 original (EPSG 4291)
>  +proj=longlat +ellps=aust_SA +nadgrids=sad69_003.gsb +nodefs
>
> Córrego alegre 1961 (EPSG 5524)
>  +proj=longlat +ellps=intl +nadgrids=ca61_003.gsb +nodefs
>
> Córrego alegre 1970-72 (EPSG 4225)
>  +proj=longlat +ellps=intl +nadgrids=ca7072_003.gsb +nodefs
>
> Tem um texto em
> "http://www.geobases.es.gov.br/portal/attachments/032_SAD69_SIRGAS2000_ArcGis_NTV2.pdf"
> que compara os dois métodos.
>
> --Miranda
>
> P.S.1: Testei a primeira transformação, e nos pontos testados a diferença
> ficou entre 4cm (Distrito Federal) e 1m (Pará) entre a transformação
> utilizando grids e a utilizando parâmetros towgs84.
>
> P.S.2: Os arquivos *.gsb são distribuídos junto com o sofrware progrid do
> IBGE e devem ser copiados para a pasta "/usr/share/proj" para esses
> parâmetros funcionarem com o proj. AVISO: o proj não dá erro se você
> esquecer de copiar o arquivo ou errar o nome. Cheque os resultados.
>
>
>
> On 04/26/2012 12:31 PM, Daniel Araujo Miranda wrote:
>>
>> Segue a versão mais recente, após contribuição do Israel e errata do
>> Astro chuá.
>>
>> *Sistemas de coordenadas
>>
>> Organização:
>> Datum
>> Projeção
>> Código EPSG
>> String PROJ
>> Referência
>>
>> sad69 a partir de 95
>> longlat
>> 4618
>> +proj=longlat +ellps=aust_SA +towgs84=-67.35,+3.88,-38.22
>> RPR 01/2005 de 25/02/2005 - IBGE
>>
>> (ftp://geoftp.ibge.gov.br/documentos/geodesia/projeto_mudanca_referencial_geodesico/legislacao/rpr_01_25fev2005.pdf)
>>
>>
>> sad69 antes de 95
>> longlat
>> 4291
>> +proj=longlat +ellps=aust_SA +towgs84=-66.87,+4.37,-38.52
>> Resolução da Presidência do IBGE n° 23, de 21/02/89 (R.PR 23/89)
>> (ftp://geoftp.ibge.gov.br/documentos/geodesia/pdf/rpr_2389.pdf)
>>
>> sicad (obs: só aceita zona UTM 23s)
>> longlat
>>
>> +proj=longlat +ellps=intl +towgs84=-144.35,+242.88,-33.22
>> GDF DECRETO 32.575-2010_SICAD-SIRGAS,
>> www.terracap.df.gov.br/internet/arquivos/0073607515.doc
>>
>> Córrego Alegre
>> longlat
>> 4225
>> +proj=longlat +ellps=intl +towgs84=-205.57,+168.77,-4.12
>> https://www.mar.mil.br/dhn/chm/download/ita06.pdf, composição de
>> ftp://geoftp.ibge.gov.br/documentos/geodesia/pdf/bservico1602.pdf com
>> ftp://geoftp.ibge.gov.br/documentos/geodesia/pdf/rpr_2389.pdf
>>
>> Astro Chuá
>> longlat
>> 4224
>> +proj=longlat +ellps=intl +towgs84=-143.87,+243.37,-33.52
>> http://www.topografia.ufsc.br/Geodesia.pdf (referência não oficial)
>>
>>
>> *Elipsóides utilizados
>> aust_SA
>> a=6378160.0
>> rf=298.25
>> Australian Natl & S. Amer. 1969
>>
>> intl
>> a=6378388.0
>> rf=297.0
>> International 1909 (Hayford)
>>
>>
>> *Observações
>> Para utilizar a projeção UTM, substitua
>> "+proj=longlat"
>> pelos parâmetros de projeção, zona e unidades para a zona de interesse.
>> Por exemplo:
>> "+proj=utm +zone=23 +south +units=m" para zona 23s
>> ou
>> "+proj=utm +zone=21 +north +units=m" para zona 21n
>>
>>
>> --Miranda
>>
>> On 04/25/2012 04:45 PM, Etienne Tourigny wrote:
>>>
>>> Prezados,
>>>
>>> os dados de http://spatialreference.org usam o GDAL/OGR para obter os
>>> parametros. Eo não tenho certeza sobre a fonte que usam proj.4 e
>>> postgis.
>>>
>>> A fonte de GDAL/OGR é a base EPSG (epgs.org / epsg-registry.org).
>>> Qualquer erro tem ser ser encaminhado ao EPSG, e esse serà propagado
>>> ao softwares citados.
>>>
>>> Etienne
>>>
>>> On Wed, Apr 25, 2012 at 4:24 PM, Luiz Motta<motta.luiz@gmail.com> wrote:
>>>>
>>>> Daniel,
>>>>
>>>> Vou ver com o Thiago (Terra Legal - MDA/INCRA) como ele está
>>>> trabalhando com
>>>> as projeções com Postgis e GDAL/OGR.
>>>>
>>>> Os FOSS4G trabalha seguindo a definição da proj4
>>>> (http://spatialreference.org).
>>>>
>>>> Abs
>>>> Luiz
>>>>
>>>> Em 25 de abril de 2012 16:02, Daniel Araujo
>>>> Miranda<miranda.dam@dpf.gov.br>
>>>> escreveu:
>>>>
>>>>> Caros, fiz uma pesquisa recente e descobri que os parâmetros de
>>>>> conversão
>>>>> para diversos sistemas de coordenadas (SRS, CRS) brasileiros estão
>>>>> incorretos nos seguintes aplicativos:
>>>>>
>>>>> Proj4
>>>>> GDAL/OGR
>>>>> PostGIS
>>>>> e talvez outros.
>>>>>
>>>>> Eles estão com as mesmas informações que o site
>>>>> http://spatialreference.org/ (vide a opção proj4 para revelar os
>>>>> parâmetros
>>>>> de transformação)
>>>>>
>>>>> Levantei os seguintes parâmetros que acredito estarem corretos. Estou
>>>>> divulgando esses dados aqui para vocês utilizarem se tiverem
>>>>> interesse e
>>>>> para criticarem se houver algo errado (Motta, me ajudaria muito se pelo
>>>>> menos você desse uma olhada!).
>>>>>
>>>>> --Miranda
>>>>>
>>>>>
>>>>> organização:
>>>>> Datum
>>>>> Projeção
>>>>> EPSG
>>>>> String PROJ
>>>>> Referência
>>>>>
>>>>>
>>>>>
>>>>> sad69 apos 94
>>>>> longlat
>>>>> 4618
>>>>> +proj=longlat +a=6378160.0 +rf=298.25 +towgs84=-67.35,+3.88,-38.22
>>>>> RPR 01/2005 de 25/02/2005 - IBGE
>>>>>
>>>>> (ftp://geoftp.ibge.gov.br/documentos/geodesia/projeto_mudanca_referencial_geodesico/legislacao/rpr_01_25fev2005.pdf)
>>>>>
>>>>>
>>>>> sad69 antes de 94
>>>>> longlat
>>>>> 4291
>>>>> +proj=longlat +a=6378160.0 +rf=298.25 +towgs84=-66.87,+4.37,-38.52
>>>>> Resolução da Presidência do IBGE n° 23, de 21/02/89 (R.PR 23/89)
>>>>> (ftp://geoftp.ibge.gov.br/documentos/geodesia/pdf/rpr_2389.pdf)
>>>>>
>>>>> sicad
>>>>> longlat
>>>>>
>>>>> +proj=longlat +a=6378388.0 +rf=297.00
>>>>> +towgs84=-144.35,+242.88,-33.22
>>>>> GDF DECRETO 32.575-2010_SICAD-SIRGAS,
>>>>> www.terracap.df.gov.br/internet/arquivos/0073607515.doc
>>>>>
>>>>> sicad
>>>>> utm 23s
>>>>>
>>>>> +proj=utm +zone=23 +south +units=m +a=6378388.0 +rf=297.00
>>>>> +towgs84=-144.35,+242.88,-33.22
>>>>> GDF DECRETO 32.575-2010_SICAD-SIRGAS,
>>>>> www.terracap.df.gov.br/internet/arquivos/0073607515.doc
>>>>>
>>>>> Córrego Alegre
>>>>> longlat
>>>>> 4225
>>>>> +proj=longlat +a=6378388.0 +rf=297.00
>>>>> +towgs84=-205.57,+168.77,-4.12
>>>>> https://www.mar.mil.br/dhn/chm/download/ita06.pdf, composição de
>>>>> ftp://geoftp.ibge.gov.br/documentos/geodesia/pdf/bservico1602.pdf com
>>>>> ftp://geoftp.ibge.gov.br/documentos/geodesia/pdf/rpr_2389.pdf
>>>>>
>>>>> Astro Chuá
>>>>> longlat
>>>>> 4224
>>>>> +proj=longlat +a=6378388.0 +rf=297.00
>>>>> +towgs84=-143.87,+243.37,+33.52
>>>>> http://www.topografia.ufsc.br/Geodesia.pdf (referência não oficial)
>>>>> _______________________________________________
>>>>> Brasil mailing list
>>>>> Brasil@lists.osgeo.org
>>>>> http://lists.osgeo.org/mailman/listinfo/brasil
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Brasil mailing list
>>>> Brasil@lists.osgeo.org
>>>> http://lists.osgeo.org/mailman/listinfo/brasil
>>>>
>>>
>> _______________________________________________
>> Brasil mailing list
>> Brasil@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/brasil
>>
> _______________________________________________
> Brasil mailing list
> Brasil@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/brasil
From sivoris em hotmail.com  Fri May  4 14:41:58 2012
From: sivoris em hotmail.com (=?iso-8859-1?B?U+12b3JpIFNhcnRpIGRhIFNpbHZh?=)
Date: Fri May  4 14:44:06 2012
Subject: [OSGeo-Brasil] Road Graph
In-Reply-To: <20120504173825.8B5A3E000A2@lists.osgeo.org>
References: <20120504173825.8B5A3E000A2@lists.osgeo.org>
Message-ID: <SNT128-W28BB06B6C8C47722A0E15DA42C0@phx.gbl>


Olá,
alguém sabe informar por qual motivo o aplicativo Road Graph funcionava perfeitamente até a versão 1.7.3 do QGis e na versão 1.7.4 ele não  funciona.
Os botões se sobrepõem e nada funciona. O painél característico não aprece.
Grato.
 		 	   		  
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: http://lists.osgeo.org/pipermail/brasil/attachments/20120504/8ae538de/attachment.html
From israel.ely em sdr.incra.gov.br  Fri May  4 15:26:56 2012
From: israel.ely em sdr.incra.gov.br (israel.ely)
Date: Fri May  4 15:21:43 2012
Subject: [OSGeo-Brasil] Apostila qgis
Message-ID: <4FA42D80.9030309@sdr.incra.gov.br>

Já está disponível no site do incra a apostila utilizada no treinamento 
dos técnicos desta autarquia na elaboração de mapas temáticos com o 
quantum GIS. Durante o ano de 2011 o Técnicos do próprio incra 
promoveram o treinamento de cerca de 440 servidores na utilização do 
quantum GIS para confecção das peças técnicas utilizadas nos processos 
de desapropriação e desenvolvimento dos assentamentos transformando o 
quantum gis em software oficial da divisão de Obtenção de Terras já 
havendo interesse de outros setores desta autarquia para a adoção deste 
programa.

http://www.incra.gov.br/index.php/servicos/publicacoes/manuais-e-procedimentos/file/1193-apostila-qgis-incra-5-versao

-- 

Israel Ely de A. Oliveira
Perito Federal Agrário
INCRA - SR05/BA
(71) 3505-5344 / 5345 / 5337

From andersonmedeiros01 em gmail.com  Fri May 11 09:41:29 2012
From: andersonmedeiros01 em gmail.com (Anderson Medeiros)
Date: Fri May 11 09:41:43 2012
Subject: [OSGeo-Brasil] Re: Backup no PostgreSQL e envio de dados por FTP
In-Reply-To: <CA+1GVOrtCPojsSMRJHmA5Ss9d2S1KTwS-C_Vh8x5CupgCNOzHg@mail.gmail.com>
References: <CA+1GVOrtCPojsSMRJHmA5Ss9d2S1KTwS-C_Vh8x5CupgCNOzHg@mail.gmail.com>
Message-ID: <CA+1GVOohsyZ23k+KV7h+s6iGDqYZ+CMBAevAzbha8Yc-VQVJ4w@mail.gmail.com>

Pessoal, mais alguns detalhes:

O sistema operacional do servidor é Windows Server 2008 R2 Entreprise.
Vejam se podem, por favor, me dar alguma sugestão:

Há como definir no PostgreSQL que o backup seja feito a cada 30 minutos em
vez de apenas uma vez por dia?

Além disso, como faço para enviar os dados de forma automática via FTP.

Sou grato desde já por suas contribuições

[]'s
-- 
Anderson
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: http://lists.osgeo.org/pipermail/brasil/attachments/20120511/26f9efc4/attachment.html
From eduardo.kanegae em gmail.com  Fri May 11 22:07:09 2012
From: eduardo.kanegae em gmail.com (Eduardo Kanegae)
Date: Fri May 11 22:07:49 2012
Subject: [OSGeo-Brasil] Re: Backup no PostgreSQL e envio de dados por FTP
In-Reply-To: <CA+1GVOohsyZ23k+KV7h+s6iGDqYZ+CMBAevAzbha8Yc-VQVJ4w@mail.gmail.com>
References: <CA+1GVOrtCPojsSMRJHmA5Ss9d2S1KTwS-C_Vh8x5CupgCNOzHg@mail.gmail.com>
	<CA+1GVOohsyZ23k+KV7h+s6iGDqYZ+CMBAevAzbha8Yc-VQVJ4w@mail.gmail.com>
Message-ID: <CAF_a5S+1vJ=kovO+8cc4qyz9UBSChRz-TbEPA8mtsRZM-xDn6g@mail.gmail.com>

Anderson,

Infelizmente não é no linux, pois scripting mataria muita coisa.

Mas no windows tente rascunhar algo em torno de:
- utilitarios de backup do proprio PostgreSQL pra gerar dumps ou sql
 --- agendados via bat ou agendador de tarefas
- pesquisar algo sobre conexão FTP com o powershell (.NET)
- tem na net uns binários (linuxtools) que trazem alguns comandos
linux pra uso em windows - também ajuda.

e se precisar consulta via web o FTP, tem o net2ftp

att

Eduardo Patto Kanegae
http://www.webmapit.com | @webmapit


Em 11 de maio de 2012 10:41, Anderson Medeiros
<andersonmedeiros01@gmail.com> escreveu:
>
> Pessoal, mais alguns detalhes:
>
> O sistema operacional do servidor é Windows Server 2008 R2 Entreprise.
> Vejam se podem, por favor, me dar alguma sugestão:
>
> Há como definir no PostgreSQL que o backup seja feito a cada 30 minutos em
> vez de apenas uma vez por dia?
>
> Além disso, como faço para enviar os dados de forma automática via FTP.
>
> Sou grato desde já por suas contribuições
>
> []'s
> --
> Anderson
>
> _______________________________________________
> Brasil mailing list
> Brasil@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/brasil
>
From arthurmolina em yahoo.com.br  Sat May 12 01:30:06 2012
From: arthurmolina em yahoo.com.br (Arthur Molina)
Date: Sat May 12 01:33:21 2012
Subject: [OSGeo-Brasil] Re: Backup no PostgreSQL e envio de dados por FTP
In-Reply-To: <CAF_a5S+1vJ=kovO+8cc4qyz9UBSChRz-TbEPA8mtsRZM-xDn6g@mail.gmail.com>
References: <CA+1GVOrtCPojsSMRJHmA5Ss9d2S1KTwS-C_Vh8x5CupgCNOzHg@mail.gmail.com>
	<CA+1GVOohsyZ23k+KV7h+s6iGDqYZ+CMBAevAzbha8Yc-VQVJ4w@mail.gmail.com>
	<CAF_a5S+1vJ=kovO+8cc4qyz9UBSChRz-TbEPA8mtsRZM-xDn6g@mail.gmail.com>
Message-ID: <1336800606.49723.YahooMailNeo@web161002.mail.bf1.yahoo.com>

Cheguei a fazer algo parecido há um tempo atrás. Mas foi em Delphi usando componente de conexão FTP. 

Gerava o dump (pg_dump) via command line e conectava no ftp que quisesse...
Existe um aplicativopara o windowsque imita o cron do linux ou então usa-se uma aplicação nativa do proprio windows que é o Windows Task Scheduler (Agendador de Tarefas).
Não deve ser dificil fazer um batch, mas acredito que seria mais confiável criar uma aplicação em Delphi ou C# para poder tratar dos erros possíveis ...

abraços,
Arthur





>________________________________
> De: Eduardo Kanegae <eduardo.kanegae@gmail.com>
>Para: brasil@lists.osgeo.org 
>Enviadas: Sexta-feira, 11 de Maio de 2012 23:07
>Assunto: Re: [OSGeo-Brasil] Re: Backup no PostgreSQL e envio de dados por FTP
> 
>Anderson,
>
>Infelizmente não é no linux, pois scripting mataria muita coisa.
>
>Mas no windows tente rascunhar algo em torno de:
>- utilitarios de backup do proprio PostgreSQL pra gerar dumps ou sql
>--- agendados via bat ou agendador de tarefas
>- pesquisar algo sobre conexão FTP com o powershell (.NET)
>- tem na net uns binários (linuxtools) que trazem alguns comandos
>linux pra uso em windows - também ajuda.
>
>e se precisar consulta via web o FTP, tem o net2ftp
>
>att
>
>Eduardo Patto Kanegae
>http://www.webmapit.com | @webmapit
>
>
>Em 11 de maio de 2012 10:41, Anderson Medeiros
><andersonmedeiros01@gmail.com> escreveu:
>>
>> Pessoal, mais alguns detalhes:
>>
>> O sistema operacional do servidor é Windows Server 2008 R2 Entreprise.
>> Vejam se podem, por favor, me dar alguma sugestão:
>>
>> Há como definir no PostgreSQL que o backup seja feito a cada 30 minutos em
>> vez de apenas uma vez por dia?
>>
>> Além disso, como faço para enviar os dados de forma automática via FTP.
>>
>> Sou grato desde já por suas contribuições
>>
>> []'s
>> --
>> Anderson
>>
>> _______________________________________________
>> Brasil mailing list
>> Brasil@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/brasil
>>
>_______________________________________________
>Brasil mailing list
>Brasil@lists.osgeo.org
>http://lists.osgeo.org/mailman/listinfo/brasil
>
>
>
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: http://lists.osgeo.org/pipermail/brasil/attachments/20120511/ef7d17bb/attachment.html
From miranda.dam em dpf.gov.br  Mon May 14 16:06:53 2012
From: miranda.dam em dpf.gov.br (Daniel Araujo Miranda)
Date: Mon May 14 16:08:40 2012
Subject: [OSGeo-Brasil] Sistemas de =?ISO-8859-1?Q?refer=EAncias_in?=
	=?ISO-8859-1?Q?corretos_no_Proj=2C_GDAL/OGR_e_PostGIS?=
In-Reply-To: <CA+TxYvMMin+LcXRU1BpFu-MT9C1t1uJWhpctx602F968FCiRog@mail.gmail.com>
References: <4F984A35.2040008@dpf.gov.br>
	<CAC93zU381WNUv-nuR7bz8JXif5tShba20nxCu_3OqCs0uX-ZdA@mail.gmail.com>
	<CA+TxYvNa1uNU2BZSuo2RCnJJPVxN0isn4oaOssT+xBpt_Bnaug@mail.gmail.com>
	<4F996A42.7030603@dpf.gov.br> <4F99BFDE.1070905@dpf.gov.br>
	<CA+TxYvMMin+LcXRU1BpFu-MT9C1t1uJWhpctx602F968FCiRog@mail.gmail.com>
Message-ID: <4FB165DD.1030501@dpf.gov.br>

Criei uma página na wiki da osgeo com o conteúdo discutido aqui:

  http://wiki.osgeo.org/wiki/Brazilian_Coordinate_Reference_Systems

A página está aberta para quem quiser completar ou fazer correções.

Acho que esta lista teria autoridade para formar consenso e pedir as 
alterações.

Transcrevo abaixo um e-mail do Frank do dia 27/04:

>> On a different note, I started a discussion in brasil@lists.osgeo.org about
>> the transformation parameters bundled with proj, postgis, quantumgis, and
>> others for some EPSG codes used in Brazil (4618, 4291, 4225 and 4224, plus
>> one more that does not have an EPSG code (SR-ORG:6664)). Is it possible,
>> given that the list eventually reaches consensus on the parameters, to fix
>> the transformations in the upstream of proj/postgis?
> It is best if you (as a community) can ask me (via ticket) to prefer some
> particular datum transformation out of the list published by EPSG rather
> than override them completely.  So if the consensus transformation isn't
> in the EPSG dictionary it would be nice to push it in upstream.
>
> That said, yes, I am open to improvements of this nature.  The ticket
> on the issue is can be filed against PROJ.4, GDAL or libgeotiff.  The
> actual override is normally done in libgeotiff which is the root of my
> EPSG dictionary translation process.
>
> Best regards,
> -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush    | Geospatial Software Developer


Alguém achou algum erro nas transformações? Alguém pode confirmar mais 
alguma além do SAD69 mais recente? (vide 
http://wiki.osgeo.org/wiki/Brazilian_Coordinate_Reference_Systems para a 
última versão)

Um abraço,
--Miranda



On 05/04/2012 02:43 PM, Etienne Tourigny wrote:
> Prezados,
>
> seria muito interessante puder atualizar essas informações nos varios
> softwares livres e o registro da EPSG, se realmente está todo
> conforme.
>
> Eu sugiro o seguinte:
>
> 1) preparar uma wiki com todas as informações (+towgs84 e ntv2 grids),
> com referencias ao site da IBGE.
> 2) consultar a comunidade osgeo (talvez no mailing list de proj4 e
> gdal) em Ingles para saber o procedimento. Eu tenho certeza que o F
> Warmerdam pode ajudar a gente, entre outros
> 3) submeter as mudanças para o EPSG e softwares livres como proj.4,
> libgeotiff e gdal
>
> abs
> Etienne
>
From etourigny.dev em gmail.com  Mon May 14 16:29:26 2012
From: etourigny.dev em gmail.com (Etienne Tourigny)
Date: Mon May 14 16:29:56 2012
Subject: =?ISO-8859-1?Q?Re=3A_=5BOSGeo=2DBrasil=5D_Sistemas_de_refer=EAncias_incorret?=
	=?ISO-8859-1?Q?os_no_Proj=2C_GDAL=2FOGR_e_PostGIS?=
In-Reply-To: <4FB165DD.1030501@dpf.gov.br>
References: <4F984A35.2040008@dpf.gov.br>
	<CAC93zU381WNUv-nuR7bz8JXif5tShba20nxCu_3OqCs0uX-ZdA@mail.gmail.com>
	<CA+TxYvNa1uNU2BZSuo2RCnJJPVxN0isn4oaOssT+xBpt_Bnaug@mail.gmail.com>
	<4F996A42.7030603@dpf.gov.br> <4F99BFDE.1070905@dpf.gov.br>
	<CA+TxYvMMin+LcXRU1BpFu-MT9C1t1uJWhpctx602F968FCiRog@mail.gmail.com>
	<4FB165DD.1030501@dpf.gov.br>
Message-ID: <CA+TxYvNh_ZcCONRH9mL2YuUbXp6gFn-JeuNLgsLUtrT4QDk8mA@mail.gmail.com>

Daniel,

parece muito bom.  Eu acho que as informações cruciais (parametros,
etc.) devem e podem ser em inglês, para todos poderem entender.

Voce quer que eu traduz para o Inglês?  Caso positivo, voce quer uma
versão em Português ou o Inglês é suficiente?

Etienne

On Mon, May 14, 2012 at 5:06 PM, Daniel Araujo Miranda
<miranda.dam@dpf.gov.br> wrote:
> Criei uma página na wiki da osgeo com o conteúdo discutido aqui:
>
>  http://wiki.osgeo.org/wiki/Brazilian_Coordinate_Reference_Systems
>
> A página está aberta para quem quiser completar ou fazer correções.
>
> Acho que esta lista teria autoridade para formar consenso e pedir as
> alterações.
>
> Transcrevo abaixo um e-mail do Frank do dia 27/04:
>
>>> On a different note, I started a discussion in brasil@lists.osgeo.org
>>> about
>>> the transformation parameters bundled with proj, postgis, quantumgis, and
>>> others for some EPSG codes used in Brazil (4618, 4291, 4225 and 4224,
>>> plus
>>> one more that does not have an EPSG code (SR-ORG:6664)). Is it possible,
>>> given that the list eventually reaches consensus on the parameters, to
>>> fix
>>> the transformations in the upstream of proj/postgis?
>>
>> It is best if you (as a community) can ask me (via ticket) to prefer some
>> particular datum transformation out of the list published by EPSG rather
>> than override them completely.  So if the consensus transformation isn't
>> in the EPSG dictionary it would be nice to push it in upstream.
>>
>> That said, yes, I am open to improvements of this nature.  The ticket
>> on the issue is can be filed against PROJ.4, GDAL or libgeotiff.  The
>> actual override is normally done in libgeotiff which is the root of my
>> EPSG dictionary translation process.
>>
>> Best regards,
>> --
>> ---------------------------------------+--------------------------------------
>> I set the clouds in motion - turn up   | Frank Warmerdam,
>> warmerdam@pobox.com light and sound - activate the windows |
>> http://pobox.com/~warmerdam and watch the world go round - Rush    |
>> Geospatial Software Developer
>
>
>
> Alguém achou algum erro nas transformações? Alguém pode confirmar mais
> alguma além do SAD69 mais recente? (vide
> http://wiki.osgeo.org/wiki/Brazilian_Coordinate_Reference_Systems para a
> última versão)
>
> Um abraço,
> --Miranda
>
>
>
>
> On 05/04/2012 02:43 PM, Etienne Tourigny wrote:
>>
>> Prezados,
>>
>> seria muito interessante puder atualizar essas informações nos varios
>> softwares livres e o registro da EPSG, se realmente está todo
>> conforme.
>>
>> Eu sugiro o seguinte:
>>
>> 1) preparar uma wiki com todas as informações (+towgs84 e ntv2 grids),
>> com referencias ao site da IBGE.
>> 2) consultar a comunidade osgeo (talvez no mailing list de proj4 e
>> gdal) em Ingles para saber o procedimento. Eu tenho certeza que o F
>> Warmerdam pode ajudar a gente, entre outros
>> 3) submeter as mudanças para o EPSG e softwares livres como proj.4,
>> libgeotiff e gdal
>>
>> abs
>> Etienne
>>
>
From miranda.dam em dpf.gov.br  Mon May 14 17:12:25 2012
From: miranda.dam em dpf.gov.br (Daniel Araujo Miranda)
Date: Mon May 14 17:13:29 2012
Subject: [OSGeo-Brasil] Sistemas de =?ISO-8859-1?Q?refer=EAncias_in?=
	=?ISO-8859-1?Q?corretos_no_Proj=2C_GDAL/OGR_e_PostGIS?=
In-Reply-To: <CA+TxYvNh_ZcCONRH9mL2YuUbXp6gFn-JeuNLgsLUtrT4QDk8mA@mail.gmail.com>
References: <4F984A35.2040008@dpf.gov.br>
	<CAC93zU381WNUv-nuR7bz8JXif5tShba20nxCu_3OqCs0uX-ZdA@mail.gmail.com>
	<CA+TxYvNa1uNU2BZSuo2RCnJJPVxN0isn4oaOssT+xBpt_Bnaug@mail.gmail.com>
	<4F996A42.7030603@dpf.gov.br> <4F99BFDE.1070905@dpf.gov.br>
	<CA+TxYvMMin+LcXRU1BpFu-MT9C1t1uJWhpctx602F968FCiRog@mail.gmail.com>
	<4FB165DD.1030501@dpf.gov.br>
	<CA+TxYvNh_ZcCONRH9mL2YuUbXp6gFn-JeuNLgsLUtrT4QDk8mA@mail.gmail.com>
Message-ID: <4FB17539.7080203@dpf.gov.br>

Boa idéia, fique à vontade. Traduzir os parâmetros não prejudica o 
entendimento dos brasileiros e ajuda os demais.

É bom ter só uma versão em inglês, para evitar retrabalho e possíveis erros.


On 05/14/2012 05:29 PM, Etienne Tourigny wrote:
> Daniel,
>
> parece muito bom.  Eu acho que as informações cruciais (parametros,
> etc.) devem e podem ser em inglês, para todos poderem entender.
>
> Voce quer que eu traduz para o Inglês?  Caso positivo, voce quer uma
> versão em Português ou o Inglês é suficiente?
>
> Etienne
>
> On Mon, May 14, 2012 at 5:06 PM, Daniel Araujo Miranda
> <miranda.dam@dpf.gov.br>  wrote:
>> Criei uma página na wiki da osgeo com o conteúdo discutido aqui:
>>
>>   http://wiki.osgeo.org/wiki/Brazilian_Coordinate_Reference_Systems
>>
>> A página está aberta para quem quiser completar ou fazer correções.
>>
>> Acho que esta lista teria autoridade para formar consenso e pedir as
>> alterações.
>>
>> Transcrevo abaixo um e-mail do Frank do dia 27/04:
>>
>>>> On a different note, I started a discussion in brasil@lists.osgeo.org
>>>> about
>>>> the transformation parameters bundled with proj, postgis, quantumgis, and
>>>> others for some EPSG codes used in Brazil (4618, 4291, 4225 and 4224,
>>>> plus
>>>> one more that does not have an EPSG code (SR-ORG:6664)). Is it possible,
>>>> given that the list eventually reaches consensus on the parameters, to
>>>> fix
>>>> the transformations in the upstream of proj/postgis?
>>>
>>> It is best if you (as a community) can ask me (via ticket) to prefer some
>>> particular datum transformation out of the list published by EPSG rather
>>> than override them completely.  So if the consensus transformation isn't
>>> in the EPSG dictionary it would be nice to push it in upstream.
>>>
>>> That said, yes, I am open to improvements of this nature.  The ticket
>>> on the issue is can be filed against PROJ.4, GDAL or libgeotiff.  The
>>> actual override is normally done in libgeotiff which is the root of my
>>> EPSG dictionary translation process.
>>>
>>> Best regards,
>>> --
>>> ---------------------------------------+--------------------------------------
>>> I set the clouds in motion - turn up   | Frank Warmerdam,
>>> warmerdam@pobox.com light and sound - activate the windows |
>>> http://pobox.com/~warmerdam and watch the world go round - Rush    |
>>> Geospatial Software Developer
>>
>>
>>
>> Alguém achou algum erro nas transformações? Alguém pode confirmar mais
>> alguma além do SAD69 mais recente? (vide
>> http://wiki.osgeo.org/wiki/Brazilian_Coordinate_Reference_Systems para a
>> última versão)
>>
>> Um abraço,
>> --Miranda
>>
>>
>>
>>
>> On 05/04/2012 02:43 PM, Etienne Tourigny wrote:
>>>
>>> Prezados,
>>>
>>> seria muito interessante puder atualizar essas informações nos varios
>>> softwares livres e o registro da EPSG, se realmente está todo
>>> conforme.
>>>
>>> Eu sugiro o seguinte:
>>>
>>> 1) preparar uma wiki com todas as informações (+towgs84 e ntv2 grids),
>>> com referencias ao site da IBGE.
>>> 2) consultar a comunidade osgeo (talvez no mailing list de proj4 e
>>> gdal) em Ingles para saber o procedimento. Eu tenho certeza que o F
>>> Warmerdam pode ajudar a gente, entre outros
>>> 3) submeter as mudanças para o EPSG e softwares livres como proj.4,
>>> libgeotiff e gdal
>>>
>>> abs
>>> Etienne
>>>
>>
>
From etourigny.dev em gmail.com  Mon May 14 20:59:59 2012
From: etourigny.dev em gmail.com (Etienne Tourigny)
Date: Mon May 14 21:00:23 2012
Subject: =?ISO-8859-1?Q?Re=3A_=5BOSGeo=2DBrasil=5D_Sistemas_de_refer=EAncias_incorret?=
	=?ISO-8859-1?Q?os_no_Proj=2C_GDAL=2FOGR_e_PostGIS?=
In-Reply-To: <4FB17539.7080203@dpf.gov.br>
References: <4F984A35.2040008@dpf.gov.br>
	<CAC93zU381WNUv-nuR7bz8JXif5tShba20nxCu_3OqCs0uX-ZdA@mail.gmail.com>
	<CA+TxYvNa1uNU2BZSuo2RCnJJPVxN0isn4oaOssT+xBpt_Bnaug@mail.gmail.com>
	<4F996A42.7030603@dpf.gov.br> <4F99BFDE.1070905@dpf.gov.br>
	<CA+TxYvMMin+LcXRU1BpFu-MT9C1t1uJWhpctx602F968FCiRog@mail.gmail.com>
	<4FB165DD.1030501@dpf.gov.br>
	<CA+TxYvNh_ZcCONRH9mL2YuUbXp6gFn-JeuNLgsLUtrT4QDk8mA@mail.gmail.com>
	<4FB17539.7080203@dpf.gov.br>
Message-ID: <CA+TxYvMUu7mwbcOcfi3_7tNGwXv=Ag6On7ih2a-2_qZ_PgTb8g@mail.gmail.com>

Eu traduz tudo exceto as dicas no final e acrescentei algumas coisas.
Faltam informação sobre o SIRGAS2000 e alguns parametros e
informações.

Etienne

2012/5/14 Daniel Araujo Miranda <miranda.dam@dpf.gov.br>:
> Boa idéia, fique à vontade. Traduzir os parâmetros não prejudica o
> entendimento dos brasileiros e ajuda os demais.
>
> É bom ter só uma versão em inglês, para evitar retrabalho e possíveis erros.
>
>
>
> On 05/14/2012 05:29 PM, Etienne Tourigny wrote:
>>
>> Daniel,
>>
>> parece muito bom.  Eu acho que as informações cruciais (parametros,
>> etc.) devem e podem ser em inglês, para todos poderem entender.
>>
>> Voce quer que eu traduz para o Inglês?  Caso positivo, voce quer uma
>> versão em Português ou o Inglês é suficiente?
>>
>> Etienne
>>
>> On Mon, May 14, 2012 at 5:06 PM, Daniel Araujo Miranda
>> <miranda.dam@dpf.gov.br>  wrote:
>>>
>>> Criei uma página na wiki da osgeo com o conteúdo discutido aqui:
>>>
>>>  http://wiki.osgeo.org/wiki/Brazilian_Coordinate_Reference_Systems
>>>
>>> A página está aberta para quem quiser completar ou fazer correções.
>>>
>>> Acho que esta lista teria autoridade para formar consenso e pedir as
>>> alterações.
>>>
>>> Transcrevo abaixo um e-mail do Frank do dia 27/04:
>>>
>>>>> On a different note, I started a discussion in brasil@lists.osgeo.org
>>>>> about
>>>>> the transformation parameters bundled with proj, postgis, quantumgis,
>>>>> and
>>>>> others for some EPSG codes used in Brazil (4618, 4291, 4225 and 4224,
>>>>> plus
>>>>> one more that does not have an EPSG code (SR-ORG:6664)). Is it
>>>>> possible,
>>>>> given that the list eventually reaches consensus on the parameters, to
>>>>> fix
>>>>> the transformations in the upstream of proj/postgis?
>>>>
>>>>
>>>> It is best if you (as a community) can ask me (via ticket) to prefer
>>>> some
>>>> particular datum transformation out of the list published by EPSG rather
>>>> than override them completely.  So if the consensus transformation isn't
>>>> in the EPSG dictionary it would be nice to push it in upstream.
>>>>
>>>> That said, yes, I am open to improvements of this nature.  The ticket
>>>> on the issue is can be filed against PROJ.4, GDAL or libgeotiff.  The
>>>> actual override is normally done in libgeotiff which is the root of my
>>>> EPSG dictionary translation process.
>>>>
>>>> Best regards,
>>>> --
>>>>
>>>> ---------------------------------------+--------------------------------------
>>>> I set the clouds in motion - turn up   | Frank Warmerdam,
>>>> warmerdam@pobox.com light and sound - activate the windows |
>>>> http://pobox.com/~warmerdam and watch the world go round - Rush    |
>>>> Geospatial Software Developer
>>>
>>>
>>>
>>>
>>> Alguém achou algum erro nas transformações? Alguém pode confirmar mais
>>> alguma além do SAD69 mais recente? (vide
>>> http://wiki.osgeo.org/wiki/Brazilian_Coordinate_Reference_Systems para a
>>> última versão)
>>>
>>> Um abraço,
>>> --Miranda
>>>
>>>
>>>
>>>
>>> On 05/04/2012 02:43 PM, Etienne Tourigny wrote:
>>>>
>>>>
>>>> Prezados,
>>>>
>>>> seria muito interessante puder atualizar essas informações nos varios
>>>> softwares livres e o registro da EPSG, se realmente está todo
>>>> conforme.
>>>>
>>>> Eu sugiro o seguinte:
>>>>
>>>> 1) preparar uma wiki com todas as informações (+towgs84 e ntv2 grids),
>>>> com referencias ao site da IBGE.
>>>> 2) consultar a comunidade osgeo (talvez no mailing list de proj4 e
>>>> gdal) em Ingles para saber o procedimento. Eu tenho certeza que o F
>>>> Warmerdam pode ajudar a gente, entre outros
>>>> 3) submeter as mudanças para o EPSG e softwares livres como proj.4,
>>>> libgeotiff e gdal
>>>>
>>>> abs
>>>> Etienne
>>>>
>>>
>>
>
From fsq em univali.br  Tue May 15 12:51:12 2012
From: fsq em univali.br (Fernando Quadro)
Date: Tue May 15 12:52:52 2012
Subject: [OSGeo-Brasil] =?utf-8?q?Tradu=C3=A7=C3=A3o_do_GeoServer_para_o_?=
 =?utf-8?q?Portugu=C3=AAs_Brasileiro?=
Message-ID: <1d96561a4d9b25f9102595aa96b9bbf8@localhost>


Pessoal,

O que acham de termos novamente o GeoServer em português, digo novamente,
pois antes da versão 2.x ser lançada, o GeoServer possuia versão na lingua
portuguesa. Com as mudanças de versão, foram criados diversos novos
arquivos properties e o GeoServer acabou perdendo a sua versão em
português. 

Porém, existe um projeto para traduzir o GeoServer para diversas linguas,
e uma delas é o pt-BR. Então convido a quem tiver interesse se cadastrar
no
site abaixo e começar a tradução.

http://translate.geoserver.1os.su/project/geoserver/pt-BR

A ferramenta é muito interessante, e se algumas pessoas estiverem
dispostas, acredito que o trabalho não fique tão árduo.

-- 
Fernando Quadro
http://www.fernandoquadro.com.br
twitter.com/fernandoquadro
From pablotcarreira em gmail.com  Wed May 16 08:04:15 2012
From: pablotcarreira em gmail.com (Pablo Carreira)
Date: Wed May 16 08:04:55 2012
Subject: =?ISO-8859-1?Q?Re=3A_=5BOSGeo=2DBrasil=5D_Tradu=E7=E3o_do_GeoServer_para_o_Po?=
	=?ISO-8859-1?Q?rtugu=EAs_Brasileiro?=
In-Reply-To: <1d96561a4d9b25f9102595aa96b9bbf8@localhost>
References: <1d96561a4d9b25f9102595aa96b9bbf8@localhost>
Message-ID: <CAFsRgV=c+Dn=F9wd8FXmLdRtGpwnXvopwBO-1z5odHnQC8Qt6A@mail.gmail.com>

Legal, a ferramenta é muito boa mesmo.
Vamos contribuir pessoal.

Abraços.

Em 15 de maio de 2012 13:51, Fernando Quadro <fsq@univali.br> escreveu:

>
> Pessoal,
>
> O que acham de termos novamente o GeoServer em português, digo novamente,
> pois antes da versão 2.x ser lançada, o GeoServer possuia versão na lingua
> portuguesa. Com as mudanças de versão, foram criados diversos novos
> arquivos properties e o GeoServer acabou perdendo a sua versão em
> português.
>
> Porém, existe um projeto para traduzir o GeoServer para diversas linguas,
> e uma delas é o pt-BR. Então convido a quem tiver interesse se cadastrar
> no
> site abaixo e começar a tradução.
>
> http://translate.geoserver.1os.su/project/geoserver/pt-BR
>
> A ferramenta é muito interessante, e se algumas pessoas estiverem
> dispostas, acredito que o trabalho não fique tão árduo.
>
> --
> Fernando Quadro
> http://www.fernandoquadro.com.br
> twitter.com/fernandoquadro
>
> _______________________________________________
> Brasil mailing list
> Brasil@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/brasil
>
>


-- 
Pablo T. Carreira
19 93462359
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: http://lists.osgeo.org/pipermail/brasil/attachments/20120516/46665e2a/attachment.html
From andersonmedeiros01 em gmail.com  Fri May 11 09:05:05 2012
From: andersonmedeiros01 em gmail.com (Anderson Medeiros)
Date: Thu May 17 09:31:02 2012
Subject: [OSGeo-Brasil] Backup no PostgreSQL e envio de dados por FTP
Message-ID: <CA+1GVOrtCPojsSMRJHmA5Ss9d2S1KTwS-C_Vh8x5CupgCNOzHg@mail.gmail.com>

Pessoal, vejam se podem, por favor, me dar alguma sugestão:

Há como definir que o backup seja feito a cada 30 minutos em vez de apenas
uma vez por dia?

Além disso, como faço para enviar os dados de forma automática via FTP.

Obrigado desde já por suas sugestões. Abraço!

-- 
Anderson
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: http://lists.osgeo.org/pipermail/brasil/attachments/20120511/70dbb27a/attachment.html
From press em gvsig.com  Thu May 17 06:30:25 2012
From: press em gvsig.com (gvSIG News Office)
Date: Thu May 17 09:31:03 2012
Subject: [OSGeo-Brasil] =?iso-8859-1?q?4as_Jornadas_da_Am=E9rica_Latina_e?=
	=?iso-8859-1?q?_do_Caribe_de_gvSIG=3A_=22Crescendo_em_comunidade?=
	=?iso-8859-1?q?=22?=
Message-ID: <E43C32BC5843E34FB4C00CDFAAAAF7D802C4E6FB@australia.prodevelop.local>



No período de 24 a 28 de setembro de 2012 se realizarão as 4as. Jornadas da América Latina e do Caribe de gvSIG (LAC) [1], em Montevidéu – Uruguai, sob o lema “Crescendo em comunidade”. 

As Jornadas da América Latina e do Caribe de gvSIG têm como objetivo proporcionar um ponto de encontro onde técnicos, pesquisadores, desenvolvedores, expertos, e a comunidade latinoamericana em geral possam debater e discutir temas relacionados à geomática livre e ao gvSIG.

Estas jornadas serão, por sua vez, as 2as. Jornadas Uruguaias de gvSIG, onde se terá a oportunidade de reunir novamente os participantes das primeiras Jornadas Uruguaias de gvSIG, realizadas em Montevidéu – Faculdade de Arquitetura, em 2011.

Já está aberto o período para  envio de propostas para comunicações para as Jornadas. A partir de hoje as comunicações podem ser enviadas ao seguinte endereço eletrônico: jornadas.latinoamericanas@gvsig.org. O comitê científico avaliará sua inclusão no programa das Jornadas. Existem duas modalidades de comunicação: apresentação oral e pôster. Toda as informações sobre as normas para a apresentação de comunicações podem ser consultadas no tópico comunicações [2]. O período de submissão de resumos se encerra no dia 30 de julho.

[1] http://www.gvsig.org/web/community/events/jornadas-lac/2012
[2] http://www.gvsig.org/web/community/events/jornadas-lac/2012/comunicacoes
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: http://lists.osgeo.org/pipermail/brasil/attachments/20120517/a7761397/attachment.html
From israel.ely em sdr.incra.gov.br  Fri May 18 10:43:51 2012
From: israel.ely em sdr.incra.gov.br (israel.ely)
Date: Fri May 18 10:38:29 2012
Subject: [OSGeo-Brasil] Atlas plugin Qgis
Message-ID: <4FB66027.7050808@sdr.incra.gov.br>

Coloquei um tutorial para impressão de mapas no quantumGIS utilizando o 
Atlas plugin no site http://www.ebah.com.br/, esse plugin pega um mapa e 
divide em várias folhas, podemos pegar um mapa que seria impresso em 
formato A2 e dividir em 4 folhas do formato A4, por exemplo, utilizando 
a mesma escala.

-- 
Israel Ely de A. Oliveira
Perito Federal Agrário
INCRA - SR05/BA
(71) 3505-5344 / 5345 / 5337

From etourigny.dev em gmail.com  Fri May 18 10:47:14 2012
From: etourigny.dev em gmail.com (Etienne Tourigny)
Date: Fri May 18 10:47:27 2012
Subject: [OSGeo-Brasil] Atlas plugin Qgis
In-Reply-To: <4FB66027.7050808@sdr.incra.gov.br>
References: <4FB66027.7050808@sdr.incra.gov.br>
Message-ID: <CA+TxYvMUW=VWaJc3a9irMpJn8i1G=jq2DCR=dRkAmEqa=qvBVg@mail.gmail.com>

Israel - voce não mandou o link para o tutorial...

2012/5/18 israel.ely <israel.ely@sdr.incra.gov.br>:
> Coloquei um tutorial para impressão de mapas no quantumGIS utilizando o
> Atlas plugin no site http://www.ebah.com.br/, esse plugin pega um mapa e
> divide em várias folhas, podemos pegar um mapa que seria impresso em formato
> A2 e dividir em 4 folhas do formato A4, por exemplo, utilizando a mesma
> escala.
>
> --
> Israel Ely de A. Oliveira
> Perito Federal Agrário
> INCRA - SR05/BA
> (71) 3505-5344 / 5345 / 5337
>
> _______________________________________________
> Brasil mailing list
> Brasil@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/brasil
From israel.ely em sdr.incra.gov.br  Mon May 21 08:28:21 2012
From: israel.ely em sdr.incra.gov.br (israel.ely)
Date: Mon May 21 08:23:02 2012
Subject: [OSGeo-Brasil] Atlas Plugin
Message-ID: <4FBA34E5.4000808@sdr.incra.gov.br>

O site é de uma rede social com vários arquivos acaemicos e 
técnicos...vc se cadastra e coloca o nome do material na busca....mesmo 
assim segue o link abaixo:

http://www.ebah.com.br/content/ABAAAfJzMAL/elaboracao-mapas-tematicos-no-quantum-gis

-- 
Israel Ely de A. Oliveira
Perito Federal Agrário
INCRA - SR05/BA
(71) 3505-5344 / 5345 / 5337

From israel.ely em sdr.incra.gov.br  Mon May 21 08:37:00 2012
From: israel.ely em sdr.incra.gov.br (israel.ely)
Date: Mon May 21 08:31:13 2012
Subject: [OSGeo-Brasil] =?iso-8859-1?q?Corre=E7=E3o_do_link?=
Message-ID: <4FBA36EC.8080803@sdr.incra.gov.br>

Desculpem, mandei o link de outro material que está nesse site, segue 
abaixo o link correto:

http://www.ebah.com.br/content/ABAAAfJzgAA/manual-plugin-atlas-qgis

-- 
Israel Ely de A. Oliveira
Perito Federal Agrário
INCRA - SR05/BA
(71) 3505-5344 / 5345 / 5337

From israel.ely em sdr.incra.gov.br  Thu May 24 10:54:42 2012
From: israel.ely em sdr.incra.gov.br (israel.ely)
Date: Thu May 24 10:49:06 2012
Subject: [OSGeo-Brasil] =?iso-8859-1?q?Par=E2metros_de_proje=E7=E3o?=
Message-ID: <4FBE4BB2.9090709@sdr.incra.gov.br>

Oi Helder, tudo bem? Olá a todos!

Calma, calma Helder! rs
Se você pegar um par de coordenadas em SIRGAS e converter para SAD69 
utilizando o TCGEO encontrará as mesmas coordenadas que utilizando a 
conversão de SIRGAS para SAD (com os parâmetros configurados) no Quantum 
GIS. Já utilizando o GRS67 dá uma diferença de milímetros. Quando estava 
montando a primeira apostila eu também fiquei em dúvida e testei isso 
dezenas de vezes. E diga-se de passagem dezenas de outras pessoas também 
testaram

Uma das explicações (manuais Terra Legal) é que O desvio resultante para 
a definição que utiliza o elipsóide GRS67 é inferior a 5cm (projeção 
UTM), enquanto que utilizando o "aust_SA" é nulo até a casa dos 
milímetros (projeção UTM).

Testei e constatei, mas se a colega Ana quiser maiores explicações 
sugiro que entre em contato com thiago.marra@incra.gov.br

Marília.


Em 24/5/2012 09:03, helder.santos@sdr.incra.gov.br escreveu:
> Cara Ana, bom dia!
>
> Obrigado pela pergunta.
> Informo que deve ter ocorrido um falha na hora de copiar os parâmetros 
> do Quantum GIS. O correto seria utilizar o elipsoide GRS 67.
> Os parâmetros corretos seguem no arquivo txt em anexo.
> Em breve providenciaremos as correções na apostila.
>
> Muito obrigado,
>
> Hélder Gramacho dos Santos
> Perito Federal Agrário/Engenheiro Agrônomo
> INCRA/SR-05/Divisão de Obtenção de Terras
> Av.Ulisses Guimarães, 640 - Centro Administrativo
> Salvador Bahia CEP: 41746-900 tel:(71)3505-5344
> e-mail:helder.santos@sdr.incra.gov.br  <mailto:helder.santos@sdr.incra.gov.br>  
>
> On 22/05/2012 15:40, Ana Correia wrote:
>>
>> Olá, boa tarde!
>>
>> Trabalho na SR-29 (Petrolina), no cargo de Analista em Reforma e 
>> Desenvolvimento Agrário - Engenharia Cartográfica e fui nomeada agora 
>> neste último concurso.
>>
>> Surgiu uma dúvida em relação aos parâmetros de transformação do QGIS 
>> e gostaríamos de obter uma resposta.
>>
>> O QGIS não oferece os parâmetros de transformação de SAD69 para 
>> SIRGAS2000, mas permite que configuremos um novo SRC.
>>
>> No arquivo "*parâmetros transformação resolução 1_2005 IBGE.txt*", 
>> fornecido junto com o material do treinamento, foram configurados 
>> novos SRC com o *elipsóide aust_SA*, conforme se vê abaixo:
>>
>> SAD69_UTM18_IBGE
>> +proj=utm +zone=18 +south +ellps=aust_SA +towgs84=-67.35,3.88,-38.22 
>> +units=m +no_defs
>> SAD69_UTM19_IBGE
>> +proj=utm +zone=19 +south +ellps=aust_SA +towgs84=-67.35,3.88,-38.22 
>> +units=m +no_defs
>> SAD69_UTM20_IBGE
>> +proj=utm +zone=20 +south +ellps=aust_SA +towgs84=-67.35,3.88,-38.22 
>> +units=m +no_defs
>> SAD69_UTM21_IBGE
>> +proj=utm +zone=21 +south +ellps=aust_SA +towgs84=-67.35,3.88,-38.22 
>> +units=m +no_defs
>> SAD69_UTM22_IBGE
>> +proj=utm +zone=22 +south +ellps=aust_SA +towgs84=-67.35,3.88,-38.22 
>> +units=m +no_defs
>> SAD69_UTM23_IBGE
>> +proj=utm +zone=23 +south +ellps=aust_SA +towgs84=-67.35,3.88,-38.22 
>> +units=m +no_defs
>> SAD69_UTM24_IBGE
>> +proj=utm +zone=24 +south +ellps=aust_SA +towgs84=-67.35,3.88,-38.22 
>> +units=m +no_defs
>>
>> A pergunta é: porque utilizaram o elipsóide *aust_SA ao invés 
>> do GRS67*? Perguntei a outros colegas, que tb não souberam me 
>> responder. :(
>>
>> Aguardo um retorno, agradecendo desde já.
>>
>> *Ana Carolina Schuler Correia**
>> *INCRA SR-29/F/F2
>> Analista em Reforma e Desenv. Agrário - Engenheira Cartógrafa
>>
>> Nenhum vírus encontrado nessa mensagem.
>> Verificado por AVG - www.avgbrasil.com.br <http://www.avgbrasil.com.br>
>> Versão: 2012.0.2176 / Banco de dados de vírus: 2425/5015 - Data de 
>> Lançamento: 05/22/12
>>
Estamos num novo imparce quanto aos parâmetros de transformação de 
coordenadas, vejam as duvidas que surgiram na semana passada....

-- 
Israel Ely de A. Oliveira
Perito Federal Agrário
INCRA - SR05/BA
(71) 3505-5344 / 5345 / 5337

-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: http://lists.osgeo.org/pipermail/brasil/attachments/20120524/9c0468c4/attachment.html
From etourigny.dev em gmail.com  Thu May 24 12:11:40 2012
From: etourigny.dev em gmail.com (Etienne Tourigny)
Date: Thu May 24 12:12:28 2012
Subject: =?ISO-8859-1?Q?Re=3A_=5BOSGeo=2DBrasil=5D_Par=E2metros_de_proje=E7=E3o?=
In-Reply-To: <4FBE4BB2.9090709@sdr.incra.gov.br>
References: <4FBE4BB2.9090709@sdr.incra.gov.br>
Message-ID: <CA+TxYvPBGT-36LCD623CyugOCAGm3OoYWZ2WOqEs0Ur-NX8LXw@mail.gmail.com>

Alguem pode commentar se essa informação traz algo ne novo na
discussão sobre a mudança dos parametros TOWGS84, e se for o caso,
modificar o wiki

http://wiki.osgeo.org/wiki/Brazilian_Coordinate_Reference_Systems

ref. discussão na lista  "Sistemas de referências incorretos no Proj,
GDAL/OGR e PostGIS"


Etienne

2012/5/24 israel.ely <israel.ely@sdr.incra.gov.br>:
> Oi Helder, tudo bem? Olá a todos!
>
> Calma, calma Helder! rs
> Se você pegar um par de coordenadas em SIRGAS e converter para SAD69
> utilizando o TCGEO encontrará as mesmas coordenadas que utilizando a
> conversão de SIRGAS para SAD (com os parâmetros configurados) no Quantum
> GIS. Já utilizando o GRS67 dá uma diferença de milímetros. Quando estava
> montando a primeira apostila eu também fiquei em dúvida e testei isso
> dezenas de vezes. E diga-se de passagem dezenas de outras pessoas também
> testaram
>
> Uma das explicações (manuais Terra Legal) é que O desvio resultante para a
> definição que utiliza o elipsóide GRS67 é inferior a 5cm (projeção UTM),
> enquanto que utilizando o "aust_SA" é nulo até a casa dos milímetros
> (projeção UTM).
>
> Testei e constatei, mas se a colega Ana quiser maiores explicações sugiro
> que entre em contato com thiago.marra@incra.gov.br
>
> Marília.
>
>
> Em 24/5/2012 09:03, helder.santos@sdr.incra.gov.br escreveu:
>
> Cara Ana, bom dia!
>
> Obrigado pela pergunta.
> Informo que deve ter ocorrido um falha na hora de copiar os parâmetros do
> Quantum GIS. O correto seria utilizar o elipsoide GRS 67.
> Os parâmetros corretos seguem no arquivo txt em anexo.
> Em breve providenciaremos as correções na apostila.
>
> Muito obrigado,
>
> Hélder Gramacho dos Santos
> Perito Federal Agrário/Engenheiro Agrônomo
> INCRA/SR-05/Divisão de Obtenção de Terras
> Av.Ulisses Guimarães, 640 - Centro Administrativo
> Salvador Bahia CEP: 41746-900 tel:(71)3505-5344
> e-mail: helder.santos@sdr.incra.gov.br
>
>
> On 22/05/2012 15:40, Ana Correia wrote:
>
> Olá, boa tarde!
>
> Trabalho na SR-29 (Petrolina), no cargo de Analista em Reforma e
> Desenvolvimento Agrário - Engenharia Cartográfica e fui nomeada agora neste
> último concurso.
>
> Surgiu uma dúvida em relação aos parâmetros de transformação do QGIS e
> gostaríamos de obter uma resposta.
>
> O QGIS não oferece os parâmetros de transformação de SAD69 para SIRGAS2000,
> mas permite que configuremos um novo SRC.
>
> No arquivo "parâmetros transformação resolução 1_2005 IBGE.txt", fornecido
> junto com o material do treinamento, foram configurados novos SRC com o
> elipsóide aust_SA, conforme se vê abaixo:
>
> SAD69_UTM18_IBGE
> +proj=utm +zone=18 +south +ellps=aust_SA +towgs84=-67.35,3.88,-38.22
> +units=m +no_defs
> SAD69_UTM19_IBGE
> +proj=utm +zone=19 +south +ellps=aust_SA +towgs84=-67.35,3.88,-38.22
> +units=m +no_defs
> SAD69_UTM20_IBGE
> +proj=utm +zone=20 +south +ellps=aust_SA +towgs84=-67.35,3.88,-38.22
> +units=m +no_defs
> SAD69_UTM21_IBGE
> +proj=utm +zone=21 +south +ellps=aust_SA +towgs84=-67.35,3.88,-38.22
> +units=m +no_defs
> SAD69_UTM22_IBGE
> +proj=utm +zone=22 +south +ellps=aust_SA +towgs84=-67.35,3.88,-38.22
> +units=m +no_defs
> SAD69_UTM23_IBGE
> +proj=utm +zone=23 +south +ellps=aust_SA +towgs84=-67.35,3.88,-38.22
> +units=m +no_defs
> SAD69_UTM24_IBGE
> +proj=utm +zone=24 +south +ellps=aust_SA +towgs84=-67.35,3.88,-38.22
> +units=m +no_defs
>
> A pergunta é: porque utilizaram o elipsóide aust_SA ao invés do GRS67?
> Perguntei a outros colegas, que tb não souberam me responder. :(
>
> Aguardo um retorno, agradecendo desde já.
>
> Ana Carolina Schuler Correia
> INCRA SR-29/F/F2
> Analista em Reforma e Desenv. Agrário - Engenheira Cartógrafa
>
> Nenhum vírus encontrado nessa mensagem.
> Verificado por AVG - www.avgbrasil.com.br
> Versão: 2012.0.2176 / Banco de dados de vírus: 2425/5015 - Data de
> Lançamento: 05/22/12
>
> Estamos num novo imparce quanto aos parâmetros de transformação de
> coordenadas, vejam as duvidas que surgiram na semana passada....
>
> --
> Israel Ely de A. Oliveira
> Perito Federal Agrário
> INCRA - SR05/BA
> (71) 3505-5344 / 5345 / 5337
>
>
> _______________________________________________
> Brasil mailing list
> Brasil@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/brasil
>
From fsq em univali.br  Mon May 28 05:24:26 2012
From: fsq em univali.br (Fernando Quadro)
Date: Mon, 28 May 2012 09:24:26 -0300
Subject: [OSGeo-Brasil] =?utf-8?q?Curso_Online_de_GeoServer=2C_=C3=BAltimo?=
 =?utf-8?q?s_dias_de_inscri=C3=A7=C3=B5es_com_pre=C3=A7o_promocional!?=
Message-ID: <f37180f87dfc74e31722cbec09257916@localhost>


A GEOCURSOS está oferecendo um Curso Online de GeoServer, ministrado pelo
Instrutor Fernando Quadro, referência nacional no assunto.

Aprenda a disponibilizar dados espaciais na internet com o GeoServer, um
servidor open source de  que permite aos usuários compartilhar e editar
dados espaciais. Projetado para a interoperabilidade, publica dados de
qualquer fonte de dados espacial utilizando padrões abertos (OGC
Standards). 

No curso serão abordados tópicos como: configuração de dados, criação de
estilo com SLD, padrões OGC, interface administrativa (web), visualização
com OpenLayers, entre outros. 

Não perca esta chance, pois as inscrições com preço promocional vão até o
dia 31/05.

Para saber mais informações basta acessar o site
(http://www.geocursos.com.br).

Att,

GEOCURSOS
http://www.geocursos.com.br
http://twitter.com/geo_cursos
http://www.facebook.com/geocursosbr

-- 
Fernando Quadro
http://www.fernandoquadro.com.br
twitter.com/fernandoquadro

From miranda.dam em dpf.gov.br  Mon May 28 06:21:47 2012
From: miranda.dam em dpf.gov.br (Daniel Araujo Miranda)
Date: Mon, 28 May 2012 10:21:47 -0300
Subject: [OSGeo-Brasil] =?utf-8?b?UGFyw6JtZXRyb3MgZGUgcHJvamXDp8Ojbw==?=
In-Reply-To: <CA+TxYvPBGT-36LCD623CyugOCAGm3OoYWZ2WOqEs0Ur-NX8LXw@mail.gmail.com>
References: <4FBE4BB2.9090709@sdr.incra.gov.br>
	<CA+TxYvPBGT-36LCD623CyugOCAGm3OoYWZ2WOqEs0Ur-NX8LXw@mail.gmail.com>
Message-ID: <4FC37BEB.90906@dpf.gov.br>

Ana Correia e demais,
  O IBGE define os parâmetros na Resolução 01/2005
  (http://www.ibge.gov.br/home/geociencias/geodesia/default_normas.shtm
ftp://geoftp.ibge.gov.br/documentos/geodesia/projeto_mudanca_referencial_geodesico/legislacao/rpr_01_25fev2005.pdf)

SAD 69 para SIRGAS2000
a1 = 6.378.160 m
f1 = 1/298,25
a2 = 6.378.137 m
f2 = 1/298,257222101
?X = ? 67,35 m
?Y = + 3,88 m
?Z = ? 38,22 m

Os parâmetros a1 e f1 são exatamente os do elipsóide aust_SA e divergem 
levemente do GRS 67 (não tenho o conhecimento técnico para analisar os 
demais parâmetros). De acordo com isso as strings que você citou estão 
corretas (mas não servem para as partes do brasil acima da linha do 
equador, para isso seria necessário declarar "+north" ao invés de "+south").

Como disse o Etyenne, estamos trabalhando para atingir um consenso 
nesses parâmetros na wiki. Vide 
http://wiki.osgeo.org/wiki/Brazilian_Coordinate_Reference_Systems (a 
seção "Observações" mostra como utilizar UTM ao invés de Lat/long)

Pelo que eu entendi dos e-mails (helder.santos), existe alguma 
referência que indicaria o GRS 67 como correto. Que referência é essa?

Um abraço,
--Miranda

On 05/24/2012 01:11 PM, Etienne Tourigny wrote:
> Alguem pode commentar se essa informação traz algo ne novo na
> discussão sobre a mudança dos parametros TOWGS84, e se for o caso,
> modificar o wiki
>
> http://wiki.osgeo.org/wiki/Brazilian_Coordinate_Reference_Systems
>
> ref. discussão na lista  "Sistemas de referências incorretos no Proj,
> GDAL/OGR e PostGIS"

>
>
> Etienne
>
> 2012/5/24 israel.ely<israel.ely em sdr.incra.gov.br>:
>> Oi Helder, tudo bem? Olá a todos!
>>
>> Calma, calma Helder! rs
>> Se você pegar um par de coordenadas em SIRGAS e converter para SAD69
>> utilizando o TCGEO encontrará as mesmas coordenadas que utilizando a
>> conversão de SIRGAS para SAD (com os parâmetros configurados) no Quantum
>> GIS. Já utilizando o GRS67 dá uma diferença de milímetros. Quando estava
>> montando a primeira apostila eu também fiquei em dúvida e testei isso
>> dezenas de vezes. E diga-se de passagem dezenas de outras pessoas também
>> testaram
>>
>> Uma das explicações (manuais Terra Legal) é que O desvio resultante para a
>> definição que utiliza o elipsóide GRS67 é inferior a 5cm (projeção UTM),
>> enquanto que utilizando o "aust_SA" é nulo até a casa dos milímetros
>> (projeção UTM).
>>
>> Testei e constatei, mas se a colega Ana quiser maiores explicações sugiro
>> que entre em contato com thiago.marra em incra.gov.br
>>
>> Marília.
>>
>>
>> Em 24/5/2012 09:03, helder.santos em sdr.incra.gov.br escreveu:
>>
>> Cara Ana, bom dia!
>>
>> Obrigado pela pergunta.
>> Informo que deve ter ocorrido um falha na hora de copiar os parâmetros do
>> Quantum GIS. O correto seria utilizar o elipsoide GRS 67.
>> Os parâmetros corretos seguem no arquivo txt em anexo.
>> Em breve providenciaremos as correções na apostila.
>>
>> Muito obrigado,
>>
>> Hélder Gramacho dos Santos
>> Perito Federal Agrário/Engenheiro Agrônomo
>> INCRA/SR-05/Divisão de Obtenção de Terras
>> Av.Ulisses Guimarães, 640 - Centro Administrativo
>> Salvador Bahia CEP: 41746-900 tel:(71)3505-5344
>> e-mail: helder.santos em sdr.incra.gov.br
>>
>>
>> On 22/05/2012 15:40, Ana Correia wrote:
>>
>> Olá, boa tarde!
>>
>> Trabalho na SR-29 (Petrolina), no cargo de Analista em Reforma e
>> Desenvolvimento Agrário - Engenharia Cartográfica e fui nomeada agora neste
>> último concurso.
>>
>> Surgiu uma dúvida em relação aos parâmetros de transformação do QGIS e
>> gostaríamos de obter uma resposta.
>>
>> O QGIS não oferece os parâmetros de transformação de SAD69 para SIRGAS2000,
>> mas permite que configuremos um novo SRC.
>>
>> No arquivo "parâmetros transformação resolução 1_2005 IBGE.txt", fornecido
>> junto com o material do treinamento, foram configurados novos SRC com o
>> elipsóide aust_SA, conforme se vê abaixo:
>>
>> SAD69_UTM18_IBGE
>> +proj=utm +zone=18 +south +ellps=aust_SA +towgs84=-67.35,3.88,-38.22
>> +units=m +no_defs
>> SAD69_UTM19_IBGE
>> +proj=utm +zone=19 +south +ellps=aust_SA +towgs84=-67.35,3.88,-38.22
>> +units=m +no_defs
>> SAD69_UTM20_IBGE
>> +proj=utm +zone=20 +south +ellps=aust_SA +towgs84=-67.35,3.88,-38.22
>> +units=m +no_defs
>> SAD69_UTM21_IBGE
>> +proj=utm +zone=21 +south +ellps=aust_SA +towgs84=-67.35,3.88,-38.22
>> +units=m +no_defs
>> SAD69_UTM22_IBGE
>> +proj=utm +zone=22 +south +ellps=aust_SA +towgs84=-67.35,3.88,-38.22
>> +units=m +no_defs
>> SAD69_UTM23_IBGE
>> +proj=utm +zone=23 +south +ellps=aust_SA +towgs84=-67.35,3.88,-38.22
>> +units=m +no_defs
>> SAD69_UTM24_IBGE
>> +proj=utm +zone=24 +south +ellps=aust_SA +towgs84=-67.35,3.88,-38.22
>> +units=m +no_defs
>>
>> A pergunta é: porque utilizaram o elipsóide aust_SA ao invés do GRS67?
>> Perguntei a outros colegas, que tb não souberam me responder. :(
>>
>> Aguardo um retorno, agradecendo desde já.
>>
>> Ana Carolina Schuler Correia
>> INCRA SR-29/F/F2
>> Analista em Reforma e Desenv. Agrário - Engenheira Cartógrafa
>>
>> Nenhum vírus encontrado nessa mensagem.
>> Verificado por AVG - www.avgbrasil.com.br
>> Versão: 2012.0.2176 / Banco de dados de vírus: 2425/5015 - Data de
>> Lançamento: 05/22/12
>>
>> Estamos num novo imparce quanto aos parâmetros de transformação de
>> coordenadas, vejam as duvidas que surgiram na semana passada....
>>
>> --
>> Israel Ely de A. Oliveira
>> Perito Federal Agrário
>> INCRA - SR05/BA
>> (71) 3505-5344 / 5345 / 5337
>>
>>
>> _______________________________________________
>> Brasil mailing list
>> Brasil em lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/brasil
>>
> _______________________________________________
> Brasil mailing list
> Brasil em lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/brasil
>

From israel.ely em sdr.incra.gov.br  Mon May 28 07:41:18 2012
From: israel.ely em sdr.incra.gov.br (israel.ely)
Date: Mon, 28 May 2012 11:41:18 -0300
Subject: [OSGeo-Brasil] =?iso-8859-1?q?Resolu=E7=E3o_n1_de_2005_do_IBGE?=
Message-ID: <4FC38E8E.5090106@sdr.incra.gov.br>

Analisamos o texto da resolução do *IBGE nº1 de 2005* e chegamos à 
seguinte conclusão:

Na*pág. 5* da resolução do IBGE, é citado o *GRS 1967* como sendo o 
elipsóide oficial para o *SAD69* com os parâmetros descritos abaixo;
         Semi eixo maior *a = 6.378,160m*
         Achatamento *f = 1/298,25 *

Pesquisando sobre o *GRS67* encontramos os seguintes parâmetros***:
         Semi eixo maior *  a = 6.378,160m*
         Achatamento *f = 1/298,247167427*

O IBGE apesar de informar que o elipsóide oficial é o *GRS67*, ao 
aproximar os valores do achatamento para 298,25, transformou o *GRS67 
*em *Aust SA*, e internamente no qgis o GRS67 deve conter as casas 
decimais *(sem aproximação)*, coisa que não deve ocorrer no PROGRID 
(programa oficial do IBGE para conversão de coordenadas). Por esse 
motivo devem ocorrer as divergências nas transformações.

***Fonte: www.ufrgs.br/museudetopografia/Artigos/Geóide.pdf

-- 
Israel Ely de A. Oliveira
Perito Federal Agrário
INCRA - SR05/BA
(71) 3505-5344 / 5345 / 5337

-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://lists.osgeo.org/pipermail/brasil/attachments/20120528/5a8ad23e/attachment.html>

From etourigny.dev em gmail.com  Mon May 28 08:12:53 2012
From: etourigny.dev em gmail.com (Etienne Tourigny)
Date: Mon, 28 May 2012 12:12:53 -0300
Subject: [OSGeo-Brasil] =?iso-8859-1?q?Resolu=E7=E3o_n1_de_2005_do_IBGE?=
In-Reply-To: <4FC38E8E.5090106@sdr.incra.gov.br>
References: <4FC38E8E.5090106@sdr.incra.gov.br>
Message-ID: <CA+TxYvM4Y+AWnyEm+YE=gCytJ4Lke+FzjwU=UU17z84uzO3RGg@mail.gmail.com>

Segue informações do epsg registry (www.epsg-registry.org)

http://www.epsg-registry.org/report.htm?type=selection&entity=urn:ogc:def:ellipsoid:EPSG::7036&entity=urn:ogc:def:ellipsoid:EPSG::7050&reportDetail=long&style=urn:uuid:report-style:default-with-code&style_name=OGP%20Default%20With%20Code&title=

2012/5/28 israel.ely <israel.ely em sdr.incra.gov.br>:
> Analisamos o texto da resolução do IBGE nº1 de 2005 e chegamos à seguinte
> conclusão:
>
> Na pág. 5 da resolução do IBGE, é citado o GRS 1967 como sendo o elipsóide
> oficial para o SAD69 com os parâmetros descritos abaixo;
>         Semi eixo maior            a = 6.378,160m
>         Achatamento                f = 1/298,25

Corresponde ao Ellipsoid "GRS 1967 Modified" (ou "GRS 1967 Truncated"
segundo ESRI) da EPSG, codigo 7050 - aust_SA no proj.4

Segundo a EPSG, é esse que deve ser usado com o datum SAD69: "Used
with SAD69 and TWD67 datums"

>
> Pesquisando sobre o GRS67 encontramos os seguintes parâmetros*:
>         Semi eixo maior            a = 6.378,160m
>         Achatamento                f = 1/298,247167427

Corresponde ao Ellipsoid "GRS 1967" (ou "International 1967") da EPSG,
codigo 7036 - GRS67 no proj.4


>
> O IBGE apesar de informar que o elipsóide oficial é o GRS67, ao aproximar os
> valores do achatamento para 298,25, transformou o GRS67 em Aust SA, e
> internamente no qgis o GRS67 deve conter as casas decimais (sem
> aproximação), coisa que não deve ocorrer no PROGRID (programa oficial do
> IBGE para conversão de coordenadas). Por esse motivo devem ocorrer as
> divergências nas transformações.

o qgis usa o seguinte para o SAD69:
+proj=longlat +ellps=aust_SA +towgs84=-57,1,-41,0,0,0,0 +no_defs

e os parametros de ellipsoid do proj.4 (4.7.0) são
"aust_SA",	"a=6378160.0", "rf=298.25", "Australian Natl & S. Amer. 1969",
"GRS67",	"a=6378160.0", "rf=298.2471674270", "GRS 67(IUGG 1967)",

então, o QGis usa a forma aproximada ( 298,25), o que não explica a
diferencia com o PROGRID.

Qual é mesma a diferencia entre o qgis e o PROGRID?

A diferencia deve ser porque usar o TOWGS84 é uma aprroximação, que
pode gera um erro, dependendo do towgs84 utilisado.  O towgs84
utilisado por gdal (EPSG::1864 / towgs84=-57,1,-41,0,0,0,0), o erro é
: "Accuracy 15m, 6m and 9m in X, Y and Z axes"

Ver:
http://www.epsg-registry.org/report.htm?type=lastQuery&title=&reportDetail=long&style=urn:uuid:report-style:default-with-code&style_name=OGP%20Default%20With%20Code&title=

>
> *Fonte: www.ufrgs.br/museudetopografia/Artigos/Geóide.pdf
>
> --
> Israel Ely de A. Oliveira
> Perito Federal Agrário
> INCRA - SR05/BA
> (71) 3505-5344 / 5345 / 5337
>
>
> _______________________________________________
> Brasil mailing list
> Brasil em lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/brasil
>

From miranda.dam em dpf.gov.br  Mon May 28 08:17:18 2012
From: miranda.dam em dpf.gov.br (Daniel Araujo Miranda)
Date: Mon, 28 May 2012 12:17:18 -0300
Subject: [OSGeo-Brasil]
 =?utf-8?b?UGFyw6JtZXRyb3MgZGUgcHJvamXDp8OjbyAoUmVz?=
 =?utf-8?q?olu=C3=A7=C3=A3o_n1_de_2005_do_IBGE=29?=
In-Reply-To: <4FC37BEB.90906@dpf.gov.br>
References: <4FBE4BB2.9090709@sdr.incra.gov.br>
	<CA+TxYvPBGT-36LCD623CyugOCAGm3OoYWZ2WOqEs0Ur-NX8LXw@mail.gmail.com>
	<4FC37BEB.90906@dpf.gov.br>
Message-ID: <4FC396FE.1020807@dpf.gov.br>


Pesquisando no www.epsg-registry.org:

GRS 1967
EPSG::7036
Adopted by IUGG 1967 Lucerne. 1/f given is derived from geocentric 
gravitational constant (GM)= 398603e9 m*m*m/s/s; dynamic form factor 
(J2) = 0.0010827 and Earth's angular velocity w = 7.2921151467e-...


GRS 1967 Modified
EPSG::7050
Ellipsoid
Based on the GRS 1967 figure (code 7036) but with 1/f taken to 2 decimal 
places exactly. Used with SAD69 and TWD67 datums. The dimensions are 
also used as the Australian National Spheroid (code 7003).

Pelo que eu entendi, a RPR 01/2005 usa a versão modificada, e apesar de 
não explicitar isso no nome do elipsóide, deixou bem claro nos parâmetros.

Na minha opinião o correto é usar o Aust_SA mesmo, o que vocês acham?

--Miranda

On 05/28/2012 11:41 AM, israel.ely wrote:
 > Analisamos o texto da resolução do *IBGE nº1 de 2005* e chegamos à
 > seguinte conclusão:
 >
 > Na*pág. 5* da resolução do IBGE, é citado o *GRS 1967* como sendo o
 > elipsóide oficial para o *SAD69* com os parâmetros descritos abaixo;
 > Semi eixo maior *a = 6.378,160m*
 > Achatamento *f = 1/298,25 *
 >
 > Pesquisando sobre o *GRS67* encontramos os seguintes parâmetros***:
 > Semi eixo maior *a = 6.378,160m*
 > Achatamento *f = 1/298,247167427*
 >
 > O IBGE apesar de informar que o elipsóide oficial é o *GRS67*, ao
 > aproximar os valores do achatamento para 298,25, transformou o *GRS67
 > *em *Aust SA*, e internamente no qgis o GRS67 deve conter as casas
 > decimais *(sem aproximação)*, coisa que não deve ocorrer no PROGRID
 > (programa oficial do IBGE para conversão de coordenadas). Por esse
 > motivo devem ocorrer as divergências nas transformações.
 >
 > ***Fonte: www.ufrgs.br/museudetopografia/Artigos/Geóide.pdf
 >
 > --
 > Israel Ely de A. Oliveira
 > Perito Federal Agrário
 > INCRA - SR05/BA
 > (71) 3505-5344 / 5345 / 5337
 >
 >
 >
 > _______________________________________________
 > Brasil mailing list
 > Brasil em lists.osgeo.org
 > http://lists.osgeo.org/mailman/listinfo/brasil



On 05/28/2012 10:21 AM, Daniel Araujo Miranda wrote:
> Ana Correia e demais,
> O IBGE define os parâmetros na Resolução 01/2005
> (http://www.ibge.gov.br/home/geociencias/geodesia/default_normas.shtm
> ftp://geoftp.ibge.gov.br/documentos/geodesia/projeto_mudanca_referencial_geodesico/legislacao/rpr_01_25fev2005.pdf)
>
>
> SAD 69 para SIRGAS2000
> a1 = 6.378.160 m
> f1 = 1/298,25
> a2 = 6.378.137 m
> f2 = 1/298,257222101
> ?X = ? 67,35 m
> ?Y = + 3,88 m
> ?Z = ? 38,22 m
>
> Os parâmetros a1 e f1 são exatamente os do elipsóide aust_SA e divergem
> levemente do GRS 67 (não tenho o conhecimento técnico para analisar os
> demais parâmetros). De acordo com isso as strings que você citou estão
> corretas (mas não servem para as partes do brasil acima da linha do
> equador, para isso seria necessário declarar "+north" ao invés de
> "+south").
>
> Como disse o Etyenne, estamos trabalhando para atingir um consenso
> nesses parâmetros na wiki. Vide
> http://wiki.osgeo.org/wiki/Brazilian_Coordinate_Reference_Systems (a
> seção "Observações" mostra como utilizar UTM ao invés de Lat/long)
>
> Pelo que eu entendi dos e-mails (helder.santos), existe alguma
> referência que indicaria o GRS 67 como correto. Que referência é essa?
>
> Um abraço,
> --Miranda
>
> On 05/24/2012 01:11 PM, Etienne Tourigny wrote:
>> Alguem pode commentar se essa informação traz algo ne novo na
>> discussão sobre a mudança dos parametros TOWGS84, e se for o caso,
>> modificar o wiki
>>
>> http://wiki.osgeo.org/wiki/Brazilian_Coordinate_Reference_Systems
>>
>> ref. discussão na lista "Sistemas de referências incorretos no Proj,
>> GDAL/OGR e PostGIS"
>
>>
>>
>> Etienne
>>
>> 2012/5/24 israel.ely<israel.ely em sdr.incra.gov.br>:
>>> Oi Helder, tudo bem? Olá a todos!
>>>
>>> Calma, calma Helder! rs
>>> Se você pegar um par de coordenadas em SIRGAS e converter para SAD69
>>> utilizando o TCGEO encontrará as mesmas coordenadas que utilizando a
>>> conversão de SIRGAS para SAD (com os parâmetros configurados) no Quantum
>>> GIS. Já utilizando o GRS67 dá uma diferença de milímetros. Quando estava
>>> montando a primeira apostila eu também fiquei em dúvida e testei isso
>>> dezenas de vezes. E diga-se de passagem dezenas de outras pessoas também
>>> testaram
>>>
>>> Uma das explicações (manuais Terra Legal) é que O desvio resultante
>>> para a
>>> definição que utiliza o elipsóide GRS67 é inferior a 5cm (projeção UTM),
>>> enquanto que utilizando o "aust_SA" é nulo até a casa dos milímetros
>>> (projeção UTM).
>>>
>>> Testei e constatei, mas se a colega Ana quiser maiores explicações
>>> sugiro
>>> que entre em contato com thiago.marra em incra.gov.br
>>>
>>> Marília.
>>>
>>>
>>> Em 24/5/2012 09:03, helder.santos em sdr.incra.gov.br escreveu:
>>>
>>> Cara Ana, bom dia!
>>>
>>> Obrigado pela pergunta.
>>> Informo que deve ter ocorrido um falha na hora de copiar os
>>> parâmetros do
>>> Quantum GIS. O correto seria utilizar o elipsoide GRS 67.
>>> Os parâmetros corretos seguem no arquivo txt em anexo.
>>> Em breve providenciaremos as correções na apostila.
>>>
>>> Muito obrigado,
>>>
>>> Hélder Gramacho dos Santos
>>> Perito Federal Agrário/Engenheiro Agrônomo
>>> INCRA/SR-05/Divisão de Obtenção de Terras
>>> Av.Ulisses Guimarães, 640 - Centro Administrativo
>>> Salvador Bahia CEP: 41746-900 tel:(71)3505-5344
>>> e-mail: helder.santos em sdr.incra.gov.br
>>>
>>>
>>> On 22/05/2012 15:40, Ana Correia wrote:
>>>
>>> Olá, boa tarde!
>>>
>>> Trabalho na SR-29 (Petrolina), no cargo de Analista em Reforma e
>>> Desenvolvimento Agrário - Engenharia Cartográfica e fui nomeada agora
>>> neste
>>> último concurso.
>>>
>>> Surgiu uma dúvida em relação aos parâmetros de transformação do QGIS e
>>> gostaríamos de obter uma resposta.
>>>
>>> O QGIS não oferece os parâmetros de transformação de SAD69 para
>>> SIRGAS2000,
>>> mas permite que configuremos um novo SRC.
>>>
>>> No arquivo "parâmetros transformação resolução 1_2005 IBGE.txt",
>>> fornecido
>>> junto com o material do treinamento, foram configurados novos SRC com o
>>> elipsóide aust_SA, conforme se vê abaixo:
>>>
>>> SAD69_UTM18_IBGE
>>> +proj=utm +zone=18 +south +ellps=aust_SA +towgs84=-67.35,3.88,-38.22
>>> +units=m +no_defs
>>> SAD69_UTM19_IBGE
>>> +proj=utm +zone=19 +south +ellps=aust_SA +towgs84=-67.35,3.88,-38.22
>>> +units=m +no_defs
>>> SAD69_UTM20_IBGE
>>> +proj=utm +zone=20 +south +ellps=aust_SA +towgs84=-67.35,3.88,-38.22
>>> +units=m +no_defs
>>> SAD69_UTM21_IBGE
>>> +proj=utm +zone=21 +south +ellps=aust_SA +towgs84=-67.35,3.88,-38.22
>>> +units=m +no_defs
>>> SAD69_UTM22_IBGE
>>> +proj=utm +zone=22 +south +ellps=aust_SA +towgs84=-67.35,3.88,-38.22
>>> +units=m +no_defs
>>> SAD69_UTM23_IBGE
>>> +proj=utm +zone=23 +south +ellps=aust_SA +towgs84=-67.35,3.88,-38.22
>>> +units=m +no_defs
>>> SAD69_UTM24_IBGE
>>> +proj=utm +zone=24 +south +ellps=aust_SA +towgs84=-67.35,3.88,-38.22
>>> +units=m +no_defs
>>>
>>> A pergunta é: porque utilizaram o elipsóide aust_SA ao invés do GRS67?
>>> Perguntei a outros colegas, que tb não souberam me responder. :(
>>>
>>> Aguardo um retorno, agradecendo desde já.
>>>
>>> Ana Carolina Schuler Correia
>>> INCRA SR-29/F/F2
>>> Analista em Reforma e Desenv. Agrário - Engenheira Cartógrafa
>>>
>>> Nenhum vírus encontrado nessa mensagem.
>>> Verificado por AVG - www.avgbrasil.com.br
>>> Versão: 2012.0.2176 / Banco de dados de vírus: 2425/5015 - Data de
>>> Lançamento: 05/22/12
>>>
>>> Estamos num novo imparce quanto aos parâmetros de transformação de
>>> coordenadas, vejam as duvidas que surgiram na semana passada....
>>>
>>> --
>>> Israel Ely de A. Oliveira
>>> Perito Federal Agrário
>>> INCRA - SR05/BA
>>> (71) 3505-5344 / 5345 / 5337
>>>
>>>
>>> _______________________________________________
>>> Brasil mailing list
>>> Brasil em lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/brasil
>>>
>> _______________________________________________
>> Brasil mailing list
>> Brasil em lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/brasil
>>
> _______________________________________________
> Brasil mailing list
> Brasil em lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/brasil

From israel.ely em sdr.incra.gov.br  Mon May 28 10:18:28 2012
From: israel.ely em sdr.incra.gov.br (israel.ely)
Date: Mon, 28 May 2012 14:18:28 -0300
Subject: [OSGeo-Brasil] =?iso-8859-1?q?Transforma=E7=E3o_de_coordenadas?=
Message-ID: <4FC3B364.4000909@sdr.incra.gov.br>

Estou encaminhando as conclusões a que o grupo daqui do INCRA Bahia chegou:

Olá Pessoal,

Olha só a confirmação do que Israel havia afirmado através de shapes 
gerados pelo QGIS: no item *1)* existe o elipsoide *"GRS_1967" *que está 
com os parâmetros do achatamento sem aproximação; no item *2)* o 
elipsoide*aust_SA* aparece com a denominação *"GRS_1967_Modified"* e 
está com os parâmetros conforme a Resolução 01 de 2005 do IBGE (*GRS67 
aproximado*)

*1) 
*PROJCS["SAD69_UTM_zone_24S_deprecated",GEOGCS["GCS_SAD69",DATUM["D_South_American_1969",SPHEROID 
"GRS_1967",*6378160,298.247167427]]*

*2)* 
PROJCS["SAD69_UTM_zone_24S",GEOGCS["GCS_SAD69",DATUM["D_South_American_1969",SPHEROID["GRS_1967_Modified",*6378160,298.25]]*

Com isso podemos finalmente responder à Ana Correia e esclarecer o 
debate da semana passada:

Ana, na nossa apostila foi utilizado o *aust_SA* porque o IBGE utiliza 
os parâmetros do *"GRS_1967_Modified" * que aproxima o parâmetro do 
achatamento do*GRS67* original, e o torna igual ao *aust_SA* sendo 
assim, quem utilizar o *GRS67* estará utilizando o parâmetro sem 
aproximação, enquanto que quem utiliza o *aust_SA* está utilizando o 
parâmetro conforme a Resolução 01 de 2005.

Portando:

1) Quem precisa trabalhar de acordo com a Resolução 01 de 2005 do IBGE 
não pode utilizar o elipsóide GRS67 no caso, os arquivos de projeção que 
tem a denominação "deprecated" no final;

2) O procedimento adotado na apostila está correto sob o ponto de vista 
da Resolução 01 de 2005 do IBGE;

3) Desconsiderem o email enviado por mim na semana passada, peço 
desculpas pela informação incorreta;

Atenciosamente,

Hélder Gramacho dos Santos
Perito Federal Agrário/Engenheiro Agrônomo
INCRA/SR-05/Divisão de Obtenção de Terras
Av.Ulisses Guimarães, 640 - Centro Administrativo
Salvador Bahia CEP: 41746-900 tel:(71)3505-5344
e-mail:helder.santos em sdr.incra.gov.br

-- 
Israel Ely de A. Oliveira
Perito Federal Agrário
INCRA - SR05/BA
(71) 3505-5344 / 5345 / 5337

-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://lists.osgeo.org/pipermail/brasil/attachments/20120528/dcf4473f/attachment.html>