On Tue, Oct 8, 2013 at 11:56 PM, David Winslow <[email protected]>wrote:
> David was also questioning the usage of the "random" keyword, suggesting
>> fill-jitter might
>> be a better option.
>> Personally I don't like it, because I cannot associate jitter with the
>> random distribution of
>> symbols out of the box, but maybe it's because I'm not a native enligsh
>> speaker.
>>
>
> It is more important to me to have "fill" in the name than to avoid
> calling it "random." This is a design consideration specific to CSS because
> the option will not be nested inside a <PolygonSymbolizer> element but
> jumbled in with all other properties. If we keep the name 'random' then I
> can just use the '-gt-fill' prefix in CSS as I do '-gt-label' for many
> text-symbolizer-related vendor options.
>
Ah yes, it makes sense, and I would be in favour of adding -gt-fill- as the
prefix, given than in
SLD the context seems to clarify what we're randomizing.
Uhm... unless someone eventually wants to consider random distribution of
symbols along a line for
graphic strokes.... is this something anyone ever heard of/seen?
>
> Also both David and Tim did not like having rotation being a separate
>> boolean parameter.
>> A possibility here could be to have it controlled as second parameter to
>> random:
>>
>> random: grid false (gridded, no random rotation)
>> random: free true (freeform, random rotation)
>>
>> Personally I don't like this approach because it's not clear what "true"
>> or "false" mean there,
>> whilst random-rotation: true is verbose, but clear.
>>
>
> I guess it sounded kind of confusing that I proposed a boolean parameter
> in the middle of my spiel against boolean parameters. My intent was that
> the presence or absence of the keyword 'rotation' would control whether the
> rotation was also randomized. Your examples then become:
>
> random: grid rotation;
> random: grid;
>
Ah sure, I can go with that. How do others feel?
>
>
>> Please comment.
>> Any improvement that does not require a significant rewrite of the
>> current code is welcomed
>> (for the others.. it would have been better to comment on the random fill
>> when I asked
>> for feedback before writing the code... but let's hear it anyways, if
>> there is a lot of consesus
>> I guess I can do the rewrite in my spare time instead of reviewing pull
>> requests
>> or fixing bugs, although it would set a bad precedent for whoever is
>> trying to do paid
>> work in this community)
>>
>
> It's not my intent to prevent folks from getting paid to do work on
> GeoTools - I am all in favor of it. As I said on the GeoScript list, if we
> are past the design phase of this GeoTools feature then I will work with
> that.
>
The design discussion was done end of August, but as said, happy to include
any improvement
that does not require deep changes
Cheers
Andrea
--
==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
information.
==
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
-------------------------------------------------------
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk
_______________________________________________
GeoTools-Devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
