line_locate_point: 2st arg isn't a point\n - Again...

Question

I'm so close (I think) to exporting a usable file, except I can't get the stationing into it:

   CROSS-SECTION:
      STREAM ID:Forsythe Creek
      REACH ID:2
      STATION:None
      NODE NAME:
      BANK POSITIONS: None, None
      REACH LENGTHS: None, None, None
      NVALUES:
   LEVEE POSITIONS:
   INEFFECTIVE POSITIONS:
   BLOCKED POSITIONS:
   CUT LINE:
         6214410.26143986, 2222433.82224242
         6214375.33004066, 2222527.52281525
   SURFACE LINE:
         6214410.26143986, 2222433.82224242, 217.22
         6214401.17927607, 2222458.18439136, 214.05
         6214391.74779828, 2222483.48354602, 212.01
         6214382.3163205, 2222508.78270069, 213.99
         6214375.33004066, 2222527.52281525, 213.99
   END:

When I try, I get:

Calculating cross-sections stationing...
InternalError("line_locate_point: 2st arg isn't a point\n",)
Process aborted!

Calculating cross-sections banks stations...
Done.

Calculating cross-sections distances to the next cross-section downstream ...
InternalError('line_locate_point: 2st arg isn\'t a point\nCONTEXT:  SQL statement "SELECT\n        (1 - ST_LineLocatePoint(path.geom, ST_Intersection(r.geom, path.geom))) * ST_Length(path.geom)\n                             FROM\n        "ridge1"."Flowpaths" AS path\n    WHERE\n        path."LineType" = \'Channel\' AND\n        ST_Intersects(r.geom, path.geom)"\nPL/pgSQL function ridge1.downstream_reach_lengths() line 11 at SQL statement\n',)
Process aborted!
XSCutLines already exists inside RiverGIS registry.
Left flowpaths done.
XSCutLines already exists inside RiverGIS registry.
Right flowpaths done.
DTMs already exists inside RiverGIS registry.
XSSurface already exists inside RiverGIS registry.
XSCutLines already exists inside RiverGIS registry.

Probing DTM along XSCutLines...
Done

And HEC-RAS crashes when I import the result and try to select Cross Sections and IB Nodes. It finds nothing for "All Rivers". If I manually select only one Reach there, the Import River: <name> and "(All Reaches)" appear, but I instantly (before any data appears) get an error dialog:
---
Run-time error '9':
Subscript out of range
---
Dismiss the error and the whole program is gone.

I found http://q2a.rivergis.com/119/problem-calculating-bank-stations

And I did have overlapping cutlines on some kinky parts of my stream. But now I have spaced them out and verified none overlap, even at stream junctions, and I still get the errors.

I also found http://q2a.rivergis.com/414/calculating-cross-section-stationing

Which is more like my problem, but has no answers or comments.

I don't remember seeing those errors before, but my earlier attempts made the same kind of output files with no stationing, so maybe I just missed them.

Looking at my flowpaths layer, its table is just "1, Channel, 2, Channel" - I see the LineType = Channel part, but no data there...  But it draws the stream on the map, so there must be data somewhere... 

I guess I'm rambling...  Would appreciate help with this!

Loren

Answer 1

After many days of "learning experiences", I've gotten past this 'line_locate_point: 2st arg isn't a point" issue. At least in my case, it had nothing to do with the odd label capitalization or displayed sort order of the lines in the shapefile I was importing XSCutLines from. (It appears QGIS randomly garbles the sort order of the rows in the "Attribute Table" display!) Nor with all the columns of elevation data the SAGA Cross Profile tool had entered. Nor with a few cutlines being exactly on node points. The ras2dCreate2dPoints routine does call the correct 'ST_LineLocatePoint' function for my QGIS 3.2, despite showing 'line_locate_point' in the error message.

(The QGIS Processing -> Toolbox -> SAGA -> Terrain Analysis - Profiles parameter issue is now fixed in 3.2. If you do use the SAGA tool, and get "The following layers were not correctly generated", try using "Save to temporary file" instead of saving directly to a shapefile.)

The RiverGIS problem was an automatically generated cutline that was apparently too close in orientation to the river line. It had been generated very near a vertex where the river line changed angle, and it retained the orientation of the previous cutlines instead of splitting the difference with the ones around the corner. Easy to zoom in and see it only crossing the centerline once, and not touching anything else.

"ST_Intersection — (T) Returns a geometry that represents the shared portion of geomA and geomB." So it can return a point, but also a point _set_, or other geometry...  Somehow, despite both geometries assumedly being straight single line segments between distinct points, with easily visible different orientations, it must have decided they intersected at multiple points. Delete that one line and the error is gone! Two other lines that looked almost as close to the upstream centerline on the map did not trigger the problem.

When you're totally mystified where the problem might be, run this SQL query:

SELECT
    xs."XsecID" AS "XsecID",
    xs."ReachID" AS "ReachID",
    xs."Station" AS "Station",
    xs."RiverCode" AS "RiverCode",
    xs."ReachCode" AS "ReachCode",
    ST_Intersection(xs.geom, riv.geom) AS "Fraction"
FROM
    "<your project name>"."StreamCenterlines" AS riv,
    "<your project name>"."XSCutLines" AS xs
WHERE
    ST_Intersects(xs.geom, riv.geom)
ORDER BY xs."ReachID" ASC, xs."Station" DESC

Obviously replace "<your project name>" with the QGIS project name.

Also works for BankLines step if you replace "StreamCenterlines" with "BankLines".

You'll get a listing with shorter geometry strings for good cross sections and double-length strings for bad ones. Probably need to widen your display column a lot to see this.

Works for me in pgAdmn4, or in QGIS3 -> Database -> DB Manager -> (click the wrench icon). You could select only bad lines, but I find the background info helpful.

(BTW, I solved my last bit of confusion about "where is the data?" - If you open and select an "Attribute Table" display, at least for a line shapefile, you see all the columns of the layer _except_ the data. But if you select a row or all the rows there and Ctrl+C Copy, you get the data as well! Paste it to a text editor to examine it.)

Answer 2

Hello Loren !

I've encountered a same issue with the banks stations.

One XS were crossing a bank line twice (a matter of centimeters). I've found the bad intersection by targeting successively some parts of XS in the model geometry.

Try this way to solve your problem of crosssection VS channel.

I hope it could help.