[GRASS-dev] [GRASS GIS] #66: v.out.svg: Standardise the `type' option interpretation

#66: v.out.svg: Standardise the `type' option interpretation
-------------------------+--------------------------------------------------
Reporter: 1gray | Owner: grass-dev@lists.osgeo.org
     Type: enhancement | Status: new
Priority: minor | Milestone: 7.0.0
Component: default | Version: unspecified
Keywords: |
-------------------------+--------------------------------------------------
Currently {{{v.out.svg}}} interprets its {{{type}}} option in a
non-standard way, namely:

  * it's not allowed to specify multiple types per {{{v.out.svg}}}
invocation;

  * the name for the area feature type is {{{poly}}}, while it should be
{{{area}}}.

  * there's no way to choose only points or centroids for output, only
both; similarly for lines and boundaries.

Hence, I suggest the following patch.

Since the patch breaks the compatibility with the former versions of the
module, I believe it should only be considered for GRASS 7.

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/66&gt;
GRASS GIS <http://grass.osgeo.org>
GRASS Geographic Information System (GRASS GIS) - http://grass.osgeo.org/

GRASS GIS <trac@osgeo.org> writes:

[...]

> Currently {{{v.out.svg}}} interprets its {{{type}}} option in a
> non-standard way, namely:

[...]

> Hence, I suggest the following patch.

> Since the patch breaks the compatibility with the former versions of
> the module, I believe it should only be considered for GRASS 7.

  ... Though, of course, anyone interested is encouraged to test
  it just now. I have only a few vector maps in my disposal, and
  they're either too simple, or too large, so I haven't tested
  this change much myself.

#66: v.out.svg: Standardise the `type' option interpretation
--------------------------+-------------------------------------------------
  Reporter: 1gray | Owner: grass-dev@lists.osgeo.org
      Type: enhancement | Status: new
  Priority: minor | Milestone: 7.0.0
Component: default | Version: unspecified
Resolution: | Keywords:
  Platform: Unspecified | Cpu: Unspecified
--------------------------+-------------------------------------------------
Changes (by neteler):

  * platform: => Unspecified
  * cpu: => Unspecified

Comment:

Patch redone for current 6.5/7 (and uploaded uncompressed for easier
review). Compiling, I get this warning:
{{{
main.c:122: warning: assignment from incompatible pointer type
}}}

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/66#comment:1&gt;
GRASS GIS <http://grass.osgeo.org>

#66: v.out.svg: Standardise the `type' option interpretation
--------------------------+-------------------------------------------------
  Reporter: 1gray | Owner: grass-dev@lists.osgeo.org
      Type: enhancement | Status: new
  Priority: minor | Milestone: 7.0.0
Component: default | Version: unspecified
Resolution: | Keywords:
  Platform: Unspecified | Cpu: Unspecified
--------------------------+-------------------------------------------------
Comment (by glynn):

Replying to [comment:1 neteler]:
> Patch redone for current 6.5/7 (and uploaded uncompressed for easier
review). Compiling, I get this warning:
{{{
main.c:122: warning: assignment from incompatible pointer type
}}}

The ->answers field is {{{char **}}} which isn't compatible with {{{const
char **}}}.

You can implicitly cast {{{char *}}} to {{{const char *}}}, but not with
additional levels of indirection. In theory, a {{{const char *}}} could be
wider than a {{{char *}}}, so you can cast these types, but not pointers
to them.

{{{char * const *}}} should work.

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/66#comment:2&gt;
GRASS GIS <http://grass.osgeo.org>

#66: v.out.svg: Standardise the `type' option interpretation
--------------------------+-------------------------------------------------
  Reporter: 1gray | Owner: grass-dev@lists.osgeo.org
      Type: enhancement | Status: new
  Priority: minor | Milestone: 7.0.0
Component: default | Version: unspecified
Resolution: | Keywords:
  Platform: Unspecified | Cpu: Unspecified
--------------------------+-------------------------------------------------
Comment (by 1gray):

Replying to [comment:2 glynn]:
> Replying to [comment:1 neteler]:
>> Patch redone for current 6.5/7 (and uploaded uncompressed for easier
review). Compiling, I get this warning:
>> {{{
>> main.c:122: warning: assignment from incompatible pointer type
>> }}}

> The ->answers field is {{{char **}}} which isn't compatible with
{{{const char **}}}.

> You can implicitly cast {{{char *}}} to {{{const char *}}}, but not with
additional levels of indirection. In theory, a {{{const char *}}} could be
wider than a {{{char *}}}, so you can cast these types, but not pointers
to them.

Is this actually permitted by some standard (either C89 or C99)?

> {{{char * const *}}} should work.

Do I understand it correctly that it means variable pointer to constant
pointer to variable character data?

I think that the part of code in question, once extracted into a separate
function, could occasionally be useful when processing constant data. And
I'm quite surprised that two functions would be necessary to achieve that
instead of just one.

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/66#comment:3&gt;
GRASS GIS <http://grass.osgeo.org>

#66: v.out.svg: Standardise the `type' option interpretation
--------------------------+-------------------------------------------------
  Reporter: 1gray | Owner: grass-dev@lists.osgeo.org
      Type: enhancement | Status: new
  Priority: minor | Milestone: 7.0.0
Component: default | Version: unspecified
Resolution: | Keywords:
  Platform: Unspecified | Cpu: Unspecified
--------------------------+-------------------------------------------------
Comment (by glynn):

Replying to [comment:3 1gray]:

> > You can implicitly cast {{{char *}}} to {{{const char *}}}, but not
with additional levels of indirection. In theory, a {{{const char *}}}
could be wider than a {{{char *}}}, so you can cast these types, but not
pointers to them.
>
> Is this actually permitted by some standard (either C89 or C99)?

Is what permitted? Implicit casts or pointer size varying depending upon
whether the target is "const"? The answers are "sometimes" and "yes"
respectively, for both C89 and C99.

> > {{{char * const *}}} should work.
>
> Do I understand it correctly that it means variable pointer to constant
pointer to variable character data?

Yes.

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

#66: v.out.svg: Standardise the `type' option interpretation
--------------------------+-------------------------------------------------
  Reporter: 1gray | Owner: grass-dev@lists.osgeo.org
      Type: enhancement | Status: new
  Priority: minor | Milestone: 7.0.0
Component: Vector | Version: unspecified
Resolution: | Keywords: v.out.svg
  Platform: Unspecified | Cpu: Unspecified
--------------------------+-------------------------------------------------
Changes (by martinl):

  * keywords: => v.out.svg
  * component: default => Vector

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/66#comment:5&gt;
GRASS GIS <http://grass.osgeo.org>