Pedro, mto boa noite.
Estou de acordo consigo.
A explicação é essa.
Um abraço.
JCGS
A Ter, 8 de mai de 2018, 20:01, <qgis-pt-request@lists.osgeo.org> escreveu:
Send QGIS-pt mailing list submissions to
qgis-pt@lists.osgeo.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.osgeo.org/mailman/listinfo/qgis-pt
or, via email, send a message with subject or body ‘help’ to
qgis-pt-request@lists.osgeo.org
You can reach the person managing the list at
qgis-pt-owner@lists.osgeo.org
When replying, please edit your Subject line so it is more specific
than “Re: Contents of QGIS-pt digest…”
Today’s Topics:
- Re: QGIS 3 - transformação incorrecta de EPSG:102164 e
EPSG:102161 para EPSG:3763 (Pedro Pereira)
Message: 1
Date: Mon, 7 May 2018 23:14:44 +0100
From: Pedro Pereira <pedromap@gmail.com>
To: QGIS PT - lista de utilizadores QGIS, em português.
<qgis-pt@lists.osgeo.org>
Subject: Re: [QGIS-pt] QGIS 3 - transformação incorrecta de
EPSG:102164 e EPSG:102161 para EPSG:3763
Message-ID:
<CAFzQen9ZgKhweJOGzyYU09xD+3Vx7OULyrs87DwSqSDFMOEYQg@mail.gmail.com>
Content-Type: text/plain; charset=“utf-8”
Boas,
Não estou a dizer que seja culpa da ESRI, é uma opção deles…
O problema não está no QGIS3 ou QGIS2.18, em ambos o qgis não “entende” o
prj do ARCMAP.
A solução é indicar o código EPSG equivalente ao código ESRI, como disse o
Rui (do ESRI 102164 e 102161, para EPSG 20790 ou 20791).
Não é nehum problema a shp ter o código ESRI, o que acontece é que os
disponibiliza deveria ter esse cuidado de alertar o utilizador para saber
com o que conta.
Como eu muitas pessoas poderão ter levado algum tempo até se aperceberem do
problema.
Atentamente,
Pedro
2018-05-07 22:56 GMT+01:00 Antonio Sobral Almeida <sobral.almeida@gmail.com>
:
Viva, Pedro,
É verdade, mas a ESRI não vai desistir do seu sistema de projecção.
O problema é que vão (ainda) continuar a existir milhares de ficheiros
nestes dois sistemas (102164 e 102161), e o QGIS3 não os consegue projectar
correctamente (para já, esperemos), o que vai levar a que mais cartografia
seja produzida com estes erros que, recordo, são deslocações, à volta dos
250 metros, para NE (caso do 102164) ou para SW (caso do 102161) das suas
reais localizações!
Na minha modesta opinião, acho que a versão 2.18 do QGIS, que consegue
projectar correctamente shapes nestes dois sistemas da ESRI, ainda é a
melhor solução para quem precisa de trabalhar com ficheiros de muitas
origens.
Cprts. a todos,
Sobral Almeida
2018-05-06 21:57 GMT+01:00 Pedro Pereira <pedromap@gmail.com>:
São códigos ESRI tive uma dor de cabeça com isso com os dados do ICNF que
estão nesse formato.
A dom, 6/05/2018, 13:16, Rui Cavaco <rpcavaco@gmail.com> escreveu:
Bom dia caro António.
Na lista de códigos EPSG (assumido como padrão de “facto”) os códigos
correctos para o “Datum Lisboa” são:
- EPSG:20790 (com falsa origem, apenas coordenadas positivas)
- EPSG:20791 (sem falsa origem - utilização mais habitual do Datum
Lisboa)
Os códigos que indica são códigos específicos que a ESRI insiste em
manter, contra toda a lógica da definição de padrões que se querem abertos.
Assim, nas listas actuais de códigos de sistemas de coordenadas a
designação que procurava seria, para o Datum Lisboa falsa origem:
ESRI:102164 http://spatialreference.org/ref/esri/102164/
Se este código não existir na lista, basta trocar a indicação do sistema
de referência dos dados pelo padrão correcto EPSG:20790.
EPSG:102164 é uma indicação incoerente e incorrecta.
Cumprimentos
Rui Cavaco
Antonio Sobral Almeida <sobral.almeida@gmail.com> escreveu no dia
domingo, 6/05/2018 às 12:36:
Bom dia,
No QGis 2.18 estava completamente resolvida a projecção correcta do
EPSG:102164 “Lisboa_Hayford_Gauss_IGeoE” e EPSG:102161
“Datum_73_Hayford_Gauss_IPCC” para EPSG:3763 “ETRS89 / Portugal TM06”,
como se pode ver na imagem descarregável no seguinte link:
https://we.tl/2rzaemBCGY
No QGis 3.0 não é possível seleccionar qualquer transformação de DATUM,
como se pode ver nas imagens.
Em ambos os casos seguiu-se o indicado em
http://qgis.pt/blog/2014/07/13/transformacao-de-coordenadas-
e-utilizacao-das-grelhas-ntv2-no-qgis/#3
Haverá alguma outra forma de ultrapassar este problema?
Cprts., Sobral Almeida
QGIS-pt mailing list
QGIS-pt@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/qgis-pt
QGIS-pt mailing list
QGIS-pt@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/qgis-pt
QGIS-pt mailing list
QGIS-pt@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/qgis-pt
QGIS-pt mailing list
QGIS-pt@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/qgis-pt
–
Pedro Pereira
-------------- next part --------------
An HTML attachment was scrubbed…
URL: <http://lists.osgeo.org/pipermail/qgis-pt/attachments/20180507/4d661c4f/attachment-0001.html>
Subject: Digest Footer
QGIS-pt mailing list
QGIS-pt@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/qgis-pt
End of QGIS-pt Digest, Vol 50, Issue 4
Carissimos,
Um outro ponto de vista possivel…
Vivemos na Europa, certo? Devemos cumprir a diretivas Europeias, certo? No caso em concreto devemos cumprir a diretiva INSPIRE, certo?
O que diz o INSPIRE sobre Coordinate Reference Systems (CRS)?
http://inspire.ec.europa.eu/documents/Data_Specifications/INSPIRE_DataSpecification_RS_v3.2.pdf
Diz:
5.5 Identifiers
These Technical Guidelines propose to use the http URIs provided by the Open Geospatial
Consortium as coordinate reference system identifiers (see identifiers for the default CRSs below).
These are based on and redirect to the definition in the EPSG Geodetic Parameter Registry
(http://www.epsg-registry.org/).
Ora tentem lá:
Em http://www.epsg-registry.org/ no “retreive by code” encontrar o EPSG:102164 e 102161…
resultado=“no result”
Em http://spatialreference.org/ref/epsg/?search=102164&srtext=Search
Resultado=“Did you mean: ESRI:102164?”
http://spatialreference.org/ref/esri/102164/
http://spatialreference.org/ref/esri/102161/
E EPSG=20790 ou 20791… já aparece! certo?
http://spatialreference.org/ref/epsg/20790/
http://spatialreference.org/ref/epsg/20791/
Talvez seja tempo de dizer aos senhores da ESRI que na Europa há que ser Europeu e cumprir as regras e leis em vigor, ou seja usar CÓDIGOS EPSG e NÃO CODIGOS ESRI!
INTEROPERABILIDADE É ISTO!
CUMPRIR E FAZER CUMPRIR AS REGRAS COMUNS PARA QUE TODOS SE ENTENDAM!
Cumprimentos
···
No dia 8 de maio de 2018 às 21:03, José Carlos Santos <jcgarciadossantos@gmail.com> escreveu:
Pedro, mto boa noite.
Estou de acordo consigo.
A explicação é essa.
Um abraço.
JCGS
A Ter, 8 de mai de 2018, 20:01, <qgis-pt-request@lists.osgeo.org> escreveu:
Send QGIS-pt mailing list submissions to
qgis-pt@lists.osgeo.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.osgeo.org/mailman/listinfo/qgis-pt
or, via email, send a message with subject or body ‘help’ to
qgis-pt-request@lists.osgeo.org
You can reach the person managing the list at
qgis-pt-owner@lists.osgeo.org
When replying, please edit your Subject line so it is more specific
than “Re: Contents of QGIS-pt digest…”
Today’s Topics:
- Re: QGIS 3 - transformação incorrecta de EPSG:102164 e
EPSG:102161 para EPSG:3763 (Pedro Pereira)
Message: 1
Date: Mon, 7 May 2018 23:14:44 +0100
From: Pedro Pereira <pedromap@gmail.com>
To: QGIS PT - lista de utilizadores QGIS, em português.
<qgis-pt@lists.osgeo.org>
Subject: Re: [QGIS-pt] QGIS 3 - transformação incorrecta de
EPSG:102164 e EPSG:102161 para EPSG:3763
Message-ID:
<CAFzQen9ZgKhweJOGzyYU09xD+3Vx7OULyrs87DwSqSDFMOEYQg@mail.gmail.com>
Content-Type: text/plain; charset=“utf-8”
Boas,
Não estou a dizer que seja culpa da ESRI, é uma opção deles…
O problema não está no QGIS3 ou QGIS2.18, em ambos o qgis não “entende” o
prj do ARCMAP.
A solução é indicar o código EPSG equivalente ao código ESRI, como disse o
Rui (do ESRI 102164 e 102161, para EPSG 20790 ou 20791).
Não é nehum problema a shp ter o código ESRI, o que acontece é que os
disponibiliza deveria ter esse cuidado de alertar o utilizador para saber
com o que conta.
Como eu muitas pessoas poderão ter levado algum tempo até se aperceberem do
problema.
Atentamente,
Pedro
2018-05-07 22:56 GMT+01:00 Antonio Sobral Almeida <sobral.almeida@gmail.com>
:
Viva, Pedro,
É verdade, mas a ESRI não vai desistir do seu sistema de projecção.
O problema é que vão (ainda) continuar a existir milhares de ficheiros
nestes dois sistemas (102164 e 102161), e o QGIS3 não os consegue projectar
correctamente (para já, esperemos), o que vai levar a que mais cartografia
seja produzida com estes erros que, recordo, são deslocações, à volta dos
250 metros, para NE (caso do 102164) ou para SW (caso do 102161) das suas
reais localizações!
Na minha modesta opinião, acho que a versão 2.18 do QGIS, que consegue
projectar correctamente shapes nestes dois sistemas da ESRI, ainda é a
melhor solução para quem precisa de trabalhar com ficheiros de muitas
origens.
Cprts. a todos,
Sobral Almeida
2018-05-06 21:57 GMT+01:00 Pedro Pereira <pedromap@gmail.com>:
São códigos ESRI tive uma dor de cabeça com isso com os dados do ICNF que
estão nesse formato.
A dom, 6/05/2018, 13:16, Rui Cavaco <rpcavaco@gmail.com> escreveu:
Bom dia caro António.
Na lista de códigos EPSG (assumido como padrão de “facto”) os códigos
correctos para o “Datum Lisboa” são:
- EPSG:20790 (com falsa origem, apenas coordenadas positivas)
- EPSG:20791 (sem falsa origem - utilização mais habitual do Datum
Lisboa)
Os códigos que indica são códigos específicos que a ESRI insiste em
manter, contra toda a lógica da definição de padrões que se querem abertos.
Assim, nas listas actuais de códigos de sistemas de coordenadas a
designação que procurava seria, para o Datum Lisboa falsa origem:
ESRI:102164 http://spatialreference.org/ref/esri/102164/
Se este código não existir na lista, basta trocar a indicação do sistema
de referência dos dados pelo padrão correcto EPSG:20790.
EPSG:102164 é uma indicação incoerente e incorrecta.
Cumprimentos
Rui Cavaco
Antonio Sobral Almeida <sobral.almeida@gmail.com> escreveu no dia
domingo, 6/05/2018 às 12:36:
Bom dia,
No QGis 2.18 estava completamente resolvida a projecção correcta do
EPSG:102164 “Lisboa_Hayford_Gauss_IGeoE” e EPSG:102161
“Datum_73_Hayford_Gauss_IPCC” para EPSG:3763 “ETRS89 / Portugal TM06”,
como se pode ver na imagem descarregável no seguinte link:
https://we.tl/2rzaemBCGY
No QGis 3.0 não é possível seleccionar qualquer transformação de DATUM,
como se pode ver nas imagens.
Em ambos os casos seguiu-se o indicado em
http://qgis.pt/blog/2014/07/13/transformacao-de-coordenadas-
e-utilizacao-das-grelhas-ntv2-no-qgis/#3
Haverá alguma outra forma de ultrapassar este problema?
Cprts., Sobral Almeida
QGIS-pt mailing list
QGIS-pt@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/qgis-pt
QGIS-pt mailing list
QGIS-pt@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/qgis-pt
QGIS-pt mailing list
QGIS-pt@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/qgis-pt
QGIS-pt mailing list
QGIS-pt@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/qgis-pt
–
Pedro Pereira
-------------- next part --------------
An HTML attachment was scrubbed…
URL: <http://lists.osgeo.org/pipermail/qgis-pt/attachments/20180507/4d661c4f/attachment-0001.html>
Subject: Digest Footer
QGIS-pt mailing list
QGIS-pt@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/qgis-pt
End of QGIS-pt Digest, Vol 50, Issue 4
QGIS-pt mailing list
QGIS-pt@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/qgis-pt
–
Ricardo Pinho