Re: [Geotools-devel] A SVG based mark factory

Hi, following up a year later... "A relative path in a well known name" -> yes, because external graphic does not extract a shape that can be filled and stroked, but a final image to be used "as is". The job of returning a shape is WellKnownMark one. (which is common knowledge to anyone doing styl

Re: [Geotools-devel] A SVG based mark factory

A relative path in a well known name? Is it possible to use external graphic? -- Jody Garnett On 30 July 2017 at 13:17, Andrea Aime wrote: > Hi, > working on some OSM styling I've found that nowadays OSM uses mostly > SVG based icons. > The icons are "black", but the CartoCSS style associates t

Re: [Geotools-devel] A SVG based mark factory

Looks good to me, and is a useful upgrade to existing SVG usage too. Ian On 30 July 2017 at 21:17, Andrea Aime wrote: > Hi, > working on some OSM styling I've found that nowadays OSM uses mostly > SVG based icons. > The icons are "black", but the CartoCSS style associates them with a > color, e

[Geotools-devel] A SVG based mark factory

Hi, working on some OSM styling I've found that nowadays OSM uses mostly SVG based icons. The icons are "black", but the CartoCSS style associates them with a color, e.g.: [feature = 'amenity_biergarten'][zoom >= 17] { marker-file: url('symbols/biergarten.svg'); marker-fill: @amenity-bro

Re: [Geotools-devel] A few changes coming to the CSS module (and then its graduation)

e- > > From: Andrea Aime [mailto:[email protected]] > > Sent: Monday, 5 June 2017 15:52 > > To: Ben Caradoc-Davies > > Cc: Geotools-Devel list > > Subject: Re: [Geotools-devel] A few changes coming to the CSS module (and > > then its graduation)

Re: [Geotools-devel] A few changes coming to the CSS module (and then its graduation)

, 5 June 2017 15:52 > To: Ben Caradoc-Davies > Cc: Geotools-Devel list > Subject: Re: [Geotools-devel] A few changes coming to the CSS module (and > then its graduation) > > On Sun, Jun 4, 2017 at 10:58 PM, Ben Caradoc-Davies <mailto:[email protected]> > wrote: > > &

Re: [Geotools-devel] A few changes coming to the CSS module (and then its graduation)

On Sun, Jun 4, 2017 at 10:58 PM, Ben Caradoc-Davies wrote: > Andrea, > > do you mean "m" for "milli"? The SI prefix for "micro" is "µ". > Yep, you're right, sorry! Anyhow, what do we do about that feedback? Cheers Andrea -- == GeoServer Professional Services from the experts! Visit http://goo

Re: [Geotools-devel] A few changes coming to the CSS module (and then its graduation)

Andrea, do you mean "m" for "milli"? The SI prefix for "micro" is "µ". Kind regards, Ben. On 04/06/17 19:28, Andrea Aime wrote: So we have feedback from Brad on the pull request: https://github.com/geotools/geotools/pull/1615#issuecomment-306006167 Should we keep m for "micro"? Hum... cartogr

Re: [Geotools-devel] A few changes coming to the CSS module (and then its graduation)

So we have feedback from Brad on the pull request: https://github.com/geotools/geotools/pull/1615#issuecomment-306006167 Should we keep m for "micro"? Hum... cartography speaking it would make no sense I believe, but indeed there are application using mapping like tools for the very large objects,

Re: [Geotools-devel] A few changes coming to the CSS module (and then its graduation)

Here we go with the scale dependency related work: https://github.com/geotools/geotools/pull/1615 A GeoServer pull request will follow with updated documentation. Cheers Andrea On Tue, May 30, 2017 at 8:06 PM, Andrea Aime wrote: > On Sun, May 28, 2017 at 10:30 PM, Ben Caradoc-Davies > wrote:

Re: [Geotools-devel] A few changes coming to the CSS module (and then its graduation)

On Sun, May 28, 2017 at 10:30 PM, Ben Caradoc-Davies wrote: > If you want SI then it should be "k" and "M" and "G". Personally I find > lowercase to be more readable. I say accept both, but then I also prefer > 1e10. :-) > Hum... and G would be useful for scale dependencies on a map of... Jupit

Re: [Geotools-devel] A few changes coming to the CSS module (and then its graduation)

I see where you are going with removing the "-gt-" prefix, and yeah this is a rendering language specifically for the geoserver renderer - no need to reference the SLD portability questions at all. aside: The 100k is a great idea, perhaps we can encourage YSLD to adopt it. -- Jody Garnett On 28

Re: [Geotools-devel] A few changes coming to the CSS module (and then its graduation)

On 29/05/17 01:16, Andrea Aime wrote: - Scale denominator numbers can be long and that makes them hard to read. Who can say, without counting the zeros, if 1000 is 1 billion, 10 millions, 1 million? I am going to allow a shortcut syntax with k and m specifiers, e.g 10m, that shoul

Re: [Geotools-devel] A few changes coming to the CSS module (and then its graduation)

On Sun, May 28, 2017 at 2:24 PM, Nuno Oliveira < [email protected]> wrote: > Hi Andrea, > > Some small comments in-line ... > > On 28-05-2017 09:04, Andrea Aime wrote: > > Hi, > I am working on a large-ish CSS style, that gave me the opportunity to > observe a few annoying bits in the

Re: [Geotools-devel] A few changes coming to the CSS module (and then its graduation)

Hi Andrea, Some small comments in-line ... On 28-05-2017 09:04, Andrea Aime wrote: Hi, I am working on a large-ish CSS style, that gave me the opportunity to observe a few annoying bits in the syntax. I set out to fix those, in particular: * Scale denominator numbers can be long and that ma

[Geotools-devel] A few changes coming to the CSS module (and then its graduation)

Hi, I am working on a large-ish CSS style, that gave me the opportunity to observe a few annoying bits in the syntax. I set out to fix those, in particular: - Scale denominator numbers can be long and that makes them hard to read. Who can say, without counting the zeros, if 1000 is 1 bil

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

Wonder if we split the "hint" into two - one for evaluating and one for writing. I am saying evaluating (rather than parsing) since the issue is found when mbstyle constructs a filterfactory.literal("red"). The mbstyle parser cannot control the use of hints when the renderer uses the resulting Ex

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

On Tue, Apr 25, 2017 at 4:05 PM, Jody Garnett wrote: > I do not mind, it has the "danger" of making people write non standard SLD > files. > I don't see it as a big problem per se, we are not OGC cops (otherwise we would not have any vendor option), as long as the documentation is clear that usi

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

I do not mind, it has the "danger" of making people write non standard SLD files. I know the SLD spec says it supports SvgParameters but they only have examples of hex: *The “stroke” SvgParameter element gives the solid color that will be used for a stroke. The color value is RGB-encoded using tw

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

Wondering if there is an actual need for a function to start with. What's the harm in just allowing the CSS color converter to be used as normal? it would allow named color usage in all styling languages. Cheers Andrea --

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

I do want to move that function into the mix - but wanted to ask about naming it correctly first. Now that you have a bunch more functions the conversation becomes more important :) I was thinking about naming it "css" (since it speaks a wide range of css string representations), rather than "colo

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

On Mon, Apr 24, 2017 at 7:34 AM, Jody Garnett wrote: > That is interesting, I just made a function similar in nature here: > > - https://github.com/geotools/geotools/blob/master/modules/ > unsupported/mbstyle/src/main/java/org/geotools/mbstyle/ > function/ColorFunction.java > > We should combine

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

That is interesting, I just made a function similar in nature here: - https://github.com/geotools/geotools/blob/master/modules/unsupported/mbstyle/src/main/java/org/geotools/mbstyle/function/ColorFunction.java We should combine forces. -- Jody Garnett On 23 April 2017 at 02:46, Andrea Aime wro

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

[Geotools-devel] A bunch of color operation functions

Hi, this pull request adds a bunch of lesscss.org color operation functions: https://github.com/geotools/geotools/pull/1562 At first I was thinking to add them in the CSS module, but realized I could actually just make them standard GeoTools functions and add some syntactic sugar to the CSS module

Re: [Geotools-devel] A quick question on GEOT-724 (PR 1228)

On 16-09-16 10:53, Mark Prins wrote: > I can prep backport pull requests for the branches if there is interest > so it can be included in 15.2 I've gone ahead and prepared backport PR's since 15.2 release is planned shortly https://github.com/geotools/geotools/pull/1312 https://github.com/geoto

[Geotools-devel] A quick question on GEOT-724 (PR 1228)

Hi, Ian prepared/merged a fix for empty/null geometries in Oracle in PR 1228 [ https://github.com/geotools/geotools/pull/1228], closing Jira GEOT-724 [ https://osgeo-org.atlassian.net/browse/GEOT-724]. Jira tells me that this was fixed for 16-M0 I'm trying to find out is this was backported to 15.x

Re: [Geotools-devel] A bug in the WFS_1_1_0_DataStore class?

Thanks for this Andrea. Yes the code I was talking about is from gt-wfs. We'll have a go at porting our code to gt-wfs-ng and see how it goes. Thanks again for this. Regards, Gerson On Thu, May 14, 2015 at 6:19 PM, Andrea Aime wrote: > On Thu, May 14, 2015 at 1:40 AM, Gerson Galang > wrote:

Re: [Geotools-devel] A bug in the WFS_1_1_0_DataStore class?

On Thu, May 14, 2015 at 2:43 PM, Jody Garnett wrote: > I am happy to drop gt-wfs. Now if we can just port gt-wms to the gtxml > parser we can remove one of our xml parsing stacks. > You mean gt-xsd right? Might be annoying, we need XML schemas and WMS 1.1 is DTD based... there are tools to do th

Re: [Geotools-devel] A bug in the WFS_1_1_0_DataStore class?

I am happy to drop gt-wfs. Now if we can just port gt-wms to the gtxml parser we can remove one of our xml parsing stacks. On Thu, May 14, 2015 at 1:20 AM Andrea Aime wrote: > On Thu, May 14, 2015 at 1:40 AM, Gerson Galang > wrote: > >> Hi guys, >> >> I sent this yesterday to the users list but

Re: [Geotools-devel] A bug in the WFS_1_1_0_DataStore class?

On Thu, May 14, 2015 at 1:40 AM, Gerson Galang wrote: > Hi guys, > > I sent this yesterday to the users list but sending it here might be > more appropriate. I'd like to get your advice if I should create a > jira ticket for this. > Hi Gerson, am I correct in saying this is gt-wfs, and not gt-wf

[Geotools-devel] A bug in the WFS_1_1_0_DataStore class?

Hi guys, I sent this yesterday to the users list but sending it here might be more appropriate. I'd like to get your advice if I should create a jira ticket for this. Thanks, Gerson -- Forwarded message -- From: Gerson Galang Date: Wed, May 13, 2015 at 3:16 PM Subject: A bug in

Re: [Geotools-devel] A pull request to speed up GML encoding speed for simple features

No problem, just trying to check if the project is alive. On Tue, Apr 21, 2015 at 11:12 PM Andrea Aime wrote: > On Tue, Apr 21, 2015 at 11:00 PM, Jody Garnett > wrote: > >> Dived into looking at the pull request ... one question for the email >> list: >> >> The code uses PicoContainer - isn'tt

Re: [Geotools-devel] A pull request to speed up GML encoding speed for simple features

On Tue, Apr 21, 2015 at 11:00 PM, Jody Garnett wrote: > Dived into looking at the pull request ... one question for the email list: > > The code uses PicoContainer - isn'tt that is rather dead by this time - > is pico container still earning its keep here? > The whole binding architecture is ba

Re: [Geotools-devel] A pull request to speed up GML encoding speed for simple features

Dived into looking at the pull request ... one question for the email list: The code uses PicoContainer - isn'tt that is rather dead by this time - is pico container still earning its keep here? The project movie to github (https://github.com/picocontainer/picocontainer) although a lot is still

[Geotools-devel] A pull request to speed up GML encoding speed for simple features

Hi, as you are probably aware, our gt-xsd encoding performance is not exactly stellar, and lags quite a bit behind the old FeatureTranslator approach. A few years ago Justin tried an approach to speed up simple feature encoding, as that provides a predictable structure that we can leverage to avoi

Re: [Geotools-devel] A possibly simple fix for the postgis online test cases hidden failure

On 14/04/15 00:52, Andrea Aime wrote: > On Mon, Apr 13, 2015 at 1:04 AM, Ben Caradoc-Davies >> I would be happier if we made an even more brutal refactoring: a test with >> a fixture always runs; the *OnlineTest name pattern is used to turn on some >> classes with -Ponline. No more silent failures

Re: [Geotools-devel] A possibly simple fix for the postgis online test cases hidden failure

On Mon, Apr 13, 2015 at 1:04 AM, Ben Caradoc-Davies wrote: > On 13/04/15 01:07, Andrea Aime wrote: > >> Basically I would switch the test to simply: >> if (available == null || available.booleanValue()) { << >> here! >> This way once "available" has been set, we stay that way for th

Re: [Geotools-devel] A possibly simple fix for the postgis online test cases hidden failure

On 13/04/15 01:07, Andrea Aime wrote: > Basically I would switch the test to simply: > if (available == null || available.booleanValue()) { << here! > This way once "available" has been set, we stay that way for the rest of > the test. That looks unchanged to me. You mean change this

Re: [Geotools-devel] A possibly simple fix for the postgis online test cases hidden failure

Some buds good, make a note in the test fixture docs, glad to address this in the super class On Sun, Apr 12, 2015 at 6:08 AM Andrea Aime wrote: > Hi, > as you probably know the current blue state of the geotools online build > is due, among other > things, to the postgis tests switching to offli

[Geotools-devel] A possibly simple fix for the postgis online test cases hidden failure

Hi, as you probably know the current blue state of the geotools online build is due, among other things, to the postgis tests switching to offline mode mid way because the jndi test fails the onlin test, causing all other tests to be skipped: Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time

Re: [Geotools-devel] A bit of a mess in coverage related proposals

Hi again, the 2 proposals are ready: *Views manager cleanup:* *Proposal:* http://docs.codehaus.org/display/GEOTOOLS/Views+Management+removal *Associated JIRA:* https://jira.codehaus.org/browse/GEOT-5050 *Related pull request* https://github.com/geotools/geotools/pull/782 *JAI-EXT integration:*

Re: [Geotools-devel] A bit of a mess in coverage related proposals

Daniele, just a quick clarification, we would be deprecating views on 13.x, and just drop them on 14.x, and there would be no jai-ext work on 13.x So, it would be two very different pull requests, the 13.x being just adding @Deprecated annotations around for anything we'd be dropping in 14.x Cheer

Re: [Geotools-devel] A bit of a mess in coverage related proposals

Hi Team, Nicola is working on setting up 2 proposals: One for the viewsType deprecation and the other for the JAI-EXT integration. He will come back as soon as possible (tomorrow or the next day) with links to the Confluence pages containing them. We haven't done that before since we had originally

Re: [Geotools-devel] A bit of a mess in coverage related proposals

Ciao Jody, I have put this in Daniele and Nicola's hands as I don't have time for this atm. They will follow up shortly. Regards, Simone Giannecchini == GeoServer Professional Services from the experts! Visit http://goo.gl/NWWaa2 for more information. == Ing. Simone Giannecchini @simogeo Founder/

Re: [Geotools-devel] A bit of a mess in coverage related proposals

So what specifically do you want to deprecate. Reply to the email or send a pull request, need to deprecate now to be in position to remove later. On Sat, Mar 14, 2015 at 4:21 AM Simone Giannecchini < [email protected]> wrote: > Ciao Jody, > that would be _great_. > > Regards, >

Re: [Geotools-devel] A bit of a mess in coverage related proposals

Ciao Jody, that would be _great_. Regards, Simone Giannecchini == GeoServer Professional Services from the experts! Visit http://goo.gl/NWWaa2 for more information. == Ing. Simone Giannecchini @simogeo Founder/Director GeoSolutions S.A.S. Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phon

Re: [Geotools-devel] A bit of a mess in coverage related proposals

Okay, As an emergency release next week measure can we at least deprecate the ViewType interfaces for the GeoTools 13.0 release. That would allow us to drop the class for GeoTools 14.0 Jody -- Jody Garnett On 13 March 2015 at 12:04, Andrea Aime wrote: > Hi, > so we have a separate thread that

[Geotools-devel] A bit of a mess in coverage related proposals

Hi, so we have a separate thread that contains actually two proposed changes: * One by Daniele to drop the ViewType * One by Nicola to switch to jai-ext Both are in the wrong place... they should be proposals in Confluence, so that we can vote on them, and they should be discussed in two separate

Re: [Geotools-devel] A dropSchema equivalent for coverages

Actually there is an enum set that can be used in this case. But yeah do what is needed, I just hate boolean (true|false) or Boolean(true|false|null) as an exercise in API confusion. -- Jody Garnett On 19 February 2015 at 08:43, Andrea Aime wrote: > On Thu, Feb 19, 2015 at 5:28 PM, Jody Garnett

Re: [Geotools-devel] A dropSchema equivalent for coverages

On Thu, Feb 19, 2015 at 5:28 PM, Jody Garnett wrote: > delete(SUPPORT_FILES) > delete(DATA) > delete(CASCADE) > delete(DATA|SUPPORT_FILES|CASCADE) > Yes, that's where I wanted to go... if you are or-in elements, then it's not a Java enum, but an integer parameter with a old style enum as static

Re: [Geotools-devel] A dropSchema equivalent for coverages

delete(SUPPORT_FILES) delete(DATA) delete(CASCADE) delete(DATA|SUPPORT_FILES|CASCADE) -- Jody Garnett On 19 February 2015 at 07:46, Andrea Aime wrote: > On Thu, Feb 19, 2015 at 4:44 PM, Jody Garnett > wrote: > >> I would prefer an enum to a Boolean. Allows the code to be clear and >> gives you

Re: [Geotools-devel] A dropSchema equivalent for coverages

Ciao Andrea, please, read below Regards, Simone Giannecchini == GeoServer Professional Services from the experts! Visit http://goo.gl/NWWaa2 for more information. == Ing. Simone Giannecchini @simogeo Founder/Director GeoSolutions S.A.S. Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy p

Re: [Geotools-devel] A dropSchema equivalent for coverages

good point Jody. Regards, Simone Giannecchini == GeoServer Professional Services from the experts! Visit http://goo.gl/NWWaa2 for more information. == Ing. Simone Giannecchini @simogeo Founder/Director GeoSolutions S.A.S. Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 96231

Re: [Geotools-devel] A dropSchema equivalent for coverages

I would prefer an enum to a Boolean. Allows the code to be clear and gives you the option to grow the functionality in the future. On Thu, Feb 19, 2015 at 7:42 AM Simone Giannecchini < [email protected]> wrote: > Ciao Andrea, > please, read below > > > Regards, > Simone Gian

Re: [Geotools-devel] A dropSchema equivalent for coverages

On Thu, Feb 19, 2015 at 4:44 PM, Jody Garnett wrote: > I would prefer an enum to a Boolean. Allows the code to be clear and gives > you the option to grow the functionality in the future. > With values SupportFiles, and DataAndSupportFiles? What would the future options be, can you make one exam

[Geotools-devel] A dropSchema equivalent for coverages

Hi, as you know around a year we added dropSchema call to dataStore, allowing clients to remove tables/files from the store. Right now we have an equivalent for coverages only in StructuredGridCoverage2DReader: /** * delete all stuff (database content, indexer files, property files, asso

Re: [Geotools-devel] A couple of questions about circular geometries integration

I would prefer to to go with your suggestion, we intend to make this a system wide change. I would also like to document these new classes (briefly!) on our geometry page. Once you have them in I will see if I can update the cla

[Geotools-devel] A couple of questions about circular geometries integration

Hi, two quick questions, do you mind if: 1) I modify WKTReader2 to parse directly into the new curved geometries, instead of linearizing on the fly during the parse 2) Have GeometryConverterFactory use WTKReader2 when converting strings to geometries The two changes above would allow us to have th

Re: [Geotools-devel] A long overdue fix for envelope reprojection

Wonderful, can I ask if you have deprecated the math transform method? Jody Garnett On Thu, May 15, 2014 at 5:05 AM, Andrea Aime wrote: > Hi, > in our existing code base there is a number of places where envelopes > are being reprojected using the method: > CRS.transform(mathTransform, envelope

Re: [Geotools-devel] A long overdue fix for envelope reprojection

On Thu, May 15, 2014 at 4:33 PM, Jody Garnett wrote: > Wonderful, can I ask if you have deprecated the math transform method? > We cannot. From my original mail: -- CRS.transform(mathTransform, envelope) This method is fine for a class of transformations, such as affine transforms

[Geotools-devel] A long overdue fix for envelope reprojection

Hi, in our existing code base there is a number of places where envelopes are being reprojected using the method: CRS.transform(mathTransform, envelope) This method is fine for a class of transformations, such as affine transforms (extensively used to apply grid to world transforms in rasters) and

[Geotools-devel] a few more headers to fix

Once again from off-list: geotools-9.3\modules\library\main\src\main\java\org\geotools\util\EnumerationConverterFactory.java geotools-9.3\modules\unsupported\process-raster\src\main\java\org\geotools\process\raster\BaseCoverageAlgebraProcess.java geotools-9.3\modules\unsupported\process-raster\sr

[Geotools-devel] A pull request with scalability related improvements

Hi, while working on some benchmarks for an improved pisces renderer for OpenJDK 8 (see http://mail.openjdk.java.net/pipermail/2d-dev/2013-June/003475.html, sorry for the table formatting, it's HTML...) I stumbled into three significant roadblocks in the GeoTools code base that limited scalability,

Re: [Geotools-devel] A patch for whole layer transparency and skipping label rendering

> > This would allow to perform the change in a well centralized place without > > having to > > mess with the rendering code and pass everywhere the hidelabels flag like > > the patch does. > > > > Unfortunately there is no support for VendorOption in FeatureTypeStyle > in current GeoTools versi

Re: [Geotools-devel] A patch for whole layer transparency and skipping label rendering

Thursday, September 27, 2012, 7:19:03 AM, you wrote: > On Mon, Sep 24, 2012 at 7:28 AM, Sebastian Graca wrote: >> I have created a patch for GeoTools which implements whole layer >> transparency (for layers and labels) and allows to skip label rendering >> for a layer. The patch is submitted as

Re: [Geotools-devel] A patch for whole layer transparency and skipping label rendering

On Mon, Sep 24, 2012 at 7:28 AM, Sebastian Graca wrote: > Hello! > > I have created a patch for GeoTools which implements whole layer > transparency (for layers and labels) and allows to skip label rendering > for a layer. The patch is submitted as a github pull request > https://github.com/geoto

Re: [Geotools-devel] A patch for whole layer transparency and skipping label rendering

Evening Sebastian: uDig has the two bits of functionality you describe. 1) for layer transparency, we render each layer into a separate raster (allowing rendering to be performed in several threads). As part of a separate composition step we can control transparency. For example we can raid out

[Geotools-devel] A patch for whole layer transparency and skipping label rendering

Hello! I have created a patch for GeoTools which implements whole layer transparency (for layers and labels) and allows to skip label rendering for a layer. The patch is submitted as a github pull request https://github.com/geotools/geotools/pull/32 Andrea asked me to explain what I try to do, so

Re: [Geotools-devel] A question about H2 GeoDB and ArcGIS geodatabase alternatives in open source

Hi Vitali, While the GeoDB project does not have too many users at this point, it is continuing to grow with interest, increased mailing activity, etc... The most notable user is the hibernate spatial project which provides a dialect for geodb. The current state of the H2/GeoDB datastore is that i

[Geotools-devel] A question about H2 GeoDB and ArcGIS geodatabase alternatives in open source

Hi. I am looking for a technological solution of an embedded database with spatial data support to be used within a custom UDIG-based application as a single data storage (of simple features with geometries and other tabular metadata) with an ability for UDIG to work with feature layers thro

Re: [Geotools-devel] a doubt about examples in cql/ecql sphinx docs

For reference here was my "review" (mostly making the code example line up with the bullet point they refer to. Let me review; you have the following: * Filter using a text pattern: .. literalinclude:: /../src/main/java/org/geotools/cql/ECQLExamples.java :language: java :start-after: // ecql l

Re: [Geotools-devel] a doubt about examples in cql/ecql sphinx docs

On Monday, May 02, 2011 01:13:44 pm Jody Garnett wrote: > Oh we should have these discussions on the email list; so others can swap > tips as well. > Ok, I am CC this to geotools-devel list > > Hello Jody, axios have taken some free day. Today we have gone back to > > work. > > > > I would like

Re: [Geotools-devel] a couple of inconsistencies around factory finders

On Sun, Feb 27, 2011 at 2:48 PM, Jody Garnett wrote: > In reviewing docs for the user guide I have looked over the various factory > finders currently in play and found some duplication. > > CommonFactoryFinder has a register with FileDataStore > (which FileDataStoreFinder uses which is nice). How

[Geotools-devel] a couple of inconsistencies around factory finders

In reviewing docs for the user guide I have looked over the various factory finders currently in play and found some duplication. CommonFactoryFinder has a register with FileDataStore (which FileDataStoreFinder uses which is nice). However it would be better to do the same thing as DataStoreFin

Re: [Geotools-devel] A patch for gt-process and some discussion

Andrea Aime ha scritto: > Michael Bedward ha scritto: >> Hi Andrea et al, >> >> Thanks for looking at ways to improve the process module ! >> >> I'm happy with your comments about both VectorToRaster and RasterToVector. >> >> I would much prefer to have FeatureSource used rather than >> FeatureColl

Re: [Geotools-devel] A patch for gt-process and some discussion

Michael Bedward ha scritto: > Hi Andrea et al, > > Thanks for looking at ways to improve the process module ! > > I'm happy with your comments about both VectorToRaster and RasterToVector. > > I would much prefer to have FeatureSource used rather than > FeatureCollection unless that presents big

Re: [Geotools-devel] A patch for gt-process and some discussion

Hi Andrea et al, Thanks for looking at ways to improve the process module ! I'm happy with your comments about both VectorToRaster and RasterToVector. I would much prefer to have FeatureSource used rather than FeatureCollection unless that presents big problems for others. Michael

Re: [Geotools-devel] A patch for gt-process and some discussion

I am going to wait for Jim to answer that one; i can see the use for it if you are writing a super specific process for a custom deployment (something like fetch me the PDF reports for this county; and you pass in the county). But here is the thing; in these cases the user has already defined a

Re: [Geotools-devel] A patch for gt-process and some discussion

Jody Garnett ha scritto: > Only thing I would add is Geometry parameters. Oh, and what about Feature parameters? There is one example process that deals with the single feature... having a hard time deciding whether it's just a bad idea and feature collections should suffice, or if there is an act

Re: [Geotools-devel] A patch for gt-process and some discussion

Jody Garnett ha scritto: > Only thing I would add is Geometry parameters. Oh right, roger that. > There is a common way to package up geometry provided by the WPS > implementations like 52N. It is basically a small schema that allows a single > geometry element to be passed in or out of a proce

Re: [Geotools-devel] A patch for gt-process and some discussion

Only thing I would add is Geometry parameters. There is a common way to package up geometry provided by the WPS implementations like 52N. It is basically a small schema that allows a single geometry element to be passed in or out of a process. Jim will know more. Jody On 11/06/2010, at 11:19

Re: [Geotools-devel] A patch for gt-process and some discussion

Andrea Aime wrote: > In general, to allow a client to describe and handle all the inputs > and output of the processes there has to be some agreement on what > data types are supported and how to handle multiplicity. And I forgot to deal with multiplicity. First off, if a parameter is marked as o

Re: [Geotools-devel] A patch for gt-process and some discussion

Hi Andrea, I am reading with interest this email, since I am nowadays extracting all the JGrass processing power into a library that implements for every module also the geotools process api. My choice in the lib has been to rely on FeatureCollection and GridCoverage2D, so I understand what you mea

[Geotools-devel] A patch for gt-process and some discussion

Hi, this week I've tried to make some of the processes in gt-process run in GeoServer, as they presented some decent variety in input and outputs. I succeded with some of them and found out a few issues in the processes that the attached patch fixes. The patch however does not contain only fixes

Re: [Geotools-devel] A missing bit in the SimpleFeatureSource switch?

Good catch; it was not intended. Jody On 27/05/2010, at 8:35 PM, Andrea Aime wrote: > Hi, > today I noticed there is still one non simple bit in the > SimpleFeatureSource family: getDataStore() still returns > DataAccess instead > of just a DataStore. > > Is this intended? I did not check the co

[Geotools-devel] A missing bit in the SimpleFeatureSource switch?

Hi, today I noticed there is still one non simple bit in the SimpleFeatureSource family: getDataStore() still returns DataAccess instead of just a DataStore. Is this intended? I did not check the consequences Cheers Andrea -- Andrea Aime OpenGeo - http://opengeo.org Expert service straight from

Re: [Geotools-devel] A plan for docs

Comments inline; but yes we all agree about the direction. Where we are stuck is on some of the details. On 26/05/2010, at 9:12 AM, Justin Deoliveira wrote: > doc/ > user/ > devel/ > web/ Agreed. trunk/web would be the current website trunk/devel would be the current developers guide 2.6

[Geotools-devel] A plan for docs

Hi all, Continuing with discussion from the "GeoTools 2.6.4 Released" side thread about documentation. So the consencus seems to be to have a top level doc module that would have three submodules: doc/ user/ devel/ web/ I agree that this is probably the easiest way forward. Having do

Re: [Geotools-devel] A couple of questions on DbaseFileHeader

Sunburned Surveyor ha scritto: > I had a couple quick questions on the DbaseFileHeader class: > > - Is there a specific Charset I should be using as a parameter to the > constructor of this class. Right now I am just using the default > Charset object returned by the Charset.defaultCharset method.

Re: [Geotools-devel] A couple of questions on DbaseFileHeader

The DBF header has some indication of charset; however it is often wrecked by programs. We found the only thing to do was allow people to override the default on a case by case basis (when working in eastern multibyte encodings). Often an application will contain a default charset - since a

[Geotools-devel] A couple of questions on DbaseFileHeader

I had a couple quick questions on the DbaseFileHeader class: - Is there a specific Charset I should be using as a parameter to the constructor of this class. Right now I am just using the default Charset object returned by the Charset.defaultCharset method. Forgive me if this is obvious, as I don'

Re: [Geotools-devel] A new style builder

Andrea Aime ha scritto: Doh, during the holiday I coded the builder I was talking about almost fully (it just misses support for text and raster symbolizers). I don't have the code handy right now but I'll post it tomorrow or Monday. Where is yours so that I can have a look at it? Here is the

Re: [Geotools-devel] A new style builder

It is called SLDContentManager; and SLDs (and SLD which was already ported to GeoTools); and I found a few other helper methods. I was bundling them all into SLDContentManager (in uDig net.refractions.udig.style.sld plugin). Mostly this was clean up; documentation; test case work. But as I

Re: [Geotools-devel] A new style builder

That is fun; post it when you get a chance - I am mostly interested in ensuring I only have one to worry about (and that it has good test coverage). Glad you enjoyed your holiday, Jody On Sun, Jul 19, 2009 at 3:10 AM, Andrea Aime wrote: > Jody Garnett ha scritto: >> >> Hi Andrea: >> >> A small up

Re: [Geotools-devel] A new style builder

Jody Garnett ha scritto: > Hi Andrea: > > A small update on this one - I have focused the last week on improving > the uDig style editing story. And have turned up not one; not two; but > three helper classes all of which fall into the roll of a "Builder" for > style. > > I am collapsing them

Re: [Geotools-devel] A new style builder

Hi Andrea: A small update on this one - I have focused the last week on improving the uDig style editing story. And have turned up not one; not two; but three helper classes all of which fall into the roll of a "Builder" for style. I am collapsing them all into one right now; now while it i

Re: [Geotools-devel] A new style builder

+1, I think it is a great idea, something I have thought of before as well. Currently #2 on my builder list right after a concise geometry builder :). -Justin Andrea Aime wrote: > Hi all, > many years ago pissed off by how hard it was to build > styles with code I created the StyleBuilder we ha

Re: [Geotools-devel] A new style builder

Ciao Andrea, don't worry, I don't think you should create a proposal for this. Simone. --- Ing. Simone Giannecchini GeoSolutions S.A.S. Owner - Software Engineer Via Carignoni 51 55041 Camaiore (LU) Italy phone: +39 0584983027 fax: +39 058

Re: [Geotools-devel] A new style builder

Simone Giannecchini ha scritto: > +1, just out of curiosity are you going to build a fully fledged > proposal for this? For a 4 classes builder? Hmmm... I did not think I would need to, but if you really want, I'll make one :) Cheers Andrea -- Andrea Aime OpenGeo - http://opengeo.org Expert ser

  1   2   3   >