Re: [Geotools-devel] GSIP RenderListener Extension
Added my +1 to the page, did not intended to hold up the proposal.
--
Jody Garnett
On Mon, 28 Oct 2019 at 04:13, Andrea Aime
wrote:
> Hi Jody,
> can you please cast a firm vote on this proposal?
> It's not clear if you are still demanding something to be changed, or not,
> and the proposal is stuck as a consequence
>
> Cheers
> Andrea
>
>
> On Thu, Oct 17, 2019 at 9:17 PM Jody Garnett
> wrote:
>
>> Thanks Andrea, I understand I am a bit late providing feedback.
>>
>> With respect to events, perhaps the interface stability aspect is
>> addressed by the ability to add default methods.
>>
>> And I agree the pattern is: RenderListener listens for RenderEvents which
>> may have a RenderEvent.Type (along with other state).
>>
>> I do not feel strongly, only want the stability aspect considered.
>> --
>> Jody Garnett
>>
>>
>> On Thu, 17 Oct 2019 at 10:10, Andrea Aime
>> wrote:
>>
>>> On Thu, Oct 17, 2019 at 12:30 AM Jody Garnett
>>> wrote:
>>>
Can I ask you to fill in the tasks section, want to be sure we have a
clear picture of the work involved.
You have events for the layer by layer notifications, and subsequent
labeling activities, is there any need to have events for the composition
steps (thinking of the rendering into multiple buffers and resulting alpha
blending effects).
>>>
>>> No need at the moment, but you can make your own GSIP for it if you do?
>>> :-)
>>> Generally speaking it's bad form to ask others for scope increase, but
>>> it's fundamental that we check
>>> the proposed design does not prevent those future improvements.
>>>
>>>
I tend to prefer notification with event enumerations, rather than
"labellingStart" and "labellingEnd" which does not scale.
Would you consider something along the lines of:
public interface RenderListener {
enum RenderEvent { START, UPDATE, END };
default void layer( Layer layer, RenderEvent event ); // covers
START, END
default void labeling( RenderingEvent event ); // covers START, END
default void composition( String name, RenderingEvent event ); //
covers START, UPDATE, END
default void rendering( RenderEvent event ); // covers START, END
}
>>>
>>> Hum... does not really improve scalability IMHO, cuts in half the number
>>> of methods, does not make them a order of magnitude
>>> smaller or a fixed number. And things like "RenderEvent" are normally
>>> objects carrying around the "change" information in listener
>>> interfaces having a single listen method, rather than being a
>>> classification... If we go for this design I'd call them EventType instead.
>>> Given that there are default implementations, an implementor does not
>>> really have to work though them, if interested in a single
>>> even, they can implement just that method.
>>>
>>> My reaction to this is... meh... do you feel strongly about it? Not the
>>> biggest deal to change the implementation, but honestly
>>> I liked the interface as proposed better :-D
>>>
>>> Cheers
>>> Andrea
>>>
>>> == GeoServer Professional Services from the experts! Visit
>>> http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf
>>> Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa
>>> (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549
>>> http://www.geo-solutions.it http://twitter.com/geosolutions_it
>>> --- *Con
>>> riferimento alla normativa sul trattamento dei dati personali (Reg. UE
>>> 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si
>>> precisa che ogni circostanza inerente alla presente email (il suo
>>> contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è
>>> riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il
>>> messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra
>>> operazione è illecita. Le sarei comunque grato se potesse darmene notizia.
>>> This email is intended only for the person or entity to which it is
>>> addressed and may contain information that is privileged, confidential or
>>> otherwise protected from disclosure. We remind that - as provided by
>>> European Regulation 2016/679 “GDPR” - copying, dissemination or use of this
>>> e-mail or the information herein by anyone other than the intended
>>> recipient is prohibited. If you have received this email by mistake, please
>>> notify us immediately by telephone or e-mail.*
>>>
>>
>
> --
>
> Regards, Andrea Aime == GeoServer Professional Services from the experts!
> Visit http://goo.gl/it488V for more information. == Ing. Andrea Aime
> @geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054
> Massarosa (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339
> 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it
> --- *Con
Re: [Geotools-devel] GSIP RenderListener Extension
Well ok, been a while, moving on and merging.
Cheers
Andrea
On Mon, Oct 28, 2019 at 12:13 PM Andrea Aime
wrote:
> Hi Jody,
> can you please cast a firm vote on this proposal?
> It's not clear if you are still demanding something to be changed, or not,
> and the proposal is stuck as a consequence
>
> Cheers
> Andrea
>
>
> On Thu, Oct 17, 2019 at 9:17 PM Jody Garnett
> wrote:
>
>> Thanks Andrea, I understand I am a bit late providing feedback.
>>
>> With respect to events, perhaps the interface stability aspect is
>> addressed by the ability to add default methods.
>>
>> And I agree the pattern is: RenderListener listens for RenderEvents which
>> may have a RenderEvent.Type (along with other state).
>>
>> I do not feel strongly, only want the stability aspect considered.
>> --
>> Jody Garnett
>>
>>
>> On Thu, 17 Oct 2019 at 10:10, Andrea Aime
>> wrote:
>>
>>> On Thu, Oct 17, 2019 at 12:30 AM Jody Garnett
>>> wrote:
>>>
Can I ask you to fill in the tasks section, want to be sure we have a
clear picture of the work involved.
You have events for the layer by layer notifications, and subsequent
labeling activities, is there any need to have events for the composition
steps (thinking of the rendering into multiple buffers and resulting alpha
blending effects).
>>>
>>> No need at the moment, but you can make your own GSIP for it if you do?
>>> :-)
>>> Generally speaking it's bad form to ask others for scope increase, but
>>> it's fundamental that we check
>>> the proposed design does not prevent those future improvements.
>>>
>>>
I tend to prefer notification with event enumerations, rather than
"labellingStart" and "labellingEnd" which does not scale.
Would you consider something along the lines of:
public interface RenderListener {
enum RenderEvent { START, UPDATE, END };
default void layer( Layer layer, RenderEvent event ); // covers
START, END
default void labeling( RenderingEvent event ); // covers START, END
default void composition( String name, RenderingEvent event ); //
covers START, UPDATE, END
default void rendering( RenderEvent event ); // covers START, END
}
>>>
>>> Hum... does not really improve scalability IMHO, cuts in half the number
>>> of methods, does not make them a order of magnitude
>>> smaller or a fixed number. And things like "RenderEvent" are normally
>>> objects carrying around the "change" information in listener
>>> interfaces having a single listen method, rather than being a
>>> classification... If we go for this design I'd call them EventType instead.
>>> Given that there are default implementations, an implementor does not
>>> really have to work though them, if interested in a single
>>> even, they can implement just that method.
>>>
>>> My reaction to this is... meh... do you feel strongly about it? Not the
>>> biggest deal to change the implementation, but honestly
>>> I liked the interface as proposed better :-D
>>>
>>> Cheers
>>> Andrea
>>>
>>> == GeoServer Professional Services from the experts! Visit
>>> http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf
>>> Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa
>>> (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549
>>> http://www.geo-solutions.it http://twitter.com/geosolutions_it
>>> --- *Con
>>> riferimento alla normativa sul trattamento dei dati personali (Reg. UE
>>> 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si
>>> precisa che ogni circostanza inerente alla presente email (il suo
>>> contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è
>>> riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il
>>> messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra
>>> operazione è illecita. Le sarei comunque grato se potesse darmene notizia.
>>> This email is intended only for the person or entity to which it is
>>> addressed and may contain information that is privileged, confidential or
>>> otherwise protected from disclosure. We remind that - as provided by
>>> European Regulation 2016/679 “GDPR” - copying, dissemination or use of this
>>> e-mail or the information herein by anyone other than the intended
>>> recipient is prohibited. If you have received this email by mistake, please
>>> notify us immediately by telephone or e-mail.*
>>>
>>
>
> --
>
> Regards, Andrea Aime == GeoServer Professional Services from the experts!
> Visit http://goo.gl/it488V for more information. == Ing. Andrea Aime
> @geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054
> Massarosa (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339
> 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it
> --- *Con riferimento
> alla normativa
Re: [Geotools-devel] GSIP RenderListener Extension
Hi Jody,
can you please cast a firm vote on this proposal?
It's not clear if you are still demanding something to be changed, or not,
and the proposal is stuck as a consequence
Cheers
Andrea
On Thu, Oct 17, 2019 at 9:17 PM Jody Garnett wrote:
> Thanks Andrea, I understand I am a bit late providing feedback.
>
> With respect to events, perhaps the interface stability aspect is
> addressed by the ability to add default methods.
>
> And I agree the pattern is: RenderListener listens for RenderEvents which
> may have a RenderEvent.Type (along with other state).
>
> I do not feel strongly, only want the stability aspect considered.
> --
> Jody Garnett
>
>
> On Thu, 17 Oct 2019 at 10:10, Andrea Aime
> wrote:
>
>> On Thu, Oct 17, 2019 at 12:30 AM Jody Garnett
>> wrote:
>>
>>> Can I ask you to fill in the tasks section, want to be sure we have a
>>> clear picture of the work involved.
>>>
>>> You have events for the layer by layer notifications, and subsequent
>>> labeling activities, is there any need to have events for the composition
>>> steps (thinking of the rendering into multiple buffers and resulting alpha
>>> blending effects).
>>>
>>
>> No need at the moment, but you can make your own GSIP for it if you do?
>> :-)
>> Generally speaking it's bad form to ask others for scope increase, but
>> it's fundamental that we check
>> the proposed design does not prevent those future improvements.
>>
>>
>>> I tend to prefer notification with event enumerations, rather than
>>> "labellingStart" and "labellingEnd" which does not scale.
>>>
>>> Would you consider something along the lines of:
>>>
>>> public interface RenderListener {
>>> enum RenderEvent { START, UPDATE, END };
>>> default void layer( Layer layer, RenderEvent event ); // covers
>>> START, END
>>> default void labeling( RenderingEvent event ); // covers START, END
>>> default void composition( String name, RenderingEvent event ); //
>>> covers START, UPDATE, END
>>> default void rendering( RenderEvent event ); // covers START, END
>>> }
>>>
>>
>> Hum... does not really improve scalability IMHO, cuts in half the number
>> of methods, does not make them a order of magnitude
>> smaller or a fixed number. And things like "RenderEvent" are normally
>> objects carrying around the "change" information in listener
>> interfaces having a single listen method, rather than being a
>> classification... If we go for this design I'd call them EventType instead.
>> Given that there are default implementations, an implementor does not
>> really have to work though them, if interested in a single
>> even, they can implement just that method.
>>
>> My reaction to this is... meh... do you feel strongly about it? Not the
>> biggest deal to change the implementation, but honestly
>> I liked the interface as proposed better :-D
>>
>> Cheers
>> Andrea
>>
>> == GeoServer Professional Services from the experts! Visit
>> http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf
>> Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa
>> (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549
>> http://www.geo-solutions.it http://twitter.com/geosolutions_it
>> --- *Con riferimento
>> alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 -
>> Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni
>> circostanza inerente alla presente email (il suo contenuto, gli eventuali
>> allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i
>> destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per
>> errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le
>> sarei comunque grato se potesse darmene notizia. This email is intended
>> only for the person or entity to which it is addressed and may contain
>> information that is privileged, confidential or otherwise protected from
>> disclosure. We remind that - as provided by European Regulation 2016/679
>> “GDPR” - copying, dissemination or use of this e-mail or the information
>> herein by anyone other than the intended recipient is prohibited. If you
>> have received this email by mistake, please notify us immediately by
>> telephone or e-mail.*
>>
>
--
Regards, Andrea Aime == GeoServer Professional Services from the experts!
Visit http://goo.gl/it488V for more information. == Ing. Andrea Aime
@geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054
Massarosa (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339
8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it
--- *Con riferimento
alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 -
Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni
circostanza inerente alla presente email (il suo contenuto, gli eventuali
allegati, etc.) è un dato la cui
Re: [Geotools-devel] GSIP RenderListener Extension
+0 Regards, Simone Giannecchini == GeoServer Professional Services from the experts! Visit http://bit.ly/gs-services for more information. == Ing. Simone Giannecchini @simogeo Founder/Director GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 333 8128928 http://www.geo-solutions.it http://twitter.com/geosolutions_it --- Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni circostanza inerente alla presente email (il suo contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato se potesse darmene notizia. This email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. We remind that - as provided by European Regulation 2016/679 “GDPR” - copying, dissemination or use of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this email by mistake, please notify us immediately by telephone or e-mail. On Thu, Oct 10, 2019 at 11:22 AM marco.volp...@geo-solutions.it wrote: > > Dear all, > > I would like to submit the following Geotools improvement proposal: > > https://github.com/geotools/geotools/wiki/RenderListener-Extension > > > I take also the opportunity to introduce myself: > I'm Marco Volpini from Italy and I start recently working as a java developer > at Geo-solutions. > > Best regards, > > Marco Volpini > ___ > GeoTools-Devel mailing list > GeoTools-Devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geotools-devel ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] GSIP RenderListener Extension
Thanks Andrea, I understand I am a bit late providing feedback.
With respect to events, perhaps the interface stability aspect is addressed
by the ability to add default methods.
And I agree the pattern is: RenderListener listens for RenderEvents which
may have a RenderEvent.Type (along with other state).
I do not feel strongly, only want the stability aspect considered.
--
Jody Garnett
On Thu, 17 Oct 2019 at 10:10, Andrea Aime
wrote:
> On Thu, Oct 17, 2019 at 12:30 AM Jody Garnett
> wrote:
>
>> Can I ask you to fill in the tasks section, want to be sure we have a
>> clear picture of the work involved.
>>
>> You have events for the layer by layer notifications, and subsequent
>> labeling activities, is there any need to have events for the composition
>> steps (thinking of the rendering into multiple buffers and resulting alpha
>> blending effects).
>>
>
> No need at the moment, but you can make your own GSIP for it if you do? :-)
> Generally speaking it's bad form to ask others for scope increase, but
> it's fundamental that we check
> the proposed design does not prevent those future improvements.
>
>
>> I tend to prefer notification with event enumerations, rather than
>> "labellingStart" and "labellingEnd" which does not scale.
>>
>> Would you consider something along the lines of:
>>
>> public interface RenderListener {
>> enum RenderEvent { START, UPDATE, END };
>> default void layer( Layer layer, RenderEvent event ); // covers
>> START, END
>> default void labeling( RenderingEvent event ); // covers START, END
>> default void composition( String name, RenderingEvent event ); //
>> covers START, UPDATE, END
>> default void rendering( RenderEvent event ); // covers START, END
>> }
>>
>
> Hum... does not really improve scalability IMHO, cuts in half the number
> of methods, does not make them a order of magnitude
> smaller or a fixed number. And things like "RenderEvent" are normally
> objects carrying around the "change" information in listener
> interfaces having a single listen method, rather than being a
> classification... If we go for this design I'd call them EventType instead.
> Given that there are default implementations, an implementor does not
> really have to work though them, if interested in a single
> even, they can implement just that method.
>
> My reaction to this is... meh... do you feel strongly about it? Not the
> biggest deal to change the implementation, but honestly
> I liked the interface as proposed better :-D
>
> Cheers
> Andrea
>
> == GeoServer Professional Services from the experts! Visit
> http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf
> Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa
> (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549
> http://www.geo-solutions.it http://twitter.com/geosolutions_it
> --- *Con riferimento
> alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 -
> Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni
> circostanza inerente alla presente email (il suo contenuto, gli eventuali
> allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i
> destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per
> errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le
> sarei comunque grato se potesse darmene notizia. This email is intended
> only for the person or entity to which it is addressed and may contain
> information that is privileged, confidential or otherwise protected from
> disclosure. We remind that - as provided by European Regulation 2016/679
> “GDPR” - copying, dissemination or use of this e-mail or the information
> herein by anyone other than the intended recipient is prohibited. If you
> have received this email by mistake, please notify us immediately by
> telephone or e-mail.*
>
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] GSIP RenderListener Extension
On Fri, Oct 11, 2019 at 8:53 PM Gabriel Roldan wrote: > Indeed it is not, I was regretting already while typing. It's just that > I've seen that typo and FeatureCollection.accepts(visitor) instead of > "accept()" far too long and felt like squeezing it in. But you're totally > right. > Eh, fixing typos in interfaces it's not that easy, because you deprecate the old method, add a new one, and break the interface in the process... at that point better to have a clean break anyways and just change the name of the method... you could do a proposal and just update master? Or regardless, propose what you want to do and act on it, without the constraints of a backport you have hands more free. Cheers Andrea == GeoServer Professional Services from the experts! Visit http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it --- *Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni circostanza inerente alla presente email (il suo contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato se potesse darmene notizia. This email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. We remind that - as provided by European Regulation 2016/679 “GDPR” - copying, dissemination or use of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this email by mistake, please notify us immediately by telephone or e-mail.* ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] GSIP RenderListener Extension
On Thu, Oct 17, 2019 at 12:30 AM Jody Garnett
wrote:
> Can I ask you to fill in the tasks section, want to be sure we have a
> clear picture of the work involved.
>
> You have events for the layer by layer notifications, and subsequent
> labeling activities, is there any need to have events for the composition
> steps (thinking of the rendering into multiple buffers and resulting alpha
> blending effects).
>
No need at the moment, but you can make your own GSIP for it if you do? :-)
Generally speaking it's bad form to ask others for scope increase, but it's
fundamental that we check
the proposed design does not prevent those future improvements.
> I tend to prefer notification with event enumerations, rather than
> "labellingStart" and "labellingEnd" which does not scale.
>
> Would you consider something along the lines of:
>
> public interface RenderListener {
> enum RenderEvent { START, UPDATE, END };
> default void layer( Layer layer, RenderEvent event ); // covers
> START, END
> default void labeling( RenderingEvent event ); // covers START, END
> default void composition( String name, RenderingEvent event ); //
> covers START, UPDATE, END
> default void rendering( RenderEvent event ); // covers START, END
> }
>
Hum... does not really improve scalability IMHO, cuts in half the number of
methods, does not make them a order of magnitude
smaller or a fixed number. And things like "RenderEvent" are normally
objects carrying around the "change" information in listener
interfaces having a single listen method, rather than being a
classification... If we go for this design I'd call them EventType instead.
Given that there are default implementations, an implementor does not
really have to work though them, if interested in a single
even, they can implement just that method.
My reaction to this is... meh... do you feel strongly about it? Not the
biggest deal to change the implementation, but honestly
I liked the interface as proposed better :-D
Cheers
Andrea
== GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf
Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa
(LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549
http://www.geo-solutions.it http://twitter.com/geosolutions_it
--- *Con riferimento
alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 -
Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni
circostanza inerente alla presente email (il suo contenuto, gli eventuali
allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i
destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per
errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le
sarei comunque grato se potesse darmene notizia. This email is intended
only for the person or entity to which it is addressed and may contain
information that is privileged, confidential or otherwise protected from
disclosure. We remind that - as provided by European Regulation 2016/679
“GDPR” - copying, dissemination or use of this e-mail or the information
herein by anyone other than the intended recipient is prohibited. If you
have received this email by mistake, please notify us immediately by
telephone or e-mail.*
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] GSIP RenderListener Extension
> Totally get it, thanks. As a matter of fact, I've used multiple > StreamingRenderer's with a shared thread pool for a desktop JavaFX app with > great success. Yes, you gotta control how many of them run in parallel > nonetheless. One pain point is labeling though, it'd be awesome if multiple > renderes could share a single LabelCache and you can progressively render > the labels as they get moved around to a top level pane. Next year :) > They can, that is the approach we use for uDig. > > ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] GSIP RenderListener Extension
On Mon, 14 Oct 2019 at 05:16, Andrea Aime wrote: > On Fri, Oct 11, 2019 at 8:53 PM Gabriel Roldan > wrote: > >> >>> Good point, they should be enclosed, meaning that the layer end needs to >>> be issued from the rendering thread. It can be done, matter of >>> implementation, something to be checked in the PR. >>> >> > Checked, it's indeed happening in the rendering thread, thus it should be > enclosing feature events: > > https://github.com/geotools/geotools/pull/2606/files#diff-0c2a1d63c591affa14372de83ef72814R3876 > > >> Speaking of MT, the rendering is only lightly multi-threaded, there are >>> two fixed threads, one reading the data, preprocessing it, preparing the >>> styles to be compatible with Java 2D, >>> and one actually rendering the geometries with the desired styles, >>> connected by a blocking queue. It was done like this to compensate for the >>> Ductus rasterizer >>> scalability issues, needs to be evaluated if it's still beneficial once >>> we move away from Java 8 (Oracle Java 8 is the last implementation based on >>> it, from Java 9 >>> onwards Marlin is built-in into the JDK). >>> >> Thanks for the clarification. So, SimpleFeatureRenderer's setThreadPool() >> says "Sets a thread pool to be used in parallel rendering". I guess its >> primary purpose is then not doing parallel rendering itself, but being >> given the thread pool it can borrow those two threads from, and allowing to >> set a limit on parallel rendering among multiple renderer instances (if the >> pool has an upper limit)? >> > > It's even simpler than that. The primary thread doing the reads and > semplification is the one you call StreamingRenderer.paint on, only the > java2d painting thread is borrowed from the pool. "Rendering" is the > activity that the StreamingRenderer does, it encompasses everything > from reading the data, reprojecting, evaluating symbolizer, and painting. > The pool provides a single thread that makes the rendering activity > parallel. > > I'm guessing you're thinking about true layer parallel rendering... I > think it would be a good idea for a desktop system, with all the resources > of a computer at the disposal of a single user, but it may prove very > problematic for a server setup under load (if light load, we're basically > going back to the single user case). Think many concurrent requests, > against a multi-layer map (e.g., seeding a OSM like map), each > one allocating separate rendering surfaces for each layer, maybe more than > one per layer to handle multiple feature type styles... the > amount of resource consumption would make the system thrash quite > quickly... Posing limits so that one ensures no more than X threads > rendering globally, no more than M megabytes of rendering surfaces > allocated, would be possible but definitely not trivial... and it would > have to be "global", the rendering surfaces keep on existing past the end > of the paint call, up until the image is fully encoded in output > in server side apps, so the system would have to allow external control. > > Totally get it, thanks. As a matter of fact, I've used multiple StreamingRenderer's with a shared thread pool for a desktop JavaFX app with great success. Yes, you gotta control how many of them run in parallel nonetheless. One pain point is labeling though, it'd be awesome if multiple renderes could share a single LabelCache and you can progressively render the labels as they get moved around to a top level pane. Next year :) > A fun project for someone with a lot of spare time (both to design it, and > then to follow it up for a year or two when it starts > actually rolling in production and the concurrency/load control issues > start popping up) :-D > The dividends would be interesting though, IMHO the ideal scalability > curve is not "linear" as many say, it's flat (full speed no > matter how many threads hit the server, using all the cores for a single > request on light load, and distributing them across > requests as the load goes up). > Screams for a reactive design IMHO. Hope I can find the time to experiment on it. Cheers and thanks for the insightful replies. Gabrie. > > Cheers > Andrea > > == > > GeoServer Professional Services from the experts! Visit > http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf > Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa > (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 > http://www.geo-solutions.it http://twitter.com/geosolutions_it > --- *Con riferimento > alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - > Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni > circostanza inerente alla presente email (il suo contenuto, gli eventuali > allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i > destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per > errore, è
Re: [Geotools-devel] GSIP RenderListener Extension
Can I ask you to fill in the tasks section, want to be sure we have a clear
picture of the work involved.
You have events for the layer by layer notifications, and subsequent
labeling activities, is there any need to have events for the composition
steps (thinking of the rendering into multiple buffers and resulting alpha
blending effects).
I tend to prefer notification with event enumerations, rather than
"labellingStart" and "labellingEnd" which does not scale.
Would you consider something along the lines of:
public interface RenderListener {
enum RenderEvent { START, UPDATE, END };
default void layer( Layer layer, RenderEvent event ); // covers START,
END
default void labeling( RenderingEvent event ); // covers START, END
default void composition( String name, RenderingEvent event ); //
covers START, UPDATE, END
default void rendering( RenderEvent event ); // covers START, END
}
--
Jody Garnett
On Thu, 10 Oct 2019 at 02:22, marco.volp...@geo-solutions.it <
marco.volp...@geo-solutions.it> wrote:
> Dear all,
>
> I would like to submit the following Geotools improvement proposal:
>
> https://github.com/geotools/geotools/wiki/RenderListener-Extension
>
>
> I take also the opportunity to introduce myself:
> I'm Marco Volpini from Italy and I start recently working as a java
> developer at Geo-solutions.
>
> Best regards,
>
> Marco Volpini
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] GSIP RenderListener Extension
Seems both useful, and unlikely to cause any problems. +1. Cheers, Torben On Thu, Oct 10, 2019 at 2:22 AM marco.volp...@geo-solutions.it < marco.volp...@geo-solutions.it> wrote: > Dear all, > > I would like to submit the following Geotools improvement proposal: > > https://github.com/geotools/geotools/wiki/RenderListener-Extension > > > I take also the opportunity to introduce myself: > I'm Marco Volpini from Italy and I start recently working as a java > developer at Geo-solutions. > > Best regards, > > Marco Volpini > ___ > GeoTools-Devel mailing list > GeoTools-Devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geotools-devel > -- Torben Barsballe Software Engineer Planet Federal tbarsba...@federal.planet.com ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] GSIP RenderListener Extension
On Fri, Oct 11, 2019 at 8:53 PM Gabriel Roldan wrote: > >> Good point, they should be enclosed, meaning that the layer end needs to >> be issued from the rendering thread. It can be done, matter of >> implementation, something to be checked in the PR. >> > Checked, it's indeed happening in the rendering thread, thus it should be enclosing feature events: https://github.com/geotools/geotools/pull/2606/files#diff-0c2a1d63c591affa14372de83ef72814R3876 > Speaking of MT, the rendering is only lightly multi-threaded, there are >> two fixed threads, one reading the data, preprocessing it, preparing the >> styles to be compatible with Java 2D, >> and one actually rendering the geometries with the desired styles, >> connected by a blocking queue. It was done like this to compensate for the >> Ductus rasterizer >> scalability issues, needs to be evaluated if it's still beneficial once >> we move away from Java 8 (Oracle Java 8 is the last implementation based on >> it, from Java 9 >> onwards Marlin is built-in into the JDK). >> > Thanks for the clarification. So, SimpleFeatureRenderer's setThreadPool() > says "Sets a thread pool to be used in parallel rendering". I guess its > primary purpose is then not doing parallel rendering itself, but being > given the thread pool it can borrow those two threads from, and allowing to > set a limit on parallel rendering among multiple renderer instances (if the > pool has an upper limit)? > It's even simpler than that. The primary thread doing the reads and semplification is the one you call StreamingRenderer.paint on, only the java2d painting thread is borrowed from the pool. "Rendering" is the activity that the StreamingRenderer does, it encompasses everything from reading the data, reprojecting, evaluating symbolizer, and painting. The pool provides a single thread that makes the rendering activity parallel. I'm guessing you're thinking about true layer parallel rendering... I think it would be a good idea for a desktop system, with all the resources of a computer at the disposal of a single user, but it may prove very problematic for a server setup under load (if light load, we're basically going back to the single user case). Think many concurrent requests, against a multi-layer map (e.g., seeding a OSM like map), each one allocating separate rendering surfaces for each layer, maybe more than one per layer to handle multiple feature type styles... the amount of resource consumption would make the system thrash quite quickly... Posing limits so that one ensures no more than X threads rendering globally, no more than M megabytes of rendering surfaces allocated, would be possible but definitely not trivial... and it would have to be "global", the rendering surfaces keep on existing past the end of the paint call, up until the image is fully encoded in output in server side apps, so the system would have to allow external control. A fun project for someone with a lot of spare time (both to design it, and then to follow it up for a year or two when it starts actually rolling in production and the concurrency/load control issues start popping up) :-D The dividends would be interesting though, IMHO the ideal scalability curve is not "linear" as many say, it's flat (full speed no matter how many threads hit the server, using all the cores for a single request on light load, and distributing them across requests as the load goes up). Cheers Andrea == GeoServer Professional Services from the experts! Visit http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it --- *Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni circostanza inerente alla presente email (il suo contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato se potesse darmene notizia. This email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. We remind that - as provided by European Regulation 2016/679 “GDPR” - copying, dissemination or use of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this email by mistake, please notify us immediately by telephone or e-mail.* ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] GSIP RenderListener Extension
On Fri, 11 Oct 2019 at 04:31, Andrea Aime wrote: > On Thu, Oct 10, 2019 at 11:36 PM Gabriel Roldan > wrote: > >> Maybe take the opportunity to fix the typo in "featureRenderer()" (it >> should be featureRendered(), shouldn't it?) and for the sake of consistency >> add feartureStart() and featureEnd(). So maybe >> deprecating featureRenderer() and make featureStart() a default that calls >> the deprecated one until it's removed? >> > > Hmm... this GSIP needs to be backportable, and the change you're > suggesting is not necessary to the task at hand. > Indeed it is not, I was regretting already while typing. It's just that I've seen that typo and FeatureCollection.accepts(visitor) instead of "accept()" far too long and felt like squeezing it in. But you're totally right. > Start/end of feature seems a bit too granular, but it's just a feeling, if > you want to go for it, > I'd suggest you make a separate proposal targeting only master, and a PR > to follow suite. A reminder, now deprecating an API implies migrating all > the calling points in GT/GWC/GS to the non deprecated > replacement, or the build will break (it's one of the checks in the QA > profile). > > >> Another question: do you expect feature events to be enclosed by >> layerStart/End events? I'm not sure how that'll play with multithreading, I >> think StreamingRenderer will do parallel rendering to separate backbuffers >> in some cases? >> > > Good point, they should be enclosed, meaning that the layer end needs to > be issued from the rendering thread. It can be done, matter of > implementation, something to be checked in the PR. > There is a case where that cannot be guaranteed though... when using > cross-layer z-ordering: > https://docs.geoserver.org/stable/en/user/styling/sld/extensions/z-order/syntax.html#z-ordering-across-layers > Not much we can do about it I'm afraid, but the javadocs and related > documentation should point that clearly at the very least. > > Speaking of MT, the rendering is only lightly multi-threaded, there are > two fixed threads, one reading the data, preprocessing it, preparing the > styles to be compatible with Java 2D, > and one actually rendering the geometries with the desired styles, > connected by a blocking queue. It was done like this to compensate for the > Ductus rasterizer > scalability issues, needs to be evaluated if it's still beneficial once we > move away from Java 8 (Oracle Java 8 is the last implementation based on > it, from Java 9 > onwards Marlin is built-in into the JDK). > Thanks for the clarification. So, SimpleFeatureRenderer's setThreadPool() says "Sets a thread pool to be used in parallel rendering". I guess its primary purpose is then not doing parallel rendering itself, but being given the thread pool it can borrow those two threads from, and allowing to set a limit on parallel rendering among multiple renderer instances (if the pool has an upper limit)? Cheers, Gabriel > > The backbuffers are used to handle multiple feature type styles applied to > the same layer, that does not cause multiple threads to be issued. > > Cheers > Andrea > > == > > GeoServer Professional Services from the experts! Visit > http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf > Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa > (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 > http://www.geo-solutions.it http://twitter.com/geosolutions_it > --- *Con riferimento > alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - > Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni > circostanza inerente alla presente email (il suo contenuto, gli eventuali > allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i > destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per > errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le > sarei comunque grato se potesse darmene notizia. This email is intended > only for the person or entity to which it is addressed and may contain > information that is privileged, confidential or otherwise protected from > disclosure. We remind that - as provided by European Regulation 2016/679 > “GDPR” - copying, dissemination or use of this e-mail or the information > herein by anyone other than the intended recipient is prohibited. If you > have received this email by mistake, please notify us immediately by > telephone or e-mail.* > -- Gabriel Roldán ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] GSIP RenderListener Extension
On Thu, Oct 10, 2019 at 11:36 PM Gabriel Roldan wrote: > Maybe take the opportunity to fix the typo in "featureRenderer()" (it > should be featureRendered(), shouldn't it?) and for the sake of consistency > add feartureStart() and featureEnd(). So maybe > deprecating featureRenderer() and make featureStart() a default that calls > the deprecated one until it's removed? > Hmm... this GSIP needs to be backportable, and the change you're suggesting is not necessary to the task at hand. Start/end of feature seems a bit too granular, but it's just a feeling, if you want to go for it, I'd suggest you make a separate proposal targeting only master, and a PR to follow suite. A reminder, now deprecating an API implies migrating all the calling points in GT/GWC/GS to the non deprecated replacement, or the build will break (it's one of the checks in the QA profile). > Another question: do you expect feature events to be enclosed by > layerStart/End events? I'm not sure how that'll play with multithreading, I > think StreamingRenderer will do parallel rendering to separate backbuffers > in some cases? > Good point, they should be enclosed, meaning that the layer end needs to be issued from the rendering thread. It can be done, matter of implementation, something to be checked in the PR. There is a case where that cannot be guaranteed though... when using cross-layer z-ordering: https://docs.geoserver.org/stable/en/user/styling/sld/extensions/z-order/syntax.html#z-ordering-across-layers Not much we can do about it I'm afraid, but the javadocs and related documentation should point that clearly at the very least. Speaking of MT, the rendering is only lightly multi-threaded, there are two fixed threads, one reading the data, preprocessing it, preparing the styles to be compatible with Java 2D, and one actually rendering the geometries with the desired styles, connected by a blocking queue. It was done like this to compensate for the Ductus rasterizer scalability issues, needs to be evaluated if it's still beneficial once we move away from Java 8 (Oracle Java 8 is the last implementation based on it, from Java 9 onwards Marlin is built-in into the JDK). The backbuffers are used to handle multiple feature type styles applied to the same layer, that does not cause multiple threads to be issued. Cheers Andrea == GeoServer Professional Services from the experts! Visit http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it --- *Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni circostanza inerente alla presente email (il suo contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato se potesse darmene notizia. This email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. We remind that - as provided by European Regulation 2016/679 “GDPR” - copying, dissemination or use of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this email by mistake, please notify us immediately by telephone or e-mail.* ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] GSIP RenderListener Extension
Maybe take the opportunity to fix the typo in "featureRenderer()" (it should be featureRendered(), shouldn't it?) and for the sake of consistency add feartureStart() and featureEnd(). So maybe deprecating featureRenderer() and make featureStart() a default that calls the deprecated one until it's removed? Another question: do you expect feature events to be enclosed by layerStart/End events? I'm not sure how that'll play with multithreading, I think StreamingRenderer will do parallel rendering to separate backbuffers in some cases? Andrea can you confirm? On Thu, 10 Oct 2019 at 06:22, marco.volp...@geo-solutions.it < marco.volp...@geo-solutions.it> wrote: > Dear all, > > I would like to submit the following Geotools improvement proposal: > > https://github.com/geotools/geotools/wiki/RenderListener-Extension > > > I take also the opportunity to introduce myself: > I'm Marco Volpini from Italy and I start recently working as a java > developer at Geo-solutions. > > Best regards, > > Marco Volpini > ___ > GeoTools-Devel mailing list > GeoTools-Devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geotools-devel > -- Gabriel Roldán ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] GSIP RenderListener Extension
Looks good to me +1 :) On Thu, 2019-10-10 at 11:04 +0100, Ian Turton wrote: > Seems uncontentious to me +1 > > Ian > > On Thu, 10 Oct 2019 at 10:22, marco.volp...@geo-solutions.it > olp...@geo-solutions.it> wrote: > > Dear all, > > > > I would like to submit the following Geotools improvement proposal: > > > > https://github.com/geotools/geotools/wiki/RenderListener-Extension > > > > > > > > I take also the opportunity to introduce myself: > > I'm Marco Volpini from Italy and I start recently working as a java > > developer at Geo-solutions. > > > > Best regards, > > > > Marco Volpini > > ___ > > GeoTools-Devel mailing list > > GeoTools-Devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/geotools-devel > > > > -- > Ian Turton > ___ > GeoTools-Devel mailing list > GeoTools-Devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geotools-devel -- Regards, Nuno Oliveira == GeoServer Professional Services from the experts! Visit http://goo.gl/it488V for more information. == Nuno Miguel Carvalho Oliveira @nmcoliveira Software Engineer GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 1660272 http://www.geo-solutions.it http://twitter.com/geosolutions_it --- Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni circostanza inerente alla presente email (il suo contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato se potesse darmene notizia. This email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. We remind that - as provided by European Regulation 2016/679 “GDPR” - copying, dissemination or use of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this email by mistake, please notify us immediately by telephone or e-mail. ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] GSIP RenderListener Extension
Pretty simple extension, no objection. +0 Cheers Andrea On Thu, Oct 10, 2019 at 11:23 AM marco.volp...@geo-solutions.it < marco.volp...@geo-solutions.it> wrote: > Dear all, > > I would like to submit the following Geotools improvement proposal: > > https://github.com/geotools/geotools/wiki/RenderListener-Extension > > > I take also the opportunity to introduce myself: > I'm Marco Volpini from Italy and I start recently working as a java > developer at Geo-solutions. > > Best regards, > > Marco Volpini > ___ > GeoTools-Devel mailing list > GeoTools-Devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geotools-devel > -- Regards, Andrea Aime == GeoServer Professional Services from the experts! Visit http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it --- *Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni circostanza inerente alla presente email (il suo contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato se potesse darmene notizia. This email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. We remind that - as provided by European Regulation 2016/679 “GDPR” - copying, dissemination or use of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this email by mistake, please notify us immediately by telephone or e-mail.* ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] GSIP RenderListener Extension
Seems uncontentious to me +1 Ian On Thu, 10 Oct 2019 at 10:22, marco.volp...@geo-solutions.it < marco.volp...@geo-solutions.it> wrote: > Dear all, > > I would like to submit the following Geotools improvement proposal: > > https://github.com/geotools/geotools/wiki/RenderListener-Extension > > > I take also the opportunity to introduce myself: > I'm Marco Volpini from Italy and I start recently working as a java > developer at Geo-solutions. > > Best regards, > > Marco Volpini > ___ > GeoTools-Devel mailing list > GeoTools-Devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geotools-devel > -- Ian Turton ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] GSIP RenderListener Extension
Dear all, I would like to submit the following Geotools improvement proposal: https://github.com/geotools/geotools/wiki/RenderListener-Extension I take also the opportunity to introduce myself: I'm Marco Volpini from Italy and I start recently working as a java developer at Geo-solutions. Best regards, Marco Volpini ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
