[GRASS-dev] [GRASS GIS] #2300: v.out.ogr: spatialite support not working

GRASS GIS trac at osgeo.org
Thu May 29 20:26:18 PDT 2014


#2300: v.out.ogr: spatialite support not working
-----------------------------------+----------------------------------------
 Reporter:  hamish                 |       Owner:  grass-dev@…              
     Type:  defect                 |      Status:  new                      
 Priority:  critical               |   Milestone:  6.4.4                    
Component:  Vector                 |     Version:  svn-trunk                
 Keywords:  v.out.ogr, spatialite  |    Platform:  Linux                    
      Cpu:  x86-64                 |  
-----------------------------------+----------------------------------------

Comment(by hamish):

 Replying to [ticket:2300 hamish]:
 > In the gdal-dev thread the solution was to pick the correct one
 > of OGR_G_SetPoint() vs. OGR_G_SetPoint_2D(), maybe that helps here?
 >
 > the code seems suitably pointy, even if it is embedded in the "lines"
 > part of the code, but I wonder if 2D vs 3D definition is causing
 trouble?

 right, that's it. The following patch vs. devbr6 makes it work:

 {{{
 Index: main.c
 ===================================================================
 --- main.c      (revision 59151)
 +++ main.c      (working copy)
 @@ -753,9 +753,13 @@
             }
             else if ((type == GV_POINT) ||
                      ((type == GV_CENTROID) && (otype & GV_CENTROID))) {
 +
                 Ogr_geometry = OGR_G_CreateGeometry(wkbPoint);
 -               OGR_G_AddPoint(Ogr_geometry, Points->x[0], Points->y[0],
 -                              Points->z[0]);
 +               if (Vect_is_3d(&In))
 +                   OGR_G_AddPoint(Ogr_geometry, Points->x[0],
 Points->y[0],
 +                                  Points->z[0]);
 +               else
 +                   OGR_G_AddPoint_2D(Ogr_geometry, Points->x[0],
 Points->y[0]);
             }
             else {              /* GV_LINE or GV_BOUNDARY */

 }}}

 but the v.out.ogr z-flag logic might require some modifications to that.
 (the force-2D flag in trunk makes a bit more sense, but also would need a
 different check for the flag)


 > Converting usgsgages to a 3D points map didn't help.

 but I don't think I used the -z flag... ? All ways need to be tested, and
 other geometry types also need to receive the same 2D vs 3D treatment I
 guess.


 Hamish

-- 
Ticket URL: <https://trac.osgeo.org/grass/ticket/2300#comment:4>
GRASS GIS <http://grass.osgeo.org>



More information about the grass-dev mailing list