date:20110622

Re: [Geotools-devel] Proposal to update to Maven 3

2011-06-22 Thread Andrea Aime

On Thu, Jun 23, 2011 at 8:41 AM, Severin (aka Cliff) wrote:

> Hi People,
>
>
> I've written up a proposal on the wiki with regard to updating the GeoTools
> build process to work under both Maven 2 and 3.
>
> Justin: jgarnett suggested I open a dialogue with you to see if you have
> any interest in updating the build box to use Maven 3 yet.
>
> Proposal is at
> http://docs.codehaus.org/display/GEOTOOLS/Update+to+use+Maven+3 for
> review.
>

Sounds to me like a good idea. Time wise we should first wait for the java 6
switch to be complete, to avoid
having two changes rocking the build happening at the same time

Cheers
Andrea


-- 
---
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy

phone: +39 0584 962313
fax:  +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

---
--
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today.
http://p.sf.net/sfu/quest-sfdev2dev___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] "Monolithic" OSGi bundle for GeoTools 2.7.2

2011-06-22 Thread Mathieu Baudier

> If you want we can update the release anouncement; or you can make a blog
> post; as you produce each monolithic bundle?

Good idea!

I will underline that a deep refactoring is being worked on, in order
to have a proper modularity, but that this is meanwhile a pragmatic
approach.

The main value added of this bundle is my tool which is merging the
SPI service files. This is probably the main problem that people face
when trying to use GeoTools in OSGi.

So, please just let me know what I should do in order to add such a blog post.

Cheers,

Mathieu

--
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today.
http://p.sf.net/sfu/quest-sfdev2dev
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] Proposal to update to Maven 3

2011-06-22 Thread Severin (aka Cliff)

Hi People,


I've written up a proposal on the wiki with regard to updating the GeoTools
build process to work under both Maven 2 and 3.

Justin: jgarnett suggested I open a dialogue with you to see if you have any
interest in updating the build box to use Maven 3 yet.

Proposal is at
http://docs.codehaus.org/display/GEOTOOLS/Update+to+use+Maven+3 for review.


Cheers,
Cliff

-- 
"We are dreamers, shapers, singers and makers..."
--
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today.
http://p.sf.net/sfu/quest-sfdev2dev___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Add pom property fork.javac

2011-06-22 Thread Jody Garnett

I was actually going to ask - could we take the build instructions into the 
user guide - and version them with each release of GeoTools?

That way we could run with *just* a "latest" developers guide reflecting our 
procedures as a project. And it would make it less crazy to update as each 
change to the developers guide basically needs a vote.

Your request to have a "simple build", followed by "magical build variations" 
is a good one. Splitting up the two would be a good idea.

-- 
Jody Garnett


On Thursday, 23 June 2011 at 2:50 PM, Ben Caradoc-Davies wrote:

> I am reluctant to clutter the guide with complicated-to-use options that 
> are not required for a successful build. To ease the induction of new 
> developers, can we leave the guide with the simplest, well-trodden path?
> 
> On 23/06/11 12:45, Jody Garnett wrote:
> > I don't see a problem with that; could you add a note to the developers 
> > guide if you make the change?
> > 
> > --
> > Jody Garnett
> > 
> > 
> > On Thursday, 23 June 2011 at 1:42 PM, Ben Caradoc-Davies wrote:
> > 
> > Both GeoTools and GeoServer settrue for maven-compiler-plugin:
> > https://jira.codehaus.org/browse/GEOT-2462
> > 
> > This makes server VM builds (including 64-bit) quite a bit slower
> > because the server VM is not that good for short-running processes.
> > 
> > I would like to add a fork.javac property in the top-level poms of
> > GeoTools and GeoServer so those running 64-bit can use
> > -Dfork.javac=false to make their builds faster. The default will be as
> > it is now (true).
> > 
> > Any objections?
> > 
> > Kind regards,
> > 
> > --
> > Ben 
> > Caradoc-Daviesmailto:ben.caradoc-dav...@csiro.au>>
> > Software Engineering Team Leader
> > CSIRO Earth Science and Resource Engineering
> > Australian Resources Research Centre
> > 
> > --
> > Simplify data backup and recovery for your virtual environment with vRanger.
> > Installation's a snap, and flexible recovery options mean your data is safe,
> > secure and there when you need it. Data protection magic?
> > Nope - It's vRanger. Get your free trial download today.
> > http://p.sf.net/sfu/quest-sfdev2dev
> > ___
> > Geotools-devel mailing list
> > Geotools-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/geotools-devel
> 
> -- 
> Ben Caradoc-Davies  (mailto:ben.caradoc-dav...@csiro.au)>
> Software Engineering Team Leader
> CSIRO Earth Science and Resource Engineering
> Australian Resources Research Centre

--
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today.
http://p.sf.net/sfu/quest-sfdev2dev___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [jira] Created: (GEOT-3665) WFS 1.0 Trips up over multiple namespace use for TinyOWS server

2011-06-22 Thread Jody Garnett (JIRA)

WFS 1.0 Trips up over multiple namespace use for TinyOWS server
---

 Key: GEOT-3665
 URL: https://jira.codehaus.org/browse/GEOT-3665
 Project: GeoTools
  Issue Type: Bug
  Components: wfs plugin
Affects Versions: 8.0-M0
Reporter: Jody Garnett
Assignee: Gabriel Roldán


>From email:

{panel}
I have a TinyOWS server configured to have feature types in two namespaces 
tows: and lv:
I can get the tows: feature types on uDig map but not the lv: feature types. 
The error uDig version 1.2 gives is as follows:
{noformat}
Caused by: java.io.IOException: org.xml.sax.SAXException: cannot merge two 
target namespaces. http://www.tinyows.org/ http://latuviitta.fi/
at org.geotools.xml.gml.FCBuffer.hasNext(FCBuffer.java:326)
at 
org.geotools.data.wfs.v1_0_0.WFSFeatureReader.loadElement(WFSFeatureReader.java:189)
at 
org.geotools.data.wfs.v1_0_0.WFSFeatureReader.hasNext(WFSFeatureReader.java:178)
at org.geotools.data.ReTypeFeatureReader.hasNext(ReTypeFeatureReader.java:192)
at 
org.geotools.data.wfs.v1_0_0.NonStrictWFSStrategy.createFeatureReaderGET(NonStrictWFSStrategy.java:134)
at 
org.geotools.data.wfs.v1_0_0.NonStrictWFSStrategy.createFeatureReader(NonStrictWFSStrategy.java:101)
at 
org.geotools.data.wfs.v1_0_0.NonStrictWFSStrategy.getFeatureReader(NonStrictWFSStrategy.java:72)
at 
org.geotools.data.wfs.v1_0_0.WFS_1_0_0_DataStore.getFeatureReader(WFS_1_0_0_DataStore.java:747)
at 
org.geotools.data.DefaultFeatureResults.reader(DefaultFeatureResults.java:210)
at 
org.geotools.data.store.DataFeatureCollection.openIterator(DataFeatureCollection.java:224)
at 
org.geotools.data.store.DataFeatureCollection.iterator(DataFeatureCollection.java:194)
at 
org.geotools.renderer.lite.StreamingRenderer.drawOptimized(StreamingRenderer.java:1931)
... 8 more
Caused by: org.xml.sax.SAXException: cannot merge two target namespaces. 
http://www.tinyows.org/ http://latuviitta.fi/
at org.geotools.xml.SchemaFactory$MergedSchema.(SchemaFactory.java:492)
at org.geotools.xml.SchemaFactory.merge(SchemaFactory.java:386)
at org.geotools.xml.SchemaFactory.getRealInstance(SchemaFactory.java:322)
at org.geotools.xml.SchemaFactory.getInstance(SchemaFactory.java:277)
at 
org.geotools.xml.handlers.ElementHandlerFactory.startPrefixMapping(ElementHandlerFactory.java:86)
at org.geotools.xml.XMLSAXHandler.startElement(XMLSAXHandler.java:373)
at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source)
{noformat}
I can use all my WFS feature types with the following WFS clients: ArcGIS, 
MapInfo, Kosmo GIS, QGis, gvSIG, Cadcorp SIS Map Browser and Gaia.

Regards,

-Jukka Rahkonen-
{panel}


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

   

--
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today.
http://p.sf.net/sfu/quest-sfdev2dev
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Add pom property fork.javac

2011-06-22 Thread Ben Caradoc-Davies

I am reluctant to clutter the guide with complicated-to-use options that 
are not required for a successful build. To ease the induction of new 
developers, can we leave the guide with the simplest, well-trodden path?

On 23/06/11 12:45, Jody Garnett wrote:
> I don't see a problem with that; could you add a note to the developers guide 
> if you make the change?
>
> --
> Jody Garnett
>
>
> On Thursday, 23 June 2011 at 1:42 PM, Ben Caradoc-Davies wrote:
>
> Both GeoTools and GeoServer settrue  for maven-compiler-plugin:
> https://jira.codehaus.org/browse/GEOT-2462
>
> This makes server VM builds (including 64-bit) quite a bit slower
> because the server VM is not that good for short-running processes.
>
> I would like to add a fork.javac property in the top-level poms of
> GeoTools and GeoServer so those running 64-bit can use
> -Dfork.javac=false to make their builds faster. The default will be as
> it is now (true).
>
> Any objections?
>
> Kind regards,
>
> --
> Ben 
> Caradoc-Daviesmailto:ben.caradoc-dav...@csiro.au>>
> Software Engineering Team Leader
> CSIRO Earth Science and Resource Engineering
> Australian Resources Research Centre
>
> --
> Simplify data backup and recovery for your virtual environment with vRanger.
> Installation's a snap, and flexible recovery options mean your data is safe,
> secure and there when you need it. Data protection magic?
> Nope - It's vRanger. Get your free trial download today.
> http://p.sf.net/sfu/quest-sfdev2dev
> ___
> Geotools-devel mailing list
> Geotools-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>

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

--
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today.
http://p.sf.net/sfu/quest-sfdev2dev
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Add pom property fork.javac

2011-06-22 Thread Jody Garnett

I don't see a problem with that; could you add a note to the developers guide 
if you make the change?

-- 
Jody Garnett


On Thursday, 23 June 2011 at 1:42 PM, Ben Caradoc-Davies wrote:

> Both GeoTools and GeoServer set true for maven-compiler-plugin:
> https://jira.codehaus.org/browse/GEOT-2462
> 
> This makes server VM builds (including 64-bit) quite a bit slower 
> because the server VM is not that good for short-running processes.
> 
> I would like to add a fork.javac property in the top-level poms of 
> GeoTools and GeoServer so those running 64-bit can use 
> -Dfork.javac=false to make their builds faster. The default will be as 
> it is now (true).
> 
> Any objections?
> 
> Kind regards,
> 
> -- 
> Ben Caradoc-Davies  (mailto:ben.caradoc-dav...@csiro.au)>
> Software Engineering Team Leader
> CSIRO Earth Science and Resource Engineering
> Australian Resources Research Centre
> 
> --
> Simplify data backup and recovery for your virtual environment with vRanger.
> Installation's a snap, and flexible recovery options mean your data is safe,
> secure and there when you need it. Data protection magic?
> Nope - It's vRanger. Get your free trial download today.
> http://p.sf.net/sfu/quest-sfdev2dev
> ___
> Geotools-devel mailing list
> Geotools-devel@lists.sourceforge.net 
> (mailto:Geotools-devel@lists.sourceforge.net)
> https://lists.sourceforge.net/lists/listinfo/geotools-devel

--
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today.
http://p.sf.net/sfu/quest-sfdev2dev___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] join api and app-schema (was: join proposal)

2011-06-22 Thread Niels

Yes, this is true. Eventually I would like to see app-schema joining be 
using the new geotools joining API, but I won't be around for that 
anymore. I think it will take more to do the migration though than just 
merging, for example because of the use of filters rather than two 
expressions for joining. In the meantime a temporary solution would need 
to be found so nothing is broken, simply renaming the method or something.

On 23/06/11 11:46, Justin Deoliveira wrote:
I just realized that the proposed api will actually cause a 
complication failure in app-schema, due to JoiningQuery which 
subclasses query and adds getJoins() but returns a different class 
called Join.

app-schema folks: what are your thoughts? the two classes are 
significantly different. Any chance of merging them? Or perhaps making 
the one in app-schema a subclass of the new Join class?

On Wed, Jun 22, 2011 at 9:34 AM, Ian Turton > wrote:

On 22 June 2011 11:23, Justin Deoliveira mailto:jdeol...@opengeo.org>> wrote:
> Hi Ian,
>
> On Wed, Jun 22, 2011 at 9:11 AM, Ian Turton mailto:ijtur...@gmail.com>> wrote:
>>
>> It looks good to me so +1.
>>
>> My small niggle is the use of
>>
>> query.getJoins().add(join1);
>>
>> where I might prefer:
>>
>> query.addJoin(join1);
>>
>> which might be easier for users to spot in the API.
>
> I don't have a strong preference but I tend to stay away from
doing that in
> apis and instead just make the collection available. Reasoning
being that
> you are start to have to turn the containing class (in this case
Query) into
> a collection type, give it a getNumberJoins() method,
removeJoin(), etc...
> which imo pollutes the api.
>>

That is a good point - but may be an addJoin() convenience method and
getJoins for everything else. I suspect most users will be just adding
a join to their query.

>> If you do stick with getJoins() is there are there good reasons to
>> make it return a list over a collection? I can't work out if it is
>> important to force an ordering to joins or not.
>
> I do think ordering is important, if for anything to determine
what order
> the attributes will be in the resulting feature type. It would
seem strange
> to do:
> query.getJoins().add(new Join("type1"))
> query.getJoins().add(new Join("type2"))
> But then have the feature type return them in the order "type2",
"type1". So
> I guess my answer would be "any reason not to make it a list"? :)

That is exactly the reason that was hoovering in the back of my mind
that I couldn't pull forward. A list is fine - I just wanted to check.

Ian

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

--
*Niels Charlier*

Software Engineer
CSIRO Earth Science and Resource Engineering
Phone: +61 8 6436 8914

Australian Resources Research Centre
26 Dick Perry Avenue, Kensington WA 6151
--
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today.
http://p.sf.net/sfu/quest-sfdev2dev___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] join api and app-schema (was: join proposal)

2011-06-22 Thread Justin Deoliveira

I just realized that the proposed api will actually cause a complication
failure in app-schema, due to JoiningQuery which subclasses query and adds
getJoins() but returns a different class called Join.

app-schema folks: what are your thoughts? the two classes are significantly
different. Any chance of merging them? Or perhaps making the one in
app-schema a subclass of the new Join class?

On Wed, Jun 22, 2011 at 9:34 AM, Ian Turton  wrote:

> On 22 June 2011 11:23, Justin Deoliveira  wrote:
> > Hi Ian,
> >
> > On Wed, Jun 22, 2011 at 9:11 AM, Ian Turton  wrote:
> >>
> >> It looks good to me so +1.
> >>
> >> My small niggle is the use of
> >>
> >> query.getJoins().add(join1);
> >>
> >> where I might prefer:
> >>
> >> query.addJoin(join1);
> >>
> >> which might be easier for users to spot in the API.
> >
> > I don't have a strong preference but I tend to stay away from doing that
> in
> > apis and instead just make the collection available. Reasoning being that
> > you are start to have to turn the containing class (in this case Query)
> into
> > a collection type, give it a getNumberJoins() method, removeJoin(),
> etc...
> > which imo pollutes the api.
> >>
>
> That is a good point - but may be an addJoin() convenience method and
> getJoins for everything else. I suspect most users will be just adding
> a join to their query.
>
>
> >> If you do stick with getJoins() is there are there good reasons to
> >> make it return a list over a collection? I can't work out if it is
> >> important to force an ordering to joins or not.
> >
> > I do think ordering is important, if for anything to determine what order
> > the attributes will be in the resulting feature type. It would seem
> strange
> > to do:
> > query.getJoins().add(new Join("type1"))
> > query.getJoins().add(new Join("type2"))
> > But then have the feature type return them in the order "type2", "type1".
> So
> > I guess my answer would be "any reason not to make it a list"? :)
>
> That is exactly the reason that was hoovering in the back of my mind
> that I couldn't pull forward. A list is fine - I just wanted to check.
>
> Ian
>



-- 
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
--
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today.
http://p.sf.net/sfu/quest-sfdev2dev___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] Add pom property fork.javac

2011-06-22 Thread Ben Caradoc-Davies

Both GeoTools and GeoServer set true for maven-compiler-plugin:
https://jira.codehaus.org/browse/GEOT-2462

This makes server VM builds (including 64-bit) quite a bit slower 
because the server VM is not that good for short-running processes.

I would like to add a fork.javac property in the top-level poms of 
GeoTools and GeoServer so those running 64-bit can use 
-Dfork.javac=false to make their builds faster. The default will be as 
it is now (true).

Any objections?

Kind regards,

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

--
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today.
http://p.sf.net/sfu/quest-sfdev2dev
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Do we have a place for XML schema files ?

2011-06-22 Thread Ben Caradoc-Davies

But end users shouldn't have to do this! We should publish any schemas 
or DTDs that we use.

On 22/06/11 23:47, Ian Schneider wrote:
> I ran into this same issue recently and while I was using Netbeans,
> the solution is the same - provide an XML catalog. An XML catalog
> allows redirection of schema locations.
>
> I googled and quickly found some resources on how to do this, though
> they appeared older. I suggest checking the documentation for xmlspy
> as each environment may be slightly different.
>
> -Ian
> - Show quoted text -
>
> On Wed, Jun 22, 2011 at 5:34 AM,  wrote:
>> And how does this work if I use my favorite xml editor, xmlspy as an
>> example ?.
>> Normally, the schema locations are absolute URLs like http://,
>>
>>
>> Zitat von Jody Garnett:
>>
>>> I think the app-schema team has a resolver that allows them to store schema
>>> files in a jar and manage them in a maven repository as normal artefacts?
>>> With the advantage of being able to bundle them up for "offline" use 
>>>
>>> Jody
>>>
>>>
>>> On Wed, Jun 22, 2011 at 8:43 PM,  wrote:
>>>
 The topic is interesting for both geotools/geoserver.

 I have XML config files in both environments and I always try to have
 a xml schema to achieve higher quality. It would be nice to use
 xsi:schemaLocation  in the concrete xml files to ease validation and
 editing.

 Tho make this work we need an official  place where we can put these
 schema files (or DTDs).
 Example: http://java.sun.com/dtd/properties.dtd

 A quick workaround would be to reference them in the svn repo like

 xsi:schemaLocation="namespaceurl

 http://svn.osgeo.org/geotools/trunk/modules/library/xml/src/test/resources/org/geotools/xml/test-data/mails.xsd
 "

 But I am not sure if this is a good idea ?

 Cheers
 Chrilstian

 
 This message was sent using IMP, the Internet Messaging Program.




 --
 Simplify data backup and recovery for your virtual environment with
 vRanger.
 Installation's a snap, and flexible recovery options mean your data is
 safe,
 secure and there when you need it. Data protection magic?
 Nope - It's vRanger. Get your free trial download today.
 http://p.sf.net/sfu/quest-sfdev2dev
 ___
 Geotools-devel mailing list
 Geotools-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/geotools-devel

>>>
>>
>>
>>
>> 
>> This message was sent using IMP, the Internet Messaging Program.
>>
>>
>>
>> --
>> Simplify data backup and recovery for your virtual environment with vRanger.
>> Installation's a snap, and flexible recovery options mean your data is safe,
>> secure and there when you need it. Data protection magic?
>> Nope - It's vRanger. Get your free trial download today.
>> http://p.sf.net/sfu/quest-sfdev2dev
>> ___
>> Geotools-devel mailing list
>> Geotools-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>
>
>
>

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

--
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today.
http://p.sf.net/sfu/quest-sfdev2dev
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Do we have a place for XML schema files ?

2011-06-22 Thread Ben Caradoc-Davies

+1

The app-schema-resolver does help in this situation. We should publish 
our schemas.

On 22/06/11 19:34, christian.muel...@nvoe.at wrote:
> And how does this work if I use my favorite xml editor, xmlspy as an
> example ?.
> Normally, the schema locations are absolute URLs like http://,
>
>
> Zitat von Jody Garnett:
>
>> I think the app-schema team has a resolver that allows them to store schema
>> files in a jar and manage them in a maven repository as normal artefacts?
>> With the advantage of being able to bundle them up for "offline" use 
>>
>> Jody
>>
>>
>> On Wed, Jun 22, 2011 at 8:43 PM,  wrote:
>>
>>> The topic is interesting for both geotools/geoserver.
>>>
>>> I have XML config files in both environments and I always try to have
>>> a xml schema to achieve higher quality. It would be nice to use
>>> xsi:schemaLocation  in the concrete xml files to ease validation and
>>> editing.
>>>
>>> Tho make this work we need an official  place where we can put these
>>> schema files (or DTDs).
>>> Example: http://java.sun.com/dtd/properties.dtd
>>>
>>> A quick workaround would be to reference them in the svn repo like
>>>
>>> xsi:schemaLocation="namespaceurl
>>>
>>> http://svn.osgeo.org/geotools/trunk/modules/library/xml/src/test/resources/org/geotools/xml/test-data/mails.xsd
>>> "
>>>
>>> But I am not sure if this is a good idea ?
>>>
>>> Cheers
>>> Chrilstian
>>>
>>> 
>>> This message was sent using IMP, the Internet Messaging Program.
>>>
>>>
>>>
>>>
>>> --
>>> Simplify data backup and recovery for your virtual environment with
>>> vRanger.
>>> Installation's a snap, and flexible recovery options mean your data is
>>> safe,
>>> secure and there when you need it. Data protection magic?
>>> Nope - It's vRanger. Get your free trial download today.
>>> http://p.sf.net/sfu/quest-sfdev2dev
>>> ___
>>> Geotools-devel mailing list
>>> Geotools-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>>
>>
>
>
>
> 
> This message was sent using IMP, the Internet Messaging Program.
>
>
>
> --
> Simplify data backup and recovery for your virtual environment with vRanger.
> Installation's a snap, and flexible recovery options mean your data is safe,
> secure and there when you need it. Data protection magic?
> Nope - It's vRanger. Get your free trial download today.
> http://p.sf.net/sfu/quest-sfdev2dev
> ___
> Geotools-devel mailing list
> Geotools-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>

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

--
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today.
http://p.sf.net/sfu/quest-sfdev2dev
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Do we have a place for XML schema files ?

2011-06-22 Thread Ben Caradoc-Davies

Yes, for target schemas, but the mapping file schema 
AppSchemaDataAccess.xsd is copied manually and is unpublished (although 
it is only used to support manual editing). We have *exactly* the same 
problem Christian has. Users have raised this issue on the lists.

Publishing at an svn url is problematic: commits might break an existing 
deployment, lots of versioning problems.

I would love to have a schemas.geotools.org or schemas.osgeo.org .

On 22/06/11 18:55, Jody Garnett wrote:
> I think the app-schema team has a resolver that allows them to store schema 
> files in a jar and manage them in a maven repository as normal artefacts? 
> With the advantage of being able to bundle them up for "offline" use 
>
> Jody
>
>
> On Wed, Jun 22, 2011 at 8:43 
> PM,mailto:christian.muel...@nvoe.at>>  wrote:
> The topic is interesting for both geotools/geoserver.
>
> I have XML config files in both environments and I always try to have
> a xml schema to achieve higher quality. It would be nice to use
> xsi:schemaLocation  in the concrete xml files to ease validation and
> editing.
>
> Tho make this work we need an official  place where we can put these
> schema files (or DTDs).
> Example: http://java.sun.com/dtd/properties.dtd
>
> A quick workaround would be to reference them in the svn repo like
>
> xsi:schemaLocation="namespaceurl
> http://svn.osgeo.org/geotools/trunk/modules/library/xml/src/test/resources/org/geotools/xml/test-data/mails.xsd";
>
> But I am not sure if this is a good idea ?
>
> Cheers
> Chrilstian
>
> 
> This message was sent using IMP, the Internet Messaging Program.
>
>
>
> --
> Simplify data backup and recovery for your virtual environment with vRanger.
> Installation's a snap, and flexible recovery options mean your data is safe,
> secure and there when you need it. Data protection magic?
> Nope - It's vRanger. Get your free trial download today.
> http://p.sf.net/sfu/quest-sfdev2dev
> ___
> Geotools-devel mailing list
> Geotools-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
>

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

--
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today.
http://p.sf.net/sfu/quest-sfdev2dev
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] "Monolithic" OSGi bundle for GeoTools 2.7.2

2011-06-22 Thread Jody Garnett

Thanks Mathieu:

If you want we can update the release anouncement; or you can make a blog post; 
as you produce each monolithic bundle?

-- 
Jody Garnett


On Thursday, 23 June 2011 at 3:52 AM, Mathieu Baudier wrote:

> Hello,
> 
> since there seem to be some interest for our "monolithic" GeoTools
> bundle (Tisham?) until we get GeoTools to integrate modularly with
> dynamic runtimes, I have packaged a GeoTools 2.7.2 version in our
> Maven repository:
> 
> http://maven.argeo.org/argeo/
> 
> with OBR metadata available here:
> http://maven.argeo.org/argeo/repository.xml
> 
> The Maven coordinates of this bundle are:
> org.argeo.dep.osgi:org.argeo.dep.osgi.geotools:2.7.2.0001
> 
> As I put previously, I had some issues with PostGIS datastores when I
> first tried 2.7.x and I hope to soon find some time to check whether
> it still occurs and if yes, fix it, so I may update this bundle again
> pretty soon.
> Meanwhile, feedback is of course welcome.
> 
> Cheers,
> 
> Mathieu
> 
> --
> Simplify data backup and recovery for your virtual environment with vRanger.
> Installation's a snap, and flexible recovery options mean your data is safe,
> secure and there when you need it. Data protection magic?
> Nope - It's vRanger. Get your free trial download today.
> http://p.sf.net/sfu/quest-sfdev2dev
> ___
> Geotools-devel mailing list
> Geotools-devel@lists.sourceforge.net 
> (mailto:Geotools-devel@lists.sourceforge.net)
> https://lists.sourceforge.net/lists/listinfo/geotools-devel

--
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today.
http://p.sf.net/sfu/quest-sfdev2dev___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] "Monolithic" OSGi bundle for GeoTools 2.7.2

2011-06-22 Thread Mathieu Baudier

Hello,

since there seem to be some interest for our "monolithic" GeoTools
bundle (Tisham?) until we get GeoTools to integrate modularly with
dynamic runtimes, I have packaged a GeoTools 2.7.2 version in our
Maven repository:

http://maven.argeo.org/argeo/

with OBR metadata available here:
http://maven.argeo.org/argeo/repository.xml

The Maven coordinates of this bundle are:
org.argeo.dep.osgi:org.argeo.dep.osgi.geotools:2.7.2.0001

As I put previously, I had some issues with PostGIS datastores when I
first tried 2.7.x and I hope to soon find some time to check whether
it still occurs and if yes, fix it, so I may update this bundle again
pretty soon.
Meanwhile, feedback is of course welcome.

Cheers,

Mathieu

--
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today.
http://p.sf.net/sfu/quest-sfdev2dev
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Do we have a place for XML schema files ?

2011-06-22 Thread Ian Schneider

I ran into this same issue recently and while I was using Netbeans,
the solution is the same - provide an XML catalog. An XML catalog
allows redirection of schema locations.

I googled and quickly found some resources on how to do this, though
they appeared older. I suggest checking the documentation for xmlspy
as each environment may be slightly different.

-Ian
- Show quoted text -

On Wed, Jun 22, 2011 at 5:34 AM,   wrote:
> And how does this work if I use my favorite xml editor, xmlspy as an
> example ?.
> Normally, the schema locations are absolute URLs like http://,
>
>
> Zitat von Jody Garnett :
>
>> I think the app-schema team has a resolver that allows them to store schema
>> files in a jar and manage them in a maven repository as normal artefacts?
>> With the advantage of being able to bundle them up for "offline" use 
>>
>> Jody
>>
>>
>> On Wed, Jun 22, 2011 at 8:43 PM,  wrote:
>>
>>> The topic is interesting for both geotools/geoserver.
>>>
>>> I have XML config files in both environments and I always try to have
>>> a xml schema to achieve higher quality. It would be nice to use
>>> xsi:schemaLocation  in the concrete xml files to ease validation and
>>> editing.
>>>
>>> Tho make this work we need an official  place where we can put these
>>> schema files (or DTDs).
>>> Example: http://java.sun.com/dtd/properties.dtd
>>>
>>> A quick workaround would be to reference them in the svn repo like
>>>
>>> xsi:schemaLocation="namespaceurl
>>>
>>> http://svn.osgeo.org/geotools/trunk/modules/library/xml/src/test/resources/org/geotools/xml/test-data/mails.xsd
>>> "
>>>
>>> But I am not sure if this is a good idea ?
>>>
>>> Cheers
>>> Chrilstian
>>>
>>> 
>>> This message was sent using IMP, the Internet Messaging Program.
>>>
>>>
>>>
>>>
>>> --
>>> Simplify data backup and recovery for your virtual environment with
>>> vRanger.
>>> Installation's a snap, and flexible recovery options mean your data is
>>> safe,
>>> secure and there when you need it. Data protection magic?
>>> Nope - It's vRanger. Get your free trial download today.
>>> http://p.sf.net/sfu/quest-sfdev2dev
>>> ___
>>> Geotools-devel mailing list
>>> Geotools-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>>
>>
>
>
>
> 
> This message was sent using IMP, the Internet Messaging Program.
>
>
>
> --
> Simplify data backup and recovery for your virtual environment with vRanger.
> Installation's a snap, and flexible recovery options mean your data is safe,
> secure and there when you need it. Data protection magic?
> Nope - It's vRanger. Get your free trial download today.
> http://p.sf.net/sfu/quest-sfdev2dev
> ___
> Geotools-devel mailing list
> Geotools-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>



-- 
Ian Schneider
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

--
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today.
http://p.sf.net/sfu/quest-sfdev2dev
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] join proposal

2011-06-22 Thread Ian Turton

On 22 June 2011 11:23, Justin Deoliveira  wrote:
> Hi Ian,
>
> On Wed, Jun 22, 2011 at 9:11 AM, Ian Turton  wrote:
>>
>> It looks good to me so +1.
>>
>> My small niggle is the use of
>>
>> query.getJoins().add(join1);
>>
>> where I might prefer:
>>
>> query.addJoin(join1);
>>
>> which might be easier for users to spot in the API.
>
> I don't have a strong preference but I tend to stay away from doing that in
> apis and instead just make the collection available. Reasoning being that
> you are start to have to turn the containing class (in this case Query) into
> a collection type, give it a getNumberJoins() method, removeJoin(), etc...
> which imo pollutes the api.
>>

That is a good point - but may be an addJoin() convenience method and
getJoins for everything else. I suspect most users will be just adding
a join to their query.


>> If you do stick with getJoins() is there are there good reasons to
>> make it return a list over a collection? I can't work out if it is
>> important to force an ordering to joins or not.
>
> I do think ordering is important, if for anything to determine what order
> the attributes will be in the resulting feature type. It would seem strange
> to do:
> query.getJoins().add(new Join("type1"))
> query.getJoins().add(new Join("type2"))
> But then have the feature type return them in the order "type2", "type1". So
> I guess my answer would be "any reason not to make it a list"? :)

That is exactly the reason that was hoovering in the back of my mind
that I couldn't pull forward. A list is fine - I just wanted to check.

Ian

--
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today.
http://p.sf.net/sfu/quest-sfdev2dev
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] join proposal

2011-06-22 Thread Justin Deoliveira

Hi Ian,

On Wed, Jun 22, 2011 at 9:11 AM, Ian Turton  wrote:

> It looks good to me so +1.
>
> My small niggle is the use of
>
> query.getJoins().add(join1);
>
> where I might prefer:
>
> query.addJoin(join1);
>
> which might be easier for users to spot in the API.
>
I don't have a strong preference but I tend to stay away from doing that in
apis and instead just make the collection available. Reasoning being that
you are start to have to turn the containing class (in this case Query) into
a collection type, give it a getNumberJoins() method, removeJoin(), etc...
which imo pollutes the api.

>
> If you do stick with getJoins() is there are there good reasons to
> make it return a list over a collection? I can't work out if it is
> important to force an ordering to joins or not.
>
I do think ordering is important, if for anything to determine what order
the attributes will be in the resulting feature type. It would seem strange
to do:

query.getJoins().add(new Join("type1"))
query.getJoins().add(new Join("type2"))

But then have the feature type return them in the order "type2", "type1". So
I guess my answer would be "any reason not to make it a list"? :)

>
> Ian
> --
> Ian Turton
>



-- 
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
--
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today.
http://p.sf.net/sfu/quest-sfdev2dev___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] join proposal

2011-06-22 Thread Ian Turton

It looks good to me so +1.

My small niggle is the use of

query.getJoins().add(join1);

where I might prefer:

query.addJoin(join1);

which might be easier for users to spot in the API.

If you do stick with getJoins() is there are there good reasons to
make it return a list over a collection? I can't work out if it is
important to force an ordering to joins or not.

Ian
-- 
Ian Turton

--
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today.
http://p.sf.net/sfu/quest-sfdev2dev
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] join proposal

2011-06-22 Thread Justin Deoliveira

As Andrea says this was considered and discussed. And as Andrea kindly
pointed out the WFS spec actually mandates that we don't use multiplicity
and complex feature references.

That said I don't think we should rule out using the Join construct to do
that... just that I would like it to be an implementation detail if
possible. Or maybe we add a flag some where in the api to change how results
are returned. Not sure. But I agree with Andrea that this not joining, its
mapping (although implemented via a join).

On Wed, Jun 22, 2011 at 4:24 AM, Jody Garnett wrote:

> Different problem my suggestion was an alternative to having to repeat the
> row:
>
>>
>>>  Park(fid:32,geom:Polygon, name:String, Lake(fid:21):SimpleFeature,
>>> POI:SimpleFeature)
>>> Park(fid:32, geom:Polygon, name:String,
>>> Lake(fid:22):SimpleFeature, POI:SimpleFeature)
>>>
>> I think Justin already clarified in another mail in this thread that this
>> won't be covered.
>>
>
> Justin clarified the feature being returned multiple times (as shown
> above). Nothing wrong with that I was asking
> if he had considered multiplicity. Sounds like he has and has left it as an
> exercise for another time if someone
> is interested.
>
> Cheers,
> Jody
>

-- 
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
--
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today.
http://p.sf.net/sfu/quest-sfdev2dev___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] join proposal

2011-06-22 Thread Justin Deoliveira

Thanks for the review Andrea. Comments inline.

On Wed, Jun 22, 2011 at 1:01 AM, Andrea Aime
wrote:

> On Tue, Jun 21, 2011 at 1:35 AM, Justin Deoliveira 
> wrote:
>
>> Hi all,
>>
>> The past couple of weeks i have been working on adding joins to the
>> geotools query api in support of joins in wfs 2. The work goes well and i
>> have a working implementation for the jdbc modules that has been tested with
>> postgis, h2, and oracle.
>>
>> The proposal is here:
>>
>>   http://docs.codehaus.org/display/GEOTOOLS/Join+Support
>>
>> Review and feedback welcome. The referenced jira issue has a patch.
>>
>> I would like to *note* though, this proposal is only for the api changes
>> and does not include the jdbc implementation. I plan to treat that as
>> a separate issue/change. There is also some more testing and cleanup that
>> needs to occur there before a presentable patch can emerge.
>>
>
> Hi Justin,
> I finally found some time to read the proposal for good.
> Generally speaking it seems good, I have two questions:
> - what about joins done just for the sake of filtering? "Find all the POIs
> inside a park" would
>   not need to return any park. Would be good to have that option in the
> join
> - not sure about the WFS 2.0 specifics, but I believe you can choose which
> properties of
>   each returned feature type need to be included in the result?
>   I see now that the Join class actually has the list of properties, yet I
> did not see it while
>   reading the proposal.
>

 Will update the proposal to make that more evident.

>
> About the first, would it make sense to have yet another join type,
> public static enum Type {
> INNER, OUTER, LEFT, RIGHT, FILTER
> }
>
> where FILTER would instruct the machinery not to return the features from
> joined
> feature type.
>

Yeah that makes sense. I can add that in.


> I'm not 100% sure, but there should also be some way to express this in WFS
> queries,
> wouldn't it?
>

Would be nice for sure... to be able to get a regular feature collection
back with a join (and not tuples). But reading through the spec it seems to
imply that if you do a join query you must return features from all the
types, via a tuple. Although as an extension perhaps we can allow the user
to specify the mode and support this. Or maybe I am missing something int
the spec.

>
> Besides this detail, +1
>
> Cheers
> Andrea
>
> --
> ---
> Ing. Andrea Aime
> GeoSolutions S.A.S.
> Tech lead
>
> Via Poggio alle Viti 1187
> 55054  Massarosa (LU)
> Italy
>
> phone: +39 0584 962313
> fax:  +39 0584 962313
>
> http://www.geo-solutions.it
> http://geo-solutions.blogspot.com/
> http://www.youtube.com/user/GeoSolutionsIT
> http://www.linkedin.com/in/andreaaime
> http://twitter.com/geowolf
>
> ---
>



-- 
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
--
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today.
http://p.sf.net/sfu/quest-sfdev2dev___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] GeoTools 2.7.2 Released

2011-06-22 Thread Jody Garnett



 GeoTools 2.7.2 Released

The GeoTools 2.7.2 release is now available on sourceforge for download 
: 



   * README.html
 

   * geotools-2.7.2-bin.zip
 

   * geotools-2.7.2-project.zip
 

   * geotools-2.7.2-doc.zip
 

   * geotools-2.7.2-welcome.zip
 


If you are using maven GeoTools 2.7.2 is available from the OSGeo 
repository.


This is a bug fix release made in conjunction with GeoServer 2.1.1.

This is primarily a maintenance release focused on improving GeoTools 
2.7 and is not devoted to new features. However a few call out to 
recognise some excellent work:


A long standing glitch in rendering line patterns was resolved; and 
GeoTools has been updated to work with PostGIS 2.0. Thanks Andrea and 
GeoSolutions for both of these fixes.


Thanks to Ben for back porting EMF 2.6.1 to the stable branch.

For more information:

   * GeoTools 2.7.2 Release Notes
 

   * geotools.org 

The GeoTools development team would like to thank our customers and 
employers for making this release possible. Thanks to LISAsoft for 
sponsoring this maintenance release.


Enjoy,
The GeoTools Community

--
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today.
http://p.sf.net/sfu/quest-sfdev2dev___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] ImageI/O-Ext 1.1.0 Released

2011-06-22 Thread Daniele Romagnoli

Folks,
GeoSolutions is pleased to announce the ImageI/O-Ext 1.1.0 release.
Changes with respect to 1.0.x series can be summarised as follows:

   - *Out-of-the-box* Support for GDAL 
1.7.3,
   which means no more patches are needed for GDAL Java bindings in order to
   access it from ImageI/O-Ext.
   - *BigTiff* support,
breaking the 4GB TIFF limit.
   - *EnhancedImageReadParam *support. It extends the standard
   
ImageReadParamby
implementing Cloneable (used when supporting
   *MultiThreading *read operation) and a new *DestinationRegion* param to
   support oversampling/subsampling without specifying
sourceSubSamplingparameters.
This may be used when dealing with readers which internally take
   care of performing subSampling/overSampling, such as the *GDALImageReader
   *
   - Experimental multidimension plugin for reading spatiotemporal sources
   like:
  - netCDF raster files following the Climate and Forecast
(CF)
  convention
  - GriB edition 1 
  - HDF version 4

Finally, with respect to 1.1-RC1 version, Release 1.1.0 also adds support
for BSB and CADRG RPFTOC plugin (through GDAL) .
 Release artifacts have been deployed on the GeoSolutions maven
repository,
as well as on the
OSGEOone.

Regards,
the GeoSolutions  Team

-- 
---
Ing. Daniele Romagnoli
GeoSolutions S.A.S.
Software Engineer

Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy

phone: +39 0584 962313
fax:  +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://it.linkedin.com/in/danieleromagnoli


---
--
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today.
http://p.sf.net/sfu/quest-sfdev2dev___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Do we have a place for XML schema files ?

2011-06-22 Thread christian . mueller

And how does this work if I use my favorite xml editor, xmlspy as an  
example ?.
Normally, the schema locations are absolute URLs like http://,


Zitat von Jody Garnett :

> I think the app-schema team has a resolver that allows them to store schema
> files in a jar and manage them in a maven repository as normal artefacts?
> With the advantage of being able to bundle them up for "offline" use 
>
> Jody
>
>
> On Wed, Jun 22, 2011 at 8:43 PM,  wrote:
>
>> The topic is interesting for both geotools/geoserver.
>>
>> I have XML config files in both environments and I always try to have
>> a xml schema to achieve higher quality. It would be nice to use
>> xsi:schemaLocation  in the concrete xml files to ease validation and
>> editing.
>>
>> Tho make this work we need an official  place where we can put these
>> schema files (or DTDs).
>> Example: http://java.sun.com/dtd/properties.dtd
>>
>> A quick workaround would be to reference them in the svn repo like
>>
>> xsi:schemaLocation="namespaceurl
>>
>> http://svn.osgeo.org/geotools/trunk/modules/library/xml/src/test/resources/org/geotools/xml/test-data/mails.xsd
>> "
>>
>> But I am not sure if this is a good idea ?
>>
>> Cheers
>> Chrilstian
>>
>> 
>> This message was sent using IMP, the Internet Messaging Program.
>>
>>
>>
>>
>> --
>> Simplify data backup and recovery for your virtual environment with
>> vRanger.
>> Installation's a snap, and flexible recovery options mean your data is
>> safe,
>> secure and there when you need it. Data protection magic?
>> Nope - It's vRanger. Get your free trial download today.
>> http://p.sf.net/sfu/quest-sfdev2dev
>> ___
>> Geotools-devel mailing list
>> Geotools-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>
>




This message was sent using IMP, the Internet Messaging Program.



--
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today.
http://p.sf.net/sfu/quest-sfdev2dev
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Do we have a place for XML schema files ?

2011-06-22 Thread Jody Garnett

I think the app-schema team has a resolver that allows them to store schema
files in a jar and manage them in a maven repository as normal artefacts?
With the advantage of being able to bundle them up for "offline" use 

Jody


On Wed, Jun 22, 2011 at 8:43 PM,  wrote:

> The topic is interesting for both geotools/geoserver.
>
> I have XML config files in both environments and I always try to have
> a xml schema to achieve higher quality. It would be nice to use
> xsi:schemaLocation  in the concrete xml files to ease validation and
> editing.
>
> Tho make this work we need an official  place where we can put these
> schema files (or DTDs).
> Example: http://java.sun.com/dtd/properties.dtd
>
> A quick workaround would be to reference them in the svn repo like
>
> xsi:schemaLocation="namespaceurl
>
> http://svn.osgeo.org/geotools/trunk/modules/library/xml/src/test/resources/org/geotools/xml/test-data/mails.xsd
> "
>
> But I am not sure if this is a good idea ?
>
> Cheers
> Chrilstian
>
> 
> This message was sent using IMP, the Internet Messaging Program.
>
>
>
>
> --
> Simplify data backup and recovery for your virtual environment with
> vRanger.
> Installation's a snap, and flexible recovery options mean your data is
> safe,
> secure and there when you need it. Data protection magic?
> Nope - It's vRanger. Get your free trial download today.
> http://p.sf.net/sfu/quest-sfdev2dev
> ___
> Geotools-devel mailing list
> Geotools-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
--
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today.
http://p.sf.net/sfu/quest-sfdev2dev___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Proposed MongoDB Plugin

2011-06-22 Thread Jody Garnett

Hi Alan:

So if I understand you this is a request for a new module (for a DataStore
supporting MongoDB). Sounds great!

Modules start out as unsupported; and go through a review process before
being accepted into the library for redistribution and so on. Unsupported
modules are deployed to the maven repository; and can be used by your
geoserver community module etc.

1) So first up - the procedure to create a new module is here:
- http://docs.geotools.org/latest/developer/guide/procedures/create.html

You have already started this one, as one of the instructions is to send an
email.

2) The next step is approval by a PMC - that would be me:

+1

3) I would like to ask you to review the developers guide, and email back
with any questions:

- http://docs.geotools.org/latest/developer/index.html

It should cover the difference between supported and unsupported, the
different branches (currently we have trunk/ and 2.7.x) and the various
coding conventions and so forth.

4) Next up I need to ask you to print out the PDF mentioned on this page;
and mail it to the Open Source Geospatial Foundation. The details are
included in the PDF. You may also need to ask your employer to fill one in?

- http://docs.geotools.org/latest/developer/guide/roles/commit.html

All the best, and welcome to GeoTools :-)

Jody

On Wed, Jun 22, 2011 at 8:41 PM, Alan Mangan wrote:

> **
> hi,
>
> We've developed a MongoDB plugin for GeoServer that we'd like to add to
> GeoTools. I'm awaiting confirmation on my application to join the GeoTools
> confluence project before creating a wiki page as per the dev guide. Does
> the plugin need to go in unsupported first, or can we add it to the
> supported branch since we do plan on supporting it?
>
> cheers,
> Alan
>

PS. You may wish to adjust the footer you use for email, as any message sent
to this public email list is not "privileged and/or confidential"
--
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today.
http://p.sf.net/sfu/quest-sfdev2dev___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] Do we have a place for XML schema files ?

2011-06-22 Thread christian . mueller

The topic is interesting for both geotools/geoserver.

I have XML config files in both environments and I always try to have  
a xml schema to achieve higher quality. It would be nice to use  
xsi:schemaLocation  in the concrete xml files to ease validation and  
editing.

Tho make this work we need an official  place where we can put these  
schema files (or DTDs).
Example: http://java.sun.com/dtd/properties.dtd

A quick workaround would be to reference them in the svn repo like

xsi:schemaLocation="namespaceurl 
http://svn.osgeo.org/geotools/trunk/modules/library/xml/src/test/resources/org/geotools/xml/test-data/mails.xsd";

But I am not sure if this is a good idea ?

Cheers
Chrilstian


This message was sent using IMP, the Internet Messaging Program.



--
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today.
http://p.sf.net/sfu/quest-sfdev2dev
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] Proposed MongoDB Plugin

2011-06-22 Thread Alan Mangan

hi,

We've developed a MongoDB plugin for GeoServer that we'd like to add to
GeoTools. I'm awaiting confirmation on my application to join the
GeoTools confluence project before creating a wiki page as per the dev
guide. Does the plugin need to go in unsupported first, or can we add it
to the supported branch since we do plan on supporting it?

cheers,
Alan
-- 
=== aman...@data-tactics.com 
Alan Mangan, Sr. Software Engineer, Data Tactics Corporation
7901 Jones Branch, Suite 240
McLean, VA 22102, USA
office: +1-571-297-2157
cell: +1-571-278-7486
=== http://www.data-tactics.com/ 

The information contained in this message may be privileged and/or
confidential and protected from disclosure. If the reader of this
message is not the intended recipient or an employee or agent
responsible for delivering this message to the intended recipient, you
are hereby notified that any dissemination, distribution or copying of
this communication is strictly prohibited. If you have received this
communication in error, please notify the sender immediately by replying
to this message and deleting the material from any computer.
--
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today.
http://p.sf.net/sfu/quest-sfdev2dev___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] join proposal

2011-06-22 Thread Jody Garnett

Different problem my suggestion was an alternative to having to repeat the
row:

>
>>  Park(fid:32,geom:Polygon, name:String, Lake(fid:21):SimpleFeature,
>> POI:SimpleFeature)
>> Park(fid:32, geom:Polygon, name:String,
>> Lake(fid:22):SimpleFeature, POI:SimpleFeature)
>>
> I think Justin already clarified in another mail in this thread that this
> won't be covered.
>

Justin clarified the feature being returned multiple times (as shown above).
Nothing wrong with that I was asking
if he had considered multiplicity. Sounds like he has and has left it as an
exercise for another time if someone
is interested.

Cheers,
Jody
--
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today.
http://p.sf.net/sfu/quest-sfdev2dev___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] join proposal

2011-06-22 Thread Andrea Aime

On Wed, Jun 22, 2011 at 10:34 AM, Jody Garnett wrote:

>  Different problem my suggestion was an alternative to having to repeat
> the row:
>
>  Park(fid:32,geom:Polygon, name:String, Lake(fid:21):SimpleFeature,
> POI:SimpleFeature)
> Park(fid:32, geom:Polygon, name:String,
> Lake(fid:22):SimpleFeature, POI:SimpleFeature)
>
> Or have a List:
> Park(fid:32, geom:Polygon, name:String,
> l:List, POI:SimpleFeature)
>

I think Justin already clarified in another mail in this thread that this
won't be covered.
Joining is about returning the tuples just like sql would do, what you are
doing above
is OR mapping, which is something that can be done in app-schema land

Cheers
Andrea

-- 
---
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy

phone: +39 0584 962313
fax:  +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

---
--
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today.
http://p.sf.net/sfu/quest-sfdev2dev___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] join proposal

2011-06-22 Thread Jody Garnett

Different problem my suggestion was an alternative to having to repeat the row:

Park(fid:32,geom:Polygon, name:String, Lake(fid:21):SimpleFeature, 
POI:SimpleFeature)
Park(fid:32, geom:Polygon, name:String, Lake(fid:22):SimpleFeature, 
POI:SimpleFeature) 

Or have a List:
Park(fid:32, geom:Polygon, name:String, l:List, 
POI:SimpleFeature) 

-- 
Jody Garnett


On Wednesday, 22 June 2011 at 6:04 PM, Andrea Aime wrote:

> On Wed, Jun 22, 2011 at 9:46 AM, Jody Garnett  (mailto:jody.garn...@gmail.com)> wrote:
> > First +1 looks great; and thanks for providing readable code examples (the 
> > best way to sort out if the result will be readable).
> > 
> > Have you considered using multiplicity to handle the issue of one or more 
> > features being returned on a join? To steal from your example: 
> > 
> > Park(geom:Polygon, name:String, l:SimpleFeature, l:SimpleFeature, 
> > POI:SimpleFeature) 
> > I know that steps away from simple features.
> 
> Isn't that already addressed by having multiple join statements with same 
> feature type, but different alias? 
> And no, you can't have two attributes with the same name (not even in SQL or 
> WFS joins)
> 
> Cheers
> Andrea
> 
> 
> 
> -- 
> ---
>  Ing. Andrea Aime
> GeoSolutions S.A.S.
> Tech lead
> 
> Via Poggio alle Viti 1187
> 55054 Massarosa (LU)
> Italy
> 
> phone: +39 0584 962313
> fax: +39 0584 962313
> 
> http://www.geo-solutions.it
> http://geo-solutions.blogspot.com/
> http://www.youtube.com/user/GeoSolutionsIT
> http://www.linkedin.com/in/andreaaime
> http://twitter.com/geowolf
> 
> ---

--
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today.
http://p.sf.net/sfu/quest-sfdev2dev___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] join proposal

2011-06-22 Thread Andrea Aime

On Wed, Jun 22, 2011 at 9:46 AM, Jody Garnett wrote:

>  First +1 looks great; and thanks for providing readable code examples
> (the best way to sort out if the result will be readable).
>
> Have you considered using multiplicity to handle the issue of one or more
> features being returned on a join? To steal from your example:
>
> Park(geom:Polygon, name:String, l:SimpleFeature, l:SimpleFeature, 
> POI:SimpleFeature)
>
>
> I know that steps away from simple features.
>

Isn't that already addressed by having multiple join statements with same
feature type, but different alias?
And no, you can't have two attributes with the same name (not even in SQL or
WFS  joins)

Cheers
Andrea


-- 
---
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy

phone: +39 0584 962313
fax:  +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

---
--
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today.
http://p.sf.net/sfu/quest-sfdev2dev___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [jira] Reopened: (GEOT-1880) plugin/db2 Test-data resource origin and license needs documentation

2011-06-22 Thread Jody Garnett (JIRA)


 [ 
https://jira.codehaus.org/browse/GEOT-1880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jody Garnett reopened GEOT-1880:



Won't fix issues should not be assigned a release as it makes for a confusing 
release notes.

> plugin/db2  Test-data resource origin and license needs documentation
> -
>
> Key: GEOT-1880
> URL: https://jira.codehaus.org/browse/GEOT-1880
> Project: GeoTools
>  Issue Type: Sub-task
>  Components: admin, jdbc-db2 plugin
>Reporter: Adrian Custer
>Assignee: David Adler
>Priority: Minor
> Fix For: 2.7.2
>
>
> The origin and license for the test-data in 
> db2/src/test/resources/setup
> db2/src/test/resources/setup/data
> need to be documented.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira



--
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today.
http://p.sf.net/sfu/quest-sfdev2dev
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [jira] Reopened: (GEOT-10) Allow styling to change without replacing layer

2011-06-22 Thread Jody Garnett (JIRA)


 [ 
https://jira.codehaus.org/browse/GEOT-10?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jody Garnett reopened GEOT-10:
--


Won't fix issues should not be assigned a release as it makes for a confusing 
release notes.

> Allow styling to change without replacing layer
> ---
>
> Key: GEOT-10
> URL: https://jira.codehaus.org/browse/GEOT-10
> Project: GeoTools
>  Issue Type: Improvement
>  Components: unsupported
>Affects Versions: 2.1.M0
>Reporter: James Macgill
>Priority: Minor
> Fix For: 2.7.2
>
>   Original Estimate: 8 hours
>  Time Spent: 1 hour
>  Remaining Estimate: 7 hours
>
> RenderedLayers as originaly designed are imutable, so they do not reflect 
> changes caused by modifications to a style or because of changes to the 
> values in a feature.
> This improvment will make it possible to change styling (fill and stroke) and 
> update this rapidly in cases where the geometry itself has not changed.
> The upside is a more interactive display, the downside is that references to 
> the original feature and style objects needs to be kept. 
> Because of the downside this will be an optional aproach, the current 
> technique will be maintained.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira



--
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today.
http://p.sf.net/sfu/quest-sfdev2dev
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [jira] Reopened: (GEOT-2206) Use of GeoAPI FilterCapabilities in DB2

2011-06-22 Thread Jody Garnett (JIRA)


 [ 
https://jira.codehaus.org/browse/GEOT-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jody Garnett reopened GEOT-2206:



Won't fix issues should not be assigned a release as it makes for a confusing 
release notes.

> Use of GeoAPI FilterCapabilities in DB2
> ---
>
> Key: GEOT-2206
> URL: https://jira.codehaus.org/browse/GEOT-2206
> Project: GeoTools
>  Issue Type: Sub-task
>  Components: jdbc-db2 plugin
>Affects Versions: 2.5.2
>Reporter: Gabriel Roldán
>Assignee: David Adler
> Fix For: 2.7.2
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

   

--
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today.
http://p.sf.net/sfu/quest-sfdev2dev
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [jira] Reopened: (GEOT-2368) Filter 2.0 xml bindings

2011-06-22 Thread Jody Garnett (JIRA)


 [ 
https://jira.codehaus.org/browse/GEOT-2368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jody Garnett reopened GEOT-2368:



Duplicate issue should not be assigned a release as it makes for a confusing 
release notes.

> Filter 2.0 xml bindings
> ---
>
> Key: GEOT-2368
> URL: https://jira.codehaus.org/browse/GEOT-2368
> Project: GeoTools
>  Issue Type: New Feature
>  Components: xsd extensions
>Reporter: Justin Deoliveira
>Assignee: Justin Deoliveira
>
> xml support for filter 2.0

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira



--
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today.
http://p.sf.net/sfu/quest-sfdev2dev
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] join proposal

2011-06-22 Thread Jody Garnett

First +1 looks great; and thanks for providing readable code examples (the best 
way to sort out if the result will be readable).

Have you considered using multiplicity to handle the issue of one or more 
features being returned on a join? To steal from your example:

Park(geom:Polygon, name:String, l:SimpleFeature, l:SimpleFeature, 
POI:SimpleFeature) 
I know that steps away from simple features.

-- 
Jody Garnett


On Tuesday, 21 June 2011 at 9:35 AM, Justin Deoliveira wrote:

> Hi all,
> 
> The past couple of weeks i have been working on adding joins to the geotools 
> query api in support of joins in wfs 2. The work goes well and i have a 
> working implementation for the jdbc modules that has been tested with 
> postgis, h2, and oracle. 
> 
> The proposal is here:
> 
> http://docs.codehaus.org/display/GEOTOOLS/Join+Support
> 
> Review and feedback welcome. The referenced jira issue has a patch. 
> 
> I would like to *note* though, this proposal is only for the api changes and 
> does not include the jdbc implementation. I plan to treat that as a separate 
> issue/change. There is also some more testing and cleanup that needs to occur 
> there before a presentable patch can emerge. 
> 
> Thanks folks.
> 
> -Justin
> 
> -- 
> Justin Deoliveira
> OpenGeo - http://opengeo.org
> Enterprise support for open source geospatial.
> 
> --
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> ___
> Geotools-devel mailing list
> Geotools-devel@lists.sourceforge.net 
> (mailto:Geotools-devel@lists.sourceforge.net)
> https://lists.sourceforge.net/lists/listinfo/geotools-devel

--
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today.
http://p.sf.net/sfu/quest-sfdev2dev___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Stable GeoTools Release tomorrow

2011-06-22 Thread Jody Garnett

Release is going smoothly; the 2.7.x branch is available for work again.

I have back ported the nice README.html from trunk (that includes our logo 
etc...).

The release notes are here (if anyone cares to review):
- 
https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10270&version=17359

-- 
Jody Garnett


On Wednesday, 22 June 2011 at 9:57 AM, Jody Garnett wrote:

> Starting up shortly; join me on IRC if you would like to take part or test 
> something.
> 
> -- 
> Jody Garnett
> 
> 
> On Tuesday, 21 June 2011 at 4:02 PM, Jody Garnett wrote:
> 
> > Just a followup to last weeks discussion; stable release of GeoTools is 
> > expected tomorrow. I will be assisting Mark Leslie as needed.
> > 
> > (And thanks to LISAsoft for sponsoring this activity etc...)
> > 
> > Cheers,
> > Jody
> > 
> > 
> > 
> > 
> > 
> 
> 

--
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today.
http://p.sf.net/sfu/quest-sfdev2dev___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] join proposal

2011-06-22 Thread Andrea Aime

On Tue, Jun 21, 2011 at 1:35 AM, Justin Deoliveira wrote:

> Hi all,
>
> The past couple of weeks i have been working on adding joins to the
> geotools query api in support of joins in wfs 2. The work goes well and i
> have a working implementation for the jdbc modules that has been tested with
> postgis, h2, and oracle.
>
> The proposal is here:
>
>   http://docs.codehaus.org/display/GEOTOOLS/Join+Support
>
> Review and feedback welcome. The referenced jira issue has a patch.
>
> I would like to *note* though, this proposal is only for the api changes
> and does not include the jdbc implementation. I plan to treat that as
> a separate issue/change. There is also some more testing and cleanup that
> needs to occur there before a presentable patch can emerge.
>

Hi Justin,
I finally found some time to read the proposal for good.
Generally speaking it seems good, I have two questions:
- what about joins done just for the sake of filtering? "Find all the POIs
inside a park" would
  not need to return any park. Would be good to have that option in the join
- not sure about the WFS 2.0 specifics, but I believe you can choose which
properties of
  each returned feature type need to be included in the result?
  I see now that the Join class actually has the list of properties, yet I
did not see it while
  reading the proposal.

About the first, would it make sense to have yet another join type,
public static enum Type {
INNER, OUTER, LEFT, RIGHT, FILTER
}

where FILTER would instruct the machinery not to return the features from
joined
feature type.
I'm not 100% sure, but there should also be some way to express this in WFS
queries,
wouldn't it?

Besides this detail, +1

Cheers
Andrea

-- 
---
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy

phone: +39 0584 962313
fax:  +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

---
--
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today.
http://p.sf.net/sfu/quest-sfdev2dev___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

39 matches

Mail list logo