[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