Boost logo

Boost :

From: Barend Gehrels (barend_at_[hidden])
Date: 2008-01-30 12:29:12

Hi Michael,

Michael Fawcett wrote:
> On Jan 30, 2008 5:23 AM, Barend Gehrels <barend_at_[hidden]> wrote:
>> Maybe I should have stated more clearly that I'm a geographer and built
>> this library from a GIS perspective. We (at least in my company)
>> normally do not distinguish between polygon types, for example.
> :) That's my current field as well, although I have a background in
> game development. I have often thought a Boost.GIS library would be
> an excellent addition.
I agree! However a "boost.GIS" library is much larger than a
"boost.gis.geometry" library, it should probably contain projections,
classification and symbolization, rendering, etc. We have such a library
but that is not a boost-styled library and it is rather old, therefore
we started restyling the geometry core and adapted the std:: / boost::
>> Therefore, as in my other mail, we might change the namespace to
>> "geospatial" or to "geospatial2d" to make this more clear.
> I have a question (bare in mind I have not read your docs, so
> apologies in advance if this would have been obvious) - Do all of your
> algorithms expect Cartesian coordinates, and if so, do you provide
> conversion functions to transform from a particular geographic
> projection system to Cartesian?
They expect Cartesian coordinates indeed, and projection libraries are
currently not included in the library.
> What in your library makes it *more* "GIS" than "geometric"?
We started to call it "geometric" because it is only the geometry part
(of our larger library) which is more or less ready for boost or OSS.
However, there are many more ways to look at geometry than the way we
look, from the GIS perspective. We have focus on linestrings and
polygons, other geometry users look at triangles, trapeziums and
circles. For example. Therefore, we now think that it is better to show
the perspective and call it "geospatial::"
> If a GIS library were to be proposed to Boost, I would like to see the
> point class carry with it the projection system it was in. This could
> probably be done with Boost.Units. That way, trying to compute
> distance between two points that were in different projection systems
> simply wouldn't compile.
We didn't do that although we considered adding the SRID. But I will
have a relook and look better at boost.units for this case, good idea.
Library users can use their own points, containing the SRID, and make
algorithm specializations on them. There is an example showing that,
because there have been a discussion before about latlong points.


> --Michael Fawcett
> _______________________________________________
> Unsubscribe & other changes:

Barend Gehrels, Geodan Holding b.v., Amsterdam, The Netherlands,

Boost list run by bdawes at, gregod at, cpdaniel at, john at