[Geotools-devel] [jira] (GEOT-4823) Support large time values in netCDF files

[Shane StClair (JIRA)]

Title: Message Title










 

 Shane StClair created an issue











 






 GeoTools /  GEOT-4823



  Support large time values in netCDF files 










Issue Type:

  Improvement




Affects Versions:


 12-beta




Assignee:

 Simone Giannecchini




Components:


 coverage




Created:


 11/Jun/14 8:54 PM




Fix Versions:


 12-beta




Priority:

  Minor




Reporter:

 Shane StClair










Currently ints are used to calculate times in netCDF files. Since netCDF typically uses "since" units for time, time values can be very large and are often larger then Integer.MAX_VALUE (e.g. when using "seconds since 1900-01-01T00:00:00Z").
Time creation should be changed to use longs so that larger values can be properly read, and an exception should be thrown if we're converting a long value to an int and we lose data.











  

Re: [Geotools-devel] Request for Feedbacks: integrating unsupported's gt-mark-wkt into gt-render

[Jody Garnett]

Thanks Daniele I have been meaning to do that for a while. Keep in mind we
should update the docs.

Jody Garnett


On Thu, Jun 12, 2014 at 2:22 AM, Daniele Romagnoli <
daniele.romagn...@geo-solutions.it> wrote:

> Hi Guys,
> We would like to move the code available on mark-wkt module within
> gt-render.
> It is widely used by styles defined to render marks such as arrows,
> circles, and other shapes in general (based on WKT definitions).
>
> Moreover, we have worked on a submodule which allows to render windbarbs:
> http://en.wikipedia.org/wiki/Station_model#mediaviewer/File:Wind_barbs.gif
> Some samples here:
>
> http://www.geo-solutions.it/blog/developers-corner-supporting-wind-barbs-geoserver-geotools/
>
> Having these rendered additions integrated in gt-render module would
> represent a great improvement of the rendering engine capabilities.
> In addition, this will also avoid the need of building that part
> separately and manually integrate its jar within  the geoserver war
>
> Mark-WKT dependencies reported by maven dependency:tree
> =
>
> [INFO]
> 
> [INFO] *Building WKT symbols addition to the renderer 12-SNAPSHOT*
> [INFO]
> 
> [INFO] org.geotools:gt-mark-wkt:jar:12-SNAPSHOT
> [INFO] +- org.geotools:gt-main:jar:12-SNAPSHOT:compile
> [INFO] |  +- org.geotools:gt-api:jar:12-SNAPSHOT:compile
> [INFO] |  |  \- org.geotools:gt-referencing:jar:12-SNAPSHOT:compile
> [INFO] |  | +- java3d:vecmath:jar:1.3.2:compile
> [INFO] |  | +- commons-pool:commons-pool:jar:1.5.4:compile
> [INFO] |  | +- org.geotools:gt-metadata:jar:12-SNAPSHOT:compile
> [INFO] |  | |  \- org.geotools:gt-opengis:jar:12-SNAPSHOT:compile
> [INFO] |  | | \-
> net.java.dev.jsr-275:jsr-275:jar:1.0-beta-2:compile
> [INFO] |  | \- jgridshift:jgridshift:jar:1.0:compile
> [INFO] |  +- com.vividsolutions:jts:jar:1.13:compile
> [INFO] |  \- org.jdom:jdom:jar:1.1.3:compile
> [INFO] +- org.geotools:gt-sample-data:jar:12-SNAPSHOT:test
> [INFO] +- org.geotools:gt-render:jar:12-SNAPSHOT:compile
> [INFO] |  +- org.geotools:gt-coverage:jar:12-SNAPSHOT:compile
> [INFO] |  |  +- javax.media:jai_imageio:jar:1.1:compile
> [INFO] |  |  +-
> it.geosolutions.imageio-ext:imageio-ext-tiff:jar:1.1.10:compile
> [INFO] |  |  |  +-
> it.geosolutions.imageio-ext:imageio-ext-utilities:jar:1.1.10:compile
> [INFO] |  |  |  \- javax.media:jai_codec:jar:1.1.3:compile
> [INFO] |  |  +- org.jaitools:jt-zonalstats:jar:1.3.1:compile
> [INFO] |  |  \- org.jaitools:jt-utils:jar:1.3.1:compile
> [INFO] |  \- org.geotools:gt-cql:jar:12-SNAPSHOT:compile
> [INFO] \- javax.media:jai_core:jar:1.1.3:compile
>
> As you can see, there are no unsupported or weird dependencies inherited
> by that module.
> Only core one such as main, and render itself.
>
> About code coverage, this is the cobertura report:
>
> Package # Classes Line Coverage  Branch Coverage
>  Complexity  *All Packages*7 74%
> 389/520
>  59%
> 176/298
> 9,923org.geotools.renderer.markwkt
>  3 88%
> 105/119
> 73%
> 25/34
> 4,571 org.geotools.renderer.windbarbs
>  4 70%
> 284/401
>  57%
> 151/264
> 11,895
> What do you think about it?
> (Obviously, a JIRA will be created for that.)
>
> Cheers,
> Daniele
>
> ==
> GeoServer Professional Services from the experts! Visit
> http://goo.gl/NWWaa2 for more information.
> ==
>
> Ing. Daniele Romagnoli
> Senior Software Engineer
>
> GeoSolutions S.A.S.
> Via Poggio alle Viti 1187
> 55054  Massarosa (LU)
> Italy
> phone: +39 0584 962313
> fax:  +39 0584 1660272
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> ---
>
>
> --
> HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
> Find What Matters Most in Your Big Data with HPCC Systems
> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
> http://p.sf.net/sfu/hpccsystems
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
>
--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems___
GeoTools-Devel mailing list
GeoTools-Devel@

Re: [Geotools-devel] Request for Feedbacks: integrating unsupported's gt-mark-wkt into gt-render

[Justin Deoliveira]

Hey Daniele,

So I am clear, from the dependency graph it looks like introducing mark
into render won't add any runtime dependencies to render? If that is the
case then I see no reason not to merge it in.

-Justin


On Wed, Jun 11, 2014 at 10:22 AM, Daniele Romagnoli <
daniele.romagn...@geo-solutions.it> wrote:

> Hi Guys,
> We would like to move the code available on mark-wkt module within
> gt-render.
> It is widely used by styles defined to render marks such as arrows,
> circles, and other shapes in general (based on WKT definitions).
>
> Moreover, we have worked on a submodule which allows to render windbarbs:
> http://en.wikipedia.org/wiki/Station_model#mediaviewer/File:Wind_barbs.gif
> Some samples here:
>
> http://www.geo-solutions.it/blog/developers-corner-supporting-wind-barbs-geoserver-geotools/
>
> Having these rendered additions integrated in gt-render module would
> represent a great improvement of the rendering engine capabilities.
> In addition, this will also avoid the need of building that part
> separately and manually integrate its jar within  the geoserver war
>
> Mark-WKT dependencies reported by maven dependency:tree
> =
>
> [INFO]
> 
> [INFO] *Building WKT symbols addition to the renderer 12-SNAPSHOT*
> [INFO]
> 
> [INFO] org.geotools:gt-mark-wkt:jar:12-SNAPSHOT
> [INFO] +- org.geotools:gt-main:jar:12-SNAPSHOT:compile
> [INFO] |  +- org.geotools:gt-api:jar:12-SNAPSHOT:compile
> [INFO] |  |  \- org.geotools:gt-referencing:jar:12-SNAPSHOT:compile
> [INFO] |  | +- java3d:vecmath:jar:1.3.2:compile
> [INFO] |  | +- commons-pool:commons-pool:jar:1.5.4:compile
> [INFO] |  | +- org.geotools:gt-metadata:jar:12-SNAPSHOT:compile
> [INFO] |  | |  \- org.geotools:gt-opengis:jar:12-SNAPSHOT:compile
> [INFO] |  | | \-
> net.java.dev.jsr-275:jsr-275:jar:1.0-beta-2:compile
> [INFO] |  | \- jgridshift:jgridshift:jar:1.0:compile
> [INFO] |  +- com.vividsolutions:jts:jar:1.13:compile
> [INFO] |  \- org.jdom:jdom:jar:1.1.3:compile
> [INFO] +- org.geotools:gt-sample-data:jar:12-SNAPSHOT:test
> [INFO] +- org.geotools:gt-render:jar:12-SNAPSHOT:compile
> [INFO] |  +- org.geotools:gt-coverage:jar:12-SNAPSHOT:compile
> [INFO] |  |  +- javax.media:jai_imageio:jar:1.1:compile
> [INFO] |  |  +-
> it.geosolutions.imageio-ext:imageio-ext-tiff:jar:1.1.10:compile
> [INFO] |  |  |  +-
> it.geosolutions.imageio-ext:imageio-ext-utilities:jar:1.1.10:compile
> [INFO] |  |  |  \- javax.media:jai_codec:jar:1.1.3:compile
> [INFO] |  |  +- org.jaitools:jt-zonalstats:jar:1.3.1:compile
> [INFO] |  |  \- org.jaitools:jt-utils:jar:1.3.1:compile
> [INFO] |  \- org.geotools:gt-cql:jar:12-SNAPSHOT:compile
> [INFO] \- javax.media:jai_core:jar:1.1.3:compile
>
> As you can see, there are no unsupported or weird dependencies inherited
> by that module.
> Only core one such as main, and render itself.
>
> About code coverage, this is the cobertura report:
>
> Package # Classes Line Coverage  Branch Coverage
>  Complexity  *All Packages*7 74%
> 389/520
>  59%
> 176/298
> 9,923org.geotools.renderer.markwkt
>  3 88%
> 105/119
> 73%
> 25/34
> 4,571 org.geotools.renderer.windbarbs
>  4 70%
> 284/401
>  57%
> 151/264
> 11,895
> What do you think about it?
> (Obviously, a JIRA will be created for that.)
>
> Cheers,
> Daniele
>
> ==
> GeoServer Professional Services from the experts! Visit
> http://goo.gl/NWWaa2 for more information.
> ==
>
> Ing. Daniele Romagnoli
> Senior Software Engineer
>
> GeoSolutions S.A.S.
> Via Poggio alle Viti 1187
> 55054  Massarosa (LU)
> Italy
> phone: +39 0584 962313
> fax:  +39 0584 1660272
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> ---
>
>
> --
> HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
> Find What Matters Most in Your Big Data with HPCC Systems
> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
> http://p.sf.net/sfu/hpccsystems
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
>


-- 
*Justin Deoliveira*
Vice President, Engineering | Boundless
jdeol...@boundlessgeo.com
@j_deolive 
--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. 

[Geotools-devel] Request for Feedbacks: integrating unsupported's gt-mark-wkt into gt-render

[Daniele Romagnoli]

Hi Guys,
We would like to move the code available on mark-wkt module within
gt-render.
It is widely used by styles defined to render marks such as arrows,
circles, and other shapes in general (based on WKT definitions).

Moreover, we have worked on a submodule which allows to render windbarbs:
http://en.wikipedia.org/wiki/Station_model#mediaviewer/File:Wind_barbs.gif
Some samples here:
http://www.geo-solutions.it/blog/developers-corner-supporting-wind-barbs-geoserver-geotools/

Having these rendered additions integrated in gt-render module would
represent a great improvement of the rendering engine capabilities.
In addition, this will also avoid the need of building that part separately
and manually integrate its jar within  the geoserver war

Mark-WKT dependencies reported by maven dependency:tree
=

[INFO]

[INFO] *Building WKT symbols addition to the renderer 12-SNAPSHOT*
[INFO]

[INFO] org.geotools:gt-mark-wkt:jar:12-SNAPSHOT
[INFO] +- org.geotools:gt-main:jar:12-SNAPSHOT:compile
[INFO] |  +- org.geotools:gt-api:jar:12-SNAPSHOT:compile
[INFO] |  |  \- org.geotools:gt-referencing:jar:12-SNAPSHOT:compile
[INFO] |  | +- java3d:vecmath:jar:1.3.2:compile
[INFO] |  | +- commons-pool:commons-pool:jar:1.5.4:compile
[INFO] |  | +- org.geotools:gt-metadata:jar:12-SNAPSHOT:compile
[INFO] |  | |  \- org.geotools:gt-opengis:jar:12-SNAPSHOT:compile
[INFO] |  | | \- net.java.dev.jsr-275:jsr-275:jar:1.0-beta-2:compile
[INFO] |  | \- jgridshift:jgridshift:jar:1.0:compile
[INFO] |  +- com.vividsolutions:jts:jar:1.13:compile
[INFO] |  \- org.jdom:jdom:jar:1.1.3:compile
[INFO] +- org.geotools:gt-sample-data:jar:12-SNAPSHOT:test
[INFO] +- org.geotools:gt-render:jar:12-SNAPSHOT:compile
[INFO] |  +- org.geotools:gt-coverage:jar:12-SNAPSHOT:compile
[INFO] |  |  +- javax.media:jai_imageio:jar:1.1:compile
[INFO] |  |  +-
it.geosolutions.imageio-ext:imageio-ext-tiff:jar:1.1.10:compile
[INFO] |  |  |  +-
it.geosolutions.imageio-ext:imageio-ext-utilities:jar:1.1.10:compile
[INFO] |  |  |  \- javax.media:jai_codec:jar:1.1.3:compile
[INFO] |  |  +- org.jaitools:jt-zonalstats:jar:1.3.1:compile
[INFO] |  |  \- org.jaitools:jt-utils:jar:1.3.1:compile
[INFO] |  \- org.geotools:gt-cql:jar:12-SNAPSHOT:compile
[INFO] \- javax.media:jai_core:jar:1.1.3:compile

As you can see, there are no unsupported or weird dependencies inherited by
that module.
Only core one such as main, and render itself.

About code coverage, this is the cobertura report:

Package # Classes Line Coverage  Branch Coverage 
Complexity  *All Packages*7 74%
389/520
 59%
176/298
9,923org.geotools.renderer.markwkt
 3 88%
105/119
73%
25/34
4,571 org.geotools.renderer.windbarbs
 4 70%
284/401
 57%
151/264
11,895
What do you think about it?
(Obviously, a JIRA will be created for that.)

Cheers,
Daniele

==
GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.
==

Ing. Daniele Romagnoli
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax:  +39 0584 1660272

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

---
--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [jira] (GEOT-4822) Modify RasterAsPointCollectionProcess for supporting new features.

[Nicola Lagomarsini (JIRA)]

Title: Message Title










 

 Nicola Lagomarsini created an issue











 






 GeoTools /  GEOT-4822



  Modify RasterAsPointCollectionProcess for supporting new features. 










Issue Type:

  Improvement




Assignee:

 Nicola Lagomarsini




Components:


 unsupported




Created:


 11/Jun/14 10:18 AM




Fix Versions:


 12-beta




Priority:

  Minor




Reporter:

 Nicola Lagomarsini










The RasterAsPointCollectionProcess could be improved. It could accept new optional parameters:


a scale factor for resizing the input coverage;


an interpolation parameter for the scale operation;


a boolean parameter called emisphere which indicates the emisphere in which each point is located;


a targetCRS to indicate if the input coverage has been reprojected; this parameter will be used for calculating the Grid Convergence Angle for each point.


   

Re: [Geotools-devel] Meeting follow up - Java Port of CSS

[David Winslow]

I don't support this effort, please do not seek "technical input" from me.

I hope that the GeoServer PSC will discuss any concerns about maintenance
with me before removing my maintainer status for the GeoServer extension.


On Wed, Jun 11, 2014 at 3:14 AM, Andrea Aime 
wrote:

> On Wed, Jun 11, 2014 at 4:25 AM, Jody Garnett 
> wrote:
>
>> One thing that we missed in yesterdays meeting Andrea's idea of porting
>> the CSS module to Java for inclusion in GeoTools.
>>
>> I personally like the idea as it would put the work under more response
>> maintenance (as befitting what is now used as a GeoServer extension). The
>> only thing I was worried about was isolating David Winslow, but it sounds
>> like he has had technical input into how to port the module.
>>
>
> Trying to keep the module in Scala was the first attempt months ago, it
> did not go well, given there is evident interest in the module,
> and I like CSS styles more than SLD ones myself, I decided to unblock
> things (plus, writing the parser has been fun, let's see how
> fun the translator is now ;-) ).
>
>
>>
>> I assume the initial port would be as a GeoTools module, and then after a
>> QA pass it would take over CSS translation duty for GeoServer.
>>
>> Questions:
>> - Andrea was there anything you wanted out of a discussion before
>> proceeding with this work?
>>
>
> Not exactly no
>
>
>> - My understanding is that it is unfunded, volunteer, maintenance work
>> ... is anyone else in position to asset on this one, or supply funding?
>>
>
> Not that I know of.
>
>
>> - On a related note is porting the CSS module a good subject for FOSS4G
>> code sprint?
>>
>
> I hope to get it done much sooner than that (e.g., before the code freeze,
> although I make no promises)
>
>
>>
>> And a technical question, is there any advantage to "going native" and
>> just using the CSS data structures "as is" and constructing the appropriate
>> data structure for the Renderer? The SLD DataStructures are currently
>> translated into Style2D objects in StreamingRenderer processSymbolizers. A
>> similar approach could be used to "directly" translate the CSS data
>> structure. Advantage: May be faster to implement and easier to maintain.
>> Disadvantage: avoiding the OGC standard - SLD support may bit rot.
>>
>
> Two code paths to transform styles into style2d, having to extend the
> layer api to support other kinds of styles, rework
> the logic that figures out which features need to be painted... no thank
> you, that will definitely not fit in spare time :-)
>
> Cheers
> Andrea
>
> --
> ==
> GeoServer Professional Services from the experts! Visit
> http://goo.gl/NWWaa2 for more information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via Poggio alle Viti 1187
> 55054  Massarosa (LU)
> Italy
> phone: +39 0584 962313
> fax: +39 0584 1660272
> mob: +39  339 8844549
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> ---
>
>
> --
> HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
> Find What Matters Most in Your Big Data with HPCC Systems
> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
> http://p.sf.net/sfu/hpccsystems
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
>


-- 
David Winslow
Boundless - http://boundlessgeo.com/
--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] New community module: CSS parser and translator

[Andrea Aime]

On Wed, Jun 11, 2014 at 11:37 AM, Ariel Nunez 
wrote:

> Hello all,
>
> Could this module support the CartoCSS syntax too?
> https://www.mapbox.com/tilemill/docs/manual/carto/
>
> In downstream projects (like GeoNode) it would be very helpful to be able
> to be compatible with TileMill and CartoCSS.
>
> I am not sure which other projects use the CSS syntax used in the scala
> extension but from memory I think it was GeoServer specific. If GeoServer
> adopts CartoCSS, perhaps we can also convince/fund QGIS to support CartoCSS
> and have an excellent alternative to SLD that works in many open source
> packages.
>
> What do you think?
>

Nice one, but nothing I can do in spare time, I had a look, and CartoCSS
syntax is incompatible
with the way we handle SLD in a few ways, for example, a CSS style in carto
describes a full
map, N layers, whilst in GeoTools/GeoServer we have one SLD per layer, so a
single CSS would
have to be turned into N layers.
There is also a number of properties that have no direct translactions,
that we'd have to
implement support for.

Long story short: it can be done, but it would be a sizeable amount of
work, larger
than just doing a java version of the existing scala tooling (I'm not
calling it a port because
it's really a clean room implementation, I'm just keeping the same syntax).
So.. funding welcomed :-)

Cheers
Andrea

-- 
==
GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.
==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39  339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

---
--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] New community module: CSS parser and translator

[Jody Garnett]

You may wish to start be convincing GeoServer to support CartoCSS :) I did
make sure to ask Andrea if this was a paid effort or something he is trying
to do as a volunteer.

If you are familiar with both GeoServer CSS and CartoCSS perhaps you could
do the gap analysis? This would be required to figure out how much effort
is involved...

Jody Garnett


On Wed, Jun 11, 2014 at 7:37 PM, Ariel Nunez 
wrote:

> Hello all,
>
> Could this module support the CartoCSS syntax too?
> https://www.mapbox.com/tilemill/docs/manual/carto/
>
> In downstream projects (like GeoNode) it would be very helpful to be able
> to be compatible with TileMill and CartoCSS.
>
> I am not sure which other projects use the CSS syntax used in the scala
> extension but from memory I think it was GeoServer specific. If GeoServer
> adopts CartoCSS, perhaps we can also convince/fund QGIS to support CartoCSS
> and have an excellent alternative to SLD that works in many open source
> packages.
>
> What do you think?
>
>
> On Mon, Jun 9, 2014 at 5:27 AM, Jody Garnett 
> wrote:
>
>> Brave Move Andrea: I was thinking of doing the same thing using the
>> eclipse domain specific language stuff (and xtend).
>>
>> So big +1 from me.
>>
>>
>> Jody Garnett
>>
>>
>> On Mon, Jun 9, 2014 at 6:12 AM, Andrea Aime > > wrote:
>>
>>> Hi,
>>> as you may know in GeoServer we have a community module allowing
>>> to style maps using a CSS syntax:
>>> http://docs.geoserver.org/latest/en/user/extensions/css/index.html
>>>
>>> The module uses a Scala based parser which eventually translates the
>>> style into an equivalent SLD form.
>>>
>>> The scala parser has been source of some issues:
>>> * The module is not actively developed (last commit is 8 months old),
>>> and some
>>>   pull requests have been waiting to be accepted for months
>>> * The number of developers proficient with Scala is quite limited
>>> (proficient as in,
>>>   someone that can go and write changes to the module straight away)
>>> * There has been some complaint about the CSS->SLD translation
>>> performance
>>>
>>> A few months ago Jody was suggesting to fork the module and rewrite it
>>> in Java
>>> to get a larger potential maintaner base (
>>> http://osgeo-org.1560.x6.nabble.com/GeoTools-GeoServer-Meeting-2013-12-10-td5093533.html#a5093665).
>>> ..
>>> which is what I did in the last couple of weekends, initial results here:
>>> https://github.com/aaime/geotools/tree/css
>>>
>>> For the moment I have a (supposedly) complete parser for the syntax
>>> currently
>>> used by GeoServer based on the parbolied parser library
>>> https://github.com/sirthias/parboiled/wiki
>>> This library was suggested originally by David Winslow as we were
>>> talking about
>>> the possibility of a Java rewrite some months ago.
>>>
>>> The plan is to move forward and create a CSS->SLD translator in the next
>>> few weeks,
>>> trying to pay attention to performance, and see if some of the issues in
>>> the existing
>>> Scala version can be solved too, e.g., creationg of a line and polygon
>>> symbolizer
>>> when a single polygon symbolizer would do, and no use of ElseFilter for
>>> the
>>> rules matching "everything else".
>>> I'll probably have to pimp up the SimplifyingFilterVisitor a bit to
>>> recognize filters
>>> that match everything, or nothing, to do the above, which in the end
>>> will be
>>> of benefit also for all other users of the class above (e.g., stores
>>> translating filters
>>> into some sql/xml format)
>>>
>>> Feedback welcomed
>>>
>>> Cheers
>>> Andrea
>>>
>>> --
>>> ==
>>> GeoServer Professional Services from the experts! Visit
>>> http://goo.gl/NWWaa2 for more information.
>>> ==
>>>
>>> Ing. Andrea Aime
>>> @geowolf
>>> Technical Lead
>>>
>>> GeoSolutions S.A.S.
>>> Via Poggio alle Viti 1187
>>> 55054  Massarosa (LU)
>>> Italy
>>> phone: +39 0584 962313
>>> fax: +39 0584 1660272
>>> mob: +39  339 8844549
>>>
>>> http://www.geo-solutions.it
>>> http://twitter.com/geosolutions_it
>>>
>>> ---
>>>
>>>
>>> --
>>> Learn Graph Databases - Download FREE O'Reilly Book
>>> "Graph Databases" is the definitive new guide to graph databases and
>>> their
>>> applications. Written by three acclaimed leaders in the field,
>>> this first edition is now available. Download your free book today!
>>> http://p.sf.net/sfu/NeoTech
>>> ___
>>> GeoTools-Devel mailing list
>>> GeoTools-Devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>>
>>>
>>
>>
>> --
>> HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
>> Find What Matters Most in Your Big Data with HPCC Systems
>> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
>> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
>> http://w

Re: [Geotools-devel] New community module: CSS parser and translator

[Ariel Nunez]

Hello all,

Could this module support the CartoCSS syntax too?
https://www.mapbox.com/tilemill/docs/manual/carto/

In downstream projects (like GeoNode) it would be very helpful to be able
to be compatible with TileMill and CartoCSS.

I am not sure which other projects use the CSS syntax used in the scala
extension but from memory I think it was GeoServer specific. If GeoServer
adopts CartoCSS, perhaps we can also convince/fund QGIS to support CartoCSS
and have an excellent alternative to SLD that works in many open source
packages.

What do you think?


On Mon, Jun 9, 2014 at 5:27 AM, Jody Garnett  wrote:

> Brave Move Andrea: I was thinking of doing the same thing using the
> eclipse domain specific language stuff (and xtend).
>
> So big +1 from me.
>
>
> Jody Garnett
>
>
> On Mon, Jun 9, 2014 at 6:12 AM, Andrea Aime 
> wrote:
>
>> Hi,
>> as you may know in GeoServer we have a community module allowing
>> to style maps using a CSS syntax:
>> http://docs.geoserver.org/latest/en/user/extensions/css/index.html
>>
>> The module uses a Scala based parser which eventually translates the
>> style into an equivalent SLD form.
>>
>> The scala parser has been source of some issues:
>> * The module is not actively developed (last commit is 8 months old), and
>> some
>>   pull requests have been waiting to be accepted for months
>> * The number of developers proficient with Scala is quite limited
>> (proficient as in,
>>   someone that can go and write changes to the module straight away)
>> * There has been some complaint about the CSS->SLD translation
>> performance
>>
>> A few months ago Jody was suggesting to fork the module and rewrite it in
>> Java
>> to get a larger potential maintaner base (
>> http://osgeo-org.1560.x6.nabble.com/GeoTools-GeoServer-Meeting-2013-12-10-td5093533.html#a5093665).
>> ..
>> which is what I did in the last couple of weekends, initial results here:
>> https://github.com/aaime/geotools/tree/css
>>
>> For the moment I have a (supposedly) complete parser for the syntax
>> currently
>> used by GeoServer based on the parbolied parser library
>> https://github.com/sirthias/parboiled/wiki
>> This library was suggested originally by David Winslow as we were talking
>> about
>> the possibility of a Java rewrite some months ago.
>>
>> The plan is to move forward and create a CSS->SLD translator in the next
>> few weeks,
>> trying to pay attention to performance, and see if some of the issues in
>> the existing
>> Scala version can be solved too, e.g., creationg of a line and polygon
>> symbolizer
>> when a single polygon symbolizer would do, and no use of ElseFilter for
>> the
>> rules matching "everything else".
>> I'll probably have to pimp up the SimplifyingFilterVisitor a bit to
>> recognize filters
>> that match everything, or nothing, to do the above, which in the end will
>> be
>> of benefit also for all other users of the class above (e.g., stores
>> translating filters
>> into some sql/xml format)
>>
>> Feedback welcomed
>>
>> Cheers
>> Andrea
>>
>> --
>> ==
>> GeoServer Professional Services from the experts! Visit
>> http://goo.gl/NWWaa2 for more information.
>> ==
>>
>> Ing. Andrea Aime
>> @geowolf
>> Technical Lead
>>
>> GeoSolutions S.A.S.
>> Via Poggio alle Viti 1187
>> 55054  Massarosa (LU)
>> Italy
>> phone: +39 0584 962313
>> fax: +39 0584 1660272
>> mob: +39  339 8844549
>>
>> http://www.geo-solutions.it
>> http://twitter.com/geosolutions_it
>>
>> ---
>>
>>
>> --
>> Learn Graph Databases - Download FREE O'Reilly Book
>> "Graph Databases" is the definitive new guide to graph databases and their
>> applications. Written by three acclaimed leaders in the field,
>> this first edition is now available. Download your free book today!
>> http://p.sf.net/sfu/NeoTech
>> ___
>> GeoTools-Devel mailing list
>> GeoTools-Devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>
>>
>
>
> --
> HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
> Find What Matters Most in Your Big Data with HPCC Systems
> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
> http://www.hpccsystems.com
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
>
--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.ne

[Geotools-devel] [jira] (GEOT-4821) improve netcdf and slf4j version definitions

[Daniele Romagnoli (JIRA)]

Title: Message Title










 

 Daniele Romagnoli created an issue











 






 GeoTools /  GEOT-4821



  improve netcdf and slf4j version definitions 










Issue Type:

  Task




Affects Versions:


 11.1




Assignee:


 Unassigned




Components:


 unsupported




Created:


 11/Jun/14 3:59 AM




Priority:

  Major




Reporter:

 Daniele Romagnoli










Right now, NetCDF versions and slf4j versions are defined here and there on root's dependencyManagement as well as on some inner modules.
We should define them into the dependencyManagement, using some  xxx xxx ... 
in order to have all versions defined once












   

 Add Comment




   

Re: [Geotools-devel] Nominate Nicola Lagomarsini for direct commit access to GeoTools

[Christian Mueller]

+1 form here
Welcome.


On Wed, Jun 11, 2014 at 12:16 AM, Jody Garnett 
wrote:

> Sounds good, welcome to the team Nicola
>
> +1
>
> Jody Garnett
>
>
> On Wed, Jun 11, 2014 at 12:17 AM, Nicola Lagomarsini <
> nicola.lagomars...@geo-solutions.it> wrote:
>
>> Hi all,
>>
>> I already have the License Agreement and I read the documentation, so I
>> will be pleased to become direct committer.
>>
>> Best Regards,
>> Nicola.
>>
>>
>> 2014-06-10 16:11 GMT+02:00 Andrea Aime :
>>
>> Hi,
>>> in the last months Nicola has been making a number of pull
>>> requests against GeoTools lately, the pulls are (afaik) always coming
>>> with tests and related to a ticket in jira (the titles of which could
>>> use some love, but I believe they are undestandable).
>>>
>>> So, I would like to nominate him as a direct committer for GeoTools
>>>
>>> Nicola, I guess you already sent you licensing agreement (right?)
>>> and that you read the developer guide (right??)
>>>
>>> Feedback welcomed
>>>
>>> Cheers
>>> Andrea
>>>
>>> --
>>> ==
>>>  GeoServer Professional Services from the experts! Visit
>>> http://goo.gl/NWWaa2 for more information.
>>> ==
>>>
>>> Ing. Andrea Aime
>>> @geowolf
>>> Technical Lead
>>>
>>> GeoSolutions S.A.S.
>>> Via Poggio alle Viti 1187
>>> 55054  Massarosa (LU)
>>> Italy
>>> phone: +39 0584 962313
>>> fax: +39 0584 1660272
>>> mob: +39  339 8844549
>>>
>>> http://www.geo-solutions.it
>>> http://twitter.com/geosolutions_it
>>>
>>> ---
>>>
>>
>>
>>
>> --
>> ==
>> GeoServer Professional Services from the experts! Visit
>> http://goo.gl/NWWaa2 for more information.
>> ==
>>
>> Ing. Nicola Lagomarsini
>> Junior Software Engineer
>>
>> GeoSolutions S.A.S.
>> Via Poggio alle Viti 1187
>> 55054  Massarosa (LU)
>> Italy
>> phone: +39 0584 962313
>> fax:   +39 0584 1660272
>>
>> http://www.geo-solutions.it
>> http://twitter.com/geosolutions_it
>>
>> ---
>>
>>
>> --
>> HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
>> Find What Matters Most in Your Big Data with HPCC Systems
>> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
>> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
>> http://p.sf.net/sfu/hpccsystems
>> ___
>> GeoTools-Devel mailing list
>> GeoTools-Devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>
>>
>
>
> --
> HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
> Find What Matters Most in Your Big Data with HPCC Systems
> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
> http://p.sf.net/sfu/hpccsystems
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
>


-- 
DI Christian Mueller MSc (GIS), MSc (IT-Security)
OSS Open Source Solutions GmbH
--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Meeting follow up - Java Port of CSS

[Andrea Aime]

On Wed, Jun 11, 2014 at 4:25 AM, Jody Garnett 
wrote:

> One thing that we missed in yesterdays meeting Andrea's idea of porting
> the CSS module to Java for inclusion in GeoTools.
>
> I personally like the idea as it would put the work under more response
> maintenance (as befitting what is now used as a GeoServer extension). The
> only thing I was worried about was isolating David Winslow, but it sounds
> like he has had technical input into how to port the module.
>

Trying to keep the module in Scala was the first attempt months ago, it did
not go well, given there is evident interest in the module,
and I like CSS styles more than SLD ones myself, I decided to unblock
things (plus, writing the parser has been fun, let's see how
fun the translator is now ;-) ).


>
> I assume the initial port would be as a GeoTools module, and then after a
> QA pass it would take over CSS translation duty for GeoServer.
>
> Questions:
> - Andrea was there anything you wanted out of a discussion before
> proceeding with this work?
>

Not exactly no


> - My understanding is that it is unfunded, volunteer, maintenance work ...
> is anyone else in position to asset on this one, or supply funding?
>

Not that I know of.


> - On a related note is porting the CSS module a good subject for FOSS4G
> code sprint?
>

I hope to get it done much sooner than that (e.g., before the code freeze,
although I make no promises)


>
> And a technical question, is there any advantage to "going native" and
> just using the CSS data structures "as is" and constructing the appropriate
> data structure for the Renderer? The SLD DataStructures are currently
> translated into Style2D objects in StreamingRenderer processSymbolizers. A
> similar approach could be used to "directly" translate the CSS data
> structure. Advantage: May be faster to implement and easier to maintain.
> Disadvantage: avoiding the OGC standard - SLD support may bit rot.
>

Two code paths to transform styles into style2d, having to extend the layer
api to support other kinds of styles, rework
the logic that figures out which features need to be painted... no thank
you, that will definitely not fit in spare time :-)

Cheers
Andrea

-- 
==
GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.
==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39  339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

---
--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel