Hi all,
I have digitized a few geological cross-sections each consisting of a 1 polygon & 1 polyline layer (representing lithology & faults respectively). The layers were digitized in plan view with arbitrary coordinates in meters and imported into PostgreSQL/PostGIS. I then created views using ST_Translate(ST_RotateZ(ST_RotateX(ST_Translate(geom, ))) to correctly plot the cross-section polygons & polylines in 3D space. One day I need to learn how to multiply matrices so I can do it all in a single step!
I just tried to import them into GRASS 7.0.3RC1 using v.in.ogr and got the following error message:
ERROR 1: Reading EWKB with 4-dimensional coordinates (XYZM) is not supported
Can GRASS not import PostGIS 3D data? Is it the vertical Polygon with zero area topology problem?
What other options do I have to get 3D-cross-section data into GRASS?
I tried to use the ST_Extrude (to avoid topology problems) command in PostGIS and Grass’s v.in.ogr didn’t like that either. Is there another way to get 3D objects into GRASS?
I want to use v.hull on the vertical cross-sectional data and symbolize some geochemical drill data in Grass’s 3D viewer.
Regards,
Phil
Hi,
On Tue, Jan 12, 2016 at 11:37 PM, Phillip Allen
<phillipjallen830@gmail.com> wrote:
Hi all,
I have digitized a few geological cross-sections each consisting of a 1
polygon & 1 polyline layer (representing lithology & faults respectively).
The layers were digitized in plan view with arbitrary coordinates in meters
and imported into PostgreSQL/PostGIS. I then created views using
ST_Translate(ST_RotateZ(ST_RotateX(ST_Translate(geom, ))) to correctly plot
the cross-section polygons & polylines in 3D space. One day I need to learn
how to multiply matrices so I can do it all in a single step!
I just tried to import them into GRASS 7.0.3RC1 using v.in.ogr and got the
following error message:
ERROR 1: Reading EWKB with 4-dimensional coordinates (XYZM) is not supported
Can GRASS not import PostGIS 3D data?
This error (given the fact that it is "ERROR 1" must come from OGR and
not from GRASS GIS as we don't use numbers).
Hence, ogr2ogr would likely report the same.
Is it the vertical Polygon with zero area topology problem?
What other options do I have to get 3D-cross-section data into GRASS?
I tried to use the ST_Extrude (to avoid topology problems) command in
PostGIS and Grass's v.in.ogr didn't like that either. Is there another way
to get 3D objects into GRASS?
Which OGR version is installed? As soon as it works there I am
confident that it also works with v.in.ogr.
I see some discussion about the problem also here (random search result):
https://lists.osgeo.org/pipermail/gdal-dev/2015-February/041056.html
I want to use v.hull on the vertical cross-sectional data and symbolize some
geochemical drill data in Grass's 3D viewer.
IMHO it needs to be solved in OGR first (maybe it is in the latest
version, I didn't verify).
Best,
Markus
Markus,
Thanks for shedding some light on this problem.
Yesterday I tried to work around it by extending my sql view with:
ST_Boundary(ST_Force3d(ST_Force2d(geom)))::geometry(MultiLineStringZ,32611)
so it would eliminate the M values (also I had a few z errors in the cross-section) and convert the polygons to polyLines. I then exported them to shapefiles. After the closed polyline-shapefiles were imported into Grass I then converted them to faces using:
v.type input=xsec_c_lithL output=xsec_c_lithL_face from_type=line to_type=face
This seemed to work so I would have an enclosed area to color. But now I cannot seem to color the cross-section faces? It is just black. I have a text column with rgb values (255:255:255 format) but when I use it for “use color for thematic mapping” it keeps reporting
DBMI-SQLite driver error: error in sqlite3_prepare(): unrecognized token error “'255:255:115”
What is odd is that I was able to color the polylines…I must admit that I have never really had much luck thematically mapping vectors in Grass.
So now the question is how to color the thematically mapped cross-section Faces?
I am using the latest version 7.0.3RC1.
regards,
Phil
···
On Thu, Jan 14, 2016 at 6:55 AM, Markus Neteler <neteler@osgeo.org> wrote:
Hi,
On Tue, Jan 12, 2016 at 11:37 PM, Phillip Allen
<phillipjallen830@gmail.com> wrote:
Hi all,
I have digitized a few geological cross-sections each consisting of a 1
polygon & 1 polyline layer (representing lithology & faults respectively).
The layers were digitized in plan view with arbitrary coordinates in meters
and imported into PostgreSQL/PostGIS. I then created views using
ST_Translate(ST_RotateZ(ST_RotateX(ST_Translate(geom, ))) to correctly plot
the cross-section polygons & polylines in 3D space. One day I need to learn
how to multiply matrices so I can do it all in a single step!
I just tried to import them into GRASS 7.0.3RC1 using v.in.ogr and got the
following error message:
ERROR 1: Reading EWKB with 4-dimensional coordinates (XYZM) is not supported
Can GRASS not import PostGIS 3D data?
This error (given the fact that it is “ERROR 1” must come from OGR and
not from GRASS GIS as we don’t use numbers).
Hence, ogr2ogr would likely report the same.
Is it the vertical Polygon with zero area topology problem?
What other options do I have to get 3D-cross-section data into GRASS?
I tried to use the ST_Extrude (to avoid topology problems) command in
PostGIS and Grass’s v.in.ogr didn’t like that either. Is there another way
to get 3D objects into GRASS?
Which OGR version is installed? As soon as it works there I am
confident that it also works with v.in.ogr.
I see some discussion about the problem also here (random search result):
https://lists.osgeo.org/pipermail/gdal-dev/2015-February/041056.html
I want to use v.hull on the vertical cross-sectional data and symbolize some
geochemical drill data in Grass’s 3D viewer.
IMHO it needs to be solved in OGR first (maybe it is in the latest
version, I didn’t verify).
Best,
Markus
On Thu, Jan 14, 2016 at 3:21 PM, Phillip Allen
<phillipjallen830@gmail.com> wrote:
...
But now I
cannot seem to color the cross-section faces? It is just black. I have a
text column with rgb values (255:255:255 format) but when I use it for "use
color for thematic mapping" it keeps reporting
DBMI-SQLite driver error: error in sqlite3_prepare(): unrecognized token
error "'255:255:115"
^ -- spurious '
It would understand RGB but not with this extra character, maybe you
can filter it out.
I'd leave the rest of the questions to others.
best
Markus
Markus,
I saw that spurious character too. It is only one record and I retyped the rgb code but it still persists. Also the full message is odd:
Error in db.execute
DBMI-SQLite driver error:
Error in sqlite3_prepare():
unrecognized token: “'255:255:115”
DDBMI-SQLite driver error:
Error in sqlite3_prepare():
unrecognized token: “'255:255:115”
ERROR: Error while executing: 'UPDATE v_xsec_c_lithl_face SET
temp_0=‘255:255:115’
Should the text (rgb string) in the SET be in quotes?
regards,
Phil