Re: [Geotools-devel] Copyright header policy

My thoughts on the @author tag: I feel like the git commit log gives a clearer and more usefull picture of this sort of information - You can see the initial author, as well as the author of any major changes, and can usually get a good idea of who is currently doing the most work in that area of

Re: [Geotools-devel] wfs-ng vs wfs datastore fight!

Andre, The reason I closed it as "not a bug" was because I knew it was done by intentional design (not by me, but by the initial developer of wfs-ng) for a particular purpose and therefore I did not consider it a bug. You do make good points to criticise this choice, which does affect

[Geotools-devel] [JIRA] (GEOT-5406) Ignore NetCDF grid_mapping_name that is present but unsupported

Title: Message Title Ben Caradoc-Davies

Re: [Geotools-devel] Copyright header policy

I used to share Andrea's view but, as my confidence grew, I became more comfortable seeing @author tags as historical information not an assertion of ownership. On 23/04/16 09:24, Jody Garnett wrote: > Andrea had a very reasoned argument for not using the @author tag and > started discouraging

Re: [Geotools-devel] Copyright header policy

Andrea had a very reasoned argument for not using the @author tag and started discouraging its use. It amounted to team ownership of the codebase empowering everyone to work on a class, rather than slowing down to seek permission (or even worse wait for someone else) to fix a problem. -- Jody

Re: [Geotools-devel] Copyright header policy

+1. This is a great practice, and required by some licences. Dates in these headers cannot be removed or changed. On 23/04/16 09:19, Jody Garnett wrote: > The other clarification I have gotten from external review is to leave > headers intact when copying code into our codebase (we only have a

Re: [Geotools-devel] Copyright header policy

In fact, I think we should *require* rather than just encourage the use of @author. Kind regards, Ben. On 23/04/16 09:14, Ben Caradoc-Davies wrote: > I like the Javadoc @author tag. We should encourage its use on all new > classes, and additional @author tags for any substantial contribution to

Re: [Geotools-devel] Copyright header policy

The other clarification I have gotten from external review is to leave headers intact when copying code into our codebase (we only have a small number of examples of this). -- Jody Garnett On 22 April 2016 at 14:14, Ben Caradoc-Davies wrote: > I like the Javadoc @author tag.

Re: [Geotools-devel] Copyright header policy

I like the Javadoc @author tag. We should encourage its use on all new classes, and additional @author tags for any substantial contribution to an existing file. @author tags are useful not only for provenance but for seeking help; successive changes can make @author tags easier to use than

Re: [Geotools-devel] Copyright header policy

OSGeo is governed by projects such as ours setting a precedent. I like having headers that capture the initial author - since that has been very helpful in sorting out any questions during our incubation and subsequent external code audits. I really cannot see song away with headers as they are

Re: [Geotools-devel] Copyright header policy

My understanding is that, under the Berne Convention, there is no requirement at all for any copyright notice, "Copyright", "(C)", "All Rights Reserved", or dates. The WTO requires compliance to TRIPS rules which thus apply these rules to practically every country in the world. Even the United

Re: [Geotools-devel] [Geoserver-devel] Reading GeoTiffs from HDFS

Hi Chris, Nice! That's a fun find. Generally, I do like the idea of using Map/Reduce or Spark to pre-generate tiles or an image pyramid. We've kicked around the idea of GWC + M/R a few times in passing. If one has Hadoop infrastructure hanging around, it might make sense to use GeoTrellis,

Re: [Geotools-devel] Copyright header policy

Cool. I'll write up a quick one. On Fri, Apr 22, 2016 at 1:01 PM Jody Garnett wrote: > If you would like to make that proposal we can update the developers guide > and get it done ... > > -- > Jody Garnett > > On 22 April 2016 at 11:38, Justin Deoliveira

Re: [Geotools-devel] Copyright header policy

If you would like to make that proposal we can update the developers guide and get it done ... -- Jody Garnett On 22 April 2016 at 11:38, Justin Deoliveira wrote: > Thanks Jody. That helps me understand. > > My thought is that the day to day overhead is not worth being able

Re: [Geotools-devel] Copyright header policy

Thanks Jody. That helps me understand. My thought is that the day to day overhead is not worth being able to rest assured that in 75 years GeoTools will still be in good standing with regard to copyright ;) My vote would be to change to a process where the copyright is set to the current year

Re: [Geotools-devel] Copyright header policy

On Fri, Apr 22, 2016 at 8:06 PM, Jody Garnett wrote: > If the PMC wants to make this decision I would be -0, I understand that it > would assist with github pull requests, but I feel we would do so by > cutting a corner. > I don't feel strongly either way, copyright

Re: [Geotools-devel] Copyright header policy

There are two schools of thought Justin. I had this discussion in detail on the geowebache-devel with Arne Kepp (and did some research at that time which was unsatisfying to both of us - and probably scared away a contributor). See

Re: [Geotools-devel] Reading GeoTiffs from HDFS

Hi Simone, Thanks for the feedback! As quick response, for #1, I agree that using mosaicing / an image pyramid would be a great option. I was mainly working at the prototype phase, and I wanted to have a discussion on the mailing lists (especially since changes are required in ImageIO-Ext or

Re: [Geotools-devel] wfs-ng vs wfs datastore fight!

On Fri, Apr 22, 2016 at 7:48 PM, Andrea Aime wrote: > Given this, I'd still make it possible for GeoTools users to upgrade from > wfs to wfs-ng without this much hassle by exposing the > actual native type name. > Actually, given that wfs-ng has been available for

Re: [Geotools-devel] Reading GeoTiffs from HDFS

Dear Jim, quick feedback. First of all congratulation on making this work. As I suspected the bottleneck is getting the data out of HDFS. I can think about two things (which we are not mutually exclusive): -1- Maybe complex, put smaller bits into HFDS and use the mosaic to serve or even develop

Re: [Geotools-devel] wfs-ng vs wfs datastore fight!

On Thu, Apr 21, 2016 at 7:52 PM, Jody Garnett wrote: > > > Hum... wfs-ng was supposed to be a drop-in replacement, not having a >>> upgrade >>> > path seems to be a serious issue to me. >>> > Where is it documented? >>> >>> Quick search got us this: >>>

[Geotools-devel] Copyright header policy

Hi folks, Something I’ve been meaning to ask about is a clarification of why we have to update copyright header dates to the current year for every file change. As opposed to just having a static copyright header that signifies a “copyright event” (like the change over to osgeo) and then stands

Re: [Geotools-devel] wfs-ng vs wfs datastore fight!

2016-04-22 9:18 GMT+02:00 Andrea Aime : > On Thu, Apr 21, 2016 at 2:27 PM, Mark Prins wrote: > >> > Where is it documented? >> >> Quick search got us this: >> https://osgeo-org.atlassian.net/browse/GEOT-4883 >> and we googled some more messages

Re: [Geotools-devel] ImageMosaic API refactor proposal

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

Re: [Geotools-devel] wfs-ng vs wfs datastore fight!

On Thu, Apr 21, 2016 at 2:27 PM, Mark Prins wrote: > > Where is it documented? > > Quick search got us this: > https://osgeo-org.atlassian.net/browse/GEOT-4883 > and we googled some more messages on it. > > This happened over christmas so it's gone a bit hazy by now, we