Built site for gh-pages

Author: Quarto GHA Workflow Runner

.nojekyll

@@ -1 +1 @@
-120c1697
+ddaad231

01-geodata.html

@@ -375,7 +375,7 @@ <h2 data-number="3.1" class="anchored" data-anchor-id="geoio.jl"><span class="he
 <section id="file-formats" class="level2" data-number="3.2">
 <h2 data-number="3.2" class="anchored" data-anchor-id="file-formats"><span class="header-section-number">3.2</span> File formats</h2>
 <p>Most GIS file formats do <strong>not</strong> preserve topological information. This means that neighborhood information is lost as soon as geometries are saved to disk. To illustrate this issue, we consider a geotable over a grid:</p>
-<div id="c471528e" class="cell" data-execution_count="2">
+<div id="68193fbb" class="cell" data-execution_count="2">
 <div class="sourceCode cell-code" id="cb3"><pre class="sourceCode julia code-with-copy"><code class="sourceCode julia"><span id="cb3-1"><a href="#cb3-1" aria-hidden="true" tabindex="-1"></a><span class="im">using</span> <span class="bu">GeoIO</span></span>
 <span id="cb3-2"><a href="#cb3-2" aria-hidden="true" tabindex="-1"></a></span>
 <span id="cb3-3"><a href="#cb3-3" aria-hidden="true" tabindex="-1"></a>geotable <span class="op">=</span> GeoIO.<span class="fu">load</span>(<span class="st">"data/earth.tif"</span>)</span></code><button title="Copy to Clipboard" class="code-copy-button"><i class="bi"></i></button></pre></div>
@@ -446,7 +446,7 @@ <h2 data-number="3.2" class="anchored" data-anchor-id="file-formats"><span class
 </div>
 </div>
 <p>If we save the geotable to a <code>.geojson</code> file on disk, and then load it back, we observe that the <code>CartesianGrid</code> gets replaced by a <code>GeometrySet</code>:</p>
-<div id="89f6e7bd" class="cell" data-execution_count="3">
+<div id="9ff00ba1" class="cell" data-execution_count="3">
 <div class="sourceCode cell-code" id="cb4"><pre class="sourceCode julia code-with-copy"><code class="sourceCode julia"><span id="cb4-1"><a href="#cb4-1" aria-hidden="true" tabindex="-1"></a>fname <span class="op">=</span> <span class="fu">tempname</span>() <span class="op">*</span> <span class="st">".geojson"</span></span>
 <span id="cb4-2"><a href="#cb4-2" aria-hidden="true" tabindex="-1"></a></span>
 <span id="cb4-3"><a href="#cb4-3" aria-hidden="true" tabindex="-1"></a>GeoIO.<span class="fu">save</span>(fname, geotable)</span>
@@ -519,7 +519,7 @@ <h2 data-number="3.2" class="anchored" data-anchor-id="file-formats"><span class
 </div>
 </div>
 <p>Other file formats such as <code>.ply</code> and <code>.msh</code> are widely used in <a href="https://en.wikipedia.org/wiki/Computer_graphics">computer graphics</a> to save geospatial data over meshes, and preserve topological information:</p>
-<div id="92b39ecb" class="cell" data-execution_count="4">
+<div id="0215e98a" class="cell" data-execution_count="4">
 <div class="sourceCode cell-code" id="cb5"><pre class="sourceCode julia code-with-copy"><code class="sourceCode julia"><span id="cb5-1"><a href="#cb5-1" aria-hidden="true" tabindex="-1"></a>beethoven <span class="op">=</span> GeoIO.<span class="fu">load</span>(<span class="st">"data/beethoven.ply"</span>)</span>
 <span id="cb5-2"><a href="#cb5-2" aria-hidden="true" tabindex="-1"></a></span>
 <span id="cb5-3"><a href="#cb5-3" aria-hidden="true" tabindex="-1"></a><span class="fu">viz</span>(beethoven.geometry)</span></code><button title="Copy to Clipboard" class="code-copy-button"><i class="bi"></i></button></pre></div>
@@ -543,7 +543,7 @@ <h2 data-number="3.3" class="anchored" data-anchor-id="rationale"><span class="h
 <p>Do we gain anything by not adhering to <strong>programming interfaces</strong>?</p>
 </blockquote>
 <p>The answer is an emphatic <strong>YES</strong>! It means that we have total freedom to innovate and improve the representation of various geometries and geospatial domains with Julia’s amazing type system. To give a simple example, let’s take a look at the <code>Triangle</code> geometry:</p>
-<div id="5160d055" class="cell" data-execution_count="5">
+<div id="06551fb8" class="cell" data-execution_count="5">
 <div class="sourceCode cell-code" id="cb7"><pre class="sourceCode julia code-with-copy"><code class="sourceCode julia"><span id="cb7-1"><a href="#cb7-1" aria-hidden="true" tabindex="-1"></a>t <span class="op">=</span> <span class="fu">Triangle</span>((<span class="fl">0</span>, <span class="fl">0</span>), (<span class="fl">1</span>, <span class="fl">0</span>), (<span class="fl">1</span>, <span class="fl">1</span>))</span></code><button title="Copy to Clipboard" class="code-copy-button"><i class="bi"></i></button></pre></div>
 <div class="cell-output cell-output-display" data-execution_count="6">
 <pre><code>Triangle
@@ -553,11 +553,11 @@ <h2 data-number="3.3" class="anchored" data-anchor-id="rationale"><span class="h
 </div>
 </div>
 <p>If we treated this geometry as a generic polygon represented by a vector of vertices in memory, like it is done in <a href="https://github.com/JuliaGeo/GeoInterface.jl">GeoInterface.jl</a> for example, we wouldn’t be able to dispatch optimized code that is only valid for a triangle:</p>
-<div id="06c84d54" class="cell" data-execution_count="6">
+<div id="f439559c" class="cell" data-execution_count="6">
 <div class="sourceCode cell-code" id="cb9"><pre class="sourceCode julia code-with-copy"><code class="sourceCode julia"><span id="cb9-1"><a href="#cb9-1" aria-hidden="true" tabindex="-1"></a><span class="pp">@code_llvm</span> <span class="fu">isconvex</span>(t)</span></code><button title="Copy to Clipboard" class="code-copy-button"><i class="bi"></i></button></pre></div>
 <div class="cell-output cell-output-stdout">
 <pre><code>;  @ /home/runner/.julia/packages/Meshes/OF9k2/src/predicates/isconvex.jl:57 within `isconvex`
-define i8 @julia_isconvex_4481([1 x [3 x [1 x [1 x [2 x [1 x double]]]]]]* nocapture readonly %0) #0 {
+define i8 @julia_isconvex_4479([1 x [3 x [1 x [1 x [2 x [1 x double]]]]]]* nocapture readonly %0) #0 {
 top:
   ret i8 1
 }</code></pre>
@@ -577,7 +577,7 @@ <h2 data-number="3.3" class="anchored" data-anchor-id="rationale"><span class="h
 </div>
 </div>
 <p>Notice how the <code>isconvex</code> function is compiled away to the <strong>constant</strong> <code>1</code> (i.e.&nbsp;<code>true</code>) when called on the triangle. The code for a generic polygon is much more complicated and requires runtime checks that are too expensive to afford, especially in 3D.</p>
-<p>Another reason to not adhere to a generic interface is that we can store information in the geometry types themselves (e.g., coordinate reference system) that is relevant to to design advanced scientific visualization features illustrated in the previous chapter, and to dispatch specialized algorithms from geodesic geometry.</p>
+<p>Another reason to not adhere to a generic interface is that we can store information in the geometry types themselves (e.g., coordinate reference system) that is relevant to design advanced scientific visualization features illustrated in the previous chapter, and to dispatch specialized algorithms from geodesic geometry.</p>
 <p>Having cleared that up, we will now proceed to the last foundational chapter of the book, which covers the advanced geometric processing features of the framework.</p>