vertex simplification

[Steve Lime]

I agree that both approaches can co-exist. There is renderer-based simplification
already in place although it had an ugly bug with certain (rare) paths- hence Thomas'
work.

On the second question, I had never worried about multipoint features because they
were relatively rare, and even when encountered they had relatively few parts. You're
talking layer-level generalization I take it. Get's a bit trickier though since you'd have to
cache the point and the class being used. Wouldn't think it's worth it but I could be wrong.

Steve

>>> On 10/29/2007 at 8:16 AM, in message
<d2b988930710290616l58d4dbcbh799cb25dc5eec3a6 at mail.gmail.com>, thomas bonfort
<thomas.bonfort at GMAIL.COM> wrote:
> I don't have much more to add, as Steve's reply is right on track.
> Tamas, I do think that the naive simplification should be done at the
> renderer level, whatever preprocessing was done beforehand at the data
> source level: it doesn't make much sense for a pixel based renderer to
> spend large amounts of time rendering features that are below the
> pixel level, but it does make sense for svg for example, when you may
> not know the scale at which the output will be seen. so let the
> renderer decide what level of detail it can provide and discard what
> it knows will carry little if not no additional information.
> 
> as for the douglas-peukel simplification, I agree this could/should be
> done at the data source. I was just throwing in the idea after looking
> at http://freemap.in/world/index.cgi , where the cartographic quality
> actually decreases at large scales because the data being drawn is too
> complex. So to have some kind of simplification going on that keeps
> cartographic quality whatever the scale, you'd either have to call the
> simplification methods with  some kind of scale dependand tuning
> parameters, or else have it done at the pixel level which seems a bit
> more straightforward.
> 
> subsidiary question: should we apply vertex simplification for point
> layers, when multiple points fall in the same image pixel?
> 
> thomas
> 
> On 10/28/07, Stephen Woodbridge <woodbri at swoodbridge.com> wrote:
>> Tamas,
>>
>> I don't think these two things are mutually exclusive. The fact is that
>> once you get the lines projected into pixel space there is still a need
>> to remove redundant vertices as Thomas has already identified because it
>> generates a significant speedup. I think Thomas should move forward on
>> that front regardless of other steps that might get taken.
>>
>> Regarding adding douglas-peuker at the raster level, I think that the
>> jury is not in on that yet. The value of doing this would be because it
>> can speed up the rendering without a significant impact to the display
>> quality. I think Thomas needs to perform some test in this area and
>> report on the findings.
>>
>> There are advantages to doing simplification at the source level and
>> potentially caching the source data, in that there is less data to move
>> into mapserver and less data to manipulate and this has some savings
>> that can be pretty big depending on  a lot of variables. But once that
>> data or any data is in pixel space there are a whole other set of
>> optimizations that can/need to be applied regardless of the source data
>> that can speed up specifically the rasterizing task and this is what
>> Thomas is looking at.
>>
>> So we should get champions to move both fronts forward.
>>
>> Best regards,
>>    -Steve
>>
>> Tamas Szekeres wrote:
>> > Thomas,
>> >
>> > I think this kind of feature preprocessing task should not be bound
>> > tightly to the rendering process and should be treated differently.
>> > The concept around MS-RFC-22 (
>> > http://mapserver.gis.umn.edu/development/rfc/ms-rfc-22a ) is a kind of
>> > preliminary invocation for satisfying this need.
>> > We should also allow the user to define the desired processing
>> > pipeline along with some caching to prevent from doing the same
>> > operation twice in the further drawings or among the layers if
>> > possible.
>> > The concept out there would also allow to drag in the capabilities of
>> > the GEOS library to make more functions available like the
>> > Douglas-Peuker simplifier as it happens.
>> >
>> > In many cases however it might be desirable to make the simplification
>> > at the data source to decrease the amount of data to be retrieved.
>> >
>> > Best regards,
>> >
>> > Tamas
>> >
>> >
>> > 2007/10/27, thomas bonfort <thomas.bonfort at gmail.com>:
>> >> hi all,
>> >>
>> >> I'm looking into adding some vertex simplification at the image level,
>> >> for the time being limited to the agg renderer. I've got two questions
>> >> I'd like to have feedback on:
>> >>
>> >> * it's very easy to add a local simplification, by removing vertexes
>> >> in a linestring that are closer than some threshold to their preceding
>> >> vertex. I'm getting nice speedups by mimicking what's currently (more
>> >> or less implicitely) done with gd, by removing vertexes that fall in
>> >> the same pixel than its predecessor (of course these speedups would
>> >> only happen for complex line layers. I'm currently testing with the
>> >> canadian road data mentionned in
>> >> http://wiki.osgeo.org/index.php/FOSS4G2007_IntegrationShowcase). I
>> >> know agg is all about subpixel accuracy and such, but I'd think this
>> >> behaviour could be enabled by default ( as in this case the maximum
>> >> error for a vertex is less than a pixel)
>> >>
>> >> * is anyone interested in having a global and tunable vertex
>> >> simplification functionality. I don't think it would be too much work
>> >> work to implement a douglas-peuker line generalisation algorithm, that
>> >> could be turned on and tunable with a new mapfile keyword. That's
>> >> basically doing what postgis' SIMPLIFY can already do, except this
>> >> would be done in pixel coordinates, and therefore would not have to be
>> >> tuned w.r.t. scale.
>> >>
>> >> thomas
>> >>
>>
>>