Geometry Boost List: [ggl] Re: Finding intersection points of a ray and polygon?

Subject: [ggl] Re: Finding intersection points of a ray and polygon?
From: Elvis Stansvik (elvstone)
Date: 2010-02-23 13:55:49

2010/2/23 Barend Gehrels <Barend.Gehrels_at_[hidden]>:
> Hi Elvis,
>
>
>
> Yes, I realized this after doing some research. It's however, given
> the simple nature of my project, not a catastrophy as it would be OK
> with me to work with "rays" of finite length. That is, line strings.
>
>
>> OK, perfect
>
>
> Alright. As I'm pretty short on time and new to Boost and generic
> programming in general (coming from a background of mostly Qt
> programming, which is not so template intensive), I'm not sure
> contributing this function to Boost.Geometry is something that I'll
> have time to contribute, at least not within the constraints of my
> project. Or did you mean it would be an easy addition for you
> developers?
>
>
>> Yes, I meant that it is easy for me :-)
>> However, at this very moment I can't do it...

Ah OK. No problem at all.

>>
>> See also your other mail, segment/polygon or linestring/polygon are not yet
>> supported and I realize that though it is easy, it is not that easy for if
>> you've not the experience...

Oh I see. I was reading the slides from BoostCon '09 and got the
impression that all algorithms would work on all geometry types, and I
was successfully intersecting a linestring with a box, so I thought it
would work with a linear_ring too.

>>
>>
>> best you can get (with Boost.Geometry).
>
>
> Okay. Until now I've just experimented some with a checkout of 0.6.0.
> I guess I should get on trunk because grepping the sources i could not
> find get_turn_points(), only self_get_turn_points(). I'll download the
> trunk version.
>
>
>> Eehm, yet it should be there.

Hm I must have mis-grepped or read past it then. I'll look again.

>
> But what does it mean that it's in "coded" form? Is this information
> available to me right now (except that get_turn_points() would need to
> be extended to do line-polygon intersection). And what information
> will this give me if Boost.Geometry have no concept of rays? What is
> the "direction" of a line (segment)?
>
>
>> Will explain the coded form later.

Alright. Great.

>
>
> Yes I've come to realize that the library is in a bit of a flux. What
> I really miss though is documentation of all the member functions of
> the library. Very few of them are documented, sometimes not even their
> arguments, which makes it a bit hard for a newcomer like me to get up
> to speed with the library quickly.
>
>> When will the incorporation into Boost take place? Will there be any
>> added documentation when that happens?
>
>
>> Hopefully 1.43 or 1.44 (this spring or else summer)
>> Yes, there will be more documentation, it is currently being
>> restructured/rewritten.

That's great.

My little project is over just a couple of months. But 50% of the
grade is about how my process works and how good I am with documenting
what I'm doing, the other 50% is the end result, so who knows I might
have to change my ambition level and make the program simpler. The
goal of illustrating the law of refraction can be met anyways.

If I could make use of Boost.Geometry that would be great, as I don't
think I'll have time to figure out hand-written algorithms for the
things I need and still meet the deadline. Otherwise I'll just have to
change my goal and make the program simpler.

Elvis

>>
>> Regards, Barend
>>
>
>
>
> _______________________________________________
> ggl mailing list
> ggl_at_[hidden]
> http://lists.osgeo.org/mailman/listinfo/ggl
>
>