<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
I've fixed this so that currently all tests pass (at least locally).<br>
<br>
Now Shapefiles, which are created XY come back as XY, XYM as XYM,
XYZ as XYZ, and XYZM as XYZM. Also one should be able to set the
required coordinate combination using parameters - that's not
comprehensively tested however. <br>
<br>
There are still a couple of fixme's in the code (shape2ogr.cpp),
writing a shape should take into account the requested coordinate
combination and whether to skip Ms or write them as "no data" (value
< 1038 according to the doc).<br>
<br>
I changed the code for OGRFeature::SetGeomFieldDirectly to set or
unset the geometry M or Z coordinates depending on the geometry
field type of the feature. That's somewhat bold but the way I did it
at least did not break anything in the tests.<br>
<br>
Ari<br>
<br>
<div class="moz-cite-prefix">10.02.2016, 13:26, Ari Jolma kirjoitti:<br>
</div>
<blockquote cite="mid:56BB1E83.5000701@gmail.com" type="cite">
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
One more issue came up.<br>
<br>
Shapefiles, which have Z will also have M, at least a placeholder
for it.<br>
<br>
Having shapefiles as XYZM always in that case may be problematic.<br>
<br>
It is possible to use the open options SHPT=type to override the
default. We could have Z => XYZ as default for backwards
compatibility and require open option for Z => XYZM.<br>
<br>
Ari<br>
<br>
<br>
<div class="moz-cite-prefix">09.02.2016, 17:07, Ari Jolma
kirjoitti:<br>
</div>
<blockquote cite="mid:56BA00A7.8080404@gmail.com" type="cite">
<meta content="text/html; charset=utf-8"
http-equiv="Content-Type">
I declare this motion passed with +1 from Even, Tamas, Jukka and
Daniel and no -1.<br>
<br>
I'll commit soon the changes to the core and then later the
drivers: memory, shape and pg. The goal is to keep the travis
test build passing.<br>
<br>
Ari<br>
<br>
<div class="moz-cite-prefix">05.02.2016, 10:04, Ari Jolma
kirjoitti:<br>
</div>
<blockquote cite="mid:56B45770.7000405@gmail.com" type="cite">
<meta http-equiv="content-type" content="text/html;
charset=utf-8">
I'd like to ask the PSC and others to vote on adopting RFC
61:
<meta http-equiv="content-type" content="text/html;
charset=utf-8">
Support for measured geometries.<br>
<br>
The draft RFC is at <br>
<br>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="https://trac.osgeo.org/gdal/wiki/rfc61_support_for_measured_geometries">https://trac.osgeo.org/gdal/wiki/rfc61_support_for_measured_geometries</a><br>
<br>
and a draft implementation is at<br>
<br>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="https://github.com/ajolma/GDAL-XYZM">https://github.com/ajolma/GDAL-XYZM</a><br>
<br>
which is tested at<br>
<br>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="https://travis-ci.org/ajolma/GDAL-XYZM">https://travis-ci.org/ajolma/GDAL-XYZM</a><br>
<br>
(the test #34, which passed, was the so far last one after
core changes with unchanged autotests and a rather
comprehensive set of WKT tests in the Perl tests directory)<br>
<br>
This is seemingly a small change but it is at the heart of OGR
so it has some important implications. The only backwards
incompatibilities that have appeared so far are with some
drivers, for example shapefile, which can be lessened with,
e.g., open options.<br>
<br>
Best,<br>
<br>
Ari<br>
<br>
</blockquote>
<br>
</blockquote>
<br>
</blockquote>
<br>
</body>
</html>