Geometry Boost List: [ggl] [order] 2: read_wkt to read

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:
> Hi,
>
> 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
geometry/io/
presumably with substructure of
geometry/io/write_dsv.hpp
geometry/io/domain/gis/read_wkt.hpp
...

> 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.

OK.

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
> deprecated.

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.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
Member of ACCU, http://accu.org