Subject: [ggl] [order] 2: read_wkt to read
From: Mateusz Åoskot (mateusz)
Date: 2011-10-19 09:51:56
On 27 February 2011 11:49, Barend Gehrels <barend_at_[hidden]> wrote:
> Yesterday I mailed part 1 of the order of parameters (combine). This is
> about read_wkt.
> It's signature: void read_wkt(string, Geometry);
> should probably change to read_wkt(Geometry, string) to conform to the order
> GeometryIn, GeometryOut, others.
More precisely, you mean read_wkt(Geometry& out, string const& in), right?
OK. I also prefer input/output argument as first.
It fits the tradition of std::memcpy and others.
> At the same time, read_wkt is currently an extension. It is extensively used
> in nearly every testcase, many samples, etc. If we go to the
> release-branche, we either should skip all extensions or move WKT to
> something else.
I have proposed
presumably with substructure of
> To allow for all these changes at the same time, I propose the following.
> 1) We make a new folder "domains" which is subdivided as the "extensions"
> are. So we now get a:
> domains/gis/io/wkt for the WKT-parser.
Where write_dsv.hpp fits?
Where SVG I/O utilities would fit?
> 2) We move wkt to there
> 3) At the higher level (in io, or in domains, or in algorithms) we make one
> new algorithm called "read". This one has a required template parameter
> denoting the format. And it reverses the arguments. So we get, for example:
> polygon_2d triangle;
> boost::geometry::read<format_wkt>(triangle, "POLYGON((1 1,1 2,2 1,1 1))");
I like it!
> and we can get the same for format_wkb and possibly other formats we will
> support for reading. There even might be a format_autodetect which figures
> out the format from the string. In OGC this algorithm is called
> geomfromtext, returning a geometry. I had this earlier but it was discarded
> because there are so many text formats, but now we might consider using that
> name again.
Yes, it opens plenty of design possibilities to users indeed.
> Changing all read_wkt to read<format_wkt> will be a bigger change especially
> for me, because of all tests (reversing the arguments), but I think it is
> manageable, and better like this. The read_wkt function itself can stay in
> extensions for backwards compatiblity, with a compiler warning that it is
OK. Let me know if you need help.
> There is one tweak, because there is also:
> read_wkt(std::string const& wkt, OutputIterator out)
> only working for linestring and ring. This case is probably not used and
> might be deprecated either (so no new function read<format_wkt> for it).
> Objections to this all?
No objections from me.
-- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org
Geometry list run by mateusz at loskot.net