[GRASS-user] v.external, postgis materialized views and projection

Moritz Lennert mlennert at club.worldonline.be
Tue Aug 17 01:16:57 PDT 2021


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 at lists.osgeo.org> ON BEHALF OF
> Donovan Cameron
>  SENT: tirsdag 17. august 2021 07:06
>  TO: grass-user at 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 at 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 at 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%7C01%7C%7C542dd240835b472f88ae08d9613cb730%7C6cef373021314901831055b3abf02c73%7C0%7C0%7C637647736003704409%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=xICdQBainNrRKS0F3Efppf67CgX%2FugCL9uSsgKIIph8%3D&reserved=0
> 
> _______________________________________________
> grass-user mailing list
> grass-user at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user



More information about the grass-user mailing list