Thanks to everyone who weighed in on this one, i’ve gone ahead and merged
the change and marked the proposal as complete.
One small change though, I found that making the new options to clip and
force containment the default behaviour introduced a number of failures in
the test cases, some of which are kind of subtle and have the chance of
tripping up users as well so I decided to play it safe for now and keep the
behaviour as is. So all the new kml centroid options are still opt-in.
On Mon, Jul 10, 2017 at 11:30 AM Kevin Smith <smit...@draconic.ca> wrote:
> If you don't think vector tiles label points are relevant that's good
> enough for me. I just want to watch out for corners we might paint
> ourselves into.
>
> +1
>
>
> On 2017-07-05 07:45 PM, Justin Deoliveira wrote:
>
> I kind of disagree with trying to generalize the parameters now… if
> another format comes along and adds a similar capability will it really
> have the exact same options with the exact same semantics? I am kind of
> doubtful.
>
> Unless there is a strong consensus that this has to happen I’m inclined to
> leave the options as is and KML specific until there is a more concrete
> need to coalesce them.
>
> On Wed, Jul 5, 2017 at 1:29 PM Kevin Smith <smit...@draconic.ca> wrote:
>
>> On 2017-07-05 11:56 AM, Jody Garnett wrote:
>> > Hey Justin / Kevin:
>> >
>> > Was talking with Kevin last week, he is looking to fine tuning the
>> > output of point locations to use for labeling when doing vector tile
>> > output.
>> >
>> > So you are both working on "calculating a better centroid" - can you
>> > share top level format options to avoid duplication?
>> >
>> >
>> &format_options=centroid_contain:true;centroid_samples:10;centroid_clip:true
>> >
>> > +1 to your GSIP, I do want to hear from Kevin if we can :)
>>
>> Yes this makes sense, At the moment I'm just working on including
>> precomputed label points in the vector tiles using the existing labeler,
>> but it's quite likely that would benefit from this kind of additional
>> control in future, so it would make sense to do it in a format agnostic
>> way now (at least in terms of keywords we're adding).
>>
>>
>> --
>> Kevin Michael Smith
>> <smit...@draconic.ca>
>>
>>
>>
> --
> Kevin Michael Smith<smit...@draconic.ca> <smit...@draconic.ca>
>
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
