[Qgis-developer] branching: symbol levels in rule-based rendering

Tue May 3 15:20:06 EDT 2011

Hi Tim,
Just a note as you asked me to remind you and the core developers about
the patch for symbol levels in rule-based rendering.
The patch is the last attached file here:
http://trac.osgeo.org/qgis/ticket/3222
Named:
patch_on_r15676-rbr_symbol-levels_reordering_1st-rule_buttons.diff

Using this, I developed 339 rules giving a quite robust symbology for
OSM data (point, lines, polygons) and contour lines, with continuous
zooming capability from street view (1:2500) to national view (about
1:50 000 000).
In addition to being useful to end users, I believe it will meet the
increasing needs for customized OSM web servers, thanks to qgis-server.
Given that QGIS is much more user friendly than mapnik and osmarender
(you concentrate on mapping rather than on stylesheet writing), this
should speed up the adoption of qgis-server.
(A search for [openstreetmap custom] on google gives 2 Million of
results). Hope this helps!

Thank you,
Mayeul

Le samedi 19 mars 2011 à 09:40 +0200, Tim Sutton a écrit :
Hi

> Mayeul we will apply this after we branch for release (probably around
> 1 april). Please remind me if you see the branch notice go out and you
> havent seen your patch applied.
> 
> Regards
> 
> Tim
> 
> 
> > This does not prevent us to work towards SLD in the long term.
Still,
> > for now, all NG renderers (Single symbol, categorized, graduated)
have a
> > working "Symbol level" button, except the rule-based renderer; the
patch
> > will give similar behaviour on all renderers.
> > It "kills" me to write this, but if those few lines of the patch are
not
> > applied, IMHO it is better to remove the "Symbol levels" button from
the
> > rule-based renderer (because users will try to use it otherwise).
> >
> > Mayeul
> >
> > On Friday 04 March 2011 at 16:33 +0100, Marco Hugentobler wrote:
> >> > we could
> >> > apply your patch to the release branch and keep trunk untouched
for
> >> > Martin to implement it in his preferred way.  Martin, Marco that
sound
> >> > ok for you?
> >>
> >> +1
> >>
> >> Marco
> >>
> >> Am Freitag, 4. März 2011, um 05.42:09 schrieb Tim Sutton:
> >> > Hi Mayeul
> >> >
> >> > On Wed, Mar 2, 2011 at 7:01 PM,  <mayeul.kauffmann at free.fr>
wrote:
> >> > > Hi,
> >> > >
> >> > > (This follows this thread: Branch status for merge and release
timeline
> >> > > proposal)
> >> > >
> >> > > Thanks for you answer Tim! I found the clarification useful and
I
> >> > > appreciate your sense of diplomacy. Here are a few thoughts.
> >> > >
> >> > > You wrote: "I agree the items in your list should get
attention"
> >> > > Just to make sure: most of the list (including links to my
patch) was
> >> > > written by users Neumann and Anitagraser.
> >> >
> >> > Acknowledged thanks.
> >> >
> >> > > Among those fixes, we are several developers to believe that
symbol
> >> > > levels in rule-based rendering should be fixed, even with a
temporary
> >> > > fix. A fix was proposed in August 2010 by mhugent, see:
> >> > > http://trac.osgeo.org/qgis/ticket/2832#comment:8
> >> > > His patch was applied except for the symbol level lines (about
10 lines
> >> > > of code).
> >> > >
> >> > > I made improvements to this code and my patch was somehow
applied, again
> >> > > without the few symbol level lines of code.
> >> > > http://trac.osgeo.org/qgis/ticket/3222#comment:15
> >> > >
> >> > >
> >> > > I agree with Martin that it would be better to have a final
solution than
> >> > > an incomplete one for symbol levels. But since the rule-> based
> >> > > rendering is currently in an incomplete state, why put it in
the
> >> > > renderer stable release anyway? I believe symbol levels make >
a huge
> >> > > difference in rendering lines. With them, I have a rendering
similar to
> >> > > Osmarender or Mapnik in QGIS which gives QGIS a > definitive
bonus with
> >> > > respect to many other desktop or server GIS.
> >> >
> >> > Ok I had a read through the ticket. Martin is the maintainer of
this
> >> > code so while I share your desire for symbol levels in rule based
> >> > renderer, I think we should give Martin the space to implement
the
> >> > solution in his way if he has a better approach. I know Martin
has  a
> >> > lot of other things on his plate so lets give him some time. If
coming
> >> > up to the release we need to apply a band aid fix (that doesnt
break
> >> > any compatibility) to get 1.7 out with symbol level support, we
could
> >> > apply your patch to the release branch and keep trunk untouched
for
> >> > Martin to implement it in his preferred way. Martin, Marco that
sound
> >> > ok for you?
> >> >
> >> > > (for a rendering sample, see:
> >> > > http://www.qgis.org/qgiswiki/images/f/fd/Lago_di_varese.png
> >> > > which is compared with the OSM python plugin rendering here:
> >> > >  http://www.qgis.org/wiki/Using_OpenStreetMap_data  )
> >> >
> >> > Very nice - I also have someone working on building rendering
rules
> >> > for OSM here at Linfiniti and have been reading your notes and
the
> >> > discussions on OSM symbology here on this list with interest.
> >> >
> >> > > Also, QGIS rule-based rendering is definitely more powerful
than what you
> >> > > can achieve on ArcGIS with queries and scale-related
visibility, but
> >> > > ArcGIS users who need symbol levels will not want QGIS's
rule-based
> >> > > rendering.
> >> > >
> >> > > Ideally we should be able to have any combinations of the
following:
> >> > > -symbol levels ON or OFF
> >> > > -apply first matching rule or apply all rules
> >> > > (That's 4 combinations)
> >> > >
> >> > > With a few lines take from any of the two patches proposed by
mhugent and
> >> > > myself, we can have either: -symbol levels OFF and apply all
rules
> >> > > -symbol levels ON and apply first matching rule
> >> > >
> >> > > With the current version (since r15217) we only have:
> >> > > -symbol levels OFF and apply all rules
> >> >
> >> > Yup those all sound useful - the idea being that you could create
a
> >> > sequence of symbol layers based on rules offers powerful
> >> > possibilities. By the way did you figure out the correct syntax
for
> >> > the modulus operator? I was trying to make a simple rule to make
every
> >> > contour % 100m a bit thicker. Eventually I settled for contour in
> >> > (100,200,300....) which is ugly but worked...
> >> >
> >> > > Adding the extra capability provided in the two proposed
patches does not
> >> > > prevent working later on having the missing two combinations:
-symbol
> >> > > levels ON and apply all rules
> >> > > -symbol levels OFF and apply first matching rule
> >> > >
> >> > > What do you think?
> >> >
> >> > Yes personally I would like to see these options too.
> >> >
> >> > Best regards
> >> >
> >> > Tim
> >> >
> >> > > Regards,
> >> > > Mayeul
> >> > >
> >> > > ----- Mail Original -----
> >> > > De: "Tim Sutton" <lists at linfiniti.com>
> >> > > À: "Mayeul Kauffmann" <mayeul.kauffmann at free.fr>
> >> > > Cc: "qgis-developer" <qgis-developer at lists.osgeo.org>
> >> > > Envoyé: Mardi 1 Mars 2011 21h44:05 GMT +01:00 Amsterdam /
Berlin / Berne
> >> > > / Rome / Stockholm / Vienne Objet: Re: [Qgis-developer] Branch
status
> >> > > for merge and release timeline proposal
> >> > >
> >> > > Hi Mayeul
> >> > >
> >> > > On Tue, Mar 1, 2011 at 3:15 PM, Mayeul Kauffmann
> >> > >
> >> > > <mayeul.kauffmann at free.fr> wrote:
> >> > >> Hi,
> >> > >> What about open tickets (bug fixes) that are not in branches?
What is
> >> > >> the timeline for them?
> >> > >
> >> > > We usually try to make sure there are no show stoppers when we
release
> >> > > and remaining tickets get carried over to next release. I dont
think
> >> > > we will ever be able to be in a situation where there are no
open
> >> > > tickets left at the time of a release.
> >> > >
> >> > >> Now that New Symbology  is the default, I guess
> >> > >> the following should be fixed before release, or am I missing
something?
> >> > >>
> >> > >>
http://www.qgis.org/wiki/Switching_from_Old_to_New_Symbology_and_Labelin
> >> > >> g
> >> > >
> >> > > This is a great list / wiki page. The wait / when to release
> >> > > discussion is one that comes up periodically. I agree the items
in
> >> > > your list should get attention - and no doubt more items will
be
> >> > > raised when people are using symobology-ng by default. However
these
> >> > > are not things I believe we should put a hold on the release
for. If
> >> > > there is a general unhappiness about the situation, we can
reinstate
> >> > > old symbology by default, but if not, lets put what we have out
there
> >> > > for people to test and use, and march on towards 2.0.
> >> > >
> >> > > Regards
> >> > >
> >> > > Tim
> >> > >