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

uld be to temporarily pass a wrapping input stream killing the >> flushbefore, just for the sake of reading the header... >> >> Daniele's input much appreciated too :-D >> >> Cheers >> Andrea >> >> >> On Wed, Oct 30, 2019 at 9:43 PM Just

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

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/585b021d

Re: [Geotools-devel] Update of Graph Module

Hey Ian, great stuff! If you want to step up to take on that module you're more than welcome too. I unfortunately don't have time these days to remain an active maintainer on the project, I can only contribute as my project work allows me too. So it's all yours. Your proposed changes all sound gre

Re: [Geotools-devel] Postgis raster module

Ok, build checks all passed and PR merged. On Wed, Feb 27, 2019 at 8:47 AM Justin Deoliveira wrote: > Cool. I did add it to the unsupported/pom.xml as one of the modules > included in a normal build. So fingers crossed :) > > On Wed, Feb 27, 2019 at 8:44 AM Andrea Aime > wro

Re: [Geotools-devel] Postgis raster module

Cool. I did add it to the unsupported/pom.xml as one of the modules included in a normal build. So fingers crossed :) On Wed, Feb 27, 2019 at 8:44 AM Andrea Aime wrote: > On Wed, Feb 27, 2019 at 4:34 PM Justin Deoliveira > wrote: > >> One thing I forgot as usual is the co

Re: [Geotools-devel] Postgis raster module

Haha, all good , thanks Andrea. I'll submit a pull request shortly and if all the build checks are happy I'll go ahead and merge. One thing I forgot as usual is the copyright headers... I'll add those too :) On Wed, Feb 27, 2019 at 7:34 AM Andrea Aime wrote: > On Wed, Feb 27, 2019 at 3:30 PM And

[Geotools-devel] Postgis raster module

Hi folks, Following up on a post from a few months back I've been working on a module that supports reading rasters from a postgis database. I'd like to contribute it as an unsupported module module for now. The code can be found here: https://github.com/jdeolive/geotools/tree/postgis-raster/mo

Re: [Geotools-devel] Raster classifier operation for large inputs

Ahhh sorry, totally missed that, my apologies, too much multitasking on my part :) Anyways, +1 from me fwiw. On Wed, Nov 14, 2018 at 11:59 AM Andrea Aime wrote: > On Wed, Nov 14, 2018 at 7:54 PM Justin Deoliveira > wrote: > >> Hey Andrea, >> All of your changes sound good

Re: [Geotools-devel] Raster classifier operation for large inputs

Hey Andrea, All of your changes sound good to me. Only question I have is whether your proposed change will replace what is there? Or is your thought to add some config parameter that would trigger the histogram / approximation based method? As for moving the code to jai-text definitely makes sen

[Geotools-devel] Stepping aside from PMC

Hi folks, Some of you are probably shocked that I am still actually still on the PMC given my level of involvement over the past few years but technically I am. I figure there are other developers who are far more active with GeoTools than myself who would make great PMC members so I am happy to s

Re: [Geotools-devel] About the OGR failures

Hey guys. Definitely ok with moving the jni based module back to unsupported. As you know I havent been much of a maintainer for quite some time now so I'm fine with whatever you guys think best. On Sat, Apr 21, 2018, 2:19 AM Andrea Aime wrote: > On Sat, Apr 21, 2018 at 12:08 AM, Ben Caradoc-Dav

Re: [Geotools-devel] [Geowebcache-devel] Codebase reformat using Google/AOSP format

+1 On April 15, 2018 at 7:55:46 AM, Andrea Aime (andrea.a...@geo-solutions.it) wrote: Hi Ian, yep, I surely hope it will make everybody's life easier in the medium-long term, even if there will be an adjustment period at the beginning Cheers Andrea On Sun, Apr 15, 2018 at 2:25 PM, Ian Turton

Re: [Geotools-devel] Enhancing GeoJSON serialisation for deep properties

I’m the original author of most of that code, but as Andrea states I haven’t had the time to be a decent maintainer of it, so definitely go ahead with your improvements, having support for “deep” or “complex” properties would be great. That module is fair game! A word of warning: the way the parse

Re: [Geotools-devel] java 9 compatibility proposal

Sorry for the late vote, the plan looks great to me guys. Added my +1. On November 7, 2017 at 5:15:50 PM, Jody Garnett (jody.garn...@gmail.com) wrote: So after a month we have: - Andrea Aime +1 - Ben Caradoc-Davies +1 - Christian Mueller - Ian Turton +1 - Justin Deoliveira

Re: [Geotools-devel] Motion: CSS module graduation

+1. On Sun, Jul 30, 2017 at 3:10 PM Simone Giannecchini < simone.giannecch...@geo-solutions.it> wrote: > +1 > Regards, > Simone Giannecchini > == > GeoServer Professional Services from the experts! > Visit http://goo.gl/it488V for more information. > == > Ing. Simone Giannecchini > @simogeo > Fou

Re: [Geotools-devel] Move DataUtilities URL methods to new Urls class in gt-metadata [GEOT-5740]

I would prefer Urls, think it reads nicer. $0.02 On Tue, May 30, 2017 at 1:38 AM Andrea Aime wrote: > And I'd say "don't touch" :-) (take it as a -0) > I agree common conventions is good. And agree that we might want to set > one convention from here onwards. > But can we please do it without br

Re: [Geotools-devel] A bunch of color operation functions

A big +1 on making them central, give in that we now have sld, css, and ysld I think as much as we can share among them the better! On Sun, Apr 23, 2017 at 3:46 AM Andrea Aime wrote: > Hi, > this pull request adds a bunch of lesscss.org color operation functions: > https://github.com/geotools/ge

Re: [Geotools-devel] Question about centroid sampling code

you're getting 5% of my attention :-p (better that or full attention in the > weekend?) > Re-read again, yeah, go ahead with what you're proposing, it sounds more > than reasonable. > > Cheers > Andrea > > > On Wed, Apr 12, 2017 at 6:20 PM, Justin Deoliveira &

Re: [Geotools-devel] Question about centroid sampling code

t 5:36 PM, Justin Deoliveira > wrote: > > Thanks Andrea, I thought that might be the case. And yes, my intention is > to try and use this code for KML in order to choose a placemark placement > that lies inside the polygon. > > Any objection to adding multiple arguments (o

Re: [Geotools-devel] Question about centroid sampling code

en space already at that point? > > Cheers > Andrea > > On Wed, Apr 12, 2017 at 4:36 PM, Justin Deoliveira > wrote: > > Hi folks, > > I am working on patch that takes some code from the LabelCacheImpl into > RendererUtilities. Basically I want to re-use the logic that

[Geotools-devel] Question about centroid sampling code

Hi folks, I am working on patch that takes some code from the LabelCacheImpl into RendererUtilities. Basically I want to re-use the logic that attempts to find a central point that actually lies within a polygon. The code I have a question about is this, where the size of a sampling “step” is com

Re: [Geotools-devel] XML Binding Generation?

I think porting over the old models would be great topic for a code sprint. Especially since there will be a bit of stuff around the models (custom xml bindings, request handling in geoserver, etc…) that also needs to change. On Fri, Apr 7, 2017 at 9:12 AM Nuno Oliveira wrote: > Image-mosaic use

Re: [Geotools-devel] XML Binding Generation?

Who was it that once said something about complaining without offering up any alternative to make it better…? That said I agree with Andrea, given the chance to do this over again I would certainly push for not using EMF and the way those model generations work. I would say moving forward that def

Re: [Geotools-devel] Adding a kerning vendor option and enable it by default

I think anything that makes rendering look better out of the box is a big win. I would say as long as the performance hit isn't catastrophic this would be worth it. $0.02 On Sun, Mar 26, 2017 at 8:49 AM Andrea Aime wrote: > Hi, > a question on stackoverflow [1] prompted me to look into font kerni

Re: [Geotools-devel] Commit Access request for Unsupported Module MapBoxStyles

Welcome David! +1. I am sure Jody has already pointed it out to you but in case not, here is good info about the committer process and stuff in general: http://docs.geotools.org/latest/developer/roles/index.html -Justin On Wed, M

[Geotools-devel] Next skype meeting?

Hey folks, I am going to make an effort to try and attend the bi-weekly skype meetings. Based on the last reminder email from Ben the next meeting will be Tuesday, Feb 21, at 16:30 UTC? Do I have that right? Thanks! -Justin

Re: [Geotools-devel] Call for vote on JDBC Callback proposal

e origin of the term "gt2" is slowly being lost in the mists of time. > We have already dropped the "2." from the front of our versions. :-) > > Kind regards, > Ben. > > On 16/02/17 16:18, Justin Deoliveira wrote: > > Thanks Ben! As mentioned on the pull r

Re: [Geotools-devel] Call for vote on JDBC Callback proposal

; My only comment is that the system property could perhaps be called > "geotools.jdbc.callback" rather than "gt2.jdbc.callback". > > Kind regards, > Ben. > > On 16/02/17 03:32, Justin Deoliveira wrote: > > Thanks to everyone who submitted feedback on t

Re: [Geotools-devel] Call for vote on JDBC Callback proposal

, Justin Deoliveira wrote: Thanks to everyone who submitted feedback on the idea, I’ve incorporated it into the proposal and I would like to call for a formal vote. https://github.com/geotools/geotools/wiki/JDBC-Callbacks Thanks! -Justin

[Geotools-devel] Call for vote on JDBC Callback proposal

Thanks to everyone who submitted feedback on the idea, I’ve incorporated it into the proposal and I would like to call for a formal vote. https://github.com/geotools/geotools/wiki/JDBC-Callbacks Thanks! -Justin -- Chec

Re: [Geotools-devel] JDBC Callbacks

uest for change). > > Cheers > Andrea > > > On Mon, Feb 13, 2017 at 2:25 PM, Justin Deoliveira > wrote: > > Hi folks, > > I’ve incorporated Jody’s feedback and updated the proposal, and submitted > a pull request. > > https://github.com/geotools/geotools/pul

Re: [Geotools-devel] JDBC Callbacks

, 2017 at 1:07 PM Justin Deoliveira wrote: > Hey Jody, thanks for the feedback. > > Answers inline. > > On Thu, Feb 9, 2017 at 12:47 PM Jody Garnett > wrote: > > Thanks Justin, > > Some questions: > - Does your before query and after query methods ... need an indi

Re: [Geotools-devel] JDBC Callbacks

bc.callback=foo”. Perhaps “id” would be a better property name? > > -- > Jody Garnett > > On 9 February 2017 at 06:39, Justin Deoliveira wrote: > > Hi folks, > > A while back I sent some email about adding some code to the jdbc > datastores to facilitate the idea of

[Geotools-devel] JDBC Callbacks

Hi folks, A while back I sent some email about adding some code to the jdbc datastores to facilitate the idea of capturing metrics for jdbc data access. Here is what I have come up with in terms of a proposal. https://github.com/geotools/geotools/wiki/JDBC-Callbacks Looking forward to getting

[Geotools-devel] [JIRA] (GEOT-5639) Add JDBC callback interface to JDBC datastore modules

Title: Message Title Justin Deoliveira

Re: [Geotools-devel] web, css, x11, html color names support

On Tue, Feb 7, 2017 at 8:37 AM Jody Garnett wrote: > Andrea I shared your hesitations - have a look at > https://github.com/geotools/geotools/pull/1462 > > The converters go form String to Color, I required the hint to be set (or > they won't do anything). So although they will be available to al

Re: [Geotools-devel] web, css, x11, html color names support

On Tue, Feb 7, 2017 at 12:42 AM Andrea Aime wrote: > Hi Jody, > +1 for centralizing. > > Two hesitations about using a pluggable Converter implementation: > >- Would they convert from String to Color (a converter from String to >String does not make much sense now does it?) and then event

Re: [Geotools-devel] Promoting gt-ysld to a supported module

+1. Great work on this Torben. On Thu, Jan 26, 2017 at 4:17 PM Ben Caradoc-Davies wrote: > +1. Thanks, Torben, that is quite thorough. > > Jody, do we have a policy for which supported modules are plugins and > which are extensions? I noticed that Torben used the term "plugin" and > realised that

Re: [Geotools-devel] Promoting gt-ysld to a supported module

Hey Torben, Thanks for pushing this forward. I am happy to keep my name on as module maintainer list as long as others see fit. I know I haven’t been the most active maintainer over the past while but unfortunately my involvement is driven by requirements from project work. That said if someone el

[Geotools-devel] JDBC Metrics

Hi folks, I'm working on a project where I would like to be able to produce some metrics around reading data from a database via GeoTools/GeoServer. Some things like: - how long it takes from the initial query to reading the last row - the time it takes to run the initial query against the

Re: [Geotools-devel] jts use of Shapefile Reader

+1 On Wed, Nov 9, 2016 at 6:06 AM Andrea Aime wrote: > +1 here too > > Cheers > Andrea > > On Wed, Nov 9, 2016 at 9:48 AM, Ian Turton wrote: > > +1 from me > > Ian > > On 8 November 2016 at 22:06, Jody Garnett wrote: > > dual license: EPL / BSD > > donating/relicense same story, different work

Re: [Geotools-devel] One liner proposal: adding a reloadFeatureType(Name) method to DataStore to clear eventual caches attached to a certain feature type

Sounds like a good idea to me. I do have a comment on naming though (surprise). To me calling it “reloadFeatureType” implies that it will be reloaded immediately and is perhaps confusing/misleading? Using a verb like “flush” or “clear” might be more suitable to it’s actually purpose. $0.02 On Tue

Re: [Geotools-devel] Proposing Nuno Oliveira as committer

+1, if nothing else based on his last name alone ;) On Tue, Nov 1, 2016 at 2:30 AM Ian Turton wrote: > +1 > > Ian > > On 1 November 2016 at 04:19, Christian Mueller < > christian.muel...@os-solutions.at> wrote: > > +1 > > Cheers > > On Tue, Nov 1, 2016 at 12:26 AM, Jody Garnett > wrote: > > Agr

Re: [Geotools-devel] Upgrading xerial-jdbc driver version in geopackage and mbtiles

No suggestion unfortunately. That spatialite custom build of xerial was a pain to build, and probably not worth the effort. The intention was to have all of the library loading, etc… be transparent, in the same way that users of xerial don’t have to worry about loading the sqlite library. But it r

Re: [Geotools-devel] Fwd: Can/should we activate the github squash commits on merge option?

Hey guys, yup, definitely addressed, I wasn’t sure from the original post if this was an “always squash” but it’s clearly not. +1 for me. On Tue, Aug 30, 2016 at 1:46 AM Andrea Aime wrote: > I see no more feedback, > Justin, were your concerns addressed? > Anyone else? > > Cheers > Andrea > > >

Re: [Geotools-devel] Can/should we activate the github squash commits on merge option?

I would be slightly hesitant because it would mean you couldn’t have a pull request with multiple commits even when it makes sense? Maybe that is an ok thing to always have a single commit for a pull requests but I know I often like to break up commits in a change when it makes logical sense. For i

Re: [Geotools-devel] proposal:

ly OSGeo copyright on > creation/contribution" > > And response via email: > >- Andrea Aime +1 (second) >- Ben Caradoc-Davies +1 >- Christian Mueller +1 >- Ian Turton +1 >- Jody Garnett +1 (motion) >- Justin Deoliveira +1 >- Simone Giannecc

Re: [Geotools-devel] proposal:

t;Apply OSGeo copyright on creation/contribution" >> >> And response via email: >> >>- Andrea Aime +1 (second) >>- Ben Caradoc-Davies +0 (agreement but no clear vote) >> - Christian Mueller >>- Ian Turton >>- Jody Garne

Re: [Geotools-devel] Proposal: ask OSGeo for legal advice on copyright headers

+1. On Tue, May 31, 2016 at 3:50 PM Jody Garnett wrote: > So far we have: > >- Andrea Aime >- Ben Caradoc-Davies +1 >- Christian Mueller >- Ian Turton >- Jody Garnett +1 >- Justin Deoliveira >- Simone Giannecchini > > > > -- >

Re: [Geotools-devel] Copyright header policy

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

Re: [Geotools-devel] Copyright header policy

#x27;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 >

Re: [Geotools-devel] Copyright header policy

ders 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 cop

Re: [Geotools-devel] Copyright header policy

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, 2

Re: [Geotools-devel] Copyright header policy

someone in the (D) camp can come up with good way to achieve this I’ll go ahead and update the proposal with a plan to implement C. On Wed, May 18, 2016 at 5:47 PM Justin Deoliveira wrote: > Thanks Ben. I am agreement about option D. So unless one of the folks who > made it there first choice

Re: [Geotools-devel] Copyright header policy

avies wrote: > > Instant runoff voting give a win for D: > > https://en.wikipedia.org/wiki/Instant-runoff_voting > > > > Round 1: A eliminated > > Round 2: B eliminated > > Round 3: D wins with 3/5 votes > > > > Kind regards, > > Ben. > > >

Re: [Geotools-devel] Copyright header policy

t; >>>> The official guidance for these foundations seem to suggest at least >>>> one year should show up in the headers. >>>> I found little evidence that our current approach has benefits, >>>> although some practices seem to imply >>>> a

Re: [Geotools-devel] Avoiding to scan postgreqsql type system in JDBCDataStore

Sounds like a good approach to me. On Mon, May 16, 2016 at 11:37 AM Andrea Aime wrote: > Hi, > today I stumbled into a really weird issue, basically JDBCDataStore becomes > extremely slow (minutes if the db is not co-located) if a database has > tens of > thousands of tables in it. > > The short

Re: [Geotools-devel] Copyright header policy

nse :) > > -- > Jody Garnett > > On 25 April 2016 at 09:37, Justin Deoliveira wrote: > >> I can see how the original date could be useful for cases like this but >> have you ever seen a situation where something was marked (for example) (c) >> 2010 and from 2010 to the curren

Re: [Geotools-devel] Copyright header policy

I did have to duck out > to git history on a few occasions it was a rare occurrence - in part > because the team here has done a good job. > > -- > Jody Garnett > > On 24 April 2016 at 08:13, Justin Deoliveira wrote: > >> What is it specifically that is making you un

Re: [Geotools-devel] Copyright header policy

wow do you feel about updating the headers once each > year (via a script) so that individual pull requests are not held up? > > -- > Jody Garnett > > On 22 April 2016 at 12:05, Justin Deoliveira wrote: > >> Cool. I'll write up a quick one. >> >> On

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 wrote: >

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 tha

[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 fo

Re: [Geotools-devel] jdbc negative dates

e: > > Thanks, Justin, I have kicked to online build to confirm. > > > > Kind regards, > > Ben. > > > > On 20/04/16 06:35, Justin Deoliveira wrote: > >> Should be fixed now > >> < > https://github.com/geotools/geotools/commit/ee7d0b749bc6873

Re: [Geotools-devel] jdbc negative dates

Should be fixed now <https://github.com/geotools/geotools/commit/ee7d0b749bc6873ec599d50ee938a80f6eb94500> . On Tue, Apr 19, 2016 at 12:10 PM Justin Deoliveira wrote: > I’ll take a look. > > On Tue, Apr 19, 2016 at 10:57 AM Andrea Aime > wrote: > >> Hi guys, >&g

Re: [Geotools-devel] jdbc negative dates

. >> >> If I include this in the beta2 can I ask a few of the people tagged in on >> this thread to help out with the testing :) >> >> -- >> Jody Garnett >> >> On 15 April 2016 at 15:34, Justin Deoliveira wrote: >> >>> Ok, here is my cut a

Re: [Geotools-devel] jdbc negative dates

them back, along with filtering. On Fri, Apr 15, 2016 at 3:37 PM Justin Deoliveira wrote: > On Fri, Apr 15, 2016 at 2:05 AM Andrea Aime > wrote: > >> On Fri, Apr 15, 2016 at 5:31 AM, Justin Deoliveira >> wrote: >> >>> Hey guys. So as I started on this I quickl

Re: [Geotools-devel] jdbc negative dates

On Fri, Apr 15, 2016 at 2:05 AM Andrea Aime wrote: > On Fri, Apr 15, 2016 at 5:31 AM, Justin Deoliveira > wrote: > >> Hey guys. So as I started on this I quickly came to the realization >> (which I apologize for not seeing the obvious before) but interpreting >> val

Re: [Geotools-devel] jdbc negative dates

; I think the patch takes the approach of adjusting the calendar time is > being measured against. > > Can we be tricky and produce a calendar for each section of geological > time :) > On Thu, Apr 14, 2016 at 8:31 PM Justin Deoliveira > wrote: > >> Hey guys. So as I sta

Re: [Geotools-devel] jdbc negative dates

citing, and critical piece of making MapStory work the way we've imagined. > > > > On Tue, Apr 12, 2016 at 3:47 PM, Justin Deoliveira > wrote: > >> Great, thanks for the input Jonathon and David. I think I have enough to >> put together a proposal on how to

Re: [Geotools-devel] Solr heatmap as a grid coverage

Thanks Simone. See below. On Thu, Apr 14, 2016 at 10:55 AM Simone Giannecchini < simone.giannecch...@geo-solutions.it> wrote: > Ciao Justing, > please, read below > > > > On Thu, Apr 14, 2016 at 6:18 PM, Justin Deoliveira > wrote: > > Thanks for the in

Re: [Geotools-devel] Solr heatmap as a grid coverage

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. > > > On Thu, Apr 14, 2016 at 4:10 PM, Justin Deoliveira > wrote: > > Hey folks. > > > >

Re: [Geotools-devel] Solr heatmap as a grid coverage

t 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 > transmissio

[Geotools-devel] Approach to handling negative dates

Hey folks, I wanted to start a new thread on this topic to talk about implementation approach, since I think we can all agree that the current patch (which has been closed) needs to be redone, at least to some extent. In general I can think of two approaches to this: 1. Follow the path laid down

Re: [Geotools-devel] jdbc negative dates

n't really care > the time resolution on negative time - milli, seconds, hours. Just whatever > is the most viable pathway to go back to geologic (circa 4.5 billion). We > leave it to you to determine what you prefer. > > On Tue, Apr 12, 2016 at 2:57 PM, Justin Deoliveira > wr

Re: [Geotools-devel] jdbc negative dates

geologic record but allows for less > precision than storing milliseconds. > > On Tue, Apr 12, 2016 at 1:47 PM, Justin Deoliveira > wrote: > >> Thanks David. I was clear that native postgresql timestamp couldn’t do >> the job, but my question was whether bigint had a bi

Re: [Geotools-devel] proposal: refactor vector mask external footprint generation

Looks good, added my +1 On Tue, Apr 12, 2016 at 12:01 PM Jody Garnett wrote: > Added my +1 - we are standing at: > >- Andrea Aime: +1 >- Ben Caradoc-Davies >- Christian Mueller >- Ian Turton: +1 > - Justin Deoliveira >- Jody Garnett +1 >

Re: [Geotools-devel] jdbc negative dates

60*60)) is ~ 290 > Billion > > And to milliseconds (9 Quintillion / (365*24* 60*60*1000)) is ~ 290 Million > > On Tue, Apr 12, 2016 at 11:48 AM, Justin Deoliveira > wrote: > >> Thanks for the info guys, You’ll have to bear with me as you walk me >> through the nua

Re: [Geotools-devel] jdbc negative dates

ot;bigdate_sec" or "bigdate" and "reallybigdate". > > On Tue, Apr 12, 2016 at 11:28 AM, Justin Deoliveira > wrote: > >> Thanks David, that helps a lot. >> >> So to summarize the ask is to be able to store dates as milliseconds from >> the e

Re: [Geotools-devel] jdbc negative dates

he datetime as seconds from the Unix Epoch would > cover roughly +/-290 Billion which WOULD do the job). > > On Tue, Apr 12, 2016 at 7:30 AM, Justin Deoliveira > wrote: > >> This was my finding as well… couldn’t make up what was going on here… >> which makes me think there i

Re: [Geotools-devel] jdbc negative dates

This was my finding as well… couldn’t make up what was going on here… which makes me think there is perhaps more to this patch on the GeoNode side? Rather than flying blind has anyone tried to reach out to Ian Schneider, who afaik is the original author of the patch? If not I can give that a shot

Re: [Geotools-devel] WFS Transaction XML parsing

pushing hard for such a change since I am not sure about any other > ramifications. > > Thanks, > > Jim > > > On 04/08/2016 10:45 AM, Justin Deoliveira wrote: > > Hey Jim, > > The wfs native element might be the cleanest way to handle this. I’ve seen > folks

Re: [Geotools-devel] WFS Transaction XML parsing

Hey Jim, The wfs native element might be the cleanest way to handle this. I’ve seen folks use it before for security and validation type stuff with some success. In GeoServer you can plug in WFS transactions callbacks pretty easily using the TransactionPlugin <[https://github.com/geoserver/geoserv

Re: [Geotools-devel] Solr heatmap as a grid coverage

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 r

Re: [Geotools-devel] Solr heatmap as a grid coverage

the rendering > pipeline to achieve blur, etc. > > Cheers, > > Jim > > 1. > https://github.com/geotools/geotools/blob/master/modules/unsupported/process-feature/src/main/java/org/geotools/process/vector/HeatmapProcess.java > > > On 04/06/2016 04:02 PM, Justin Deoliveira

[Geotools-devel] Solr heatmap as a grid coverage

Hi folks, I’m working on a project to expose Solr’s heatmap capability through GeoServer. You can find details about Solr heatmaps here: https://cwiki.apache.org/confluence/display/solr/Spatial+Search (search for “Heatmap Faceting”. But the gist of it is this: If you have a spatial field tha

Re: [Geotools-devel] Boundless YSLD to GeoTools?

Can we enable it in the default profile? Tests all pass for me locally and the module builds pretty fast. Are there are any other requirements for it to be in the default unsupported profile? On Wed, Apr 6, 2016 at 12:31 PM Jody Garnett wrote: > It is a community module, so not included in a bui

Re: [Geotools-devel] Boundless YSLD to GeoTools?

Thanks a lot Kevin. Copyright headers are in place so I’ve gone ahead and submitted the pull request. So consider this the official ask for an unsupported module. On Fri, Apr 1, 2016 at 3:03 PM Kevin Smith wrote: > On Thu, Mar 31, 2016, at 07:51 PM, Justin Deoliveira wrote: > > >

Re: [Geotools-devel] Boundless YSLD to GeoTools?

For reference. https://github.com/geotools/geotools/pull/1156 On Mon, Apr 4, 2016 at 7:40 AM Justin Deoliveira wrote: > Thanks a lot Kevin. Copyright headers are in place so I’ve gone ahead and > submitted the pull request. So consider this the official ask for an > unsupport

Re: [Geotools-devel] Boundless YSLD to GeoTools?

ect contributor agreement etc... > Will do. How do you want to handle copyright headers? Shall I update the module to include the GeoTools copyright now? > > The draft docs are in the git history if you want to go digging. > Cool, I’ll go looking. > On Thu, Mar 31, 2016 at 6:13

Re: [Geotools-devel] Boundless YSLD to GeoTools?

to geotools. See >> https://github.com/geoserver/geoserver/pull/1182 and >> https://github.com/boundlessgeo/geoserver-exts/pull/100 for more details >> on this. >> >> Torben >> >> On Thu, Mar 31, 2016 at 4:11 PM, Justin Deoliveira >> wrote:

[Geotools-devel] Boundless YSLD to GeoTools?

Hey folks, I heard a while back through the grapevine that the folks at Boundless are interested in moving the YSLD styling modules currently living in the Boundless geoserver-exts repository to GeoTools? I was wondering if

Re: [Geotools-devel] [GEOT-5079] PostGISDialect Error with PostGIS 2.0

I took a quick look and the patch looks good to me. Commented with a +1 on the pull request. On Thu, Mar 17, 2016 at 12:29 PM Andrea Aime wrote: > Hi Shane, > thanks for the pull request, it might take some time to look at it as > core devs seem to be all super-busy around this time (deliverable

Re: [Geotools-devel] Inserting data in the database from GeoServer

This a question better asked on the GeoServer users list. But yes you can through GeoServer WFS service. http://docs.geoserver.org/latest/en/user/services/wfs/ On Tue, Mar 15, 2016 at 11:46 AM Sayon Kumar wrote: > Hello, > > This is a doubt from the end-user perspective. > > I can create a

Re: [Geotools-devel] Customization of the CREATE TABLE

Hi Sayon, Generally we ask that any new feature or bug fix come with a test case. However the change in this case is being made to an abstract base class so I imagine will be hard to test. I suggest you submit the changes you have currently as a pull request and we can see if there might be an ea

Re: [Geotools-devel] Improving parsing GML files without a reference to the schema

On Sun, Jan 31, 2016 at 2:37 AM Andrea Aime wrote: > On Fri, Jan 29, 2016 at 4:00 PM, Justin Deoliveira > wrote: > >> These could be added as new methods to the GML facade class: >>> SimpleFeatureType GML.decodeSchema(InputStream in) >>> SimpleFeatureColle

Re: [Geotools-devel] Improving parsing GML files without a reference to the schema

Hey Andrea, Some comments/questions inline. On Fri, Jan 29, 2016 at 4:44 AM Andrea Aime wrote: > Hi, > I'm looking into improving our ability to parse GML files whose reference > to the schema is invalid or unreachable, in other words, not usable. > > Right now the parser generates a feature co

Re: [Geotools-devel] Processes for classification

it should be pretty easy to add following the pattern of the current 3 algorithms. > > These modules are still considered unsupported so procedure is pretty > light :) > Cool. I’ll wait a bit more for other feedback and merge if no-one objects. > > -- > Jody Garnett > >

Re: [Geotools-devel] jts update from locationtech sprint

Not sure if you need a second but I second that! On Tue, Jan 26, 2016 at 2:43 PM Jody Garnett wrote: > Hanging out with Martin at the locationtech sprint ... over time JTS has > forked a couple classes from GeoTools: > > - SDO - oracle STRUCT to Geometry conversion > - Shapefile - the origional

[Geotools-devel] Processes for classification

Hi folks, Recently I have been given the opportunity to resurrect some code I wrote a long time back. The code in question adds two processes (one vector, one raster) that breaks input data into a number of classes (ranges). For each range a count of features/pixels is calculated, in addition to a

  1   2   3   4   5   6   7   8   9   10   >