Re: [boost] preview of a template geometry library

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

gchen wrote:
> Hervé Brönnimann wrote:
>   
>> Dear Bernd:  I started with a few quick notes (I really didn't do  
>> much more than glance at the documentation), which grew into a  
>> somewhat more extensive review - sorry, I've been thinking about  
>> geometric software library for a while now :)
>>
>> I have many concerns/questions/suggestions with your library:
>>
>>     
> [...]
>   
>> * naming:  within_point_in_polygon is not a good name.  I understand  
>> the desire to have all of them start with "within_" but  
>> is_point_within_polygon would read like English, at least.  As  Theo  
>> mentioned, having 2D somewhere in the name would also avoid deflated  
>> expectations from users.
>>
>>     
>
> My background in using geometry is 3D graphics. So I found some
> naming is a little strange too me, like "evelope", "within", "linestring"...
>
> IMO, "within_*" would be better is changes to "contain":
> template<typename POI, typename POL>
> bool contain(const POL& poly, const POI& pnt)
>
> I am still wondering if "evelope" is "Bounding Box" or "Hull", if
> "linestring" is "Poly Line" or "Line Strip".
>   
Those are all names defined by OGC (http://www.opengeospatial.org), we 
used their names for classes and algorithms. So the envelope is a 
buonding box, linestring is a series of segments (or points) and indeed 
often called a poly line. Those things are in the documentation.

These geometries are also called "simple features".

These names are also commonly used in spatial database such as 
PostgreSQL, MySQL and Oracle. See for example 
http://dev.mysql.com/doc/refman/5.0/en/opengis-geometry-model.html or 
http://postgis.refractions.net/docs/ch04.html#RefObject

OGC defines "within" as the general case that one geometry is completly 
inside another one. They have defined "contains" as well but just as a 
handy name for the other way round.
I understand that you give samples and all names might seem strange. 
However, we thought it was good to take standarized names.
>> * more algorithms and more implementations:  you can find working  
>> code for many intersection / detection / distance computation in many  
>> books.  Perhaps the most relevant for your purposes is the excellent  
>> "Geometric Tools for Computer Graphics"  by Philip Schneider & David  
>> Eberly
>> (http://www.amazon.com/dp/1558605940? 
>> tag=softsurfergeomet&link_code=as3&creativeASIN=1558605940&creative=3734 
>> 89&camp=211189)
>>
>>     
>
> Yeah, this book is very good. Also, David Eberly has a library implemented
> almost all the geometry primitives and algorithm introduced in the book, 
> it is
> worth to have a look:
> http://www.geometrictools.com/
>   
Thanks.
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>
>
>
>   

-- 
-------------------------------------
Barend Gehrels, Geodan Holding b.v., Amsterdam, The Netherlands, www.geodan.nl