[GRASS-dev] [GRASS GIS] #2185: Painfully Slow 'v.in.ogr' Vector Import
GRASS GIS
trac at osgeo.org
Tue Mar 21 13:47:17 PDT 2017
#2185: Painfully Slow 'v.in.ogr' Vector Import
-------------------------+------------------------------------------------
Reporter: justinzane | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 7.0.6
Component: Vector | Version: svn-trunk
Resolution: | Keywords: import, OGR, performance, v.in.ogr
CPU: x86-64 | Platform: Linux
-------------------------+------------------------------------------------
Comment (by mmetz):
Replying to [comment:37 hcho]:
> Yes, that's what I found too. Vect_line_intersection2 doesn't have this
issue, but it still creates a single point intersection at the first
vertex of the second new line (line ID 3) in the geojson example.
>
> Line ID 1: original unbroken line
>
> 1st iteration
> Line ID 2-4: new broken lines
>
> 2nd iteration
> Line ID 5: identical to line 3
> Line ID 6: start node of line 3
>
> Lines 5 & 6 shouldn't be returned at all from the intersection routine,
I think. The patch fixes this.
Such an infinite loop in Vect_break_lines() has been observed previously
and fixed back then in trunk r55796, r55813, r55848. Apparently, these
commits did not solve all issues. It is most important that the
intersection point of the same two segments is always the same, no matter
which segment is a and which is b.
Your patch might cause problems in special cases when an intersection
point is not added to a line even if there are no vertices identical with
the intersection point. That is, the line was not broken if it should have
been. Therefore I would rather not apply your patch.
--
Ticket URL: <https://trac.osgeo.org/grass/ticket/2185#comment:40>
GRASS GIS <https://grass.osgeo.org>
More information about the grass-dev
mailing list