Fixed Writing 3D WKT:Z prefix #782

Siddharth-coder13 · 2020-12-09T05:32:16Z

Changed the wkt_point struct to take 3 parameters rather than 2, for one for 2d and one for 3d, added the prefix_z function in prefix.hpp, and also added a line of code to print 3d points in 01_point_example.cpp .

mloskot

Thanks for the contribution.

Since every new improvement or feature needs to be covered with test case(s), you may consider adding some to https://github.com/boostorg/geometry/tree/develop/test/io/wkt

mloskot · 2020-12-11T15:56:18Z

@awulkiew In #664 (comment) you suggested

we'd need a separate function for that.

What did you have in mind?

This PR seems to follow my suggestion I made in #664 (comment)

@Siddharth-coder13 The commit and description of PR that addresses an existing issue should contain reference to the issue (i.e. #664)

Siddharth-coder13 · 2020-12-11T16:02:38Z

Yeah, sure from next time I will make sure this.

Siddharth-coder13 · 2020-12-13T09:30:12Z

Do this PR needs more changes? @mloskot

mloskot · 2020-12-13T09:34:10Z

@Siddharth-coder13 No, for now it does not, but we need to wait and clarify my question #782 (comment) in order to confirm this is actually the kind of change we need and want.

Siddharth-coder13 · 2020-12-29T06:10:02Z

@awulkiew, your reviews are needed on this PR.

barendgehrels

Thanks for the PR but it's not yet clear enough if we want to have a Z by default.

barendgehrels · 2020-12-30T09:47:57Z

include/boost/geometry/io/wkt/write.hpp

 struct wkt_point
 {
 template <typename Char, typename Traits>
 static inline void apply(std::basic_ostream<Char, Traits>& os, Point const& p, bool)
 {
- os << Policy::apply() << "(";
+ if(dimension<Point>::type::value == 3) os << Policy2::apply() << "(";
+ else os << Policy1::apply() << "(";


Question: do we always want a Z in our 3D point? Until now we just did without and it works without.
If we suddenly add a Z here it might be incompatible for users (if any) who use this functionality. So it's a breaking change.

Apart from this it should be a compile time condition i/o a runtime condition. So we should dispatch based on dimension. But I'm not sure about that either, because if it is optional (as it probably should be), that might be inconvenient.

As far as I can see the specification indeed mentions a Z for three dimensional points. It's unclear if a three dimensional point without a Z is acceptable or not.
But what do we do with four dimensional points? Or even more? We've not much support for them of course, but we can calculate distances for them...

In my personal opinion, for a three dimensional point, a list with three coordinates is already enough. In reading we can read or not read the Z (that is already implemented).

I would agree with @barendgehrels

Another issue here is that after this change the following code

boost::geometry::read_wkt("POINT M(1 2 3)", p); std::cout << boost::geometry::wkt(p) << std::endl;

will output

POINT Z(1 2 3)

I think we should decide how we want to support more than 2 dimensions and probably issue #664 is the right place for that.

@barendgehrels points out a valid issue.

But what do we do with four dimensional points?

From the OGC SFS point, we have:

OGC SFS 1.1.0 restricted to 2D geometries

The extended WKT/ or 2.5D WKT implemented by OGR, PostGIS, etc. allow 2, 3, 4 dimension coordinates and do not use Z or M tags, see Adam Gawne-Cain, 1999, Simple Features Revision Proposal

OGC SFS 1.2.x allows 2, 3 and 4 dimensions using the Z or M tags: POINT Z(x, y, z), POINT M(x, y, m), POINT ZM(x, y, z, m). I think many may consider M as pseudo-dimension or not a dimension but a measure value.

a list with three coordinates is already enough

It seems desirable indeed to keep the current WKT I/O that does not read/output the Z and M tags.

Perhaps, an acceptable solution would be an optional flavor parameter, or similar, with current

boost::geometry::read_wkt(wkt, geometry, flavor

boost::geometry::wkt(geometry, flavor)

where flavor is enum, something like:

enum /*class*/ wkt_flavour { ogc2d, // OGC SFS 1.1.0 ogc3d, // OGC SFS 1.2.x ogc25d, // Adam Gawne-Caine, 1999, Simple Features Revision Proposal ewkt = ogc25d // PostGIS terminology };

or as an entirely separate OGC-compliant boost/geometry/gis/io/wkt/ extension.

vissarion · 2021-01-11T14:46:31Z

include/boost/geometry/io/wkt/write.hpp

 struct wkt_point
 {
 template <typename Char, typename Traits>
 static inline void apply(std::basic_ostream<Char, Traits>& os, Point const& p, bool)
 {
- os << Policy::apply() << "(";
+ if(dimension<Point>::type::value == 3) os << Policy2::apply() << "(";


A note about style here, there should be an empty space between if and (, there are not one line ifs etc. You may want to consult https://github.com/boostorg/geometry/wiki/Guidelines-for-Developers

vissarion · 2021-01-11T15:16:46Z

include/boost/geometry/io/wkt/write.hpp

 struct wkt_point
 {
 template <typename Char, typename Traits>
 static inline void apply(std::basic_ostream<Char, Traits>& os, Point const& p, bool)
 {
- os << Policy::apply() << "(";
+ if(dimension<Point>::type::value == 3) os << Policy2::apply() << "(";
+ else os << Policy1::apply() << "(";


I would agree with @barendgehrels

Another issue here is that after this change the following code

boost::geometry::read_wkt("POINT M(1 2 3)", p); std::cout << boost::geometry::wkt(p) << std::endl;

will output

POINT Z(1 2 3)

I think we should decide how we want to support more than 2 dimensions and probably issue #664 is the right place for that.

mloskot · 2021-02-11T22:21:51Z

example/01_point_example.cpp

+ typedef model::point<double, 3, cs::cartesian> point_t;
+ typedef model::ring<point_t> ring_t;
+ typedef model::PolyhedralSurface<ring_t> poly_t;


Since the library is now C++14, the aliases could be declared with the using declarations, which is a bit neater, IMHO, as it puts the most important part, the name, to the left.

mloskot · 2021-02-11T22:23:05Z

example/01_point_example.cpp

+ poly_t polyhedron2 = {{{0,0,0}, {0, 1, 0}, {1, 1, 0}, {1, 0, 0}, {0, 0, 0}}, {{0, 0, 0}, {0, 1, 0}, {0, 1, 1}, {0, 0, 1}, {0, 0, 0}},
+ {{0, 0, 0}, {1, 0, 0}, {1, 0, 1}, {0, 0, 1}, {0, 0, 0}}, {{1, 1, 1}, {1, 0, 1}, {0, 0, 1}, {0, 1, 1}, {1, 1, 1}}, {{1, 1, 1}, {1, 0, 1}, {1, 0, 0}, {1, 1, 0}, {1, 1, 1}}, 
+ {{1, 1, 1}, {1, 1, 0}, {0, 1, 0}, {0, 1, 1}, {1, 1, 1}} };


Could you reformat it to something easier to distinguish rows and columns? e.g.

{ {{...}}, {{...}}, {{...}} };

mloskot · 2021-02-11T22:23:52Z

include/boost/geometry/core/point_type.hpp

+ typedef typename point_type
+ <
+ ring_tag,
+ typename ring_type<polyhedral_surface_tag, PolyhedralSurface>::type
+ >::type type;


The using too?

mloskot · 2021-02-11T22:25:41Z

include/boost/geometry/geometries/PolyhedralSurface.hpp

+#include <boost/config.hpp>
+#ifndef BOOST_NO_CXX11_HDR_INITIALIZER_LIST
+#include <initializer_list>
+#endif


I'd move this in these between

#include <vector> <--- #include <boost/concept/assert.hpp>

mloskot · 2021-02-11T22:26:45Z

include/boost/geometry/geometries/PolyhedralSurface.hpp

+
+ using point_type = model::point<double, 3, boost::geometry::cs::cartesian>;
+ using ring_type = ring<point_type, true, true>;
+ using ph = Container<ring_type, Allocator<ring_type> >;


What does ph stand for?
I'd suggest to use full, descriptive names, avoid abbreviations, unless others agree those are fine.

mloskot · 2021-02-11T22:27:23Z

include/boost/geometry/geometries/concepts/PolyhedralSurface_concept.hpp

+
+

Too many blank lines

mloskot · 2021-02-11T22:27:39Z

include/boost/geometry/geometries/concepts/PolyhedralSurface_concept.hpp

+
+ BOOST_CONCEPT_USAGE(PolyhedralSurface)
+ {
+


Superfluous blank

mloskot · 2021-02-11T22:28:04Z

include/boost/geometry/geometries/concepts/PolyhedralSurface_concept.hpp

+} // namepspace concepts
+
+} // namespace geometry
+
+} // namespace boost


}}} // boost::geometry::concepts

mloskot · 2021-02-11T22:28:44Z

include/boost/geometry/geometries/concepts/check.hpp

@@ -39,7 +39,7 @@
 #include <boost/geometry/geometries/concepts/polygon_concept.hpp>
 #include <boost/geometry/geometries/concepts/ring_concept.hpp>
 #include <boost/geometry/geometries/concepts/segment_concept.hpp>
-
+#include <boost/geometry/geometries/concepts/PolyhedralSurface_concept.hpp>


Please, do not use CamelCase in file names (i.e. PolyhedralSurface_concept.hpp should read polyhedralsurface_concept.hpp

mloskot · 2021-02-11T22:29:20Z

include/boost/geometry/geometries/geometries.hpp

@@ -29,5 +29,6 @@
 #include <boost/geometry/geometries/polygon.hpp>
 #include <boost/geometry/geometries/ring.hpp>
 #include <boost/geometry/geometries/segment.hpp>
+#include <boost/geometry/geometries/PolyhedralSurface.hpp>


mloskot · 2021-02-11T22:29:52Z

include/boost/geometry/geometries/register/PolyhedralSurface.hpp

+
+#define BOOST_GEOMETRY_REGISTER_POLYHEDRALSURFACE_TEMPLATED(PolyhedralSurface) \
+namespace boost { namespace geometry { namespace traits { \
+ template<typename P> struct tag< PolyhedralSurface<P> > { typedef PolyhedralSurface_tag type; }; \


< PolyhedralSurface<P> >

to

<PolyhedralSurface<P>>

mloskot · 2021-02-11T22:30:33Z

include/boost/geometry/io/wkt/read.hpp

+ {
+ handle_open_parenthesis(it, end, wkt);
+ typename ring_type<PolyhedralSurface>::type ring;
+ while(it != end && *it != ")"){


{ in separate line

mloskot · 2021-02-11T22:35:07Z

include/boost/geometry/io/wkt/detail/prefix.hpp

@@ -42,6 +47,11 @@ struct prefix_linestring
 static inline const char* apply() { return "LINESTRING"; }
 };

+struct prefix_polyhedral_surface
+{
+ static inline const char* apply() { return "POLYHEDRALSURFACE Z"; }


Not sure about the Z as per @barendgehrels #782 (comment)

mloskot · 2021-02-11T22:47:46Z

@Siddharth-coder13 Please, see #789 (comment)

Fixed Writing 3D WKT:Z prefix

df04b36

mloskot requested changes Dec 9, 2020

View reviewed changes

Added WKT:Z prefix test case

ff1f245

mloskot mentioned this pull request Dec 11, 2020

Writing 3D WKT: Z in prefix? #664

Open

Siddharth-coder13 requested a review from mloskot December 18, 2020 06:43

barendgehrels requested changes Dec 30, 2020

View reviewed changes

barendgehrels requested review from awulkiew and vissarion December 30, 2020 09:56

vissarion requested changes Jan 11, 2021

View reviewed changes

mloskot reviewed Feb 11, 2021

View reviewed changes

mloskot approved these changes Feb 11, 2021

View reviewed changes

mloskot requested changes Feb 11, 2021

View reviewed changes

mloskot mentioned this pull request Feb 11, 2021

Defined a geometry for polyhedron #789

Open

Siddharth-coder13 force-pushed the develop branch from d0e6a99 to ff1f245 Compare February 20, 2021 07:12

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Fixed Writing 3D WKT:Z prefix #782

Fixed Writing 3D WKT:Z prefix #782

Siddharth-coder13 commented Dec 9, 2020

mloskot left a comment

mloskot commented Dec 11, 2020

Siddharth-coder13 commented Dec 11, 2020

Siddharth-coder13 commented Dec 13, 2020

mloskot commented Dec 13, 2020

Siddharth-coder13 commented Dec 29, 2020

barendgehrels left a comment

barendgehrels Dec 30, 2020

barendgehrels Dec 30, 2020

vissarion Jan 11, 2021

mloskot Jan 11, 2021

vissarion Jan 11, 2021

vissarion Jan 11, 2021

mloskot Feb 11, 2021

mloskot Feb 11, 2021

mloskot Feb 11, 2021

mloskot Feb 11, 2021

mloskot Feb 11, 2021

mloskot Feb 11, 2021

mloskot Feb 11, 2021

mloskot Feb 11, 2021

mloskot Feb 11, 2021

mloskot Feb 11, 2021

mloskot Feb 11, 2021

mloskot Feb 11, 2021

mloskot Feb 11, 2021

mloskot commented Feb 11, 2021

Fixed Writing 3D WKT:Z prefix #782

Are you sure you want to change the base?

Fixed Writing 3D WKT:Z prefix #782

Conversation

Siddharth-coder13 commented Dec 9, 2020

mloskot left a comment

Choose a reason for hiding this comment

mloskot commented Dec 11, 2020

Siddharth-coder13 commented Dec 11, 2020

Siddharth-coder13 commented Dec 13, 2020

mloskot commented Dec 13, 2020

Siddharth-coder13 commented Dec 29, 2020

barendgehrels left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mloskot commented Feb 11, 2021