11 Nov
2009
11 Nov
'09
10:03 p.m.
Hi Thomas, Thanks for your pre-review. I try to answer the pieces not yet handled. I've no problem with Boost.Geometry if it is accepted, and users have indeed to change some things anyway after acceptance. > > > [...] I still took a look at "linestring_concept.hpp" to check whether you enforce a certain representation to the user. Now I'm totally confused, because "geometries/adapted/std_as_linestring.hpp" registers std::line<P> as a linestring, but the following concept requirement for linestring seem to rule out std::list<p>: > > BOOST_CONCEPT_ASSERT( (boost::RandomAccessRangeConcept<Geometry>) ); > You are right. A list is not supported, it used to be in the past but now, it is not anymore. We're using Boost.Range now everywhere, including boost::size, not supported by lists. So like Mateusz said. We will remove it from the adaption file. > Now I should try to explain what I mean by a representation. GIL gives the example that the RGB values might be saved interleaved as > > RGB RGB RGB > > or as separate arrays > > RRR GGG BBB > > and that both representations might have advantages and disadvantages for different use cases. One of the goals of GIL is to allow writing algorithms that will work on both (and most other sensible) representations. > I think this has some analogy to what GGL does: it works on rings and polygons having both orientations, clockwise and counter clockwise. Both occur. The OGC convention is clockwise. We first only supported that. But in the end the difference is not that large, in implementation. We call it generic because it should support different point-types, different line-types, etc, even in one algorithm. We're also agnostic in coordinate system and number of dimensions. Not that all is supported in 3D, in fact that support is still limited, but it is support is provided by the kernel. Finally people can add coordinate systems or even geometries (like triangle, ellipse), all is dispatched the same way. But we don't support "everything" indeed. For example, linestrings with non-linear interpretations between its vertices were discussed, but not more than that. > What does "ggl::assign_inverse" and "make_envelope" do? These are apparently OGC names, but I spend quite some time trying to verify that this is indeed the case About OGC names: - you are right about that it can be confusing now and that it should be more clear - assign and assign inverse are not OGC names; combine is also not an OGC name - envelope is the OGC name. But as we also use std:: and boost:: conventions, we decided to let functions returning a geometry being preceded by make_. So make_envelope, make_centroid. The user has to specify the type then. - read_wkt is not the exact OGC name. This has a little history again. We first had "as_text", the OGC convention. But that was too general, we also have svg and dsv, and VE-shapes, all is text. So we decided to deviate here and call the streaming "wkt". Reading wkt is not in the SF spec (Mateusz gave the link), databases call it "from text", also too general. So we call input now "read_", output is just streaming with the name I'll come with a clarification of the exact OGC names/support/deviations. They were there in earlier documentation but there are many people not interested in GIS or OGC, so we don't want to pay it too much attention everywhere in the documentation. Regards, Barend