<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>idea More options in converting Polygon to Raster in ArcGIS Pro Ideas</title>
    <link>https://community.esri.com/t5/arcgis-pro-ideas/more-options-in-converting-polygon-to-raster/idi-p/970415</link>
    <description>&lt;P&gt;The Polygon to Raster tool should have more options and a richer ruleset to specify how grid cells are assigned polygon values, and more user options to specify the desired contents of the output raster values.&lt;BR /&gt;&lt;BR /&gt;1. The user should have more control on how and when a polygon value is assigned to a raster. &amp;nbsp;User input should control what percent of a grid cell needs to be occupied by a polygon in order to receive the value (e.g. user input of "0.4" says that at least 40 percent of a given grid cell must be intersected by the &amp;nbsp;polygon to receive its value). &amp;nbsp;(A similar option should be applied to the Polyline to Raster tool to specify the minimum length of a line within a grid cell for the grid cell to receive its value.) &amp;nbsp;&lt;BR /&gt;&lt;BR /&gt;2. &amp;nbsp;The user should be able to specify additional output values. &amp;nbsp;For example, &amp;nbsp;a desired output raster value could be the &lt;U&gt;area&lt;/U&gt; of the grid cell occupied by the polygon(s) that intersect it. &amp;nbsp; This output raster would then have value for other geoprocessing that is not currently performed by the software -- for example, we could then use the FocalStatistics tool to calculate the &lt;U&gt;total area&lt;/U&gt; of all features (say, cultural resources sites) that occur within a user-defined neighborhood of each grid cell as an indication of cultural resources sensitivity.&lt;BR /&gt;&lt;BR /&gt;The software probably makes these calculations anyway, and capturing them should not cause much additional processing overhead.&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;/P&gt;&lt;!--  content transformation source ID: 087E00000004ZpN  --&gt;</description>
    <pubDate>Tue, 02 Jul 2024 19:01:21 GMT</pubDate>
    <dc:creator>EricLink1</dc:creator>
    <dc:date>2024-07-02T19:01:21Z</dc:date>
    <item>
      <title>More options in converting Polygon to Raster</title>
      <link>https://community.esri.com/t5/arcgis-pro-ideas/more-options-in-converting-polygon-to-raster/idi-p/970415</link>
      <description>&lt;P&gt;The Polygon to Raster tool should have more options and a richer ruleset to specify how grid cells are assigned polygon values, and more user options to specify the desired contents of the output raster values.&lt;BR /&gt;&lt;BR /&gt;1. The user should have more control on how and when a polygon value is assigned to a raster. &amp;nbsp;User input should control what percent of a grid cell needs to be occupied by a polygon in order to receive the value (e.g. user input of "0.4" says that at least 40 percent of a given grid cell must be intersected by the &amp;nbsp;polygon to receive its value). &amp;nbsp;(A similar option should be applied to the Polyline to Raster tool to specify the minimum length of a line within a grid cell for the grid cell to receive its value.) &amp;nbsp;&lt;BR /&gt;&lt;BR /&gt;2. &amp;nbsp;The user should be able to specify additional output values. &amp;nbsp;For example, &amp;nbsp;a desired output raster value could be the &lt;U&gt;area&lt;/U&gt; of the grid cell occupied by the polygon(s) that intersect it. &amp;nbsp; This output raster would then have value for other geoprocessing that is not currently performed by the software -- for example, we could then use the FocalStatistics tool to calculate the &lt;U&gt;total area&lt;/U&gt; of all features (say, cultural resources sites) that occur within a user-defined neighborhood of each grid cell as an indication of cultural resources sensitivity.&lt;BR /&gt;&lt;BR /&gt;The software probably makes these calculations anyway, and capturing them should not cause much additional processing overhead.&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;/P&gt;&lt;!--  content transformation source ID: 087E00000004ZpN  --&gt;</description>
      <pubDate>Tue, 02 Jul 2024 19:01:21 GMT</pubDate>
      <guid>https://community.esri.com/t5/arcgis-pro-ideas/more-options-in-converting-polygon-to-raster/idi-p/970415</guid>
      <dc:creator>EricLink1</dc:creator>
      <dc:date>2024-07-02T19:01:21Z</dc:date>
    </item>
  </channel>
</rss>

