<div dir="ltr"><div>I agree with this.  It seems better to provide more appropriate constraints than to modify data. </div><div><br></div><div>Like it or now, we're stuck with the OGC model for the foreseeable future.  But the pain points can be reduced by removing unwanted distinctions between atomic and Multi-geometries wherever possible.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Feb 16, 2023 at 8:43 PM Darafei "Komяpa" Praliaskouski <<a href="mailto:me@komzpa.net">me@komzpa.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">I believe that multigeometry constraint is instead a not well-thought constraint inherited from very legacy systems.<div><br>The useful ones are "is it point/multipoint", "is it line/multiline", "is it area/multiarea". With check for the multi- being with options "no" and "could be multi, could be single". I don't like us pushing people to convert all singles to multi: this may mean that in some time we will not have tables with plain polygons anymore.</div><div><br></div><div>I'd say that if we implement such a change we also need to have a nice way to have "linear" or "areal" dimensionality constraint on the data that will check that data is poly/multipoly or line/multiline, so it could be recommended as replacement, with simple results being in the table, not forcing everything to be more complex.</div></div>
</blockquote></div></div>