<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
    <style type="text/css">body p { margin-bottom: 0cm; margin-top: 0pt; } </style>
  </head>
  <body bidimailui-charset-is-forced="true" text="#000000"
    bgcolor="#FFFFFF">
    <br>
    <div class="moz-cite-prefix">On 01/11/2019 9:38, Markus Metz wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAG+h=FEP=Ks7kN95Fw8_8sc7DccpxcZ3LRywTacUofdzPqh3=g@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr"><br>
        <br>
        On Fri, Nov 1, 2019 at 12:11 AM Veronica Andreo <<a
          href="mailto:veroandreo@gmail.com" moz-do-not-send="true">veroandreo@gmail.com</a>>
        wrote:<br>
        ><br>
        > Hi Micha<br>
        ><br>
        > El jue., 31 oct. 2019 a las 22:36, Micha Silver (<<a
          href="mailto:tsvibar@gmail.com" moz-do-not-send="true">tsvibar@gmail.com</a>>)
        escribió:<br>
        >><br>
        >><br>
        >> On 31/10/2019 22:20, Markus Metz wrote:<br>
        >><br>
        >><br>
        >><br>
        >> On Tue, Oct 29, 2019 at 7:40 PM Veronica Andreo <<a
          href="mailto:veroandreo@gmail.com" moz-do-not-send="true">veroandreo@gmail.com</a>>
        wrote:<br>
        >> ><br>
        >> > Hi Daniel,<br>
        >> ><br>
        >> > I agree that if there's a NULL in the column,
        there should be NULL in the resulting raster. I suggest to open
        a ticket here: <a href="https://trac.osgeo.org/grass/"
          moz-do-not-send="true">https://trac.osgeo.org/grass/</a><br>
        >><br>
        >> easy solution: v.to.rast
        where="<attribute_column> is not null"<br>
        >><br>
        >> or the new PR #173<br>
        >> <a href="https://github.com/OSGeo/grass/pull/173"
          moz-do-not-send="true">https://github.com/OSGeo/grass/pull/173</a><br>
        >> if an attribute value is null, the corresponding vector
        features will not be rasterized<br>
        >><br>
        >> Markus M<br>
        >><br>
        >> I'm not sure I agree with the approach that a polygon
        with missing attribute should become NULL. In my view, NULL
        should be used only for pixels not covered at all by any
        polygon.<br>
        ><br>
        <div>> but in the resulting raster (in rasters in general),
          there's no difference, it's rather NULL or it has a value...
          it does not matter if the null comes from areas originally
          covered by a polygon or not... <br>
        </div>
        <div><br>
        </div>
        <div>I think it depends on the particular use case if it matters
          where a NULL raster value comes from: a polygon with empty
          attribute or no polygon at all for that cell.<br>
        </div>
        <div><br>
        </div>
        >><br>
        >> Perhaps an additional input parameter
        "missing_attribute" so the user can choose a value to enter into
        the raster if the attribute is missing. If no parameter is
        supplied, and the chosen attribute column has missing values,
        I'd prefer that the script exit gracefully, with a message that
        a "missing_attribute" value is required.<br>
        <div><br>
        </div>
        <div>This can easily be done with existing tools:</div>
        <div>- convert only those polygons with a valid attribute value:
          v.to.rast where="attribute is not null"<br>
        </div>
        <div>- replace missing attribute values with a valid value:
          v.db.update where="attribute is null", then v.to.rast<br>
        </div>
        <div><br>
        </div>
        <div>I'm changing my PR to issue a warning if empty attribute
          values are found and replaced with zero.</div>
      </div>
    </blockquote>
    <p><br>
    </p>
    <p>IMHO, that's probably the best way to deal with this.</p>
    <p><br>
    </p>
    <blockquote type="cite"
cite="mid:CAG+h=FEP=Ks7kN95Fw8_8sc7DccpxcZ3LRywTacUofdzPqh3=g@mail.gmail.com">
      <div dir="ltr">
        <div><br>
        </div>
        <div>Markus M<br>
        </div>
        <div><br>
        </div>
        <div>></div>
        > yes, this could be a solution to keep track of where you
        had polygons, but then you would need to use r.null anyway, no?
        I try to think of use cases in which one uses a vector attribute
        to convert to raster, but then still needs to know where the
        polygons were... because, for example, to query a raster map
        with another raster map representing zones one would convert the
        vector of polygons using cat and not an attribute, no?<br>
        ><br>
        > cheers,<br>
        > Vero<br>
        >><br>
        >><br>
        >> > El jue., 24 oct. 2019 a las 14:40, Daniel Victoria
        (<<a href="mailto:daniel.victoria@gmail.com"
          moz-do-not-send="true">daniel.victoria@gmail.com</a>>)
        escribió:<br>
        >> >><br>
        >> >> Hi list,<br>
        >> >><br>
        >> >> I have a vector polygon map that I'm
        converting to raster. The attribute column that I process has
        some empty rows (no data / null). When I run v.to.rast, these
        empty rows become 0 (zero) on my resulting raster map.<br>
        >> >><br>
        >> >> Shouldn't v.to.rast respect the empty
        attribute table and create null values for those polygons?<br>
        >> >><br>
        >> >> For now I'll use r.null to fix this problem.
        But what if 0 is a valid value?<br>
        >> >><br>
        >> >> Cheers<br>
        >> >> Daniel<br>
        >> >><br>
        >> >> PS - Running Grass 7.6.1 on Ubuntu<br>
        >> >>
        _______________________________________________<br>
        >> >> grass-user mailing list<br>
        >> >> <a href="mailto:grass-user@lists.osgeo.org"
          moz-do-not-send="true">grass-user@lists.osgeo.org</a><br>
        >> >> <a
          href="https://lists.osgeo.org/mailman/listinfo/grass-user"
          moz-do-not-send="true">https://lists.osgeo.org/mailman/listinfo/grass-user</a><br>
        >> ><br>
        >> > _______________________________________________<br>
        >> > grass-user mailing list<br>
        >> > <a href="mailto:grass-user@lists.osgeo.org"
          moz-do-not-send="true">grass-user@lists.osgeo.org</a><br>
        >> > <a
          href="https://lists.osgeo.org/mailman/listinfo/grass-user"
          moz-do-not-send="true">https://lists.osgeo.org/mailman/listinfo/grass-user</a><br>
        >><br>
        >> _______________________________________________<br>
        >> grass-user mailing list<br>
        >> <a href="mailto:grass-user@lists.osgeo.org"
          moz-do-not-send="true">grass-user@lists.osgeo.org</a><br>
        >> <a
          href="https://lists.osgeo.org/mailman/listinfo/grass-user"
          moz-do-not-send="true">https://lists.osgeo.org/mailman/listinfo/grass-user</a><br>
        >><br>
        >> -- <br>
        >> Micha Silver<br>
        >> Ben Gurion Univ.<br>
        >> Sde Boker, Remote Sensing Lab<br>
        >> cell: +972-523-665918</div>
    </blockquote>
    <pre class="moz-signature" cols="72">-- 
Micha Silver
Ben Gurion Univ.
Sde Boker, Remote Sensing Lab
cell: +972-523-665918</pre>
  </body>
</html>