Ticket #155 (new enhancement)

Opened 20 months ago

Last modified 6 weeks ago

Extend PointSymbolizer to support image scaling

Reported by: springmeyer Owned by: artem
Priority: normal Milestone: 0.8.0
Component: Symbolizers Version: SVN Trunk
Severity: Normal Keywords:
Cc: ajturner, semprebon, craig.destigter@…, mishok13, freek@… Patch Needs Improvement: no
Needs Docmentation: no Has Patch?: yes
Design Decision Needed: yes

Description

This ticket is an enhancement request to look into new design options around adding more flexibility to or extending the PointSymbolizer.

Currently the behavior of the width and height parameters seems both redundant (see Ticket #60) and non-intuitive. Setting width and height to any dimensions other than the exact dimensions of the input graphic file crops the graphic rather than scaling the image (which would be my expected behavior).

Ideally support for scaling vector graphics could be added to allow things to be done with the PointSymbolizer related to thematic display of point data, similar to this request: http://www.mail-archive.com/dev@openstreetmap.org/msg04395.html

Attachments

Ticket_155.diff (13.4 kB) - added by semprebon 16 months ago.
Patch to implement scaling and color for PointSymbolizer
point_symbolizer_scaling2_springmeyer.patch (14.4 kB) - added by springmeyer 16 months ago.
Modifications to patch, fixing typos, maintaining behavior of original point_symbolizer, fixing tabs

Change History

Changed 20 months ago by springmeyer

Also see Ticket #60

Changed 20 months ago by springmeyer

  • summary changed from Enable PointSymbolizer "Width" and "Height" to scale image dimensions to Extend PointSymbolizer to support image scaling

Changed 20 months ago by tomh

Are you saying that the Agg renderer does scale symbols and the Cairo renderer doesn't? Is this a new feature in the Agg renderer? or something I missed when doing Cairo?

Changed 20 months ago by springmeyer

  • owner changed from tomh to artem
  • component changed from Cairo Renderer to Core Library

Whoops, I didn't mean to tag that as only component cairo.

This enhancement, I assume, would affect both renderers.

Changed 20 months ago by ajturner

I've started digging into this - but haven't yet figured out in Agg where to do the scaling transformation.

More generally it would be good to expose mechanisms similar to KML's styling support: scale, 'hotspot' location (where to center the image), color overlay.

Changed 20 months ago by springmeyer

Another relevant thread relating to extending the PointSymbolizer:

Changed 20 months ago by springmeyer

Changed 19 months ago by springmeyer

  • cc ajturner added

Changed 18 months ago by ajturner

I have this somewhat working in my local copy. I'll try and clean up into a patch and submit

Changed 16 months ago by semprebon

Patch to implement scaling and color for PointSymbolizer

Changed 16 months ago by semprebon

  • has_patch set

I've taken ajturner's changes and updated them for version 0.6.0.

Changed 16 months ago by springmeyer

  • milestone changed from 1.0.0 to 0.7.0
  • design_decision_needed set

Fantastic, Thanks for the patch.

One thing I noticed right off is that we'll also need property serialization added to source:trunk/src/save_map.cpp as well.

Nice job adding it to source:trunk/src/load_map.cpp

Changed 16 months ago by springmeyer

  • cc semprebon added

Okay, so I've given the patch an initial review.

Overall I'm not sure, after thinking more about the PointSymbolizer as it is currently used, that scaling support should be added to the PointSymbolizer.

If the goal is scaling raster icons/graphics read from the filesystem then this is useful. However if the goal is proper proportional symbology (this is a feature I'd like to see and I'm assuming you are after, but correct me..) of graphics primitives (circles, rectangles, ellipses, etc) then it seems more logical to write this functionality into a new symbolizer that would accept arguments like:

<SomeSymbolizer shape="circle" fill="green" stroke="blue" fill-opacity=".5" stroke-opacity=".9" stroke-width="1" size="10">

Perhaps the actual arguments should stick to the svg spec: http://www.w3.org/TR/SVG11/shapes.html ?

Thoughts?

Changed 16 months ago by springmeyer

Modifications to patch, fixing typos, maintaining behavior of original point_symbolizer, fixing tabs

Changed 16 months ago by springmeyer

Okay, if a full blown symbolizer that supports constructing graphics primitives is not what you are after, the existing patch still needs some improvement.

These things have been fixed in my revised patch:

  • Typo in 'opcity' in include/mapnik/point_symbolizer.hpp
  • 'color' parameter not exposed in python
  • 'color' parameter should be optional
  • fixed a few mixed tabs and spaces
  • because 'color' was not optional existing graphic symbols were made all white even if color param was not supplied

I've tested the revised patch with this sample XML and symbol: http://mapnik-utils.googlecode.com/svn/sandbox/point_opacity/

It now renders original symbol correctly if the 'color' and 'scale' parameters are not used.

And it works to scale the symbol up or down and apply a color to it.

Problems:

  • overall design decision needed on approach (put more effort into PointSymbolizer or direct a new one)
  • placement finder is not sensitive to symbol size
  • Cairo bindings are crashing python
  • 'color' param should be called 'fill' throughout

Changed 14 months ago by rcoup

This patch seems to have gone a little off-course. When Craig & I were looking at scaling in #320, the outcome was to:

  • make width & height optional, since the PNG/SVG readers are perfectly capable of figuring it out themselves.
  • if neither are specified, draw as "original size" (px for raster symbols, "document units" for SVG ones)
  • if one is specified, scale proportionally to fit in that size
  • if both are specified, scale un-proportionately.

Cairo helpfully supports internal scaling via it's matrix, agg needs to use the stuff in image_util.hpp.

The scale parameter seems redundant, since I can't figure out any use cases for cropping symbols (anyone?), and it'll require a user to calculate it from the desired image width & height anyway.

Adding color is a bit OT for this ticket and should probably be handled separately.

Changed 14 months ago by springmeyer

rcoup - I fully agree.

Changed 14 months ago by cdestigter

  • cc craig.destigter@… added

Changed 14 months ago by springmeyer

I'm hoping to meet semprebon today at Where2.0 and hopefully we can chat more about directions with this and look to re-formulate goals on this based on advances with svg...

Changed 9 months ago by springmeyer

  • component changed from Core Library to Symbolizers

Changed 8 months ago by mishok13

  • cc mishok13 added

Changed 6 weeks ago by macfreek

  • cc freek@… added
Note: See TracTickets for help on using tickets.