[Geotools-devel] Issue with mosaic of indexed png's

[Justin Deoliveira]

Hi folks,

I am working on upgrading an application from a much older version of
geotools (15.1) to the latest stable. I've hit a roadblock regarding image
mosaics consisting of indexed PNG files that I think I have narrowed down
to this change:

https://github.com/geotools/geotools/commit/585b021d15df7d132bd6963d7fb78338e814b625


What appears to be happening is that the call to getRawColorModel is
advancing the underlying image stream. Later on in the process that same
stream stream is "seeked" back to the zero position in preparation for the
actual read operation, and that throws an exception:

java.lang.IllegalArgumentException: pos < flushedPos!
at
it.geosolutions.imageio.stream.input.FileImageInputStreamExtImpl.seek(FileImageInputStreamExtImpl.java:285)
at org.geotools.coverage.grid.io.imageio.ReadType$2.read(ReadType.java:131)
at
org.geotools.gce.imagemosaic.GranuleDescriptor.loadRaster(GranuleDescriptor.java:928)


I am guessing it's perhaps some limitation with the PNG format (which I
know is about the worst possible format to be rendering imagery from 樂 ).

So I guess my first question is would this be considered a bug? Or more or
a limitation with this particular file format? I am guessing a bug since
prior to this change this scenario works.

Assuming that bug is the consensus I'd be happy to attempt a patch but
probably need some guidance on how to proceed. My initial thought for a
"quick fix" was that perhaps we could add a flag to the mosaic
configuration or a read parameter that specified explicitly that the images
in the mosaic have an IndexColorModel so that we can forgo the check and
hence not pre-advance the image stream?

Thoughts appreciated.

Thanks!

-Justin
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Request for feedback/guidance: moving TimeParser from GeoServer to GeoTools

[Daniele Romagnoli]

Hi Jody,
I sent the "motion" email and I have already get some votes on that.

Any additional feedback on my question above, about the "donating code"
letter?
Kind regards,
Daniele


On Fri, Oct 25, 2019 at 10:20 AM Daniele Romagnoli <
daniele.romagn...@geo-solutions.it> wrote:

> Hi Jody,
> thanks for the feedback.
> I'm preparing the "motion" email.
>
> Not 100% sure about the "donating code" formal correspondence to be
> used/prepared for that class with several contributors.
>
> https://github.com/geoserver/geoserver/blob/master/src/ows/src/main/java/org/geoserver/ows/kvp/TimeParser.java
>
>
> Are you going to setup a letter of support to grant permission to
> redistribute that GS code in GT, once the voting motion get a "good to go"?
> Please, let me know if I need to do anything else.
>
> Cheers,
> Daniele
>
>
>
> On Wed, Oct 23, 2019 at 9:42 PM Jody Garnett 
> wrote:
>
>> Probably the email list here, make a motion and ask PSC members to
>> respond?
>>
>> We should be able to see a geotools example of donating code to JTS (here
>> it is under formal correspondence
>> ).
>> --
>> Jody Garnett
>>
>>
>> On Wed, 23 Oct 2019 at 09:47, Daniele Romagnoli <
>> daniele.romagn...@geo-solutions.it> wrote:
>>
>>>
>>>
>>> On Tue, Oct 22, 2019 at 3:32 PM Andrea Aime <
>>> andrea.a...@geo-solutions.it> wrote:
>>>
 On Tue, Oct 22, 2019 at 3:22 PM Ian Turton  wrote:

> It is possible (i.e. we've done similar before) - there is a licencing
> issue as the code needs to go from GPL to LGPL but as OSgeo "owns" both
> code bases I don't think it is an issue, I can't recall how we dealt with
> the issue last time though.
>

 Agreed, believe a PSC vote is required (unless one is the author of the
 code in question, which is not the case).

>>>
>>> Cool. Will that voting occur on the related JIRA (once created)?
>>>
>>> Cheers,
>>> Daniele
>>>
>>>


>
>
>> If affirmative, what would be the right procedure to do that?
>> Would be JIRAs + PRs (including a deprecation of current TimeParser)
>> enough for that?
>>
>>
> Probably a GISP or at least a pair of Jiras. Andrea will know best!
> Not sure if GeoServer would need to deprecate the TimeParser, though
> GeoTools would certainly want to.
>

 Tickets only, deprecate class in GeoServer, make it extend the Geotools
 one, replace all calling places in GeoServer with the GeoTools one (aka
 search imports) to
 avoid QA deprecated calls build failing

>>>
 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,
>>> Daniele Romagnoli
>>> ==
>>> GeoServer Professional Services from the experts! Visit
>>> http://goo.gl/it488V for more information.
>>> ==
>>>
>>> Ing. Daniele Romagnoli
>>> Senior 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 

Re: [Geotools-devel] GSIP RenderListener Extension

[Andrea Aime]

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] GeoTools / GeoServer PMC meeting - 2019-10-29

[Ian Turton]

Sorry I missed the meeting, I was so focused on remembering that DST
finished I completely forgot it was Tuesday and spent most of the day
thinking it was Monday :-(

17:00 UTC works best for me.

Ian

On Tue, 29 Oct 2019 at 20:06, Torben Barsballe 
wrote:

> Pretty quiet meeting today.
>
> One discussion point that we wanted to bring to the mailing lists was
> meeting time - some of us have daylight savings time ending next week,
> meaning the next meeting will be 1 hour earlier.
> We'd like to suggest pushing the meeting forward 30 minutes or an hour (
> 17:00
> 
> UTC or 17:30
> 
> UTC). Do either of these times work for everyone else? Are they problematic
> for anyone?
>
> Cheers,
> Torben
>
> On Tue, Oct 29, 2019 at 10:10 AM Torben Barsballe <
> torbenbarsba...@gmail.com> wrote:
>
>> Attending
>>
>> Torben Barsballe
>>
>> Kevin Smith
>> Actions from Last Meeting
>>
>>-
>>
>>Clean up committers list on Github and SF (Andrea And Jody) [WIP]
>>-
>>
>>Send mail to geoserver-devel asking committers to reply and confirm
>>they are subscribed to users, devel and build list [DONE]
>>
>> Agenda
>>
>>-
>>
>>Meeting Time - DST
>>-
>>
>>Build Server
>>
>> Actions
>>
>>-
>>
>>Torben: Move Java 11 builds to master node on Jenkins
>>
>> Meeting Time
>>
>> Some of us have Daylight Saving Time ending next week, which will push
>> the meeting 1hr earlier for us
>>
>>-
>>
>>Kevin would prefer moving to 17:30 UTC but 16:30 is still doable
>>- Torben is fine with 17:00 UTC, but either of the above times also
>>works
>>
>>
>> Moving discussion to mailing lists...
>>
>> Build Server
>>
>> Java 11 builds work fine on master node
>>
>> Actions: Move Java 11 builds to master node
>>
>> ___
> 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

Re: [Geotools-devel] new vendor option for TextSymbolizer to control label size durin rendering

[Nikolaos Pringouris]

If there is no other comment/suggestion I would go for* fontShrinkSizeMin.*
I think it is a good compromise.

Στις Δευ, 28 Οκτ 2019 στις 6:54 μ.μ., ο/η Ian Turton 
έγραψε:

>
>
> On Mon, 28 Oct 2019 at 16:11, Andrea Aime 
> wrote:
>
>> On Mon, Oct 28, 2019 at 4:33 PM Nikolaos Pringouris 
>> wrote:
>>
>>> Actually in my local implementation I have used the following:
>>> 5 in order
>>> to be evident that it relates to the Font size of the text Symbolizer.
>>>
>>
>> I don't mind this name, works for me, native english speakers please tell
>> us if it's ok.
>>
>>
> I think I might prefer fontShrinkSizeMin - to show it is the minimum size
> but I'm not too bothered by fontShrinkSize
>
> Ian
>
>
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel