<div dir="ltr"><div>Donovan,</div><div>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:</div><div><br></div><div>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;</div><div><br></div><div>It is an easy enough test!</div><div><br></div><div>regards,</div><div>Phil</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Aug 16, 2021 at 1:10 PM Saulteau Don <<a href="mailto:sault.don@gmail.com">sault.don@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="auto">When I use v.external to load a postgis materialized view it says the projection mismatches the Location but they are actually the same.</div><div dir="auto"><br></div><blockquote style="margin:0px 0px 0px 40px;border:medium none;padding:0px"><div><span style="font-family:monospace"><span style="color:rgb(0,0,0)">% v.external input="PG:host=localhost dbname=database" layer=table_1 output=t
</span></span></div><div><span style="font-family:monospace">ERROR: Projection of dataset does not appear to match current location.
</span></div></blockquote><div><span style="font-family:monospace"><br></span></div><span style="font-family:monospace"> Location PROJ_INFO is:</span><br><span style="font-family:monospace"> name: NAD83 / UTM zone 10N</span><br><span style="font-family:monospace"> datum: nad83</span><br><span style="font-family:monospace"> ellps: grs80</span><br><span style="font-family:monospace"> proj: utm</span><br><span style="font-family:monospace"> zone: 10</span><br><span style="font-family:monospace"> no_defs: defined</span><br><div><span style="font-family:monospace"> init: EPSG:26910
</span></div><font face="monospace"><br></font><span style="font-family:monospace"> Dataset PROJ_INFO is:</span><br><span style="font-family:monospace"> name: NAD83 / BC Albers</span><br><span style="font-family:monospace"> datum: nad83</span><br><span style="font-family:monospace"> ellps: grs80</span><br><span style="font-family:monospace"> proj: aea</span><br><span style="font-family:monospace"> lat_0: 45</span><br><span style="font-family:monospace"> lon_0: -126</span><br><span style="font-family:monospace"> lat_1: 50</span><br><span style="font-family:monospace"> lat_2: 58.5</span><br><span style="font-family:monospace"> x_0: 1000000</span><br><span style="font-family:monospace"> y_0: 0</span><br><div><span style="font-family:monospace"> no_defs: defined
</span></div><div dir="auto"><span style="font-family:monospace"><br> Difference in: proj
<br>
<br> In case of no significant differences in the projection definitions,
<br> use the -o flag to ignore them and use current location definition.
<br> Consider generating a new location from the input dataset using the
<br> 'location' parameter.<br></span><div dir="auto"><br></div><div dir="auto">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().</div><div dir="auto"><br></div><div dir="auto">Is this normal for grass to see materialized views like this?</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">Donovan</div></div>
</div>
_______________________________________________<br>
grass-user mailing list<br>
<a href="mailto:grass-user@lists.osgeo.org" target="_blank">grass-user@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/grass-user" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/grass-user</a><br>
</blockquote></div>