Boost logo

Geometry :

Subject: [ggl] folder updates
From: Barend Gehrels (Barend.Gehrels)
Date: 2009-10-08 12:36:37

Hi list,

As discussed (in a smaller group, in preparation of review request) we
propose the "extensions" idea, as GIL also has it.

I quote here some pieces of off-list messages:

> [Mateusz] Perhaps, we could mention in the review application that we are going to
> help to organise development of GGL extensions, where an extension is
> something more specific to domains like GIS, etc.
> For example, I would see the veshape there.
> Perhaps, Boost folks will object elements like WKT/WKB parsers,
> then we could move them to the official extensions.
> I mean something similar to what GIL folks arranged:

> [Mateusz]
>> > [[Barend]] Extensions probably have to be reflected in our source-tree as well
>> > (as in the text below). It sounds great to me: /boost/ggl/core
>> > /boost/ggl/algorithms (distance/within/etc here, some (names) are OGC
>> > but they are not that GIS-specific)
> I would consider it this way: algorithms like spatial predicates,
> distance, etc. are based on GIS-related specifications - the OGC.
> However, they are usable perfectly usable for general geometric
> purposes and applications
> [...]
> I would organize things more according to "what does it do", for example:
> /boost/ggl/extensions/gis/io/wkb
> /boost/ggl/extensions/gis/io/wkt
> /boost/ggl/extensions/gis/io/shape
> /boost/ggl/extensions/gis/io/gml2
> /boost/ggl/extensions/gis/io/gml3
> If one implements GeoJSON I/O for GGL, then this goes to GIS-specific
> formats:
> /boost/ggl/extensions/gis/io/geojson
> However, if someone would like to provide extension to read/write plain
> geometry and non-GIS specific objects from/to JSON format (not GeoJSON),
> then I would expect to see it here:
> /boost/ggl/extensions/io/json
> SVG is a data format, SVG "driver" for GGL is an input/output engine,
> however it is not GIS specific, so it goes out of extensions/gis:
> /boost/ggl/extensions/io/svg
> and so on...
> I think such domain-and-task-oriented organisation would make things
> clear to users (most Boost users might have no idea what OGC stands for,
> but they surely have heard about GIS).
>> > /boost/ggl/extensions/projections
> I suppose projections are for GIS-specific coordinate systems
> and projections, so perhaps:
> /boost/ggl/extensions/gis/projections
> [...]
> The /boost/ggl/extensions structure works for me.
> It follows the approach proposed by GIL, that Boost (GIL) users are
> probably used to it.

Most of these changes are no reflected in the source trees. Testfiles
and examples are updated. If projections do not compile for you, please
#include <ggl/projections/... into #include
Also moved are: svg and veshape.

The example folder will probably get subfolders "extensions" and
"extensions/gis" which is not yet done.

The WKT is special in the sense that it is OGC (so GIS) but used in most
of the test cases. I would propose to leave it where it is for the moment.

One thing not being discussed is the "multi". I now placed the
/io/svg/write_svg.hpp and /multi/io/svg/write_svg.hpp
into respectively /extensions/io/svg/write_svg.hpp and

Don't think that multi is a separate extension, and for extensions the
multi distinction is probably not that useful. But if people think
otherwise, please let know.

The spatial index will be an extension but it is NOT specific to GIS, at
least not all of them and the one which is there now, so it probably will be
/extensions/index ?
/extensions/index/rtree ?
this change is not yet done.

Furthermore the library will be requested for review in the Boost
community soon, but NOT the extensions part, unless it is necessary to
show some things.

Regards, Barend

-------------- next part --------------
An HTML attachment was scrubbed...

Geometry list run by mateusz at