[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