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

Subject: [ggl] [order] 2: read_wkt to read
From: Barend Gehrels (barend)
Date: 2011-10-20 17:38:21

Hi Mateusz,

Yes, this answer on the old mail is still relevant.

On 19-10-2011 15:51, Mateusz ?oskot wrote:
> 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?

Yes.

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

Right. It is implemented as such and forwards to the normal 
implementation. Because WKT is heavily used in the unit tests, I did not 
have the time to modify them all, so the unit tests use the old 
implementation (I just checked and there are no unit test for the new 
read method, that at least should be done...).

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

So yes ;-)
That compiler warning is not implemented yet (of course).

Regards, Barend