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
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
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
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
Olá António.
Basta indicar que os ficheiros tem os EPSG 20790 ou 20791. Os códigos da ESRI são meros “alias”.
Rui Cavaco
Antonio Sobral Almeida <sobral.almeida@gmail.com> escreveu no dia segunda, 7/05/2018 às 22:57:
···
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
Caro António,
A esri já suporta há algum tempo os códigos epsg equivalentes aos seus
próprios códigos "antigos". Isto naturalmente tem uma razão de ser
histórica... Mas penso que no futuro não é de esperar que os códigos antigos
esri sejam suportados por outros programas sig. O epsg é o padrão de facto
para definições de sistemas de coordenadas, embora mantido por uma
organização empresarial, não sendo um standard internacional "oficial".
Na minha opinião, será mais seguro redefinir os códigos dos shapefiles ou
tabelas espaciais com os códigos epsg actuais. Supondo que tem acesso a
software esri, uma vez que tem shapefiles com srids esri, poderá redefinir
os códigos em massa muito facilmente usando o arcmap.
Uma consequência de usar códigos esri é que ao publicar esses dados via
serviços wms, estes não serão reconhecidos pelos clientes web...
Cumps,
Duarte
--
Sent from: http://osgeo-org.1560.x6.nabble.com/QGIS-pt-f5128248.html
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
QGIS-pt mailing list
QGIS-pt@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/qgis-pt
–
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
Pedro Pereira