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 18:38:08

2011/10/19 Mateusz ?oskot <mateusz_at_[hidden]>:
> 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
> 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.

I have no idea how and why, but I didn't realise this post is from
February 2011.
I have been doing big migration of my e-mail server and I somehow
found this old post on top of my inbox.

If the matter is still valid, let's continue :)
Otherwise, please ignore it.

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