extend the vector modell to be able to calculate real circular segments and circles => for calculating real circular buffers of points

[mlechner]

It would be interesting to extend the grass vector model to be able to construct curves for using them to create real circular buffers instead of approximating them using several vertices.

I just was wondering - isn't it more effectice saving a buffer using one vertice and a "curved line" than using several points and approximate the circle.

An appproximated buffer could still be in the data - only newly calculated buffers are more correct then.

[hamish]

Replying to mlechner:

It would be interesting to extend the grass vector model to be able to construct curves for using them to create real circular buffers instead of approximating them using several vertices.

I just was wondering - isn't it more effectice saving a buffer using one vertice and a "curved line" than using several points and approximate the circle.

An appproximated buffer could still be in the data - only newly calculated buffers are more correct then.

Hi,

I remember some years ago seeing a presentation about a similar idea. The talk was entitled “The circle tree – a hierarchical structure for efficient storage, access and multi-scale representation of spatial data”, by Antoni Moore.

​http://www.business.otago.ac.nz/SIRC/conferences/2002_SIRC/17_Moore.pdf (and also another talk at SIRC 2003)

Tony's office is just down the hall, if needed I can ask him where it lead. ISTR they had a prototype and did some efficacy testing. (or you can just use that as scholar.google search terms for publications...)

perhaps this wish is "easier said than done".

see also the symbol library, which has a hybrid cartesian/polar polyline input method.

Hamish

[glynn]

Replying to mlechner:

It would be interesting to extend the grass vector model to be able to construct curves for using them to create real circular buffers instead of approximating them using several vertices.

Replying to hamish:

perhaps this wish is "easier said than done".

Very much so. The problem isn't creating or storing curves, but the fact that every vector module would need to be able to handle paths which contain curved segments.

Certain operations are much more complex for curves than for straight line segments, e.g. testing which side of the line a point falls on, calculating the intersection between segments, etc.

It would be possible to provide a mechanism whereby the vector libraries automatically convert a curve to a sequence of straight line segments, with the accuracy determined by either the calling module, a run-time configuration variable, or a default value stored in the map. However, this creates other issues, e.g. the results would differ depending upon the accuracy chosen.

Another option would be to allow lines to be "tagged" with an indication that they represent sampled curves. Individual modules could then (optionally) interpolate the paths to a higher detail level.

Or would could just have a separate module (or an extension to v.split) which subdivides vectors by treating them as sampled curves rather than a sequence of straight lines.