Re: [Geotools-devel] Copyright header policy

[Justin Deoliveira]

While my personal preference is the same as yours Ben (going with no date
in the header) I think this is the best middle ground. And anything that
moves us away from the constant burden on committers and contributors to
update the headers when it has no tangible benefit is a win.

So what is still unclear to me is what changes (if any) will be required if
any to the existing headers. Someone correct me if I am wrong but if we’re
going with just file creation date then we should be good? And the only
remaining work will be to document the practice?

On Fri, May 20, 2016 at 7:06 PM Ben Caradoc-Davies  wrote:

> Jody,
>
> I am happy to proceed with file creation/contribution date despite my
> small reservations. I think that file creation/contribution date is the
> option that has consensus at this time; it will solve the date
> maintenance overhead problem that is the reason for this change.
>
> I move that you ask OSGeo to obtain legal advice on this matter. I see
> this as a low priority but I think it would be nice to get some advice
> for long-term guidance.
>
> And thanks to everyone for their contributions to this thread. It has
> clarified my views on copyright headers and and changed my views on
> @author tags.
>
> Kind regards,
> Ben.
>
> On 21/05/16 12:06, Jody Garnett wrote:
> > OSGeo is able to obtain legal advice, as PMC representative I can make
> that
> > request on behalf of our project. As one of the early projects in OSGeo
> > other projects will be following our lead.
> >
> > To close this one out I would be content to update our policy to be file
> > creation/contribution date - and if you wish to make the motion Ben we
> can
> > formally ask OSGeo to obtain legal advice (they may do so directly or via
> > reaching out to another foundation with legal staff).
> > --
> > Jody Garnett
> >
> > On 20 May 2016 at 13:50, Ben Caradoc-Davies  wrote:
> >
> >> Many stackexchange comments on common law copyright and registration
> >> relate to the US prior its accession to the Berne convention (1989).
> Please
> >> see later comments and this:
> >> https://www.law.cornell.edu/wex/copyright
> >>
> >> Furthermore, and I am not a lawyer, can you copyright an individual
> source
> >> code file? Is it not like the page of a book?
> >>
> >> As this is an OSGeo project, and OSGeo is incorporated in the United
> >> States, we should give consideration to US law.
> >>
> >> Jody, does OSGeo have a policy on whether dates are required in
> copyright
> >> headers? Does copyright reside in a single source code file or GeoTools
> as
> >> a work as a whole? Is OSGeo able to obtain legal advice these matters?
> >>
> >> Kind regards,
> >> Ben.
> >>
> >
>
> --
> Ben Caradoc-Davies 
> Director
> Transient Software Limited 
> New Zealand
>
>
> --
> Mobile security can be enabling, not merely restricting. Employees who
> bring their own devices (BYOD) to work are irked by the imposition of MDM
> restrictions. Mobile Device Manager Plus allows you to control only the
> apps on BYO-devices by containerizing them, leaving personal data
> untouched!
> https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
--
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Copyright header policy

[Ben Caradoc-Davies]

Jody,

I am happy to proceed with file creation/contribution date despite my 
small reservations. I think that file creation/contribution date is the 
option that has consensus at this time; it will solve the date 
maintenance overhead problem that is the reason for this change.

I move that you ask OSGeo to obtain legal advice on this matter. I see 
this as a low priority but I think it would be nice to get some advice 
for long-term guidance.

And thanks to everyone for their contributions to this thread. It has 
clarified my views on copyright headers and and changed my views on 
@author tags.

Kind regards,
Ben.

On 21/05/16 12:06, Jody Garnett wrote:
> OSGeo is able to obtain legal advice, as PMC representative I can make that
> request on behalf of our project. As one of the early projects in OSGeo
> other projects will be following our lead.
>
> To close this one out I would be content to update our policy to be file
> creation/contribution date - and if you wish to make the motion Ben we can
> formally ask OSGeo to obtain legal advice (they may do so directly or via
> reaching out to another foundation with legal staff).
> --
> Jody Garnett
>
> On 20 May 2016 at 13:50, Ben Caradoc-Davies  wrote:
>
>> Many stackexchange comments on common law copyright and registration
>> relate to the US prior its accession to the Berne convention (1989). Please
>> see later comments and this:
>> https://www.law.cornell.edu/wex/copyright
>>
>> Furthermore, and I am not a lawyer, can you copyright an individual source
>> code file? Is it not like the page of a book?
>>
>> As this is an OSGeo project, and OSGeo is incorporated in the United
>> States, we should give consideration to US law.
>>
>> Jody, does OSGeo have a policy on whether dates are required in copyright
>> headers? Does copyright reside in a single source code file or GeoTools as
>> a work as a whole? Is OSGeo able to obtain legal advice these matters?
>>
>> Kind regards,
>> Ben.
>>
>

-- 
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

--
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Copyright header policy

[Jody Garnett]

OSGeo is able to obtain legal advice, as PMC representative I can make that
request on behalf of our project. As one of the early projects in OSGeo
other projects will be following our lead.

To close this one out I would be content to update our policy to be file
creation/contribution date - and if you wish to make the motion Ben we can
formally ask OSGeo to obtain legal advice (they may do so directly or via
reaching out to another foundation with legal staff).
--
Jody Garnett

On 20 May 2016 at 13:50, Ben Caradoc-Davies  wrote:

> Many stackexchange comments on common law copyright and registration
> relate to the US prior its accession to the Berne convention (1989). Please
> see later comments and this:
> https://www.law.cornell.edu/wex/copyright
>
> Furthermore, and I am not a lawyer, can you copyright an individual source
> code file? Is it not like the page of a book?
>
> As this is an OSGeo project, and OSGeo is incorporated in the United
> States, we should give consideration to US law.
>
> Jody, does OSGeo have a policy on whether dates are required in copyright
> headers? Does copyright reside in a single source code file or GeoTools as
> a work as a whole? Is OSGeo able to obtain legal advice these matters?
>
> Kind regards,
> Ben.
>
--
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] ImageMosaic API refactor proposal

[Devon Tucker]

Hi all,

I've been working on fleshing this proposal out and adding a bit to it. See
the conversation on on-the-fly reprojection in ImageMosaic. My updated API
proposal is on my own Wiki for now, I can update the master one but I
wanted to solicit early feedback. Please let me know if something doesn't
make sense. Wanted to throw it out there earlier for feedback rather than
later:

https://github.com/dvntucker/geotools/wiki/Refactor-ImageMosaic-for-extensibility

Cheers,
Devon

On Fri, Apr 22, 2016 at 1:20 AM, Niels Charlier  wrote:

> On 21-04-16 20:01, Jody Garnett wrote:
>
> Thanks for the clarification Niels, I was not aware that Prop was part of
> the current API.
>
> Still we have some duplication here right? Should we try running the
> property collectors, look at the results, and generate the schema
> appropriate to store the results?
>
>
> Jody, have a look at this:
> http://geoserver.geo-solutions.it/multidim/en/imagemosaic/mosaic_indexer.html#imagemosaic-xml-indexer-example
> You see that in the current index configuration file, there is a separate
> section for the schemas and the property collectors. Both sections provide
> a completely different kind of information.
>
> I do not think that there is duplication. You cannot run property
> collectors if you do not have a schema yet. The property collectors are run
> per feature (granule). The schema is made before you can even create
> features. The schema is defined per coverage inside the store and can
> differ between them. The property collectors are unaware of the coverages,
> and they may operate for multiple. Once the schema has been created for a
> coverage, the features are created and then values might be needed for each
> feature. This is the time that (for some properties) the appropriate
> property collectors are looked up and called to fill in those values.
> In summary:
> the schema -> defines the metadata (table structure) of the index per
> coverage
> the property collectors -> defines how to grab the data for the index
> (from the metadata of the granules)
> two different functions altogether.
>
>
>
>
> --
> Jody Garnett
>
> On 21 April 2016 at 03:00, Niels Charlier  wrote:
>
>> On 17-04-16 04:17, Jody Garnett wrote:
>>
>>> This proposal (and email thread) should be orthogonal to the RnD
>>> discussion on setting up a mosaic with multiple projections.
>>>
>>> This mosaic is focused on creating/managing the index used. One part I
>>> cannot wrap my head around is the workflow behind these two methods -
>>> createSchema(String name, CoordinateReferenceSystem crs) which creates the
>>> FeatureType used for the index, and Collection
>>> getPropertiesCollectors().
>>> It seems these two methods need to be implemented together, a single
>>> PropertyCollector may collect more than once value on examining a raster. I
>>> am not sure how to line up these collected values with the created schema
>>> without more information.
>>>
>>
>> Just to be clear, the proposal doesn't change anything about
>> PropertyCollectors work. This would simply continue to work as it is
>> working right now, until somebody makes a proposal to change it to
>> something else!
>>
>> These two things have a completely different function. The schema defines
>> the structure of the index.
>>
>> Property Collectors are customisable mechanisms that provides (some of
>> the) values of the index per granule, taking information from the file
>> and/or the coverage metadata.
>>
>> The schema creation includes attributes that are not collected with a
>> PropertyCollector (such as location), while one Propery Collector can
>> potentially supply multiple attribute values.
>>
>>
>>  We also have String getParameter(Prop prop) defined, but the class Prop
>>> is not included in the proposal.
>>>
>>
>> Prop already exists in the current API.
>>
>>
>>> Suggestions:
>>> - Use a list of PropertiesCollectors to provide order, which can then be
>>> used to determine the Schema?
>>> - Language consistency - raster / granule
>>> - Language consistency - could we use AttributeDescriptor rather than
>>> introduce a new thing called "Prop" ?
>>>
>>
>> You do know that Props are configuration properties, nothing to do with
>> features?
>>
>> - Are the class responsibilities clear: GranuleCatalogManager,
>>> GranuleCatalog, GranuleStore, MosaicHarvester, etc...
>>>
>>> (It could also be that since I am unfamiliar with the internals being
>>> refactored that I am just struggling with the language - so if everyone
>>> else is okay ...)
>>>
>>>
>>> Regards
>> Niels
>>
>
>
>
>
> --
> Find and fix application performance issues faster with Applications
> Manager
> Applications Manager provides deep performance insights into multiple
> tiers of
> your business applications. It resolves application problems quickly and
> reduces your MTTR. Get your free trial!
> 

Re: [Geotools-devel] Copyright header policy

[Ben Caradoc-Davies]

Justin,

I appreciate the work you have put into this one, especially your 
examination of other OSGeo projects, but in my view, copying the 
practices of other projects is another form of circling. Many of these 
practices trace their origin to the US pre-Berne. The first GPL licence 
was written in 1989, and the BSD code base is much older. Old habits die 
hard.

Under SCCS, RCS, and CVS, every file had its own revision. In Subversion 
and Git, the state of the whole code base as a single revision. It was 
also much more common in the olden days to export code from the VCS 
because of file-level locking of checkouts (oh, SCCS on Solaris, how do 
I hate thee). With Git, everyone can clone, and everyone has the file 
history. (Justin, this is for the benefit of the list: you taught me 
pretty much everything I know about Git.)

My fear is that file-level notices with dates is a practice that 
accommodates technologies that are no longer in use and conforms to laws 
that are no longer in effect. My preference is to centralise licence 
information and have a bare-bones statement without dates on files. I 
think we have a great opportunity to reduce duplication and simplify our 
workflow.

As at least one option has changed, I think we should re-vote.

I liked this comprehensive discussion of the issues:
https://softwarefreedom.org/resources/2012/ManagingCopyrightInformation.html

Kind regards,
Ben.


On 21/05/16 09:04, Justin Deoliveira wrote:
> We keep on going in circles on this one.  No OSGeo doesn’t have any rules
> to follow here, if they did we would be following them. If we want to
> “follow OSGeo rules” the best thing we can do is look at what the other
> established projects do. I looked at both MapServer and GDAL/OGR and they
> appear to do the same thing that has been proposed here: they only update
> dates in the copyright header when the copyright changes or a file is
> created. I gauged this by looking at bunch of recent commits and the
> headers in those files. If folks closer to this problem know otherwise
> please share.

-- 
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

--
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Copyright header policy

[Justin Deoliveira]

We keep on going in circles on this one.  No OSGeo doesn’t have any rules
to follow here, if they did we would be following them. If we want to
“follow OSGeo rules” the best thing we can do is look at what the other
established projects do. I looked at both MapServer and GDAL/OGR and they
appear to do the same thing that has been proposed here: they only update
dates in the copyright header when the copyright changes or a file is
created. I gauged this by looking at bunch of recent commits and the
headers in those files. If folks closer to this problem know otherwise
please share.

On Fri, May 20, 2016 at 2:50 PM Ben Caradoc-Davies  wrote:

> Many stackexchange comments on common law copyright and registration
> relate to the US prior its accession to the Berne convention (1989).
> Please see later comments and this:
> https://www.law.cornell.edu/wex/copyright
>
> Furthermore, and I am not a lawyer, can you copyright an individual
> source code file? Is it not like the page of a book?
>
> As this is an OSGeo project, and OSGeo is incorporated in the United
> States, we should give consideration to US law.
>
> Jody, does OSGeo have a policy on whether dates are required in
> copyright headers? Does copyright reside in a single source code file or
> GeoTools as a work as a whole? Is OSGeo able to obtain legal advice
> these matters?
>
> Kind regards,
> Ben.
>
> On 21/05/16 04:42, Jonathan Moules wrote:
> > I can see the appeal of having "2011-present" or similar, but I'm not
> sure it is valid.
> > I believe the point of the date is to establish when a version was
> published for copyright law purposes. This means if a file isn't touched
> for several years, it will have an invalid publication date ("present")
> from the perspective of copyright law.
> > This had a few useful insights:
> >
> http://stackoverflow.com/questions/2390230/do-copyright-dates-need-to-be-updated
> >
> > Being that the copyright on even the oldest part of GeoServer's code is
> probably not going to expire until everyone who reads this has snuffed it
> (unless there are some *very* young GeoTools developers!), I think the
> Google ethos is simplest:
> > "Google doesn't update their copyright dates because they don't care
> whether some page they started in 1999 and updated this year falls into the
> public domain in 2094 or 2109."
> > Cheers,
> > Jonathan
> >
> >  On Fri, 20 May 2016 14:48:08 +0100 Justin Deoliveira &
> lt;jdeol...@gmail.com wrote 
> >
> > Thanks Ben. I am going to go ahead with this and update the proposal.
> Thanks for the input everyone.
> >
> > On Thu, May 19, 2016 at 5:19 PM Ben Caradoc-Davies b...@transient.nz
> wrote:
> >
> > A fixed date might imply that this was the last time the file changed.
> >   Could we write this to start with the file creation year but make it an
> >   open date range?
> >
> >   (C) 2011-, Open Source Geospatial Foundation (OSGeo)
> >
> >   or
> >
> >   (C) 2011-present, Open Source Geospatial Foundation (OSGeo)
> >
> >   as the en-dash (open number range) might otherwise be incorrectly
> parsed
> >   as an em-dash (a pause in text).
> >
> >   If the project ever undergoes another copyright ownership change, we
> can
> >   locate all these "-present," elements and rewrite them to the date that
> >   the change occurs, and add a new open-ended copyright line for the new
> >   owner.
> >
> >   Kind regards,
> >   Ben.
> >
> >   On 20/05/16 07:36, Torben Barsballe wrote:
> >Copyright header with file creation date sounds like a good idea,
> although
> >a would assume we would still want aspects of option B here -
> specifically,
> >if there is ever a copyright transfer event, all the headers
> would need
> >updating. I assume we would do something similar to the following:
> >   
> >/* (c) 2014 Open Source Geospatial Foundation (OsGeo)
> >  * (c) 2001 - 2013 OpenPlans
> >  */
> >   
> >Where 2001 is the file creation date, and 2014 is the copyright
> transfer
> >date (Example taken from GeoServer).
> >   
> >Torben
> >   
> >On Thu, May 19, 2016 at 10:47 AM, Justin Deoliveira &
> lt;jdeol...@gmail.com
> >wrote:
> >   
> >To be clear option C is not to drop the copyright header all
> together,
> >just the date that lives in the header.
> >   
> >I am for any option that doesn’t require us to continuously
> change the
> >header for every commit. So I am +1 with a copyright header
> that contains
> >the file creation date.
> >   
> >On Thu, May 19, 2016 at 11:42 AM Andrea Aime &
> lt;andrea.a...@geo-solutions.it
> >wrote:
> >   
> >On Thu, May 19, 2016 at 7:37 PM, Jody Garnett &
> lt;jody.garn...@gmail.com
> >wrote:
> >   
> >Putting those two tensions together can I recommend a
> compromise -
> >   
> >"Copyright header using file creation date"
> >   
> >This compromise provides copyright header and does
> not require ongoing
> >extra effort to maintain.
> >   
> 

Re: [Geotools-devel] Copyright header policy

[Ben Caradoc-Davies]

Many stackexchange comments on common law copyright and registration 
relate to the US prior its accession to the Berne convention (1989). 
Please see later comments and this:
https://www.law.cornell.edu/wex/copyright

Furthermore, and I am not a lawyer, can you copyright an individual 
source code file? Is it not like the page of a book?

As this is an OSGeo project, and OSGeo is incorporated in the United 
States, we should give consideration to US law.

Jody, does OSGeo have a policy on whether dates are required in 
copyright headers? Does copyright reside in a single source code file or 
GeoTools as a work as a whole? Is OSGeo able to obtain legal advice 
these matters?

Kind regards,
Ben.

On 21/05/16 04:42, Jonathan Moules wrote:
> I can see the appeal of having "2011-present" or similar, but I'm not sure it 
> is valid.
> I believe the point of the date is to establish when a version was published 
> for copyright law purposes. This means if a file isn't touched for several 
> years, it will have an invalid publication date ("present") from the 
> perspective of copyright law.
> This had a few useful insights:
> http://stackoverflow.com/questions/2390230/do-copyright-dates-need-to-be-updated
>
> Being that the copyright on even the oldest part of GeoServer's code is 
> probably not going to expire until everyone who reads this has snuffed it 
> (unless there are some *very* young GeoTools developers!), I think the Google 
> ethos is simplest:
> "Google doesn't update their copyright dates because they don't care whether 
> some page they started in 1999 and updated this year falls into the public 
> domain in 2094 or 2109."
> Cheers,
> Jonathan
>
>  On Fri, 20 May 2016 14:48:08 +0100 Justin Deoliveira 
> jdeol...@gmail.com wrote 
>
> Thanks Ben. I am going to go ahead with this and update the proposal. Thanks 
> for the input everyone.
>
> On Thu, May 19, 2016 at 5:19 PM Ben Caradoc-Davies b...@transient.nz 
> wrote:
>
> A fixed date might imply that this was the last time the file changed.
>   Could we write this to start with the file creation year but make it an
>   open date range?
>
>   (C) 2011-, Open Source Geospatial Foundation (OSGeo)
>
>   or
>
>   (C) 2011-present, Open Source Geospatial Foundation (OSGeo)
>
>   as the en-dash (open number range) might otherwise be incorrectly parsed
>   as an em-dash (a pause in text).
>
>   If the project ever undergoes another copyright ownership change, we can
>   locate all these "-present," elements and rewrite them to the date that
>   the change occurs, and add a new open-ended copyright line for the new
>   owner.
>
>   Kind regards,
>   Ben.
>
>   On 20/05/16 07:36, Torben Barsballe wrote:
>Copyright header with file creation date sounds like a good idea, 
> although
>a would assume we would still want aspects of option B here - 
> specifically,
>if there is ever a copyright transfer event, all the headers would need
>updating. I assume we would do something similar to the following:
>   
>/* (c) 2014 Open Source Geospatial Foundation (OsGeo)
>  * (c) 2001 - 2013 OpenPlans
>  */
>   
>Where 2001 is the file creation date, and 2014 is the copyright 
> transfer
>date (Example taken from GeoServer).
>   
>Torben
>   
>On Thu, May 19, 2016 at 10:47 AM, Justin Deoliveira 
> jdeol...@gmail.com
>wrote:
>   
>To be clear option C is not to drop the copyright header all 
> together,
>just the date that lives in the header.
>   
>I am for any option that doesn’t require us to continuously change 
> the
>header for every commit. So I am +1 with a copyright header that 
> contains
>the file creation date.
>   
>On Thu, May 19, 2016 at 11:42 AM Andrea Aime 
> andrea.a...@geo-solutions.it
>wrote:
>   
>On Thu, May 19, 2016 at 7:37 PM, Jody Garnett 
> jody.garn...@gmail.com
>wrote:
>   
>Putting those two tensions together can I recommend a 
> compromise -
>   
>"Copyright header using file creation date"
>   
>This compromise provides copyright header and does not 
> require ongoing
>extra effort to maintain.
>   
>   
>I'd second this one too (based on my previous research about 
> foundations,
>and finding
>none that recommends having no copyright headers)
>   
>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
>   
>*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*
>   
>Le informazioni contenute in questo messaggio di posta 
> elettronica e/o
>nel/i file/s allegato/i sono da considerarsi strettamente 
> riservate. Il
>

Re: [Geotools-devel] Copyright header policy

[Jonathan Moules]

I can see the appeal of having "2011-present" or similar, but I'm not sure it 
is valid.
I believe the point of the date is to establish when a version was published 
for copyright law purposes. This means if a file isn't touched for several 
years, it will have an invalid publication date ("present") from the 
perspective of copyright law.
This had a few useful insights:
http://stackoverflow.com/questions/2390230/do-copyright-dates-need-to-be-updated

Being that the copyright on even the oldest part of GeoServer's code is 
probably not going to expire until everyone who reads this has snuffed it 
(unless there are some *very* young GeoTools developers!), I think the Google 
ethos is simplest:
"Google doesn't update their copyright dates because they don't care whether 
some page they started in 1999 and updated this year falls into the public 
domain in 2094 or 2109."
Cheers,
Jonathan

 On Fri, 20 May 2016 14:48:08 +0100 Justin Deoliveira 
jdeol...@gmail.com wrote  

Thanks Ben. I am going to go ahead with this and update the proposal. Thanks 
for the input everyone.

On Thu, May 19, 2016 at 5:19 PM Ben Caradoc-Davies b...@transient.nz 
wrote:

A fixed date might imply that this was the last time the file changed.
 Could we write this to start with the file creation year but make it an
 open date range?
 
 (C) 2011-, Open Source Geospatial Foundation (OSGeo)
 
 or
 
 (C) 2011-present, Open Source Geospatial Foundation (OSGeo)
 
 as the en-dash (open number range) might otherwise be incorrectly parsed
 as an em-dash (a pause in text).
 
 If the project ever undergoes another copyright ownership change, we can
 locate all these "-present," elements and rewrite them to the date that
 the change occurs, and add a new open-ended copyright line for the new
 owner.
 
 Kind regards,
 Ben.
 
 On 20/05/16 07:36, Torben Barsballe wrote:
  Copyright header with file creation date sounds like a good idea, although
  a would assume we would still want aspects of option B here - 
specifically,
  if there is ever a copyright transfer event, all the headers would need
  updating. I assume we would do something similar to the following:
 
  /* (c) 2014 Open Source Geospatial Foundation (OsGeo)
* (c) 2001 - 2013 OpenPlans
*/
 
  Where 2001 is the file creation date, and 2014 is the copyright transfer
  date (Example taken from GeoServer).
 
  Torben
 
  On Thu, May 19, 2016 at 10:47 AM, Justin Deoliveira 
jdeol...@gmail.com
  wrote:
 
  To be clear option C is not to drop the copyright header all together,
  just the date that lives in the header.
 
  I am for any option that doesn’t require us to continuously change the
  header for every commit. So I am +1 with a copyright header that 
contains
  the file creation date.
 
  On Thu, May 19, 2016 at 11:42 AM Andrea Aime 
andrea.a...@geo-solutions.it
  wrote:
 
  On Thu, May 19, 2016 at 7:37 PM, Jody Garnett 
jody.garn...@gmail.com
  wrote:
 
  Putting those two tensions together can I recommend a 
compromise -
 
  "Copyright header using file creation date"
 
  This compromise provides copyright header and does not 
require ongoing
  extra effort to maintain.
 
 
  I'd second this one too (based on my previous research about 
foundations,
  and finding
  none that recommends having no copyright headers)
 
  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
 
  *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*
 
  Le informazioni contenute in questo messaggio di posta 
elettronica e/o
  nel/i file/s allegato/i sono da considerarsi strettamente 
riservate. Il
  loro utilizzo è consentito esclusivamente al destinatario del 
messaggio,
  per le finalità indicate nel messaggio stesso. Qualora riceviate 
questo
  messaggio senza esserne il destinatario, Vi preghiamo 
cortesemente di
  darcene notizia via e-mail e di procedere alla distruzione del 
messaggio
  stesso, cancellandolo dal Vostro sistema. Conservare il messaggio 
stesso,
  divulgarlo anche in parte, distribuirlo ad altri soggetti, 
copiarlo, od
  utilizzarlo per finalità diverse, costituisce comportamento 
contrario ai
  principi dettati dal D.Lgs. 196/2003.
 
 
 
  The information in this message and/or attachments, is intended 
solely
  for the attention and use of the named addressee(s) and may be 
confidential
  or proprietary in nature or covered by the provisions of privacy 
act
  (Legislative Decree June, 30 2003, no.196 - Italy's New Data 
Protection
  Code).Any use not in accord with its purpose, any disclosure, 
reproduction,
  copying, distribution, or either dissemination, either whole or 
partial, is
  strictly forbidden except previous formal approval 

Re: [Geotools-devel] Copyright header policy

[Jody Garnett]

I think I did that yesterday while waiting for a build.

--
Jody Garnett

On 20 May 2016 at 06:48, Justin Deoliveira  wrote:

> Thanks Ben. I am going to go ahead with this and update the proposal.
> Thanks for the input everyone.
>
> On Thu, May 19, 2016 at 5:19 PM Ben Caradoc-Davies 
> wrote:
>
>> A fixed date might imply that this was the last time the file changed.
>> Could we write this to start with the file creation year but make it an
>> open date range?
>>
>> (C) 2011-, Open Source Geospatial Foundation (OSGeo)
>>
>> or
>>
>> (C) 2011-present, Open Source Geospatial Foundation (OSGeo)
>>
>> as the en-dash (open number range) might otherwise be incorrectly parsed
>> as an em-dash (a pause in text).
>>
>> If the project ever undergoes another copyright ownership change, we can
>> locate all these "-present," elements and rewrite them to the date that
>> the change occurs, and add a new open-ended copyright line for the new
>> owner.
>>
>> Kind regards,
>> Ben.
>>
>> On 20/05/16 07:36, Torben Barsballe wrote:
>> > Copyright header with file creation date sounds like a good idea,
>> although
>> > a would assume we would still want aspects of option B here -
>> specifically,
>> > if there is ever a copyright transfer event, all the headers would need
>> > updating. I assume we would do something similar to the following:
>> >
>> > /* (c) 2014 Open Source Geospatial Foundation (OsGeo)
>> >   * (c) 2001 - 2013 OpenPlans
>> >   */
>> >
>> > Where 2001 is the file creation date, and 2014 is the copyright transfer
>> > date (Example taken from GeoServer).
>> >
>> > Torben
>> >
>> > On Thu, May 19, 2016 at 10:47 AM, Justin Deoliveira > >
>> > wrote:
>> >
>> >> To be clear option C is not to drop the copyright header all together,
>> >> just the date that lives in the header.
>> >>
>> >> I am for any option that doesn’t require us to continuously change the
>> >> header for every commit. So I am +1 with a copyright header that
>> contains
>> >> the file creation date.
>> >>
>> >> On Thu, May 19, 2016 at 11:42 AM Andrea Aime <
>> andrea.a...@geo-solutions.it>
>> >> wrote:
>> >>
>> >>> On Thu, May 19, 2016 at 7:37 PM, Jody Garnett > >
>> >>> wrote:
>> >>>
>>  Putting those two tensions together can I recommend a compromise -
>> 
>>  "Copyright header using file creation date"
>> 
>>  This compromise provides copyright header and does not require
>> ongoing
>>  extra effort to maintain.
>> 
>> >>>
>> >>> I'd second this one too (based on my previous research about
>> foundations,
>> >>> and finding
>> >>> none that recommends having no copyright headers)
>> >>>
>> >>> 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
>> >>>
>> >>> *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*
>> >>>
>> >>> Le informazioni contenute in questo messaggio di posta elettronica e/o
>> >>> nel/i file/s allegato/i sono da considerarsi strettamente riservate.
>> Il
>> >>> loro utilizzo è consentito esclusivamente al destinatario del
>> messaggio,
>> >>> per le finalità indicate nel messaggio stesso. Qualora riceviate
>> questo
>> >>> messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
>> >>> darcene notizia via e-mail e di procedere alla distruzione del
>> messaggio
>> >>> stesso, cancellandolo dal Vostro sistema. Conservare il messaggio
>> stesso,
>> >>> divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo,
>> od
>> >>> utilizzarlo per finalità diverse, costituisce comportamento contrario
>> ai
>> >>> principi dettati dal D.Lgs. 196/2003.
>> >>>
>> >>>
>> >>>
>> >>> The information in this message and/or attachments, is intended solely
>> >>> for the attention and use of the named addressee(s) and may be
>> confidential
>> >>> or proprietary in nature or covered by the provisions of privacy act
>> >>> (Legislative Decree June, 30 2003, no.196 - Italy's New Data
>> Protection
>> >>> Code).Any use not in accord with its purpose, any disclosure,
>> reproduction,
>> >>> copying, distribution, or either dissemination, either whole or
>> partial, is
>> >>> strictly forbidden except previous formal approval of the named
>> >>> addressee(s). If you are not the intended recipient, please contact
>> >>> immediately the sender by telephone, fax or e-mail and delete the
>> >>> information in this message that has been received in error. The
>> sender
>> >>> does not give any warranty or accept liability as the content,
>> accuracy or
>> >>> completeness of sent 

[Geotools-devel] Working with 16-bit sample models in geotools?

[Rich Fecher]

I had tracked an issue with GeoWave's implementation of AbstractGridFormat
in which it seems the AbstractGridCoverage2DReader was storing and
retrieving source images that had a single 16-bit band from landsat8 (so
the data type for this sample model is unsigned short).  The GridCoverage2D
tiles that were being returned from the reader looked correct, but as it
passed through the rendering pipeline in geotools it converted the image to
8-bits per band and rescaled the samples.  This rescaling was based on a
calculation of local extrema performed by ImageWorker (at least local to
the tile request).  For a mosaic the result was this:
https://s3-us-west-2.amazonaws.com/geowave-content/example_byte_rescale_issue.png

In digging into the code a bit, the tile request is rescaled to byte here
using that local extrema calculation:
https://github.com/geotools/geotools/blob/master/modules/library/render/src/main/java/org/geotools/renderer/lite/gridcoverage2d/RasterSymbolizerHelper.java#L130

I am using the raster SLD that comes with geoserver out of the box, and
have looked at ways to apply rescaling using pre-defined global extrema.  I
*think* that one workaround could be to add a ContrastEnhancement tag to
the SLD with a normalize tag for a predefined min and max.  Having to
hard-code it in an sld doesn't seem particularly desirable.  In the global
mosaic case, for example, the extrema may change as new data is ingested,
and generally its always an extra step with an opportunity for user error.
Considering we persist an overall histogram per (mosaic'ed) grid coverage
layer it seems that within our raster format implementation we could
automate this.

So in the meantime, my takeaway from reading the code is that there is
ultimately a need to convert the image to 8-bit at some point in the render
pipeline and perhaps it may make sense to always do that conversion upfront
within our raster format where we have a little more control?  If that's
the case, to do this, my current work-around trying to re-use as much of
the existing classes is to get an instance of an ImageWorker that allows me
to set global statistics:
https://github.com/ngageoint/geowave/blob/GEOWAVE-346-landsat8/extensions/adapters/raster/src/main/java/mil/nga/giat/geowave/adapter/raster/ImageWorkerPredefineStats.java

Then I can call rescaleToBytes() using the global extrema for any grid
coverage prior to returning it from our raster format.  Does that seem
reasonable?  Am I missing something obvious or misusing the library in some
way?

Thanks in advance for the feedback!
Rich
--
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Copyright header policy

[Justin Deoliveira]

Thanks Ben. I am going to go ahead with this and update the proposal.
Thanks for the input everyone.

On Thu, May 19, 2016 at 5:19 PM Ben Caradoc-Davies  wrote:

> A fixed date might imply that this was the last time the file changed.
> Could we write this to start with the file creation year but make it an
> open date range?
>
> (C) 2011-, Open Source Geospatial Foundation (OSGeo)
>
> or
>
> (C) 2011-present, Open Source Geospatial Foundation (OSGeo)
>
> as the en-dash (open number range) might otherwise be incorrectly parsed
> as an em-dash (a pause in text).
>
> If the project ever undergoes another copyright ownership change, we can
> locate all these "-present," elements and rewrite them to the date that
> the change occurs, and add a new open-ended copyright line for the new
> owner.
>
> Kind regards,
> Ben.
>
> On 20/05/16 07:36, Torben Barsballe wrote:
> > Copyright header with file creation date sounds like a good idea,
> although
> > a would assume we would still want aspects of option B here -
> specifically,
> > if there is ever a copyright transfer event, all the headers would need
> > updating. I assume we would do something similar to the following:
> >
> > /* (c) 2014 Open Source Geospatial Foundation (OsGeo)
> >   * (c) 2001 - 2013 OpenPlans
> >   */
> >
> > Where 2001 is the file creation date, and 2014 is the copyright transfer
> > date (Example taken from GeoServer).
> >
> > Torben
> >
> > On Thu, May 19, 2016 at 10:47 AM, Justin Deoliveira 
> > wrote:
> >
> >> To be clear option C is not to drop the copyright header all together,
> >> just the date that lives in the header.
> >>
> >> I am for any option that doesn’t require us to continuously change the
> >> header for every commit. So I am +1 with a copyright header that
> contains
> >> the file creation date.
> >>
> >> On Thu, May 19, 2016 at 11:42 AM Andrea Aime <
> andrea.a...@geo-solutions.it>
> >> wrote:
> >>
> >>> On Thu, May 19, 2016 at 7:37 PM, Jody Garnett 
> >>> wrote:
> >>>
>  Putting those two tensions together can I recommend a compromise -
> 
>  "Copyright header using file creation date"
> 
>  This compromise provides copyright header and does not require ongoing
>  extra effort to maintain.
> 
> >>>
> >>> I'd second this one too (based on my previous research about
> foundations,
> >>> and finding
> >>> none that recommends having no copyright headers)
> >>>
> >>> 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
> >>>
> >>> *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*
> >>>
> >>> Le informazioni contenute in questo messaggio di posta elettronica e/o
> >>> nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
> >>> loro utilizzo è consentito esclusivamente al destinatario del
> messaggio,
> >>> per le finalità indicate nel messaggio stesso. Qualora riceviate questo
> >>> messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
> >>> darcene notizia via e-mail e di procedere alla distruzione del
> messaggio
> >>> stesso, cancellandolo dal Vostro sistema. Conservare il messaggio
> stesso,
> >>> divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
> >>> utilizzarlo per finalità diverse, costituisce comportamento contrario
> ai
> >>> principi dettati dal D.Lgs. 196/2003.
> >>>
> >>>
> >>>
> >>> The information in this message and/or attachments, is intended solely
> >>> for the attention and use of the named addressee(s) and may be
> confidential
> >>> or proprietary in nature or covered by the provisions of privacy act
> >>> (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
> >>> Code).Any use not in accord with its purpose, any disclosure,
> reproduction,
> >>> copying, distribution, or either dissemination, either whole or
> partial, is
> >>> strictly forbidden except previous formal approval of the named
> >>> addressee(s). If you are not the intended recipient, please contact
> >>> immediately the sender by telephone, fax or e-mail and delete the
> >>> information in this message that has been received in error. The sender
> >>> does not give any warranty or accept liability as the content,
> accuracy or
> >>> completeness of sent messages and accepts no responsibility  for
> changes
> >>> made after they were sent or for other risks which arise as a result of
> >>> e-mail transmission, viruses, etc.
> >>>
> >>> ---
> >>>
> >>
> >>
> >>
> 

[Geotools-devel] [JIRA] (GEOT-5423) Optimize vector rendering mode for dense hatches and large target geometries

[Andrea Aime [Administrator] (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Andrea Aime [Administrator] created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 GeoTools /  GEOT-5423  
 
 
  Optimize vector rendering mode for dense hatches and large target geometries   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Assignee: 
 Unassigned  
 
 
Components: 
 render  
 
 
Created: 
 20/May/16 11:32 AM  
 
 
Priority: 
  Medium  
 
 
Reporter: 
 Andrea Aime [Administrator]  
 

  
 
 
 
 

 
 Hatch filling in vector mode is implemented by repeating over and over the same small vector element. For very large outputs with dense fills this means generating millions of this little vectors, which in turn either makes the request go OOM, or results in extremely large PDF/SVG files that readers have trouble opening. For fills that form parallel line sets, generate the actual lines, instead of repeating the small symbol  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment