[GRASS-dev] [GRASS GIS] #3414: v.import: ERROR: Invalid e-w resolution field: 0 when importing EU_LAEA point into Sinusoidal location

[GRASS GIS]

#3414: v.import: ERROR: Invalid e-w resolution field: 0 when importing EU_LAEA
point into Sinusoidal location
---------------------------------+-------------------------
  Reporter:  neteler             |      Owner:  grass-dev@…
      Type:  defect              |     Status:  new
  Priority:  normal              |  Milestone:  7.2.2
 Component:  Projections/Datums  |    Version:  svn-trunk
Resolution:                      |   Keywords:  v.import
       CPU:  Unspecified         |   Platform:  Linux
---------------------------------+-------------------------

Comment (by mmetz):

 Replying to [comment:4 mlennert]:
 > Replying to [comment:3 mmetz]:
 > > Replying to [comment:2 mlennert]:
 > > >
 > > > [...] I get:
 > > >
 > > >
 > > > {{{
 > > > g.proj -p
 > > > ERREUR :Invalid e-w resolution field: 0
 > > > }}}
 > > >
 > > > because DEFAULT_WIND/WIND contains:
 > > >
 > > > {{{
 > > > proj:       99
 > > > zone:       0
 > > > north:      1205000
 > > > south:      1205000
 > > > east:       3674000
 > > > west:       3674000
 > > > [...]
 > > > }}}
 > > >
 > > > which seems logical as a point does not have dimensions, but the
 default region should still be defined with one cell and a resolution of
 1....
 > >
 > > A simple solution would be to add/subtract 0.5 if north == south
 and/or east == west with rows and/or cols set to 1. For latlong, this is
 only guaranteed to work in trunk.
 >
 > I think that the default region created when using a vector as input for
 georeference should always be the default n=1 s=0 e=1 w=0 res=1 region
 (i.e. the same that is created when creating a location without
 determining a default region). One could argue that the user would like to
 have a default region with the extents of the vector used for creating the
 location, but as there is no way to determine a sensible resolution, the
 risk is high that you get an arbitrarily large region with a resolution of
 1, i.e. a very large number of pixels.

 I aggree.

 > Or we would have to decide on a reasonable default number of pixels and
 adjust the region accordingly.

 I don't see a way to determine a reasonable resolution/number of pixels
 from vector extents.

 > But I think that having an obviously non-sense region is better as it
 forces the user to explicitly set the region.

 Usually, users need to set (or at least review) the region anyway.

 That means that duplicate code in g.proj/v.in.ogr where new region
 settings are estimated needs to be removed.

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/3414#comment:5>
GRASS GIS <https://grass.osgeo.org>