Boost logo

Geometry :

Subject: Re: [geometry] Integrating OGR library with Boost.Geometry
From: Menelaos Karavelas (menelaos.karavelas_at_[hidden])
Date: 2015-05-26 08:09:39

Hi Eric.

On 26/05/2015 03:00 μμ, Eric MSP Veith wrote:
> Hello Menelaos,
> On Tuesday 26 May 2015 14:47:20, Menelaos Karavelas
> <menelaos.karavelas_at_[hidden]> wrote:
>> Yes, this IS the correct way. You need to specialize various
>> metafunctions in bg::traits namespace so that things work.
>> Please keep up posted about this.
> ok, good to know. I've followed this path and provided template
> specializations for clear, resize, and push_back. The test program you
> supplied now compiles, but gives a rather surprising result:
> geometry: LINESTRING(1 1,2 2,3 3,4 4,9 9)
> points: (1, 1) (2, 2) (3, 3) (4, 4) (9, 9)
> segments: ((2.0872e-317, 6.95257e-310), (6.91222e-310, 6.91222e-310))
> ((2.0872e-317, 6.95257e-310), (6.91222e-310, 6.91222e-310)) ((2.0872e-317,
> 6.95257e-310), (6.91222e-310, 6.91222e-310)) ((2.0872e-317, 6.95257e-310),
> (6.91222e-310, 6.91222e-310))
> The values of the last line change with each run, but never much, i.e., the
> value left to the dot remains the same.

My understanding is that something is left uninitialized, hence the
strange values.

> Do I need to provide a separate segment iterator...?

You should not need to. The implementation of the segment iterator is
rather generic, but quite tricky, as it is not the typical kind of
iterator (for example, dereferrencing returns a value rather than a

What is your linestring's value type and reference type? In the
implementation of the segment iterator it is assumed that, when
dereferrencing an iterator on the points of the linestring, a reference
(or const reference) is returned. If your linestring iterator returns
point values then this could indeed be a problem.

- m.

> Thanks
> Eric
> _______________________________________________
> Geometry mailing list
> Geometry_at_[hidden]

Geometry list run by mateusz at