Sean Gillies (Posts about ogc)https://sgillies.net/tags/ogc.atom2023-12-31T01:26:21ZSean GilliesNikolaSteady as she goeshttps://sgillies.net/2014/07/02/steady-as-she-goes.html2014-07-02T00:00:00-06:002014-07-02T00:00:00-06:00Sean Gillies<p>Standards organizations are increasingly interested in the little format that
could and if <a class="reference external" href="http://www.w3.org/2014/05/geo-charter">http://www.w3.org/2014/05/geo-charter</a> is any indication it's
likely that you'll be seeing more mention of <a class="reference external" href="http://geojson.org">GeoJSON</a>
and <a class="reference external" href="http://github.com/geojson/geojson-ld">GeoJSON-LD</a> in OGC and W3C
materials soon. However, the GeoJSON working group (for which I'm speaking in
just this and the following sentence), is going to keep its own independent
course. Work on the <a class="reference external" href="http://tools.ietf.org/html/draft-butler-geojson-03">GeoJSON Internet Draft</a> will continue to be
done at <a class="reference external" href="https://github.com/geojson/draft-geojson">https://github.com/geojson/draft-geojson</a> and on the GeoJSON <a class="reference external" href="http://lists.geojson.org/listinfo.cgi/geojson-geojson.org">discussion
list</a>.</p>
<p>Now, Mapbox has recently joined the OGC and I've subsequently received emails
from OGC members seeking discussion of GeoJSON. This is exactly the thing that
I want to avoid and I will decline to do so outside of the GeoJSON venues
I listed above. I hope you will, too, because discussions of GeoJSON on closed OGC
technical committee lists or private emails with other OGC members aren't going
to do the GeoJSON format, I-D, or users any good. GeoJSON is for the open web.
Let's continue to tend it on the open web.</p>Point vs MultiPointhttps://sgillies.net/2014/01/03/point-vs-multipoint.html2014-01-03T00:00:00-07:002014-01-03T00:00:00-07:00Sean Gillies<p>I got some <a class="reference external" href="https://twitter.com/sgillies/status/418836645438160896">feedback</a>
about yesterdays blog post. To be clear, I'm not
suggesting that multipart geometry types are not needed. Rather, I think it's the
single part types that may be superfluous.</p>
<p>A couple of you suggest that single points and sets of points are different
from the higher dimensional (curve and surface) cases. What exactly sets these
geometry types apart and is the argument for setting them apart a geometrical
one? Consider the two WKT strings below and the geometric point sets they
describe.</p>
<div class="code"><pre class="code text"><a id="rest_code_a090a8ebe64c42958e5f4124fb03ba60-1" name="rest_code_a090a8ebe64c42958e5f4124fb03ba60-1" href="https://sgillies.net/2014/01/03/point-vs-multipoint.html#rest_code_a090a8ebe64c42958e5f4124fb03ba60-1"></a>POINT(0 0)
<a id="rest_code_a090a8ebe64c42958e5f4124fb03ba60-2" name="rest_code_a090a8ebe64c42958e5f4124fb03ba60-2" href="https://sgillies.net/2014/01/03/point-vs-multipoint.html#rest_code_a090a8ebe64c42958e5f4124fb03ba60-2"></a>MULTIPOINT((0 0))
</pre></div>
<p>You're banking on the distances from either of these objects to any other
object, or a 50-meter buffer zone around either object, being the same. In
a Simple Features world, you're also counting on these objects being <em>equal</em>
(See section 2.1.13.3, Named Spatial Relationship predicates based on the
DE-9IM, in OGC 99-049). Applications using Shapely, to name one category of
users, are certainly banking on it.</p>
<div class="code"><pre class="code pycon"><a id="rest_code_3c8f3d94fe5748cc82cdf21a1d5c00b4-1" name="rest_code_3c8f3d94fe5748cc82cdf21a1d5c00b4-1" href="https://sgillies.net/2014/01/03/point-vs-multipoint.html#rest_code_3c8f3d94fe5748cc82cdf21a1d5c00b4-1"></a><span class="gp">>>> </span><span class="kn">from</span> <span class="nn">shapely.geometry</span> <span class="kn">import</span> <span class="n">Point</span><span class="p">,</span> <span class="n">MultiPoint</span>
<a id="rest_code_3c8f3d94fe5748cc82cdf21a1d5c00b4-2" name="rest_code_3c8f3d94fe5748cc82cdf21a1d5c00b4-2" href="https://sgillies.net/2014/01/03/point-vs-multipoint.html#rest_code_3c8f3d94fe5748cc82cdf21a1d5c00b4-2"></a><span class="gp">>>> </span><span class="n">coords</span> <span class="o">=</span> <span class="p">(</span><span class="mf">0.0</span><span class="p">,</span> <span class="mf">0.0</span><span class="p">)</span>
<a id="rest_code_3c8f3d94fe5748cc82cdf21a1d5c00b4-3" name="rest_code_3c8f3d94fe5748cc82cdf21a1d5c00b4-3" href="https://sgillies.net/2014/01/03/point-vs-multipoint.html#rest_code_3c8f3d94fe5748cc82cdf21a1d5c00b4-3"></a><span class="gp">>>> </span><span class="n">Point</span><span class="p">(</span><span class="n">coords</span><span class="p">)</span><span class="o">.</span><span class="n">equals</span><span class="p">(</span><span class="n">MultiPoint</span><span class="p">([</span><span class="n">coords</span><span class="p">]))</span>
<a id="rest_code_3c8f3d94fe5748cc82cdf21a1d5c00b4-4" name="rest_code_3c8f3d94fe5748cc82cdf21a1d5c00b4-4" href="https://sgillies.net/2014/01/03/point-vs-multipoint.html#rest_code_3c8f3d94fe5748cc82cdf21a1d5c00b4-4"></a><span class="go">True</span>
</pre></div>
<p>If a single point with coordinates <code class="docutils literal">x,y</code> is equivalent to a set of points
with a single member (same coordinates <code class="docutils literal">x,y</code>), why do we trouble ourselves
with different representations for these things? I'm sure historical reasons
are a big part of the answer. Not just "Feature B followed Feature A"
historical reasons, but point-in-time historical reasons. I've a half-baked
thesis that the late 90s and early 00s are partly characterized by information
modeling practices that tended to produce the greatest possible number of
classes rather than the least sufficient number of classes.</p>
<p>Just thinking out loud here. And GeoJSON is the context for my thinking: how it
came to be and how things might have been done differently. And how things
might be done differently the next time around.</p>Maybe the Shapefile was right after allhttps://sgillies.net/2014/01/02/maybe-the-shapefile-was-right-after-all.html2014-01-02T00:00:00-07:002014-01-02T00:00:00-07:00Sean Gillies<p>Sometimes I agree with Martin Daly's suggestion that the Shapefile was right
all along. Not about everything, of course, but about the lack of distinction
between the geometric objects that the OGC's <a class="reference external" href="http://en.wikipedia.org/wiki/Simple_Feature_Access">Simple Features</a> model classifies as
polygons and multipolygons. What's the essential difference between a polygon
and a set of non-intersecting polygons with only one member? I'm not convinced
that there is one. Consider the features in the image below (from
<a class="reference external" href="http://education.usgs.gov/kids/tracks.html">http://education.usgs.gov/kids/tracks.html</a>).</p>
<img alt="http://farm3.staticflickr.com/2811/11631807246_b306a4a3bb_o_d.png" src="http://farm3.staticflickr.com/2811/11631807246_b306a4a3bb_o_d.png">
<p>In the simple features model, you'd classify all of these nine-part prints as
multipolygon features. In the coyote's hind print, however, the slight merger
of the middle toe prints hints at what we might see if the prints were made in
a soft enough medium: single part contiguous prints.</p>
<p>Why would we want the representation in data of a print to change from
a multi-part multipolygon to a single polygon as we dilate it (by making it
deeper in this analogy)? If I was designing a format for the exchange of animal
print data, I'd like all prints to be of the same geometric type whether they
were shallow or deep. Wouldn't you? If not, why not? What would be the use of
having separate polygon and multi-polygon types and prints that flip-flop
between them depending on incidental conditions of their observation? And would
any use outweigh the cost of documenting and explaining the difference?</p>