Re: [Geotools-devel] proposal: Separate general complex feature classes from gt-app-schema

2012-12-12 Thread Andrea Aime 
On Wed, Dec 12, 2012 at 5:29 PM, Niels Charlier  wrote:

>  Well apart from the feature type parser, there is another important part
> in the module that relies on xsd stuff, i.e. the xpath property accessor.
> This I think is a very important part of complex features; without this you
> can't have filters on complex features.
>

An xpath processor is built into the jdk, there is no need to depend on
gt-xsd and friends to have it,
e.g.: http://xml.apache.org/xalan-j/xpath_apis.html
Even if that requires some external library, it's hard to believe it
requires an entire xml parsing/encoding subsystem.

Cheers
Andrea


-- 
==
Our support, Your Success! Visit http://opensdi.geo-solutions.it 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

---
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] proposal: Separate general complex feature classes from gt-app-schema

2012-12-12 Thread Ben Caradoc-Davies 
It would be good if users could build and manipulate complex types and 
features without ever touching XML or needing an XML dependency. For 
example, they could build types and features programatically. Other 
output formats include JSON; complex relationships can be represented in 
JSON-LD.

On 12/12/12 17:30, Andrea Aime wrote:
> Scratch scratch, could you clarify what dependencies would one end up
> having in the
> classpath in order to use gt-complex?

-- 
Ben Caradoc-Davies 
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] [jira] (GEOT-4345) A few easy-to-correct bugs in the MapContent implementation

2012-12-12 Thread Michael Bedward 
Hi Andrea, Jody,

Please see my comment on this one:

https://jira.codehaus.org/browse/GEOT-4345?focusedCommentId=315573#comment-315573

Michael


On 13 December 2012 01:15, Pierre Beule (JIRA)  wrote:

>Pierre 
> Beulecreated 
> [image:
> Bug] GEOT-4345 
>  *A few easy-to-correct bugs in the MapContent 
> implementation*
>*Issue Type:*  [image: Bug] Bug   *Affects Versions:*  8.4   *
> Assignee:*  Andrea 
> Aime
> *Components:*  render   *Created:*  12/Dec/12 8:14 AM   *Description:*
>
> Hi,
>
> A CopyOnWriteArrayList is used to hold the layers of the MapContent, which
> seems a pretty good idea to resolve concurrency problems around this list.
>
> The thing is, you don't need anymore in the methods MapContent.xxx() with
> xxx a method accessing/modifying this list (i.e 'addLayer()',
> 'removeLayer()', ... and most important of all 'layers()') to manage the
> 'monitor' lock ! Because CopyOnWriteArrayList is already multithreads safe.
>
> We could think this is of no importance, but... This can ('did' for me...)
> engage some deadlocks, working with this methods. (I have found a
> workaround solution (we always can find one...), but still, since this
> locks really are useless, I think it's better to remove them).
>
> -
> Example in a multithreaded environment:
> Thread X is a background thread.
> Thread Y is the AWT thread, in charge of rendering Swing components.
>
> The component in charge of drawing is a subclass of AbstractMapPane, using
> the AbstractMapPane.drawingLock when painting. (Remember AbstractMapPane is
> a JPanel, which content is drawn in JComponent.paintComponent()).
>
> 1) Thread X takes the lock, in order to remove a layer. (why not ?) So
> here we are at the beginning of MapContent.remove() function, the 'monitor'
> lock has been taken by Thread X.
>
> 2) Thread Y is called to paint the AbstractMapPane, so it takes the lock
> 'drawingLock' of AbstractMapPane when entering the 'paintComponent' method.
> Imagine, Thread Y, in order to repaint, calls MapContent.layers() in order
> to have an access to the layers list of the MapContent. (why not ?)
>
> So here we are, Thread Y have got the AbstractMapPane.drawingLock, and
> Thread X have got MapContent.monitor lock
> For now, Thread Y is waiting, to be able to lock MapContent.monitor which
> has uselessly been taken by Thread X.
>
> 3) Thread X continues, remove the layer and... fire the layerRemoved event
> ! I let you guess what is going to happen here... AbstractMapPane is
> listening and... when the layers list change, it tries to reflect the
> changes in the display. So Thread X is now waiting for
> AbstractMapPane.drawingLock !
>
> 4) Here we are.. dead locked !
>
> -
> The solution ? Just remove the useless management of the 'monitor' lock in
> MapContent.xxx methods which access/modyfy the layers list.
> -
> For information...
> I see two workarounds in that situation..
> a) Thread X, when removing layers, does no longer calls
> MapContent.remove(myLayer)... but instead
> MapContent.layers().remove(myLayer).
> This way, 'monitor' lock is just locked the time to return the layers
> list, BUT is no longer holded by Thread X while it does remove the layer
> from the list and notice the listeners.
>
> b) This problem could also have been resolved in step 2, trying to access
> the MapContent.layers() BEFORE locking 'drawingLock'.
>
> -
> Hope I have well enough described the bug here, have a good day and happy
> coding !
>   *Environment:*  Windows XP 32bits, jdk1.7.0_07   *Project:*  
> GeoTools
> *Priority:*  [image: Major] Major   *Reporter:*  Pierre 
> Beule   
> This
> message is automatically generated by JIRA.
> If you think it was sent incorrectly, please contact your JIRA
> administrators
> .
> For more information on JIRA, see: http://www.atlassian.com/software/jira
>
>
> --
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
>
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Rem

Re: [Geotools-devel] proposal: Separate general complex feature classes from gt-app-schema

2012-12-12 Thread Niels Charlier 
Well apart from the feature type parser, there is another important part 
in the module that relies on xsd stuff, i.e. the xpath property 
accessor. This I think is a very important part of complex features; 
without this you can't have filters on complex features.


The only thing that really remains xml free are a few very simple 
builder classes.


Considering this, and seeing there was a consensus growing around it, I 
would personally prefer to stay with the current plan of a complex module.


Kind Regards
Niels Charlier


On 12/12/2012 03:03 PM, Andrea Aime wrote:
On Wed, Dec 12, 2012 at 2:45 PM, Niels Charlier > wrote:


I see. So what you'd suggest we move a bunch of that stuff in to
gt-main.

I have to have a look at which part will still remain. Perhaps too
little to keep in a separate package. Maybe we should still move
that stuff into gt-appschema-resolver but keep the name?


It's going to be easier to tell once you figured out what remains. 
Please let us know :-)


Cheers
Andrea
--
==
Our support, Your Success! Visit http://opensdi.geo-solutions.it 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

---



--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [jira] (GEOT-4346) An easy-to-solve bug in AbstractMapPane

2012-12-12 Thread Pierre Beule (JIRA) 














































Pierre Beule
 created  GEOT-4346


An easy-to-solve bug in AbstractMapPane















Issue Type:


Bug



Affects Versions:


8.4



Assignee:


Unassigned


Components:


swing



Created:


12/Dec/12 8:35 AM



Description:


In code of AbstractMapPane, there is:


---
/**

	Called when a map layer has been removed
 */
@Override
public void layerRemoved(final MapLayerListEvent event) {
	[...]



	final Layer layer = event.getElement();

	if (layer instanceof ComponentListener) {
		this.addComponentListener((ComponentListener) layer);
	}

	[...]
}

---
I am convinced what is expected to be done here is a 'removeComponentListener' and not 'addComponentListener'

Or have I missed something ?
---
Happy coding.




Environment:


Windows XP 32bits, jdk1.7.0_07




Project:


GeoTools



Priority:


Minor



Reporter:


Pierre Beule




























This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira





--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [jira] (GEOT-4345) A few easy-to-correct bugs in the MapContent implementation

2012-12-12 Thread Pierre Beule (JIRA) 














































Pierre Beule
 created  GEOT-4345


A few easy-to-correct bugs in the MapContent implementation















Issue Type:


Bug



Affects Versions:


8.4



Assignee:


Andrea Aime



Components:


render



Created:


12/Dec/12 8:14 AM



Description:


Hi,

A CopyOnWriteArrayList is used to hold the layers of the MapContent, which seems a pretty good idea to resolve concurrency problems around this list.

The thing is, you don't need anymore in the methods MapContent.xxx() with xxx a method accessing/modifying this list (i.e 'addLayer()', 'removeLayer()', ... and most important of all 'layers()') to manage the 'monitor' lock ! Because CopyOnWriteArrayList is already multithreads safe.

We could think this is of no importance, but... This can ('did' for me...) engage some deadlocks, working with this methods. (I have found a workaround solution (we always can find one...), but still, since this locks really are useless, I think it's better to remove them).

-
Example in a multithreaded environment:
Thread X is a background thread.
Thread Y is the AWT thread, in charge of rendering Swing components.

The component in charge of drawing is a subclass of AbstractMapPane, using the AbstractMapPane.drawingLock when painting. (Remember AbstractMapPane is a JPanel, which content is drawn in JComponent.paintComponent()).

1) Thread X takes the lock, in order to remove a layer. (why not ?) So here we are at the beginning of MapContent.remove() function, the 'monitor' lock has been taken by Thread X.

2) Thread Y is called to paint the AbstractMapPane, so it takes the lock 'drawingLock' of AbstractMapPane when entering the 'paintComponent' method.
Imagine, Thread Y, in order to repaint, calls MapContent.layers() in order to have an access to the layers list of the MapContent. (why not ?)

So here we are, Thread Y have got the AbstractMapPane.drawingLock, and Thread X have got MapContent.monitor lock
For now, Thread Y is waiting, to be able to lock MapContent.monitor which has uselessly been taken by Thread X.

3) Thread X continues, remove the layer and... fire the layerRemoved event ! I let you guess what is going to happen here... AbstractMapPane is listening and... when the layers list change, it tries to reflect the changes in the display. So Thread X is now waiting for AbstractMapPane.drawingLock !

4) Here we are.. dead locked !

-
The solution ? Just remove the useless management of the 'monitor' lock in MapContent.xxx methods which access/modyfy the layers list.
-
For information...
I see two workarounds in that situation..
a) Thread X, when removing layers, does no longer calls MapContent.remove(myLayer)... but instead MapContent.layers().remove(myLayer).
This way, 'monitor' lock is just locked the time to return the layers list, BUT is no longer holded by Thread X while it does remove the layer from the list and notice the listeners.

b) This problem could also have been resolved in step 2, trying to access the MapContent.layers() BEFORE locking 'drawingLock'.

-
Hope I have well enough described the bug here, have a good day and happy coding !




Environment:


Windows XP 32bits, jdk1.7.0_07




Project:


GeoTools



Priority:


Major



Reporter:


Pierre Beule




























This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira





-

Re: [Geotools-devel] proposal: Separate general complex feature classes from gt-app-schema

2012-12-12 Thread Andrea Aime 
On Wed, Dec 12, 2012 at 2:45 PM, Niels Charlier  wrote:

>  I see. So what you'd suggest we move a bunch of that stuff in to gt-main.
>
> I have to have a look at which part will still remain. Perhaps too little
> to keep in a separate package. Maybe we should still move that stuff into
> gt-appschema-resolver but keep the name?
>

It's going to be easier to tell once you figured out what remains. Please
let us know :-)

Cheers
Andrea

-- 
==
Our support, Your Success! Visit http://opensdi.geo-solutions.it 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

---
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] proposal: Separate general complex feature classes from gt-app-schema

2012-12-12 Thread Niels Charlier 

I see. So what you'd suggest we move a bunch of that stuff in to gt-main.

I have to have a look at which part will still remain. Perhaps too 
little to keep in a separate package. Maybe we should still move that 
stuff into gt-appschema-resolver but keep the name?


On 12/12/2012 01:56 PM, Andrea Aime wrote:
On Wed, Dec 12, 2012 at 12:47 PM, Niels Charlier > wrote:


[INFO] org.geotools:gt-complex:jar:9-SNAPSHOT
[INFO] +- org.geotools:gt-app-schema-resolver:jar:9-SNAPSHOT:compile
[INFO] |  +- org.geotools.xsd:gt-xsd-core:jar:9-SNAPSHOT:compile
[INFO] |  |  +- org.geotools:gt-graph:jar:9-SNAPSHOT:compile
[INFO] |  |  |  \- org.geotools:gt-main:jar:9-SNAPSHOT:compile
[INFO] |  |  | +- org.geotools:gt-api:jar:9-SNAPSHOT:compile
[INFO] |  |  | |  \-
org.geotools:gt-referencing:jar:9-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:9-SNAPSHOT:compile
[INFO] |  |  | | |  \-
org.geotools:gt-opengis:jar:9-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.12:compile
[INFO] |  |  | \- jdom:jdom:jar:1.0:compile
[INFO] |  |  +- picocontainer:picocontainer:jar:1.2:compile
[INFO] |  |  |  \- xml-apis:xml-apis:jar:1.3.04:compile (version
managed from 1.0.b2)
[INFO] |  |  +- xerces:xercesImpl:jar:2.7.1:compile
[INFO] |  |  +- xml-apis:xml-apis-xerces:jar:2.7.1:compile
[INFO] |  |  +- commons-jxpath:commons-jxpath:jar:1.3:compile
[INFO] |  |  +-
commons-collections:commons-collections:jar:3.1:compile
[INFO] |  |  +- org.eclipse.emf:common:jar:2.6.0:compile
[INFO] |  |  +- org.eclipse.emf:ecore:jar:2.6.1:compile
[INFO] |  |  \- org.eclipse.xsd:xsd:jar:2.6.0:compile
[INFO] |  \- org.apache.xml:xml-commons-resolver:jar:1.2:compile
[INFO] +- xpp3:xpp3_min:jar:1.1.4c:compile
[INFO] +- javax.media:jai_core:jar:1.1.3:compile
[INFO] \- junit:junit:jar:4.4:test


Eh, as I suspected, very tightly married to XML things, which is 
something I hope

complex features remain free of.
Don't get me wrong, being able to parse a feature type from a XSD is a
very good feature, but these large set of dependencies should not be 
forced

into whoever uses complex features.

Is there a way to cut it so that generic complex feature stuff is on 
one side,

and XML and XSD specific support is on the other?

Cheers
Andrea

--
==
Our support, Your Success! Visit http://opensdi.geo-solutions.it 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

---



--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] proposal: Separate general complex feature classes from gt-app-schema

2012-12-12 Thread Andrea Aime 
On Wed, Dec 12, 2012 at 12:47 PM, Niels Charlier  wrote:

>  [INFO] org.geotools:gt-complex:jar:9-SNAPSHOT
> [INFO] +- org.geotools:gt-app-schema-resolver:jar:9-SNAPSHOT:compile
> [INFO] |  +- org.geotools.xsd:gt-xsd-core:jar:9-SNAPSHOT:compile
> [INFO] |  |  +- org.geotools:gt-graph:jar:9-SNAPSHOT:compile
> [INFO] |  |  |  \- org.geotools:gt-main:jar:9-SNAPSHOT:compile
> [INFO] |  |  | +- org.geotools:gt-api:jar:9-SNAPSHOT:compile
> [INFO] |  |  | |  \- org.geotools:gt-referencing:jar:9-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:9-SNAPSHOT:compile
> [INFO] |  |  | | |  \-
> org.geotools:gt-opengis:jar:9-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.12:compile
> [INFO] |  |  | \- jdom:jdom:jar:1.0:compile
> [INFO] |  |  +- picocontainer:picocontainer:jar:1.2:compile
> [INFO] |  |  |  \- xml-apis:xml-apis:jar:1.3.04:compile (version managed
> from 1.0.b2)
> [INFO] |  |  +- xerces:xercesImpl:jar:2.7.1:compile
> [INFO] |  |  +- xml-apis:xml-apis-xerces:jar:2.7.1:compile
> [INFO] |  |  +- commons-jxpath:commons-jxpath:jar:1.3:compile
> [INFO] |  |  +- commons-collections:commons-collections:jar:3.1:compile
> [INFO] |  |  +- org.eclipse.emf:common:jar:2.6.0:compile
> [INFO] |  |  +- org.eclipse.emf:ecore:jar:2.6.1:compile
> [INFO] |  |  \- org.eclipse.xsd:xsd:jar:2.6.0:compile
> [INFO] |  \- org.apache.xml:xml-commons-resolver:jar:1.2:compile
> [INFO] +- xpp3:xpp3_min:jar:1.1.4c:compile
> [INFO] +- javax.media:jai_core:jar:1.1.3:compile
> [INFO] \- junit:junit:jar:4.4:test
>
>
Eh, as I suspected, very tightly married to XML things, which is something
I hope
complex features remain free of.
Don't get me wrong, being able to parse a feature type from a XSD is a
very good feature, but these large set of dependencies should not be forced
into whoever uses complex features.

Is there a way to cut it so that generic complex feature stuff is on one
side,
and XML and XSD specific support is on the other?

Cheers
Andrea


-- 
==
Our support, Your Success! Visit http://opensdi.geo-solutions.it 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

---
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] proposal: Separate general complex feature classes from gt-app-schema

2012-12-12 Thread Niels Charlier 

[INFO] org.geotools:gt-complex:jar:9-SNAPSHOT
[INFO] +- org.geotools:gt-app-schema-resolver:jar:9-SNAPSHOT:compile
[INFO] |  +- org.geotools.xsd:gt-xsd-core:jar:9-SNAPSHOT:compile
[INFO] |  |  +- org.geotools:gt-graph:jar:9-SNAPSHOT:compile
[INFO] |  |  |  \- org.geotools:gt-main:jar:9-SNAPSHOT:compile
[INFO] |  |  | +- org.geotools:gt-api:jar:9-SNAPSHOT:compile
[INFO] |  |  | |  \- org.geotools:gt-referencing:jar:9-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:9-SNAPSHOT:compile
[INFO] |  |  | | |  \- 
org.geotools:gt-opengis:jar:9-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.12:compile
[INFO] |  |  | \- jdom:jdom:jar:1.0:compile
[INFO] |  |  +- picocontainer:picocontainer:jar:1.2:compile
[INFO] |  |  |  \- xml-apis:xml-apis:jar:1.3.04:compile (version managed 
from 1.0.b2)

[INFO] |  |  +- xerces:xercesImpl:jar:2.7.1:compile
[INFO] |  |  +- xml-apis:xml-apis-xerces:jar:2.7.1:compile
[INFO] |  |  +- commons-jxpath:commons-jxpath:jar:1.3:compile
[INFO] |  |  +- commons-collections:commons-collections:jar:3.1:compile
[INFO] |  |  +- org.eclipse.emf:common:jar:2.6.0:compile
[INFO] |  |  +- org.eclipse.emf:ecore:jar:2.6.1:compile
[INFO] |  |  \- org.eclipse.xsd:xsd:jar:2.6.0:compile
[INFO] |  \- org.apache.xml:xml-commons-resolver:jar:1.2:compile
[INFO] +- xpp3:xpp3_min:jar:1.1.4c:compile
[INFO] +- javax.media:jai_core:jar:1.1.3:compile
[INFO] \- junit:junit:jar:4.4:test


On 12/12/2012 10:30 AM, Andrea Aime wrote:
On Tue, Dec 11, 2012 at 12:15 PM, Niels Charlier > wrote:


The Proposal:


http://docs.codehaus.org/display/GEOTOOLS/Separate+general+complex+feature+classes+from+gt-app-schema

Please vote, or provide criticism.


Scratch scratch, could you clarify what dependencies would one end up 
having in the

classpath in order to use gt-complex?
A dependency:tree or dependency:list output of that module would help

I'm also wondering, say we start building complex feature versions of the
many decorating collections we have, where would you see them ending up,
in main or gt-complex?

Cheers
Andrea


--
==
Our support, Your Success! Visit http://opensdi.geo-solutions.it 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

---



--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Contribution Agreement Clarity

2012-12-12 Thread Andrea Aime 
On Tue, Dec 11, 2012 at 11:06 PM, Jody Garnett wrote:

> Thanks for contacting us Frank, we have not had any feedback to this
> effect previously.
>
> I am sure we can tightening up the language in the CLA, and could issue a
> new version of the document following our usual change procedure.
>
> Our project is "open" allowing you to assemble a "proposal" to change the
> wording (as outlined in the developers guide). You do not have to be a
> member of the project steering committee to make a proposal. This would
> also give your legal department something to review prior to us issuing a
> new copy of the document. In this particular case we will need to assemble
> a document, and then pass it to the OSGeo board for final approval (as
> OSGeo is the legal entity effected).
>

I agree with the idea. It's easier for us to tell you if something cooked
up by a lawyer team defines Geotools than try to give
you a definition that would suit lawyers.
Hopefully the material on the GeoTools web site and this discussion helps
clarify what we feel GeoTools is

Cheers
Andrea

-- 
==
Our support, Your Success! Visit http://opensdi.geo-solutions.it 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

---
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Contribution Agreement Clarity

2012-12-12 Thread Andrea Aime 
On Wed, Dec 12, 2012 at 4:01 AM, Ben Caradoc-Davies <
ben.caradoc-dav...@csiro.au> wrote:

> On 12/12/12 10:59, Michael Bedward wrote:
> > I read their concern as being that the current wording was so open it
> > was asking them to sign up to an undefined and possibly moving target.
> > Probably any of "software" or "toolkit" or "framework" or "library and
> > utilities" etc. would be an improvement.
> > I wouldn't drop "Java" from the description. I like the JTS model: a
> > reference implementation in Java with ports to other languages managed
> > as separate projects. Seems more "agile" :)
>
> If we kept the "Java" part, would patent grants extend to other languages?
>

I agree with Michael, if one day we rewrite the library in another
language, it will
be another library, GeoTools no more.

That said, the situation of languages for the VM is so much in flux that I
don't
see any of the new languages taking over anytime soon. An approach like
GeoScript, different library addressing some of the JVM languages (and it's
not a case that it's not just one) makes more sense to me.

Cheers
Andrea

-- 
==
Our support, Your Success! Visit http://opensdi.geo-solutions.it 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

---
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] proposal: Separate general complex feature classes from gt-app-schema

2012-12-12 Thread Andrea Aime 
On Tue, Dec 11, 2012 at 12:15 PM, Niels Charlier  wrote:

> The Proposal:
>
>
> http://docs.codehaus.org/display/GEOTOOLS/Separate+general+complex+feature+classes+from+gt-app-schema
>
> Please vote, or provide criticism.
>


Scratch scratch, could you clarify what dependencies would one end up
having in the
classpath in order to use gt-complex?
A dependency:tree or dependency:list output of that module would help

I'm also wondering, say we start building complex feature versions of the
many decorating collections we have, where would you see them ending up,
in main or gt-complex?

Cheers
Andrea


-- 
==
Our support, Your Success! Visit http://opensdi.geo-solutions.it 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

---
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Rendering slow due to FidFilterImpl

2012-12-12 Thread Andrea Aime 
On Wed, Dec 12, 2012 at 1:26 AM, Jody  wrote:

>  Thanks for the investigation. Report the issue with patch & test case. Or
> via pull request and we should be good to go.
>
> In many cases functionality such as this was tested with small data sets
> for completeness / correctness and can be revisited now that we work with
> larger datasets and an interactive setting.
>
> For most data stores we expect them to handle this natively based in an
> index - what datastore were you testing with ?
>

This kind of patch was already tried, but it broke geogit-versioned.
Have a look here for a discussion... maybe someone has time to figure out a
way to solve the issue?

http://jira.codehaus.org/browse/GEOT-3986

Cheers
Andrea


-- 
==
Our support, Your Success! Visit http://opensdi.geo-solutions.it 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

---
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel