You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
<p>In order to disrupt existing practices and really develop something new in Julia, we had to make some hard decisions along the way. One of these decisions relates to how we are willing to interface our framework with existing GIS standards and workflows.</p>
353
353
<p>On the one hand, we could have followed the path that was followed by other communities such as Python and R, and focus our energy interfacing with well-tested GIS libraries written in C/C++ (e.g., <ahref="https://gdal.org/index.html">GDAL</a>, <ahref="https://libgeos.org">GEOS</a>). This is precisely what the JuliaGeo organization has been doing over the years, and it is an important agenda to bring people from other languages that are used to the <ahref="https://www.ogc.org/standards">OGC</a> standards.</p>
354
354
<p>On the other hand, we have young geoscientists and first-time programmers who have never studied GIS before, and who <em>really struggle</em> learning the technology as it is today. The widespread emphasis on machine representation and software engineering has created a gap between the developers and the users of GIS software. A typical gap the Julia programming language helps to close.</p>
355
-
<p>We decided to limit our interface with existing GIS technology to input and output (IO) of files. This gives users of the framework the chance to</p>
355
+
<p>We decided to limit our interface with existing GIS technology to input and output (IO) of files while it matures. This gives users of the framework the chance to</p>
356
356
<oltype="1">
357
357
<li>Import geospatial data stored as simple features</li>
358
358
<li>Perform geospatial data science with a rich set of tools</li>
<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>
@@ -446,7 +446,7 @@ <h2 data-number="3.2" class="anchored" data-anchor-id="file-formats"><span class
446
446
</div>
447
447
</div>
448
448
<p>If we save the geotable to a <code>.geojson</code> file on disk, and then load it back, we observe that the grid gets replaced by a geometry set:</p>
@@ -519,7 +519,7 @@ <h2 data-number="3.2" class="anchored" data-anchor-id="file-formats"><span class
519
519
</div>
520
520
</div>
521
521
<p>Other file formats such as <code>.ply</code> and <code>.msh</code> are widely used in <ahref="https://en.wikipedia.org/wiki/Computer_graphics">computer graphics</a> to save geospatial data over meshes, and preserve topological information:</p>
<p>Do we gain anything by not adhering to <strong>programming interfaces</strong>?</p>
544
544
</blockquote>
545
545
<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>
<p>If we treated this geometry as a generic polygon represented by a vector of vertices in memory, like it is done in <ahref="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>
0 commit comments