When I use v.external to load a postgis materialized view it says the projection mismatches the Location but they are actually the same.
% v.external input=“PG:host=localhost dbname=database” layer=table_1 output=t
ERROR: Projection of dataset does not appear to match current location.
Location PROJ_INFO is:
name: NAD83 / UTM zone 10N
datum: nad83
ellps: grs80
proj: utm
zone: 10
no_defs: defined
init: EPSG:26910
Dataset PROJ_INFO is:
name: NAD83 / BC Albers
datum: nad83
ellps: grs80
proj: aea
lat_0: 45
lon_0: -126
lat_1: 50
lat_2: 58.5
x_0: 1000000
y_0: 0
no_defs: defined
Difference in: proj
In case of no significant differences in the projection definitions,
use the -o flag to ignore them and use current location definition.
Consider generating a new location from the input dataset using the
‘location’ parameter.
It looks like GRASS sees the projection from the source table used for the materialized view instead of the materialized views projection that was set in postgis using ST_Transform().
Is this normal for grass to see materialized views like this?
Donovan
Donovan,
I am not sure about GRASS’s quirks in respect to this problem but I do see in QGIS that in my views I often have to specifically CAST my geometries so QGIS can see the Z & M values:
example: SELECT b. sample_id, b. au_ppm, b. as_ppm, b. cu_ppm, ST_TRANSFORM(b.geom, 32718 )::geometry(LineStringZM,32718) FROM bore_hole b;
It is an easy enough test!
regards,
Phil
On Mon, Aug 16, 2021 at 1:10 PM Saulteau Don <sault.don@gmail.com> wrote:
When I use v.external to load a postgis materialized view it says the projection mismatches the Location but they are actually the same.
% v.external input=“PG:host=localhost dbname=database” layer=table_1 output=t
ERROR: Projection of dataset does not appear to match current location.
Location PROJ_INFO is:
name: NAD83 / UTM zone 10N
datum: nad83
ellps: grs80
proj: utm
zone: 10
no_defs: defined
init: EPSG:26910
Dataset PROJ_INFO is:
name: NAD83 / BC Albers
datum: nad83
ellps: grs80
proj: aea
lat_0: 45
lon_0: -126
lat_1: 50
lat_2: 58.5
x_0: 1000000
y_0: 0
no_defs: defined
Difference in: proj
In case of no significant differences in the projection definitions,
use the -o flag to ignore them and use current location definition.
Consider generating a new location from the input dataset using the
‘location’ parameter.
It looks like GRASS sees the projection from the source table used for the materialized view instead of the materialized views projection that was set in postgis using ST_Transform().
Is this normal for grass to see materialized views like this?
Donovan
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
On 2021-08-16 12:18 p.m., Phillip Allen wrote:
I am not sure about GRASS's quirks in respect to this problem but I do see in QGIS that in my views I often have to specifically CAST my geometries so QGIS can see the Z & M values:
example: SELECT b. sample_id, b. au_ppm, b. as_ppm, b. cu_ppm, ST_TRANSFORM(b.geom, 32718 )::geometry(LineStringZM,32718) FROM bore_hole b;
Tested on a new set of polygons and casted but it didn't make a difference. GRASS doesn't like ST_Transform on materialized views it looks like.
All the views are opening in QGIS fine and with their correct projection and geometry type (with and without casting to a specific type).
On Mon, Aug 16, 2021 at 1:10 PM Saulteau Don <sault.don@gmail.com <mailto:sault.don@gmail.com>> wrote:
When I use v.external to load a postgis materialized view it says
the projection mismatches the Location but they are actually the same.
% v.external input="PG:host=localhost dbname=database"
layer=table_1 output=t
ERROR: Projection of dataset does not appear to match current
location.
Location PROJ_INFO is:
name: NAD83 / UTM zone 10N
datum: nad83
ellps: grs80
proj: utm
zone: 10
no_defs: defined
init: EPSG:26910
Dataset PROJ_INFO is:
name: NAD83 / BC Albers
datum: nad83
ellps: grs80
proj: aea
lat_0: 45
lon_0: -126
lat_1: 50
lat_2: 58.5
x_0: 1000000
y_0: 0
no_defs: defined
Difference in: proj
In case of no significant differences in the projection
definitions,
use the -o flag to ignore them and use current location
definition.
Consider generating a new location from the input dataset
using the
'location' parameter.
It looks like GRASS sees the projection from the source table used
for the materialized view instead of the materialized views
projection that was set in postgis using ST_Transform().
Is this normal for grass to see materialized views like this?
Donovan
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org <mailto:grass-user@lists.osgeo.org>
https://lists.osgeo.org/mailman/listinfo/grass-user
<https://lists.osgeo.org/mailman/listinfo/grass-user>
Hi Donovan,
Did you try the suggestion from the error message to use the -o flag?
That overwrites the projection check and should link the data assuming the projection of your GRASS mapset.
Cheers
Stefan
···
From: grass-user grass-user-bounces@lists.osgeo.org On Behalf Of Donovan Cameron
Sent: tirsdag 17. august 2021 07:06
To: grass-user@lists.osgeo.org
Subject: Re: [GRASS-user] v.external, postgis materialized views and projection
On 2021-08-16 12:18 p.m., Phillip Allen wrote:
I am not sure about GRASS’s quirks in respect to this problem but I do see in QGIS that in my views I often have to specifically CAST my geometries so QGIS can see the Z & M values:
example: SELECT b. sample_id, b. au_ppm, b. as_ppm, b. cu_ppm, ST_TRANSFORM(b.geom, 32718 )::geometry(LineStringZM,32718) FROM bore_hole b;
Tested on a new set of polygons and casted but it didn’t make a difference. GRASS doesn’t like ST_Transform on materialized views it looks like.
All the views are opening in QGIS fine and with their correct projection and geometry type (with and without casting to a specific type).
On Mon, Aug 16, 2021 at 1:10 PM Saulteau Don <sault.don@gmail.com> wrote:
When I use v.external to load a postgis materialized view it says the projection mismatches the Location but they are actually the same.
% v.external input=“PG:host=localhost dbname=database” layer=table_1 output=t
ERROR: Projection of dataset does not appear to match current location.
Location PROJ_INFO is:
name: NAD83 / UTM zone 10N
datum: nad83
ellps: grs80
proj: utm
zone: 10
no_defs: defined
init: EPSG:26910
Dataset PROJ_INFO is:
name: NAD83 / BC Albers
datum: nad83
ellps: grs80
proj: aea
lat_0: 45
lon_0: -126
lat_1: 50
lat_2: 58.5
x_0: 1000000
y_0: 0
no_defs: defined
Difference in: proj
In case of no significant differences in the projection definitions,
use the -o flag to ignore them and use current location definition.
Consider generating a new location from the input dataset using the
‘location’ parameter.
It looks like GRASS sees the projection from the source table used for the materialized view instead of the materialized views projection that was set in postgis using ST_Transform().
Is this normal for grass to see materialized views like this?
Donovan
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
Am 17.08.2021 09:38 schrieb Stefan Blumentrath:
Hi Donovan,
Did you try the suggestion from the error message to use the -o flag?
That overwrites the projection check and should link the data assuming
the projection of your GRASS mapset.
That is a useful workaround, but I would still consider Donovan's observation as a bug, so please post an issue about it.
Make sure to indicate which version of GRASS GIS you are working with, including the GDAL and PROJ versions as there has been quite a lot of change in that domain across the latest releases.
Moritz
Cheers
Stefan
FROM: grass-user <grass-user-bounces@lists.osgeo.org> ON BEHALF OF
Donovan Cameron
SENT: tirsdag 17. august 2021 07:06
TO: grass-user@lists.osgeo.org
SUBJECT: Re: [GRASS-user] v.external, postgis materialized views and
projection
On 2021-08-16 12:18 p.m., Phillip Allen wrote:
I am not sure about GRASS's quirks in respect to this problem but I
do see in QGIS that in my views I often have to specifically CAST my
geometries so QGIS can see the Z & M values:
example: SELECT b. sample_id, b. au_ppm, b. as_ppm, b. cu_ppm,
ST_TRANSFORM(b.geom, 32718 )::geometry(LineStringZM,32718) FROM
bore_hole b;
Tested on a new set of polygons and casted but it didn't make a
difference. GRASS doesn't like ST_Transform on materialized views it
looks like.
All the views are opening in QGIS fine and with their correct
projection and geometry type (with and without casting to a specific
type).
On Mon, Aug 16, 2021 at 1:10 PM Saulteau Don <sault.don@gmail.com>
wrote:
When I use v.external to load a postgis materialized view it says
the projection mismatches the Location but they are actually the
same.
% v.external input="PG:host=localhost dbname=database" layer=table_1
output=t
ERROR: Projection of dataset does not appear to match current
location.
Location PROJ_INFO is:
name: NAD83 / UTM zone 10N
datum: nad83
ellps: grs80
proj: utm
zone: 10
no_defs: defined
init: EPSG:26910
Dataset PROJ_INFO is:
name: NAD83 / BC Albers
datum: nad83
ellps: grs80
proj: aea
lat_0: 45
lon_0: -126
lat_1: 50
lat_2: 58.5
x_0: 1000000
y_0: 0
no_defs: defined
Difference in: proj
In case of no significant differences in the projection
definitions,
use the -o flag to ignore them and use current location definition.
Consider generating a new location from the input dataset using the
'location' parameter.
It looks like GRASS sees the projection from the source table used
for the materialized view instead of the materialized views
projection that was set in postgis using ST_Transform().
Is this normal for grass to see materialized views like this?
Donovan
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user [1]
Links:
------
[1]
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.osgeo.org%2Fmailman%2Flistinfo%2Fgrass-user&data=04|01||542dd240835b472f88ae08d9613cb730|6cef373021314901831055b3abf02c73|0|0|637647736003704409|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000&sdata=xICdQBainNrRKS0F3Efppf67CgX%2FugCL9uSsgKIIph8%3D&reserved=0
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user