[Geotools-devel] Geotools 8.0 stable release

[Victor.Tey]

Geotools 8.0 Released

The Geotools community is pleased to announce the availability of Geotools 8.0 
for download on 
sourceforge.

 *   
geotools-8.0-bin.zip
 *   
geotools-8.0-doc.zip
 *   
geotools-8.0-userguide.zip
 *   
geotools-8.0-project.zip
If you are using Maven, this release is deployed to our OSGeo Maven Repository:

For more information on setting up your project with Maven, see the Quickstart 
 
(included in the user guide documentation pack above).

Geotools 8.0 is a stable release made in conjunction with GeoServer 2.2-RC2 and 
GeoWebCache 1.3-RC4. Currently there are no additional updates to 2.7.x planned.

Geotools 8.0 comes feature packed compared to its 2.7.x releases. Highlights 
include:

 *   Function lookup using qualified 
Name
 *   Update to Java 6
 *   Add support for joins to the WFS 
protocol
 *   New ILIKE 
statement
 *   Support Multi-Valued Attributes in Filter Comparison 
Operators
 *   Temporal 
Filters
 *   Allow build with Maven 2 or Maven 
3
 *   Describe Function with 
FunctionName
 *   Detailed Argument and Return Info for 
FunctionName
 *   Introduction for the use of 
ResourceId
 *   Sphinx generated user guide 
with live codes examples, tutorials and build instructions
 *   MapContext 
refactor
More information can be found by checking out the proposals made for this 
release here.

For those migrating from GeoTools 2.7, additional instructions are available 
here.

We would like to take the opportunity to thank all the developers, users and 
contributor that have helped to make this release possible.

Enjoy,
The GeoTools Community
http://geotools.org



--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Meeting 2012-08-06

[Ben Caradoc-Davies]

On 07/08/12 00:57, Justin Deoliveira wrote:
> Sorry I couldn't make it today, it is a holiday in Canada and i am not
> working a regular working day.

And it is the two weeks in which Canada isn't frozen solid.  ;-)

> Regarding the security stuff for 2.2.x being a blocker is that referring
> to what Christian recently posted? Looks like it, will respond to that
> thread.

Yes, I thought we might need to attend to this one before release.

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



--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Time boxed releases proposal turned into a first doc page

[Justin Deoliveira]

Thanks for putting that together Andrea. Looked it over and made some
edits. Mostly just some minor rewording, spelling, etc... You can find the
result here.


https://github.com/jdeolive/geoserver/blob/release_schedule_doc/doc/en/developer/source/release-schedule/index.rst

If you have no concerns about the changes i will merge them in.

-Justin

On Sat, Aug 4, 2012 at 8:44 AM, Andrea Aime wrote:

> Hi,
> I've turned GSIP 77 into a documentation page for GeoServer here:
>
> http://docs.geoserver.org/stable/en/developer/time-boxed-releases/index.html
>
> Can someone have a look and confirm it's looking good?
> Once eventual fixes go in I'll just copy it over to the geotools guide as
> well
> (amending as necessary due to the differences in the two projects)
>
> 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 962313
> mob:   +39  339 8844549
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> ---
>
>
>
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
>


-- 
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Meeting 2012-08-06

[Justin Deoliveira]

Hey guys,

Sorry I couldn't make it today, it is a holiday in Canada and i am not
working a regular working day.

Regarding the security stuff for 2.2.x being a blocker is that referring to
what Christian recently posted? Looks like it, will respond to that thread.

-Justin

On Mon, Aug 6, 2012 at 8:40 AM, Jody Garnett  wrote:

> Participants
> ---
>
> Attending:
> - Andrea Aime (part)
> - Ben Caradoc-Davies
> - Jody Garnett
>
> Agenda
> ==
>
> - Dual-License Request
> - Upcoming Board Meeting
> - GeoServer PSC refresh
> - Security in GeoServer 2.2.x
> - Reshape/Transform module in GeoTools
> - GeoTools 8 Release
>
> Dual-License Request
> 
>
> Apache wondering why OSGeo exists in the first place.
> Author can do whatever it wants with the code... not clear of whether
> re-assign copyright though is allowed
>
> http://docs.codehaus.org/display/GEOTOOLS/Dual+License+Request Proposal
> withdrawn anyway.
>
> Jody made contact with sis-dev to avoid communication troubles, a couple
> of ideas have been floated including a) OSGeo providing a code grant b)
> geotools signing an agreement
>
> Upcoming Board Meeting
> ==
>
> The GeoTools PMC processes and impartialty has been brought into question,
> it would like ensure a member of the GeoTools PMC is present to answer any
> questions on process.
>
> - http://wiki.osgeo.org/wiki/Board_Meeting_2012-08-09
>
> Jody is unable to attend board meetings at that hour, offered to step down
> if needed.
>
> Significant miscommunication going on, slowness to answer (busy with work,
> vacation time) mistaken for a deadlock, try participating to the OSGeo
> board meeting.
>
> Concerns:
> - board is obliged to act in consultation with the project steering
> committee
> - PMC followed formal change request procedure, request has subsequently
> been withdrawn
> - check if a complaint has been made
>
> Action:
> - Andrea may be able to go?
>
> GeoServer PSC Refresh
> ==
>
> Looked into obtaining PSC representation from the active user community.
> Phil Scadden has publically nominated himself.
> One private enquiry.
> Not enough members in this meeting to proceed.
>
> Mark Leslie has stepped down.
>
> ACTION: review list of PSC members and update by removing members who have
> stepped down or been declared inactive.
>
>  Security in GeoServer 2.2.x
> 
> Release blocker for 2.2? Or strongly worded release notes ...
> Default to admin password?
>
>  Reshape/Transform module in GeoTools
> =
>
> Some coordinate with uDig required as this is live code; but sounds great!
> Is collecting support on email list. Anything more to discuss?
>
> GeoTools 8 Release
> ===
> No status update, still in holding pattern.
>
> Reshape stuff
> ===
>
> Good.
>
> Catchup
> ==
>
> - https://github.com/geotools/geotools/pull/1
> - outstanding jira patch
> - review time boxed release cycle
>
> GeoServer Patch Party
> -
> http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+GEOS+AND+status+in+%28Open%2C+%22In+Progress%22%2C+Reopened%29+AND+%22Number+of+attachments+%22+%3E%3D+%221%22+ORDER+BY+cf%5B10163%5D+ASC%2C+key+DESC
>
> 1) GEOS-5148 Support 3D WFS Bounding Box
> - the accessor methods are deprecated, use the literal for the real
> ReferencedEnvelope (3D or 2D)
>
> And GeoTools as well:
>
> http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+GEOT+AND+status+in+%28Open%2C+%22In+Progress%22%2C+Reopened%29+AND+%22Number+of+attachments+%22+%3E%3D+%221%22+ORDER+BY+cf%5B10163%5D+ASC%2C+key+DESC
>
> Concern: other projects are more responsive to users/contributors, this
> might contribute to the impression that we are "deadlocked": find ways to
> be more responsive?
>
> Actions:
> - kill postgis-versioned
>
>
>
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
>


-- 
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_

[Geotools-devel] Meeting 2012-08-06

[Jody Garnett]

Participants
---

Attending:
- Andrea Aime (part)
- Ben Caradoc-Davies
- Jody Garnett

Agenda
==

- Dual-License Request
- Upcoming Board Meeting
- GeoServer PSC refresh
- Security in GeoServer 2.2.x
- Reshape/Transform module in GeoTools
- GeoTools 8 Release

Dual-License Request


Apache wondering why OSGeo exists in the first place.
Author can do whatever it wants with the code... not clear of whether re-assign 
copyright though is allowed

http://docs.codehaus.org/display/GEOTOOLS/Dual+License+Request Proposal 
withdrawn anyway.

Jody made contact with sis-dev to avoid communication troubles, a couple of 
ideas have been floated including a) OSGeo providing a code grant b) geotools 
signing an agreement

Upcoming Board Meeting
==

The GeoTools PMC processes and impartialty has been brought into question, it 
would like ensure a member of the GeoTools PMC is present to answer any 
questions on process.

- http://wiki.osgeo.org/wiki/Board_Meeting_2012-08-09

Jody is unable to attend board meetings at that hour, offered to step down if 
needed.

Significant miscommunication going on, slowness to answer (busy with work, 
vacation time) mistaken for a deadlock, try participating to the OSGeo board 
meeting.

Concerns:
- board is obliged to act in consultation with the project steering committee
- PMC followed formal change request procedure, request has subsequently been 
withdrawn
- check if a complaint has been made

Action:
- Andrea may be able to go?

GeoServer PSC Refresh
==

Looked into obtaining PSC representation from the active user community. 
Phil Scadden has publically nominated himself.
One private enquiry.
Not enough members in this meeting to proceed.

Mark Leslie has stepped down.

ACTION: review list of PSC members and update by removing members who have 
stepped down or been declared inactive.

 Security in GeoServer 2.2.x

Release blocker for 2.2? Or strongly worded release notes ...
Default to admin password?

 Reshape/Transform module in GeoTools
=

Some coordinate with uDig required as this is live code; but sounds great! Is 
collecting support on email list. Anything more to discuss?

GeoTools 8 Release
===
No status update, still in holding pattern. 

Reshape stuff
===

Good.

Catchup
==

- https://github.com/geotools/geotools/pull/1
- outstanding jira patch
- review time boxed release cycle

GeoServer Patch Party
- 
http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+GEOS+AND+status+in+%28Open%2C+%22In+Progress%22%2C+Reopened%29+AND+%22Number+of+attachments+%22+%3E%3D+%221%22+ORDER+BY+cf%5B10163%5D+ASC%2C+key+DESC

1) GEOS-5148 Support 3D WFS Bounding Box
- the accessor methods are deprecated, use the literal for the real 
ReferencedEnvelope (3D or 2D)

And GeoTools as well:
http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+GEOT+AND+status+in+%28Open%2C+%22In+Progress%22%2C+Reopened%29+AND+%22Number+of+attachments+%22+%3E%3D+%221%22+ORDER+BY+cf%5B10163%5D+ASC%2C+key+DESC

Concern: other projects are more responsive to users/contributors, this might 
contribute to the impression that we are "deadlocked": find ways to be more 
responsive?

Actions:
- kill postgis-versioned 



--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] *proposal* (new version): Support for three-dimensional envelopes and bounding box filters

[Niels Charlier]

Update
>
> Patch:
> + Implement 
> ReferencedEnvelope3D.reference(org.opengis.geometry.Envelope) method
> + Implement better Transform method
> + Use CRS.toSRS( bounds.getCoordinateReferenceSystem() ) to return 
> SRS string in filter class
> + Remove filtervisitor hack and update DuplicatingFilterVisitor
> + Support for bbox3d in OGC post filters
> + change dimension/srs checking in ReferencedEnvelope from = to <
>
> Proposal Text:
> + Add Implications for Filter Visitors (and docs)
>
>
> Does that cover it?
>

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] *proposal* (new version): Support for three-dimensional envelopes and bounding box filters

[Niels Charlier]

On 08/06/2012 01:56 PM, Niels Charlier wrote:
>> * for the trasform method imho a better, but simple implementation
>> would be to reproject the x,y and leave the Z
>> unaltered (but preserve it). This is what JTS.tarnsform(Geometry,
>> MathTransform) does today, so it would also preserve
>> consistency within the library
> Actually, the current implementation already does exactly this.
>
> Because transform works by calling expandToInclude on 2 coordinates, the
> 2d boundaries are expanded but the 3d boundaries are simply left untouched.
>
> Is that what you meant?
>
> Kind Regards
> Niels

Sorry, I did still have to add the preservation of the 3d coordinate 
because it starts from an empty target before it call expand. So I just 
have to add one line that smuggles the third coordinate back in.

Regards
Niels

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] *proposal* (new version): Support for three-dimensional envelopes and bounding box filters

[Niels Charlier]

>
> * for the trasform method imho a better, but simple implementation 
> would be to reproject the x,y and leave the Z
>unaltered (but preserve it). This is what JTS.tarnsform(Geometry, 
> MathTransform) does today, so it would also preserve
>consistency within the library

Actually, the current implementation already does exactly this.

Because transform works by calling expandToInclude on 2 coordinates, the 
2d boundaries are expanded but the 3d boundaries are simply left untouched.

Is that what you meant?

Kind Regards
Niels

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] *proposal* (new version): Support for three-dimensional envelopes and bounding box filters

[Niels Charlier]

On 08/06/2012 12:23 PM, Niels Charlier wrote:
>> Afaik this works the way I explained before, that is, the Z dimension is left
>> unaltered during the reprojection.
>> Which is not true reprojection, but what we can afford given that the 
>> vertical
>> transformation module is not working
>>
> I reprojected from WGS84 to WGS66 which only differ in their Z
> dimension, and the values are being altered.
> I am currently in the process of doing the calculations to see if it is
> indeed mathematically correct, but it is definitely altered.
>

And I can confirm that the 3d reprojection is indeed 100% mathematically 
accurate.

Regards
Niels

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] *proposal* (new version): Support for three-dimensional envelopes and bounding box filters

[Niels Charlier]

> Afaik this works the way I explained before, that is, the Z dimension is left
> unaltered during the reprojection.
> Which is not true reprojection, but what we can afford given that the vertical
> transformation module is not working
>

I reprojected from WGS84 to WGS66 which only differ in their Z 
dimension, and the values are being altered.
I am currently in the process of doing the calculations to see if it is 
indeed mathematically correct, but it is definitely altered.

Regards
Niels Charlier

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] *proposal* (new version): Support for three-dimensional envelopes and bounding box filters

[Andrea Aime]

On Mon, Aug 6, 2012 at 10:45 AM, Niels Charlier  wrote:
> The current patch and proposal does not include these features. However, I'd
> understand that WFS post requests need to at least support the same features
> as wfs get requests. Please let me know the minimum requirements with
> regards to this to get the patch approved.

The GeoTools part is not affected, but in order to commit the GeoServer part you
will need to make sure POST requests are supported as well.
Only some time ago Justin complained that some WFS functionalities have been
added on GET requests only and that moving forward we should try to implement
everything on both sides.

> Yes, you have a point here, this is a weak part. I stole the code from your
> fastbbox, but it is indeed an ugly hack. I would be happy to change the
> filter visitors instead, but I was trying to minimise changes to the core.
> I am sorry I didn't point this out in the proposal, I will do something
> about it.

The hack makes sense in the FastBBOX case because it's just a faster alias to
the BBOX filter, it's not a new type of filter, yours is a brand new
one that implementors
should be aware of.


> The method checkCoordinateReferenceSystemDimension is identical to the one
> in its superclass, ReferencedEnvelope. (In fact, I should remove this
> copy-pasted method and instead make it protected instead of private in its
> superclass, this is left-over from changing the class structure).
> So the existing implementation already checks the srs's dimensionality
> against this. This means that is now forbidden to apply a 2D bbox against a
> 3D SRS. It only seemed logical for me to extend the same logic to situation
> the other way around.
> I would personally recommend to use a 3D SRS if you have 3D geometries, even
> in postgis, this seems to me like the best way to work. If this is not
> desired behaviour, I think it is not just my changes, but the existing code
> of the ReferencedEnvelope class that must be reviewed.
> Perhaps I could change the check to test if the dimension of SRS < than the
> dimension of the bbox? Does that make any sense at all?

Hmm... I don't have a good answer to this one off the top of my head.
While I agree that in theory one should just use a 3d system, the
practice is difference
and here we are not doing research, but industrial systems that must work
in the real world.
Whatever path is chosen imho it should allow to write 3d filters
against a PostGIS
store that has a 2d crs but has 3 dimensions in the geometry columns table.

SRS < than the dimensions of the bbox seems a bit hacky but indeed it might well
be the only solution.

>
>> I find it suprising that 3D reprojection works indeed. Afaik to do it one
>> needs proper support
>> for vertical CRSs, which is contained in referencing3D. I though that
>> module was not complete,
>> have you looked into it and found otherwise?
>
>
> As far as I know that module isn't functional.
> I admit I am not 100% knowledgeable about everything in this field, I have
> only been learning this SRS stuff the past few months, so there is still a
> lot I don't know.
> I am only needing to reproject point and linestring geometries with 3d
> coordinates. Perhaps that explains it.

Afaik this works the way I explained before, that is, the Z dimension is left
unaltered during the reprojection.
Which is not true reprojection, but what we can afford given that the vertical
transformation module is not working

Cheres
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 962313
mob:   +39  339 8844549

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

---

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] *proposal* (new version): Support for three-dimensional envelopes and bounding box filters

[Niels Charlier]

Andrea,

I am trying to make an overview of all the changes that require me to do 
to the patch and proposal to get them passed.

This is what I have so far:

Patch:
Implement 
ReferencedEnvelope3D.reference(org.opengis.geometry.Envelope) method

Implement better Transform method
Use CRS.toSRS( bounds.getCoordinateReferenceSystem() ) to return 
SRS string in filter class

? Support for bbox3d in OGC post filters
? change dimension/srs checking in ReferencedEnvelope

Proposal Text:
Add Implications for Filter Visitors (and docs)

Does that cover it?

Cheers
Niels



On 08/06/2012 10:45 AM, Niels Charlier wrote:

Hi,


I'm not saying that you have to do everything at once, can you answer
the simple question above though?
Restating it: "How sure you are that you're going to implement proper
encoding of 3D bboxes at the very least for JDBC stores (and possibly
for shapefiles as well?)"

I am sorry, I cannot give you a guarantee about that at this moment.


I have looked at the patch and I don't see where in the code you are
handling the parsing of a BBOX filter
coming from a OGC filter in a POST request, or a BBOX coming from a
CQL filter.
If you are not planning to support them please state so, if you are
planning to do please clarify how
and when

The current patch and proposal does not include these features. However,
I'd understand that WFS post requests need to at least support the same
features as wfs get requests. Please let me know the minimum
requirements with regards to this to get the patch approved.


The proposal is effectively adding a new type of filter, normally that
would require a change
in the filter visitor API to handle such new filter explicitly,
however this case is peculiar
in that the new filter extends an existing one.

This means the API might not be in need of change, but it has
consequences on the API.
In particular, all filter visitors dedicated to the manipulation of
filters (including the
simplifiying filter visitor) will create a copy that's a plain 2D
BBOX, and the CQL encoder
will encode the bbox as a 2D one.

I see there is in the code:
...

I'm sure this works with most/all of the existing code, but is this
the right way to go?
Given that most filters manipulating filters are extending from the
duplicating filter visitor,
wouldn't it be better to fix that one instead?
Also, I believe the ReprojectingFilterVisitor won't work properly with
the above hack,
and that it might need some logic changes (a way consistent with
geometry reprojection
would be to reproject the 2d component of the bbox and leave the 3d
part move
unaltered to the result)

Also, given this is an API change there should be some documentation on a
"upgrade to 9.x" page telling people to expect this new kind of filter
in their custom
visitors, and probably some changes on the FilterVisitor javadocs are
in order as well.

This is one problematic area of the proposal, it would have been
better to point
it out in the proposal document instead of having people have to
review the code
in order to see it: a good proposal is also showing what is _not_
covered/done and
what the potentially problematic areas are (and how the problems have
been addressed).

Yes, you have a point here, this is a weak part. I stole the code from
your fastbbox, but it is indeed an ugly hack. I would be happy to change
the filter visitors instead, but I was trying to minimise changes to the
core.
I am sorry I didn't point this out in the proposal, I will do something
about it.


This went a bit off the tangent, but here is the part that affects the
filtering code.
Say I have a layer in postgis that is declared as EPSG:4326 with
dimension=3
(perfectly legit in postgis), how am I going to filter it using BBOX3D?
It seems whatever I do I might be in some issue from some point of view:
* if I state the crs is EPSG:4326 then the dimensionality check in
ReferencedEnvelope3D.checkCoordinateReferenceSystemDimension()
   will make it impossible to build the filter
* as a user I could know that I have to use EPSG:4327 instead, but this
   will make the CRS inconsistent with the one on the DBMS.. besides that,
   I don't see an immediate way for automated code to build the "3d
equivalent"
   of a 2d system, and the layer will be declared in the feature type
as having
   EPSG:4326 (since that's what we reflect out of the database)

The method checkCoordinateReferenceSystemDimension is identical to the
one in its superclass, ReferencedEnvelope. (In fact, I should remove
this copy-pasted method and instead make it protected instead of private
in its superclass, this is left-over from changing the class structure).
So the existing implementation already checks the srs's dimensionality
against this. This means that is now forbidden to apply a 2D bbox
against a 3D SRS. It only seemed logical for me to extend the same logic
to situation the other way around.
I would personally recommend to use a 3D SRS if you have 3D geometries,
eve

Re: [Geotools-devel] *proposal* (new version): Support for three-dimensional envelopes and bounding box filters

[Niels Charlier]

Hi,

> I'm not saying that you have to do everything at once, can you answer 
> the simple question above though?
> Restating it: "How sure you are that you're going to implement proper 
> encoding of 3D bboxes at the very least for JDBC stores (and possibly 
> for shapefiles as well?)"

I am sorry, I cannot give you a guarantee about that at this moment.

> I have looked at the patch and I don't see where in the code you are 
> handling the parsing of a BBOX filter
> coming from a OGC filter in a POST request, or a BBOX coming from a 
> CQL filter.
> If you are not planning to support them please state so, if you are 
> planning to do please clarify how
> and when

The current patch and proposal does not include these features. However, 
I'd understand that WFS post requests need to at least support the same 
features as wfs get requests. Please let me know the minimum 
requirements with regards to this to get the patch approved.

> The proposal is effectively adding a new type of filter, normally that 
> would require a change
> in the filter visitor API to handle such new filter explicitly, 
> however this case is peculiar
> in that the new filter extends an existing one.
>
> This means the API might not be in need of change, but it has 
> consequences on the API.
> In particular, all filter visitors dedicated to the manipulation of 
> filters (including the
> simplifiying filter visitor) will create a copy that's a plain 2D 
> BBOX, and the CQL encoder
> will encode the bbox as a 2D one.
>
> I see there is in the code:
> ...
>
> I'm sure this works with most/all of the existing code, but is this 
> the right way to go?
> Given that most filters manipulating filters are extending from the 
> duplicating filter visitor,
> wouldn't it be better to fix that one instead?
> Also, I believe the ReprojectingFilterVisitor won't work properly with 
> the above hack,
> and that it might need some logic changes (a way consistent with 
> geometry reprojection
> would be to reproject the 2d component of the bbox and leave the 3d 
> part move
> unaltered to the result)
>
> Also, given this is an API change there should be some documentation on a
> "upgrade to 9.x" page telling people to expect this new kind of filter 
> in their custom
> visitors, and probably some changes on the FilterVisitor javadocs are 
> in order as well.
>
> This is one problematic area of the proposal, it would have been 
> better to point
> it out in the proposal document instead of having people have to 
> review the code
> in order to see it: a good proposal is also showing what is _not_ 
> covered/done and
> what the potentially problematic areas are (and how the problems have 
> been addressed).

Yes, you have a point here, this is a weak part. I stole the code from 
your fastbbox, but it is indeed an ugly hack. I would be happy to change 
the filter visitors instead, but I was trying to minimise changes to the 
core.
I am sorry I didn't point this out in the proposal, I will do something 
about it.

> This went a bit off the tangent, but here is the part that affects the 
> filtering code.
> Say I have a layer in postgis that is declared as EPSG:4326 with 
> dimension=3
> (perfectly legit in postgis), how am I going to filter it using BBOX3D?
> It seems whatever I do I might be in some issue from some point of view:
> * if I state the crs is EPSG:4326 then the dimensionality check in
> ReferencedEnvelope3D.checkCoordinateReferenceSystemDimension()
>   will make it impossible to build the filter
> * as a user I could know that I have to use EPSG:4327 instead, but this
>   will make the CRS inconsistent with the one on the DBMS.. besides that,
>   I don't see an immediate way for automated code to build the "3d 
> equivalent"
>   of a 2d system, and the layer will be declared in the feature type 
> as having
>   EPSG:4326 (since that's what we reflect out of the database)

The method checkCoordinateReferenceSystemDimension is identical to the 
one in its superclass, ReferencedEnvelope. (In fact, I should remove 
this copy-pasted method and instead make it protected instead of private 
in its superclass, this is left-over from changing the class structure).
So the existing implementation already checks the srs's dimensionality 
against this. This means that is now forbidden to apply a 2D bbox 
against a 3D SRS. It only seemed logical for me to extend the same logic 
to situation the other way around.
I would personally recommend to use a 3D SRS if you have 3D geometries, 
even in postgis, this seems to me like the best way to work. If this is 
not desired behaviour, I think it is not just my changes, but the 
existing code of the ReferencedEnvelope class that must be reviewed.
Perhaps I could change the check to test if the dimension of SRS < than 
the dimension of the bbox? Does that make any sense at all?

> I find it suprising that 3D reprojection works indeed. Afaik to do it 
> one needs proper support
> for vertical CRSs, which is cont

Re: [Geotools-devel] New community module: reshape feature source/store

[Andrea Aime]

On Mon, Aug 6, 2012 at 10:17 AM,   wrote:
> Looks good, +1 for the module.
>
> I see another possible future use case, access control for individual
> attributes. It should be possible to define such a feature hiding some
> attributes and use this feature for access control.
>
> Another possibility could be adding converters returning null if a user has
> no access privilege for an attribute.

Btw, this functionality is already available in the GeoServer security
subsystem,
but to drive it today you have to use either GeoFence (previously known as
GeoRepository) or GeoShield

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 962313
mob:   +39  339 8844549

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

---

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] New community module: reshape feature source/store

[christian . mueller]

Looks good, +1 for the module.

I see another possible future use case, access control for individual  
attributes. It should be possible to define such a feature hiding some  
attributes and use this feature for access control.

Another possibility could be adding converters returning null if a  
user has no access privilege for an attribute.

Christian


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



--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] New community module: reshape feature source/store

[Andrea Aime]

On Mon, Aug 6, 2012 at 5:53 AM, Gabriel Roldan  wrote:
> Hi Andrea,
>
> I think this makes for a very welcomed contribution.
>
> Of particular interest to me is the ability to "reshape" shapefiles.
> It's actually something that's been rounding my mind for the last week
> anticipating its need for another project. What do you think about the
> idea of having a (yet another) shapefile sidecar file that somehow
> defines the schema of the shapefile? The use case is exporting a
> feature type to shapefile without loosing type accuracy and/or
> attribute names.

I see. Well, sure, why not, I guess we can add this ability inside the
ShapefileDataStoreFactory, if the sidecar file is there it would first
build the plain shapefile and then wrap it.

Hm... actually there is a bit of a show stopper though.
The wrapper is meant for featuresource/featurestore, it actually builds
a data store too but right now it does not have the full capabilities
that a store should have, in particular the readers and writers method
cannot be implemented against the feature source abilities because
they take a Transaction per method, while the feature source/store
have a transaction as a field.

Now that I think about it though, it's just a matter of grabbing the DataStore
off the FeatureSource and fall back on those methods.

Long story short, to get where you want I guess the following is needed:
- fix the reshape store so that the missing methods are filled in
- push the module into supported land, so that shapefile can depend on it
- devise a file format that can hold the transforming definitions, use
it as a sidecar
  for the shapefile

Next weekend I'll merge the store into the official GeoTools repo

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 962313
mob:   +39  339 8844549

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

---

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [jira] (GEOT-4221) Add quotes to Djava.library.path in root-level pom.

[Adam Brown (JIRA)]

Adam Brown
 created  GEOT-4221


Add quotes to Djava.library.path in root-level pom.















Issue Type:


Bug



Assignee:


Andrea Aime



Attachments:


maven_output.txt



Created:


06/Aug/12 2:51 AM



Description:


argLine for maven-surefire-plugin doesn't include quotes around the value for Djava.library.path. It needs to be changed to:

"-Djava.library.path=${java.library.path}"

as it currently won't work in Windows environments that have spaces in the path.




Environment:


Windows




Project:


GeoTools



Priority:


Critical



Reporter:


Adam Brown




























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





--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] New community module: reshape feature source/store

[Andrea Aime]

On Mon, Aug 6, 2012 at 5:15 AM, Jody Garnett  wrote:
> If I can recommend calling it "transform" as the name "reshape" has caused
> no end of confusion. Indeed you will find the current process called
> "transform".

Cool, will do that

> +1 on the new module however!
>
> I am very impressed with the read and write support, nicely done.

Thanks

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 962313
mob:   +39  339 8844549

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

---

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel