Re: [Geotools-devel] app-schema numberMatched regression

[Niels Charlier via GeoTools-Devel]

Hello Marco,

Thanks for clearing this up. I have made a PR 
https://github.com/geotools/geotools/pull/4016


Cheers

Niels

On 13/09/2022 08:10, Marco Volpini wrote:

Dear Niels,
thanks for your point. I think that the block can indeed be removed. I 
don't remember why I've added that but I did some tests and saw that 
actually the if statement will evaluate always to false on a property 
name since the namespace support  is null in the 
AttributeExpressionImpl object at that point. Moreover the 
JoiningJdbcFeatureSource does checks on its own to determine if the 
filter is over nested attributes or not.


Regards,

Marco Volpini

==GeoServer Professional Services from the experts!

Visit http://bit.ly/gs-services-us <http://bit.ly/gs-services-us>for 
more information.==Marco Volpini


Software EngineerGeoSolutions Groupphone: +39 0584 962313

fax:     +39 0584 1660272


https://www.geosolutionsgroup.com/ <https://www.geosolutionsgroup.com/>

http://twitter.com/geosolutions_it <http://twitter.com/geosolutions_it>

---


Con riferimento alla normativa sul trattamento dei dati personali 
(Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati 
“GDPR”), si precisa che ogni circostanza inerente alla presente email 
(il suo contenuto, gli eventuali allegati, etc.) è un dato la cui 
conoscenza è riservata al/i solo/i destinatario/i indicati dallo 
scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a 
cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato 
se potesse darmene notizia.This email is intended only for the person 
or entity to which it is addressed and may contain information that is 
privileged, confidential or otherwise protected from disclosure. We 
remind that - as provided by European Regulation 2016/679 “GDPR” - 
copying, dissemination or use of this e-mail or the information herein 
by anyone other than the intended recipient is prohibited. If you have 
received this email by mistake, please notify us immediately by 
telephone or e-mail.





width= 
<http://www.avg.com/email-signature?utm_medium=email_source=link_campaign=sig-email_content=webmail> 
	Privo di virus.www.avg.com 
<http://www.avg.com/email-signature?utm_medium=email_source=link_campaign=sig-email_content=webmail> 




On Mon, Sep 12, 2022 at 10:19 AM Niels Charlier  wrote:

Hello everyone,

I found a bug in app-schema that was recently introduced by
https://osgeo-org.atlassian.net/browse/GEOT-7214, a patch by Marco
Volpini, but I am a bit confused about the changes and would like to
know to what extent they are intentional. Bug logged at:
https://osgeo-org.atlassian.net/browse/GEOT-7214

The problem is situated here:

https://github.com/geotools/geotools/blob/main/modules/extension/app-schema/app-schema/src/main/java/org/geotools/data/complex/AppSchemaDataAccess.java#L311

It seems that the true block of the if statement does not unroll the
filter. But I am not sure if that could ever make sense or if this
was
somehow intentional. The changes are only tested by an online
integration test on the geoserver side
(GetFeatureNumberMatchedGMLTest).
The only test method that actually goes inside the true block of
the if
statement is a test without a filter, so this is actually not
being tested.

The problem occurs with an id filter rather than a property name
filter.
In this case the check does return true and since the filter is not
unrolled it cannot work. What should actually happen here?
Shouldn't I
simply remove this if-statement and always unroll the filter?

Kind Regards

Niels
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] app-schema numberMatched regression

[Niels Charlier via GeoTools-Devel]

Hello everyone,

I found a bug in app-schema that was recently introduced by 
https://osgeo-org.atlassian.net/browse/GEOT-7214, a patch by Marco 
Volpini, but I am a bit confused about the changes and would like to 
know to what extent they are intentional. Bug logged at: 
https://osgeo-org.atlassian.net/browse/GEOT-7214


The problem is situated here: 
https://github.com/geotools/geotools/blob/main/modules/extension/app-schema/app-schema/src/main/java/org/geotools/data/complex/AppSchemaDataAccess.java#L311


It seems that the true block of the if statement does not unroll the 
filter. But I am not sure if that could ever make sense or if this was 
somehow intentional. The changes are only tested by an online 
integration test on the geoserver side (GetFeatureNumberMatchedGMLTest). 
The only test method that actually goes inside the true block of the if 
statement is a test without a filter, so this is actually not being tested.


The problem occurs with an id filter rather than a property name filter. 
In this case the check does return true and since the filter is not 
unrolled it cannot work. What should actually happen here? Shouldn't I 
simply remove this if-statement and always unroll the filter?


Kind Regards

Niels



___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Ignored netcdf test - intended?

[Niels Charlier via GeoTools-Devel]

I am aware, I git blamed it too. But I just cannot recall or see any 
reason why I did this. Ben seems to have missed it too, he even made a 
comment "this is pretty thorough unit test coverage"... My guess would 
be that it is a mistake. Thanks to Brad for finding it.


Kind Regards

Niels

On 04/04/2022 10:43, Andrea Aime wrote:

Hi Niels,
Brad is correctly asking you, since you added that test, and you also 
ignored it, a few months later, in these two commits:


image.png

Daniele would be the maintainer, but he was away in honeymoon and 
could not review the PR that ignored the test,

which was reviewed by Ben instead, see here:

https://github.com/geotools/geotools/pull/1531

That said... the test is passing so I guess we could just keep it, and 
yes, use commons-compress to unpack the tar.gz,

or maybe even better, just change sampledata.tar.gz to smapledata.zip...

Cheers
Andrea


On Sat, Apr 2, 2022 at 2:42 PM Niels Charlier via GeoTools-Devel 
 wrote:


Hello Brad,

I do not recall why the test was ignored. It actually seems to
work when
I try so I wouldn't personally remove it.

I have to say I don't remember much about this module any more,
and I do
not use it. Since it is a plugin I suppose someone is maintaining it?

Kind Regards

Niels

On 02/04/2022 05:29, Brad Hards wrote:
>

https://github.com/geotools/geotools/blob/main/modules/plugin/coverage-multidim/netcdf/src/test/java/org/geotools/coverage/io/netcdf/
> NetCDFMultiDimTest.java#L67 is turning off testing (since 2017).
>
> Should the test be removed, or is something required?
>
> This came up because it looks like this is the only use of the
plexus-
> archiver, which is a bit old. If it goes, we can remove that
test dep, or if
> its still needed we can switch to something less involved, like
commons-
> compress.
>
> Brad
>
>
>


___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel



--

Regards,

Andrea Aime

==GeoServer Professional Services from the experts!

Visit http://bit.ly/gs-services-us <http://bit.ly/gs-services-us>for 
more information.==Ing. Andrea Aime @geowolfTechnical Lead


GeoSolutions Groupphone: +39 0584 962313

fax:     +39 0584 1660272

mob:   +39  333 8128928


https://www.geosolutionsgroup.com/ <https://www.geosolutionsgroup.com/>

http://twitter.com/geosolutions_it <http://twitter.com/geosolutions_it>

---


Con riferimento alla normativa sul trattamento dei dati personali 
(Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati 
“GDPR”), si precisa che ogni circostanza inerente alla presente email 
(il suo contenuto, gli eventuali allegati, etc.) è un dato la cui 
conoscenza è riservata al/i solo/i destinatario/i indicati dallo 
scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a 
cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato 
se potesse darmene notizia.This email is intended only for the person 
or entity to which it is addressed and may contain information that is 
privileged, confidential or otherwise protected from disclosure. We 
remind that - as provided by European Regulation 2016/679 “GDPR” - 
copying, dissemination or use of this e-mail or the information herein 
by anyone other than the intended recipient is prohibited. If you have 
received this email by mistake, please notify us immediately by 
telephone or e-mail___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Ignored netcdf test - intended?

[Niels Charlier via GeoTools-Devel]

Hello Brad,

I do not recall why the test was ignored. It actually seems to work when 
I try so I wouldn't personally remove it.


I have to say I don't remember much about this module any more, and I do 
not use it. Since it is a plugin I suppose someone is maintaining it?


Kind Regards

Niels

On 02/04/2022 05:29, Brad Hards wrote:

https://github.com/geotools/geotools/blob/main/modules/plugin/coverage-multidim/netcdf/src/test/java/org/geotools/coverage/io/netcdf/
NetCDFMultiDimTest.java#L67 is turning off testing (since 2017).

Should the test be removed, or is something required?

This came up because it looks like this is the only use of the plexus-
archiver, which is a bit old. If it goes, we can remove that test dep, or if
its still needed we can switch to something less involved, like commons-
compress.

Brad






___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] [Geoserver-devel] reprojections and multiple geometries

[Niels Charlier via GeoTools-Devel]

Hello everyone,

Thanks for your comments. I suggest then that I implement the behaviour 
as it was suggested in the example of WFS 2.0 specs, since this is also 
the least invasive for the geotools/geoserver code, and there don't 
appear to be any particular objections against it. I suggest also 
however, that I add a boolean parameter to the method in the CRS utility 
class "allowDifferentDimension" so that the method is generic enough for 
other purposes and its behaviour with regards to dimensional differences 
is clear.


Is this a solution that makes sense ?

Kind Regards

Niels

On 1/10/2021 09:43, Andrea Aime wrote:
On Mon, Oct 11, 2021 at 7:05 PM Niels Charlier <mailto:ni...@scitus.be>> wrote:


Hello Andrea,

I did not mean to misrepresent you. I actually thought your
suggestion made sense. The new method in the CRS class is
(currently) only intended for reprojection.


The CRS class is a generic facade to the capabilities of the 
referencing subsystem, exposing some of its functionality in a simpler 
way.
Its javadoc states "Simple utility class for making use of the 
{@linkplain CoordinateReferenceSystem coordinate
 reference system} and associated {@linkplain 
org.opengis.referencing.Factory} implementations."


While most of the methods deal with reprojection, some have nothing to 
do with it, like "lookupIdentifier". The class is definitely
not meant to be restricted to reprojection alone, nor has a specific 
focus on WFS related activities.
As said before, it should represent the true capabilities of the 
referencing subsystem, modules that need specific restrictions

should have their

As far as the standard goes, I was referring to the ""OGC® Web
Feature Service 2.0 Interface Standard – With Corrigendum"

sections: 7.9.2.4.4 srsName parameter
(https://docs.opengeospatial.org/is/09-025r2/09-025r2.html#95
<https://docs.opengeospatial.org/is/09-025r2/09-025r2.html#95>)
and 7.9.2.4.4.2 compatibly coordinate systems

And in particular this example:
"EXAMPLE: A feature with both 2D and 3D geometry properties is
requested with srsName set to a 2D CRS; the 2D property is encoded
in the requested CRS, and the 3D property is encoded with some 3D
CRS identified in the srsName of the geometry."

Oh, quite interesting!
In the meantime, I've got this two bits of response:

- Regarding OGC API - Features: "if the server implements Part 2 and a 
CRS is specified then all geometries in the response must be 
reprojected to the requested CRS in the response."
- Regarding WFS: " WFS is a little more flexible since you can have 
multiple queries in one request each in a different CRS"


I've added the quote above in my chat with the OGC people, let's see 
if it stirs up more feedback.
If you want to participate directly, get on gitter and get in this 
chat: https://gitter.im/opengeospatial/WFS_FES 
<https://gitter.im/opengeospatial/WFS_FES>


Cheers
Andrea
==

GeoServer Professional Services from the experts!

Visit http://bit.ly/gs-services-us <http://bit.ly/gs-services-us>for 
more information.==Ing. Andrea Aime @geowolfTechnical Lead


GeoSolutions Groupphone: +39 0584 962313

fax:     +39 0584 1660272

mob:   +39  333 8128928


https://www.geosolutionsgroup.com/ <https://www.geosolutionsgroup.com/>

http://twitter.com/geosolutions_it <http://twitter.com/geosolutions_it>

---


Con riferimento alla normativa sul trattamento dei dati personali 
(Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati 
“GDPR”), si precisa che ogni circostanza inerente alla presente email 
(il suo contenuto, gli eventuali allegati, etc.) è un dato la cui 
conoscenza è riservata al/i solo/i destinatario/i indicati dallo 
scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a 
cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato 
se potesse darmene notizia.This email is intended only for the person 
or entity to which it is addressed and may contain information that is 
privileged, confidential or otherwise protected from disclosure. We 
remind that - as provided by European Regulation 2016/679 “GDPR” - 
copying, dissemination or use of this e-mail or the information herein 
by anyone other than the intended recipient is prohibited. If you have 
received this email by mistake, please notify us immediately by 
telephone or e-mail
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] [Geoserver-devel] reprojections and multiple geometries

[Niels Charlier via GeoTools-Devel]

Hello Andrea,

I did not mean to misrepresent you. I actually thought your suggestion 
made sense. The new method in the CRS class is (currently) only intended 
for reprojection.


As far as the standard goes, I was referring to the ""OGC® Web Feature 
Service 2.0 Interface Standard – With Corrigendum"


sections: 7.9.2.4.4 srsName parameter 
(https://docs.opengeospatial.org/is/09-025r2/09-025r2.html#95 
<https://docs.opengeospatial.org/is/09-025r2/09-025r2.html#95>)

and 7.9.2.4.4.2 compatibly coordinate systems

And in particular this example:
"EXAMPLE: A feature with both 2D and 3D geometry properties is requested 
with srsName set to a 2D CRS; the 2D property is encoded in the 
requested CRS, and the 3D property is encoded with some 3D CRS 
identified in the srsName of the geometry."


Kind Regards

Niels

On 11/10/2021 17:41, Andrea Aime wrote:
On Mon, Oct 11, 2021 at 3:21 PM Niels Charlier via GeoTools-Devel 
<mailto:geotools-devel@lists.sourceforge.net>> wrote:


2) allow reprojection 3D->2D and only prevent 2D->3D reprojection
(Andrea's suggestion). 



Before this gets out of hand, my suggestion is limited to the CRS 
class 
<https://github.com/geotools/geotools/pull/3642#discussion_r721165134>.
The class is not WFS specific, and should be representing the 
abilities of GeoTools
coordinate reference subsystem truthfully, rather than being bent to 
the needs

of a specific WFS use case.

The WFS related issue starts appearing at upper levels... but far 
sooner than WFS itself,
because the GeoTools Query API is inspired by the WFS API (has only 
one target CRS)
and the basic reprojection utility classes are geared towards the same 
model, e.g.,

ReprojectFeatureReader.

That said, I don't believe the standard has suggestions as to what to 
do regarding
reprojection of multiple geometry fields but I'm asking the OGC 
experts about it.

Will report back here when I have an answer.

I might have missed some bits of the discussion, sorry, trying to do 
too many things today...
but I felt I was being mis-represented and had to put a stop to it 
sooner rather than later.


Cheers
Andrea

==

GeoServer Professional Services from the experts!

Visit http://bit.ly/gs-services-us <http://bit.ly/gs-services-us>for 
more information.==Ing. Andrea Aime @geowolfTechnical Lead


GeoSolutions Groupphone: +39 0584 962313

fax:     +39 0584 1660272

mob:   +39  333 8128928


https://www.geosolutionsgroup.com/ <https://www.geosolutionsgroup.com/>

http://twitter.com/geosolutions_it <http://twitter.com/geosolutions_it>

---


Con riferimento alla normativa sul trattamento dei dati personali 
(Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati 
“GDPR”), si precisa che ogni circostanza inerente alla presente email 
(il suo contenuto, gli eventuali allegati, etc.) è un dato la cui 
conoscenza è riservata al/i solo/i destinatario/i indicati dallo 
scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a 
cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato 
se potesse darmene notizia.This email is intended only for the person 
or entity to which it is addressed and may contain information that is 
privileged, confidential or otherwise protected from disclosure. We 
remind that - as provided by European Regulation 2016/679 “GDPR” - 
copying, dissemination or use of this e-mail or the information herein 
by anyone other than the intended recipient is prohibited. If you have 
received this email by mistake, please notify us immediately by 
telephone or e-mail
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] [Geoserver-devel] reprojections and multiple geometries

[Niels Charlier via GeoTools-Devel]

Hello Jukka,

Thanks for your answer. I guess I wanted to ask the opinion of the 
community on how to proceed. I see at this point two options:


1) stick with the suggestion of the standard, and do not project 3D->2D. 
(The easiest solution, what I already have).


2) allow reprojection 3D->2D and only prevent 2D->3D reprojection 
(Andrea's suggestion). This will require quite a lot of further core 
changes:
- modification of Query in geotools to allow reprojection per geometry 
(with backwards compatibility for the current existing fields).
- modification of GetFeature implementation in geoserver so that without 
srsName specified, the 'right' geometries are being reprojected to the 
right CRS.


Kind Regards

Niels

On 09/10/2021 15:00, Rahkonen Jukka (MML) wrote:

Hi,

If I understand right your message and the standard, WFS 2.0 does not have any 
support for reprojecting both 2D and 3D geometries with a single request 
because srsName can appear only once in GetFeature.  So if srsName is some 2D 
crs then 3D geometry is not projected and if srsName is some 3D crs then the 2D 
geometry is not projected. That feels suboptimal.

I agree that transforming 3D CRS into 2D when there is no srsName in GetFeature 
request is clearly unwanted behaviour. Otherwise I think that WFS 2.0 does not 
feel ready for handling reprojection of multiple geometries in different native 
CRS. The solution could to make it possible in WFS to give a separate srsName 
for each geometry. It seems that the problem will be the same with OGC API 
Features. The core says that features may have several geometries but the crs 
extension supports only one crs in the items request.

It may be impossible to do this with so that it is both right according to the 
standards and reasonable for the users but I wish you a good luck.

-Jukka Rahkonen-


-Alkuperäinen viesti-
Lähettäjä: Niels Charlier via Geoserver-devel 

Lähetetty: lauantai 9. lokakuuta 2021 15.05
Vastaanottaja: Geotools-Devel list ; 
Geoserver-devel 
Aihe: [Geoserver-devel] reprojections and multiple geometries
D-
Hello Everyone,

I am sending this email to both geotools and geoserver lists because the matter 
concerns both.

I recently made a PR to improve geotools/geoserver behaviour with respect to 
multiple geometries that have different CRS.
(https://github.com/geotools/geotools/pull/3642) One of the matters that is 
being discussed between Andrea and me is the expected behaviour on reprojection.

I attempted to follow the instructions and examples given for the "srsName" 
parameter specified by the OCR WFS2.0 specs
(https://docs.opengeospatial.org/is/09-025r2/09-025r2.html#95
<https://docs.opengeospatial.org/is/09-025r2/09-025r2.html#95>) These seem to 
suggest that geometries that have a 'incompatible' CRS are simply not reprojected, 
without failure. The only example given for 'incompatibility' is having a different 
dimension. Andrea noted that transformation only fails in the direction 2D->3D while 
it works the other way around, so that it should still be reprojected in that case.
However, the example given in the specs suggests explicitely that a 3D geometry 
would not be converted to a 2D srsName. This seems to be what is expected in my 
use case as well.

The problem is complicated further by the fact that in geoserver, the 
implementation of GetFeature sometimes explicitly specifies a reprojection CRS 
in the query, even if there was no srsName in the http request (the reason has 
something to do with how different wfs versions handle crs encoding and axis 
order. ) What would happen then is that even when no srsName is specified, the 
3D CRS is always being transformed to 2D, which is clearly unwanted behaviour.

Inspire schemas often require feature types with a (primary) 2D geometry and a 
(secondary) 3D geometry.

Kind Regards

Niels



___
Geoserver-devel mailing list
geoserver-de...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel



___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] reprojections and multiple geometries

[Niels Charlier via GeoTools-Devel]

Hello Everyone,

I am sending this email to both geotools and geoserver lists because the 
matter concerns both.


I recently made a PR to improve geotools/geoserver behaviour with 
respect to multiple geometries that have different CRS. 
(https://github.com/geotools/geotools/pull/3642) One of the matters that 
is being discussed between Andrea and me is the expected behaviour on 
reprojection.


I attempted to follow the instructions and examples given for the 
"srsName" parameter specified by the OCR WFS2.0 specs 
(https://docs.opengeospatial.org/is/09-025r2/09-025r2.html#95 
) These 
seem to suggest that geometries that have a 'incompatible' CRS are 
simply not reprojected, without failure. The only example given for 
'incompatibility' is having a different dimension. Andrea noted that 
transformation only fails in the direction 2D->3D while it works the 
other way around, so that it should still be reprojected in that case. 
However, the example given in the specs suggests explicitely that a 3D 
geometry would not be converted to a 2D srsName. This seems to be what 
is expected in my use case as well.


The problem is complicated further by the fact that in geoserver, the 
implementation of GetFeature sometimes explicitly specifies a 
reprojection CRS in the query, even if there was no srsName in the http 
request (the reason has something to do with how different wfs versions 
handle crs encoding and axis order. ) What would happen then is that 
even when no srsName is specified, the 3D CRS is always being 
transformed to 2D, which is clearly unwanted behaviour.


Inspire schemas often require feature types with a (primary) 2D geometry 
and a (secondary) 3D geometry.


Kind Regards

Niels



___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] Fwd: [Geoserver-devel] powermock for unit tests in app-schema

[Niels Charlier via GeoTools-Devel]

I guess I sent this to the wrong ML



 Forwarded Message 
Subject:[Geoserver-devel] powermock for unit tests in app-schema
Date:   Mon, 8 Mar 2021 13:01:23 +0100
From: 	Niels Charlier via Geoserver-devel 


Reply-To:   Niels Charlier 
To: Geoserver-devel 



Hello,

I fixed a bug in geoserver app-schema 
(https://github.com/geotools/geotools/pull/3367 
https://osgeo-org.atlassian.net/browse/GEOT-6801). The change I made was 
very small (one character actually) and in one specific class. To me it 
seemed appropriate to write a unit test. Since it is JDBC an integration 
test would only be run online with db, but still require a lot of amount 
of work to create the right table, mapping etc... Mocking seems useful 
to me.


Anyway, because one of the classes I need is final, I had to use 
PowerMock to write the test. The Reviewer of the patch ask to check with 
the list if it is okay to add the PowerMock library to the test scope. I 
know traditionally we have more integration tests than unit tests, but I 
think it wouldn't be bad to add more unit tests in general.


Kind Regards

Niels



___
Geoserver-devel mailing list
geoserver-de...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] mapbox vector tiles

[Niels Charlier via GeoTools-Devel]

Ah, sorry, indeed, a fairly recent feature. I see it is using the same 
ECC library as geoserver to decode them. But it still only possible to 
read the PBF's as part of a mbtiles/sqlite database, right. Not by 
itself, or with a tilejson file?


Kind Regards

Niels

On 03/09/2020 15:41, Andrea Aime wrote:

I must have imagined this one:
https://github.com/geotools/geotools/blob/master/modules/unsupported/mbtiles/src/main/java/org/geotools/mbtiles/MBTilesDataStore.java

Cheers
Andrea

On Thu, Sep 3, 2020 at 3:38 PM Niels Charlier <mailto:ni...@scitus.be>> wrote:


An mbtiles file can indeed contain data in PBF format, but here as
well, it seems that the geotools module doesn't go as far
supporting this feature. Only raster images seem to be supported
as binary data in the mbtiles sqlite database: see

https://github.com/geotools/geotools/blob/master/modules/unsupported/mbtiles/src/main/java/org/geotools/mbtiles/mosaic/MBTilesReader.java#L261

Cheers

Niels

On 03/09/2020 14:43, Andrea Aime wrote:

Not completely unrelated, read here:
https://github.com/mapbox/mbtiles-spec/blob/master/1.3/spec.md

Cheers
Andrea


On Thu, Sep 3, 2020 at 2:42 PM Niels Charlier mailto:ni...@scitus.be>> wrote:

Andrea,

Confusingly, mbtiles and mapbox vector tiles are two entirely
distinct formats, as I understand it.

Mapbox vector tiles are unrelated to sqlite.

https://github.com/mapbox/vector-tile-spec

Regards

Niels

On 03/09/2020 14:33, Andrea Aime wrote:

Hi Niels,
the mbtiles store can read vector tiles stored in a sqlite
database. For map rendering usage only,
don't try to use that thing for WFS, won't be pretty :-D

Cheers
Andrea

On Thu, Sep 3, 2020 at 1:14 PM Niels Charlier via
GeoTools-Devel mailto:geotools-devel@lists.sourceforge.net>> wrote:

Hello,

Is it correct that there is currently no possibility to
read mapbox
binary vector tiles with geotools (PBF files).

There is a mapbox style parser, but I don't see anything
there that can
be done with PBF sources specified inside it.

Geoserver has MB vector tiles output format (an old
version, using an
old library).

Just checking I am not missing anything?

Kind Regards

Niels



___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
<mailto:GeoTools-Devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/geotools-devel



-- 


Regards, Andrea Aime

== GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information. == Ing. Andrea
Aime @geowolf Technical Lead GeoSolutions S.A.S. Via di
Montramito 3/A 55054 Massarosa (LU) phone: +39 0584 962313
fax: +39 0584 1660272 mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
--- /Con
riferimento alla normativa sul trattamento dei dati
personali (Reg. UE 2016/679 - Regolamento generale sulla
protezione dei dati “GDPR”), si precisa che ogni circostanza
inerente alla presente email (il suo contenuto, gli
eventuali allegati, etc.) è un dato la cui conoscenza è
riservata al/i solo/i destinatario/i indicati dallo
scrivente. Se il messaggio Le è giunto per errore, è
tenuta/o a cancellarlo, ogni altra operazione è illecita. Le
sarei comunque grato se potesse darmene notizia. This email
is intended only for the person or entity to which it is
addressed and may contain information that is privileged,
confidential or otherwise protected from disclosure. We
remind that - as provided by European Regulation 2016/679
“GDPR” - copying, dissemination or use of this e-mail or the
information herein by anyone other than the intended
recipient is prohibited. If you have received this email by
mistake, please notify us immediately by telephone or e-mail./




-- 


Regards, Andrea Aime

== GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information. == Ing. Andrea Aime
@geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A
55054 Massarosa (LU) phone: +39 0584 962313 fax: +39 0584 1660272
mob: +39 339 8844549 http://www.geo-solutions.it
http://twitter.com/geosolutions_it
--- /Con
riferimento alla normativa sul trattamento dei dati personali
(Reg. UE 2016/679 - Regolamento generale su

Re: [Geotools-devel] mapbox vector tiles

[Niels Charlier via GeoTools-Devel]

An mbtiles file can indeed contain data in PBF format, but here as well, 
it seems that the geotools module doesn't go as far supporting this 
feature. Only raster images seem to be supported as binary data in the 
mbtiles sqlite database: see 
https://github.com/geotools/geotools/blob/master/modules/unsupported/mbtiles/src/main/java/org/geotools/mbtiles/mosaic/MBTilesReader.java#L261


Cheers

Niels

On 03/09/2020 14:43, Andrea Aime wrote:

Not completely unrelated, read here:
https://github.com/mapbox/mbtiles-spec/blob/master/1.3/spec.md

Cheers
Andrea


On Thu, Sep 3, 2020 at 2:42 PM Niels Charlier <mailto:ni...@scitus.be>> wrote:


Andrea,

Confusingly, mbtiles and mapbox vector tiles are two entirely
distinct formats, as I understand it.

Mapbox vector tiles are unrelated to sqlite.

https://github.com/mapbox/vector-tile-spec

Regards

Niels

On 03/09/2020 14:33, Andrea Aime wrote:

Hi Niels,
the mbtiles store can read vector tiles stored in a sqlite
database. For map rendering usage only,
don't try to use that thing for WFS, won't be pretty :-D

Cheers
Andrea

On Thu, Sep 3, 2020 at 1:14 PM Niels Charlier via GeoTools-Devel
mailto:geotools-devel@lists.sourceforge.net>> wrote:

Hello,

Is it correct that there is currently no possibility to read
mapbox
binary vector tiles with geotools (PBF files).

There is a mapbox style parser, but I don't see anything
there that can
be done with PBF sources specified inside it.

Geoserver has MB vector tiles output format (an old version,
using an
old library).

Just checking I am not missing anything?

Kind Regards

Niels



___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
<mailto:GeoTools-Devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/geotools-devel



-- 


Regards, Andrea Aime

== GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information. == Ing. Andrea Aime
@geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A
55054 Massarosa (LU) phone: +39 0584 962313 fax: +39 0584 1660272
mob: +39 339 8844549 http://www.geo-solutions.it
http://twitter.com/geosolutions_it
--- /Con
riferimento alla normativa sul trattamento dei dati personali
(Reg. UE 2016/679 - Regolamento generale sulla protezione dei
dati “GDPR”), si precisa che ogni circostanza inerente alla
presente email (il suo contenuto, gli eventuali allegati, etc.) è
un dato la cui conoscenza è riservata al/i solo/i destinatario/i
indicati dallo scrivente. Se il messaggio Le è giunto per errore,
è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le
sarei comunque grato se potesse darmene notizia. This email is
intended only for the person or entity to which it is addressed
and may contain information that is privileged, confidential or
otherwise protected from disclosure. We remind that - as provided
by European Regulation 2016/679 “GDPR” - copying, dissemination
or use of this e-mail or the information herein by anyone other
than the intended recipient is prohibited. If you have received
this email by mistake, please notify us immediately by telephone
or e-mail./




--

Regards, Andrea Aime

== GeoServer Professional Services from the experts! Visit 
http://goo.gl/it488V for more information. == Ing. Andrea Aime 
@geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 
55054 Massarosa (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: 
+39 339 8844549 http://www.geo-solutions.it 
http://twitter.com/geosolutions_it 
--- /Con 
riferimento alla normativa sul trattamento dei dati personali (Reg. UE 
2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si 
precisa che ogni circostanza inerente alla presente email (il suo 
contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è 
riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il 
messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra 
operazione è illecita. Le sarei comunque grato se potesse darmene 
notizia. This email is intended only for the person or entity to which 
it is addressed and may contain information that is privileged, 
confidential or otherwise protected from disclosure. We remind that - 
as provided by European Regulation 2016/679 “GDPR” - copying, 
dissemination or use of this e-mail or the information herein by 
anyone other than the intended recipient is prohibited. If you have 
received this email by mistake, please notify us immediately by

Re: [Geotools-devel] mapbox vector tiles

[Niels Charlier via GeoTools-Devel]

Andrea,

Confusingly, mbtiles and mapbox vector tiles are two entirely distinct 
formats, as I understand it.


Mapbox vector tiles are unrelated to sqlite.

https://github.com/mapbox/vector-tile-spec

Regards

Niels

On 03/09/2020 14:33, Andrea Aime wrote:

Hi Niels,
the mbtiles store can read vector tiles stored in a sqlite database. 
For map rendering usage only,

don't try to use that thing for WFS, won't be pretty :-D

Cheers
Andrea

On Thu, Sep 3, 2020 at 1:14 PM Niels Charlier via GeoTools-Devel 
<mailto:geotools-devel@lists.sourceforge.net>> wrote:


Hello,

Is it correct that there is currently no possibility to read mapbox
binary vector tiles with geotools (PBF files).

There is a mapbox style parser, but I don't see anything there
that can
be done with PBF sources specified inside it.

Geoserver has MB vector tiles output format (an old version, using an
old library).

Just checking I am not missing anything?

Kind Regards

Niels



___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
<mailto:GeoTools-Devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/geotools-devel



--

Regards, Andrea Aime

== GeoServer Professional Services from the experts! Visit 
http://goo.gl/it488V for more information. == Ing. Andrea Aime 
@geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 
55054 Massarosa (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: 
+39 339 8844549 http://www.geo-solutions.it 
http://twitter.com/geosolutions_it 
--- /Con 
riferimento alla normativa sul trattamento dei dati personali (Reg. UE 
2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si 
precisa che ogni circostanza inerente alla presente email (il suo 
contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è 
riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il 
messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra 
operazione è illecita. Le sarei comunque grato se potesse darmene 
notizia. This email is intended only for the person or entity to which 
it is addressed and may contain information that is privileged, 
confidential or otherwise protected from disclosure. We remind that - 
as provided by European Regulation 2016/679 “GDPR” - copying, 
dissemination or use of this e-mail or the information herein by 
anyone other than the intended recipient is prohibited. If you have 
received this email by mistake, please notify us immediately by 
telephone or e-mail./


___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] mapbox vector tiles

[Niels Charlier via GeoTools-Devel]

Hello,

Is it correct that there is currently no possibility to read mapbox 
binary vector tiles with geotools (PBF files).


There is a mapbox style parser, but I don't see anything there that can 
be done with PBF sources specified inside it.


Geoserver has MB vector tiles output format (an old version, using an 
old library).


Just checking I am not missing anything?

Kind Regards

Niels



___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Is there a reason we do not have an ECQL null literal?

[Niels Charlier via GeoTools-Devel]

There is "Expression/NIL".

But it is not a literal, it's a property :/ A pseudo-property I'd say. 
See org.geotools.filter.expression.NullPropertyAccessorFactory


It definitely has uses, it's used in both app-schema and CSW mappings.

A literal would be more appropriate.

Regards

Niels

On 15/05/2020 04:15, Jody Garnett wrote:
I have been updating mbstyle filter to support expressions, and ran 
into something odd when writing tests (using ECQL to compare the 
output). It appears that a literal null value does not have a 
representation in ECQL. Indeed right now this causes a nice stacktrace 
to ECQL.toECQL( filter ).


I am not sure how we made it this far without one? Options:

  * '' - empty string is not quite NULL but close
  * NULL - already a reserved word, may actually be correct?

At a minimum I would like to throw a kinder error message - 
ExpressionToText:


    public Object visit(Literal expression, Object extraData) {
...
        } else {
            if (literal == null) {
throw new NullPointerException("ECQL does not support null literal 
value");

            } else {
String escaped = literal.toString().replaceAll("'", "''");
output.append("'" + escaped + "'");
            }
        }
        return output;
}

Searching online is difficult as the presence of "IS NULL" and "IS NOT 
NULL".

--
Jody Garnett


___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] unsupported kml datastore, no profile available

[Niels Charlier]

AFAIAC, it can be removed. I am not using it or maintaining it. That is 
my answer, at least from my own point of view.


But perhaps if others are using and somewhat maintaining it, a profile 
could be created instead? That is just a suggestion, on the condition 
that those others speak up.


Kind Regards

Niels

On 09/02/2020 14:24, Jody Garnett wrote:

Your name is on the work, so I am asking you :)

On Sun, Feb 9, 2020 at 2:20 PM Niels Charlier <mailto:ni...@scitus.be>> wrote:


I don't mind personally but Ian's recent fixes/improvements seems
to suggest he or someone is using it.

Kind Regards

Niels

On 09/02/2020 13:02, Jody Garnett wrote:

I have been arguing with IntiliJ and the geotools build for a bit
this afternoon, one thing I noticed was your KML DataStore

<https://github.com/geotools/geotools/blob/master/modules/unsupported/kml/pom.xml>
module, is not available in any profile

<https://github.com/geotools/geotools/blob/master/modules/unsupported/pom.xml>.

Should this be removed? It looks like the last commit was one
month ago... by Ian.  It looks like the last interesting bit of
work was your 2013 initial commit.
--
Jody Garnett


--
--
Jody Garnett
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] unsupported kml datastore, no profile available

[Niels Charlier]

I don't mind personally but Ian's recent fixes/improvements seems to 
suggest he or someone is using it.


Kind Regards

Niels

On 09/02/2020 13:02, Jody Garnett wrote:
I have been arguing with IntiliJ and the geotools build for a bit this 
afternoon, one thing I noticed was your KML DataStore 
 
module, is not available in any profile 
.


Should this be removed? It looks like the last commit was one month 
ago... by Ian.  It looks like the last interesting bit of work was 
your 2013 initial commit.

--
Jody Garnett
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] filter function "not"

[Niels Charlier]

It's probably possible but I think it's going to be really a lot of work 
I think, for something nobody ever noticed before.


An alias would be the preferred option IMHO.

On 01/05/2019 05:01, Jody Garnett wrote:
The reserved words are still just tokens in the grammar: 
http://old.geotools.org/ECQL-Parser-Design_110493908.html


We already have some special cases to recognize odd patterns (and 
encode odd patterns) for ECQL constructs like "property IN (1,2,3)" 
which is mapped to filter "in(1,2,3) == TRUE"



--
Jody Garnett


On Tue, 30 Apr 2019 at 14:59, Niels Charlier <mailto:ni...@scitus.be>> wrote:


I meant the CQL parser, including if you're parsing just an
expression, not an actual filter (CQL.toExpression). This method
is called from the AbstractStyleBuilder, app-schema and CSW. But
indeed the function would still work fine if you use filterfactory
methods to build the expression from scratch, and probably also
with XML parsers.

I think the CQL parser is automatically generated. I can't think
of any language that allows reserved words to be used for
identifiers. This is because reserved words are already detected
and separated from identifiers in the tokenizer stage.

On 30/04/2019 17:31, Andrea Aime wrote:

On Tue, Apr 30, 2019 at 11:25 AM Niels Charlier mailto:ni...@scitus.be>> wrote:

Hello,

I discovered that the implemented and documented filter
function "not"
doesn't actually work.


In what context? See below


The parser treats the word "not" as a reserved word, used for
filters,
therefore it does not manage to parse it as an identifier
inside an
expression.


"The parser", but filter functions can be created via code
directly, and via multiple parsers.
I'm guessing you mean CQL, where indeed NOT is a reserved keyword?
Would it work if you create it by code, or create it as part of a
OGC Filter 1.0 for example? Or as part of SLD?

Perhaps I am missing something, but otherwise the function
should
probably be renamed or removed?


Or, if the problem is CQL specific, get the parser fixed so that
it can tell the difference between NOT and NOT().
Does not sound easy, but I'd avoid removing functions, they can
be used in a variety of contexts (e.g., SLD).
Maybe just add an "alias" (a delegating function) that uses a
different name for usage in CQL, if modifying
the javacc parser looks too hard?

Cheers
Andrea
==

GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information. == Ing. Andrea Aime
@geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A
55054 Massarosa (LU) phone: +39 0584 962313 fax: +39 0584 1660272
mob: +39 339 8844549 http://www.geo-solutions.it
http://twitter.com/geosolutions_it
--- /Con
riferimento alla normativa sul trattamento dei dati personali
(Reg. UE 2016/679 - Regolamento generale sulla protezione dei
dati “GDPR”), si precisa che ogni circostanza inerente alla
presente email (il suo contenuto, gli eventuali allegati, etc.) è
un dato la cui conoscenza è riservata al/i solo/i destinatario/i
indicati dallo scrivente. Se il messaggio Le è giunto per errore,
è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le
sarei comunque grato se potesse darmene notizia. This email is
intended only for the person or entity to which it is addressed
and may contain information that is privileged, confidential or
otherwise protected from disclosure. We remind that - as provided
by European Regulation 2016/679 “GDPR” - copying, dissemination
or use of this e-mail or the information herein by anyone other
than the intended recipient is prohibited. If you have received
this email by mistake, please notify us immediately by telephone
or e-mail./


___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
<mailto:GeoTools-Devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/geotools-devel

___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] filter function "not"

[Niels Charlier]

I meant the CQL parser, including if you're parsing just an expression, 
not an actual filter (CQL.toExpression). This method is called from the 
AbstractStyleBuilder, app-schema and CSW. But indeed the function would 
still work fine if you use filterfactory methods to build the expression 
from scratch, and probably also with XML parsers.


I think the CQL parser is automatically generated. I can't think of any 
language that allows reserved words to be used for identifiers. This is 
because reserved words are already detected and separated from 
identifiers in the tokenizer stage.


On 30/04/2019 17:31, Andrea Aime wrote:
On Tue, Apr 30, 2019 at 11:25 AM Niels Charlier <mailto:ni...@scitus.be>> wrote:


Hello,

I discovered that the implemented and documented filter function
"not"
doesn't actually work.


In what context? See below


The parser treats the word "not" as a reserved word, used for
filters,
therefore it does not manage to parse it as an identifier inside an
expression.


"The parser", but filter functions can be created via code directly, 
and via multiple parsers.

I'm guessing you mean CQL, where indeed NOT is a reserved keyword?
Would it work if you create it by code, or create it as part of a OGC 
Filter 1.0 for example? Or as part of SLD?


Perhaps I am missing something, but otherwise the function should
probably be renamed or removed?


Or, if the problem is CQL specific, get the parser fixed so that it 
can tell the difference between NOT and NOT().
Does not sound easy, but I'd avoid removing functions, they can be 
used in a variety of contexts (e.g., SLD).
Maybe just add an "alias" (a delegating function) that uses a 
different name for usage in CQL, if modifying

the javacc parser looks too hard?

Cheers
Andrea
==

GeoServer Professional Services from the experts! Visit 
http://goo.gl/it488V for more information. == Ing. Andrea Aime 
@geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 
55054 Massarosa (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: 
+39 339 8844549 http://www.geo-solutions.it 
http://twitter.com/geosolutions_it 
--- /Con 
riferimento alla normativa sul trattamento dei dati personali (Reg. UE 
2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si 
precisa che ogni circostanza inerente alla presente email (il suo 
contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è 
riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il 
messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra 
operazione è illecita. Le sarei comunque grato se potesse darmene 
notizia. This email is intended only for the person or entity to which 
it is addressed and may contain information that is privileged, 
confidential or otherwise protected from disclosure. We remind that - 
as provided by European Regulation 2016/679 “GDPR” - copying, 
dissemination or use of this e-mail or the information herein by 
anyone other than the intended recipient is prohibited. If you have 
received this email by mistake, please notify us immediately by 
telephone or e-mail./


___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] filter function "not"

[Niels Charlier]

Hello,

I discovered that the implemented and documented filter function "not" 
doesn't actually work.


The parser treats the word "not" as a reserved word, used for filters, 
therefore it does not manage to parse it as an identifier inside an 
expression.


Perhaps I am missing something, but otherwise the function should 
probably be renamed or removed?


I'm not sure if there is much other use for it:
- there is a notEqualsTo, and I don't know if there are any other 
boolean functions besides equality tests
- there is no function for "and" and "or", so complicated boolean 
expressions are not possible
- boolean expressions are probably only used as condition for 
if_then_else, and you can always switch the then and the else


Regards

Niels



___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [JIRA] (GEOT-5793) MultiGeometry not working in GML 3.2 parser/encoded

[Niels Charlier (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Niels Charlier created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 GeoTools /  GEOT-5793  
 
 
  MultiGeometry not working in GML 3.2 parser/encoded   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Affects Versions: 
 17.1  
 
 
Assignee: 
 Niels Charlier  
 
 
Components: 
 xsd-gml  
 
 
Created: 
 31/Jul/17 11:04 AM  
 
 
Priority: 
  Medium  
 
 
Reporter: 
 Niels Charlier  
 

  
 
 
 
 

 
 GML 3.2 doesn't parse or encode multigeometries. Considering that multipolygons are removed in GML 3.2, they are rather important.  
 

  
 
 
  
 

 
 
 

 
 
 Add Comment

[Geotools-devel] [JIRA] (GEOT-5702) NetCDF support two-dimensional variable

[Niels Charlier (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Niels Charlier created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 GeoTools /  GEOT-5702  
 
 
  NetCDF support two-dimensional variable   
 

  
 
 
 
 

 
Issue Type: 
  Improvement  
 
 
Assignee: 
 Niels Charlier  
 
 
Components: 
 netcdf  
 
 
Created: 
 17/Apr/17 12:33 PM  
 
 
Priority: 
  Medium  
 
 
Reporter: 
 Niels Charlier  
 

  
 
 
 
 

 
 We would like to provide some support for 2D coordinate variables in NetCDF, in particular in aggregations. An example use case: NC files with different time values being aggregated over runtime. The idea is not to provide support for 2D coordinates in geotools, but to expose the 2D coordinate as a regular coordinate to geotools/geoserver. Some of the expected behaviour (using the example of a 2D time over runtime):  In the GetCapabilities, all possible time values are listed (no value is mentioned twice of course, so a unique flat list is composed from the 2D value table). The user may of course specify a valid combination of a time and a runtime in a WMS/WCS request to get the appropriate data. An invalid combination returns no data. NetCDF can be configured to retrieve the maximum or minimum runtime RELATIVE to a provided time in the request. This requires geoserver to configure the runtime dimension default value as "built-in". In addition, we want to support an auxiliary WFS store that exposes the index in order to list all possible time/runtime combinations, since this cannot be retrieved from the GetCa

Re: [Geotools-devel] [Geoserver-devel] proposed change: coverage readers custom dimension data type conversion

[Niels Charlier]

Thanks Andrea.

Considering we haven't gotten any response, do you think it is safe to 
merge now?


Kind Regards
Niels

On 22-03-17 14:56, Andrea Aime wrote:

Hi Niels,
there is one test about custom dimensions treatment that was 
contributed by Mike Benowitz years ago, I've
cc'ed him along with another fellow at GDIT, they might be affected 
(or not).
I also know GeoMesa has their own custom readers, no idea if they are 
dimension enabled or not. Cc'ed Jim just in case.


Cheers
Andrea


On Wed, Mar 22, 2017 at 2:27 PM, Niels Charlier <ni...@scitus.be 
<mailto:ni...@scitus.be>> wrote:


Hello,

This message is particularly aimed at people who develop/use coverage
readers that support custom dimensions, but are outside of the main
geotools/geoserver code base.

I am proposing a change that may affect them (see
https://osgeo-org.atlassian.net/browse/GEOS-7989
<https://osgeo-org.atlassian.net/browse/GEOS-7989>). In short:

At this moment Coverage Reader may or may not advertise a Java class
through their metadata for each custom dimension.

However, geoserver WMS and WCS1 ignore this and always put custom
dimension values in String format inside the query filter. My PR would
change this and attempt to convert to the advertised type first, if
possible.

The only affected readers in the official code base are netcdf and
imagemosaic. My change would break neither, but rather improve
both (by
supporting Dates). However, it is possible that there are other
readers
around that advertise a class but still assume a String in the query
(because that is how it works now).

So if that is the case, please respond to this message.

In general, I would like to know whether this change is OK with the
community.

Kind Regards

Niels



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Geoserver-devel mailing list
geoserver-de...@lists.sourceforge.net
<mailto:geoserver-de...@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
<https://lists.sourceforge.net/lists/listinfo/geoserver-devel>




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

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39  339 8844549

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

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica e/o 
nel/i file/s allegato/i sono da considerarsi strettamente riservate. 
Il loro utilizzo è consentito esclusivamente al destinatario del 
messaggio, per le finalità indicate nel messaggio stesso. Qualora 
riceviate questo messaggio senza esserne il destinatario, Vi preghiamo 
cortesemente di darcene notizia via e-mail e di procedere alla 
distruzione del messaggio stesso, cancellandolo dal Vostro sistema. 
Conservare il messaggio stesso, divulgarlo anche in parte, 
distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità 
diverse, costituisce comportamento contrario ai principi dettati dal 
D.Lgs. 196/2003.


The information in this message and/or attachments, is intended solely 
for the attention and use of the named addressee(s) and may be 
confidential or proprietary in nature or covered by the provisions of 
privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New 
Data Protection Code).Any use not in accord with its purpose, any 
disclosure, reproduction, copying, distribution, or either 
dissemination, either whole or partial, is strictly forbidden except 
previous formal approval of the named addressee(s). If you are not the 
intended recipient, please contact immediately the sender by 
telephone, fax or e-mail and delete the information in this message 
that has been received in error. The sender does not give any warranty 
or accept liability as the content, accuracy or completeness of sent 
messages and accepts no responsibility  for changes made after they 
were sent or for other risks which arise as a result of e-mail 
transmission, viruses, etc.



---



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] proposed change: coverage readers custom dimension data type conversion

[Niels Charlier]

Hello,

This message is particularly aimed at people who develop/use coverage 
readers that support custom dimensions, but are outside of the main 
geotools/geoserver code base.

I am proposing a change that may affect them (see 
https://osgeo-org.atlassian.net/browse/GEOS-7989). In short:

At this moment Coverage Reader may or may not advertise a Java class 
through their metadata for each custom dimension.

However, geoserver WMS and WCS1 ignore this and always put custom 
dimension values in String format inside the query filter. My PR would 
change this and attempt to convert to the advertised type first, if 
possible.

The only affected readers in the official code base are netcdf and 
imagemosaic. My change would break neither, but rather improve both (by 
supporting Dates). However, it is possible that there are other readers 
around that advertise a class but still assume a String in the query 
(because that is how it works now).

So if that is the case, please respond to this message.

In general, I would like to know whether this change is OK with the 
community.

Kind Regards

Niels


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] netcdf runtime pull requests

[Niels Charlier]

Hello Andrea,

Indeed, that is fine. But in the meantime it is there already for review 
when it suits.


Regards

Niels


On 01-03-17 12:03, Andrea Aime wrote:

Hi Niels,
cannot comment on the pull request contents, but just in case you're 
not aware,
we're in feature freeze for the 2.11-RC1 release, new features will 
have to wait

for the master branch to switch to 18-snapshot/2.12-snapshot to be merged

Cheers
Andrea


On Wed, Mar 1, 2017 at 11:43 AM, Niels Charlier <ni...@scitus.be 
<mailto:ni...@scitus.be>> wrote:


Hello Simone, Daniele,

I have made two pull requests with the aim of supporting "runtime"
as an
additional dimension in netcdf-java:

The first is in the netcdf-java module itself:

https://github.com/geotools/geotools/pull/1472
<https://github.com/geotools/geotools/pull/1472>

Rather than just adding runtime to the supported time and
elevation, it
is implemented in such a way that the VariableAdapter is now
generalised
for any number of dimensions, which is something I discussed
months ago
with Daniele and I thought it was a very good idea.

The second is in geoserver, which supports parsing custom
dimensions to
Date (or other data types) before sending them to the geotools store,
rather than always sending them as a String:

https://github.com/geoserver/geoserver/pull/2117
<https://github.com/geoserver/geoserver/pull/2117>


If you could have a look at these, that would be great. Thanks in
advance.

Kind Regards

Niels



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
<mailto:GeoTools-Devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/geotools-devel
<https://lists.sourceforge.net/lists/listinfo/geotools-devel>




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

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39  339 8844549

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

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica e/o 
nel/i file/s allegato/i sono da considerarsi strettamente riservate. 
Il loro utilizzo è consentito esclusivamente al destinatario del 
messaggio, per le finalità indicate nel messaggio stesso. Qualora 
riceviate questo messaggio senza esserne il destinatario, Vi preghiamo 
cortesemente di darcene notizia via e-mail e di procedere alla 
distruzione del messaggio stesso, cancellandolo dal Vostro sistema. 
Conservare il messaggio stesso, divulgarlo anche in parte, 
distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità 
diverse, costituisce comportamento contrario ai principi dettati dal 
D.Lgs. 196/2003.


The information in this message and/or attachments, is intended solely 
for the attention and use of the named addressee(s) and may be 
confidential or proprietary in nature or covered by the provisions of 
privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New 
Data Protection Code).Any use not in accord with its purpose, any 
disclosure, reproduction, copying, distribution, or either 
dissemination, either whole or partial, is strictly forbidden except 
previous formal approval of the named addressee(s). If you are not the 
intended recipient, please contact immediately the sender by 
telephone, fax or e-mail and delete the information in this message 
that has been received in error. The sender does not give any warranty 
or accept liability as the content, accuracy or completeness of sent 
messages and accepts no responsibility  for changes made after they 
were sent or for other risks which arise as a result of e-mail 
transmission, viruses, etc.



---


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] netcdf runtime pull requests

[Niels Charlier]

Hello Simone, Daniele,

I have made two pull requests with the aim of supporting "runtime" as an 
additional dimension in netcdf-java:

The first is in the netcdf-java module itself:

https://github.com/geotools/geotools/pull/1472

Rather than just adding runtime to the supported time and elevation, it 
is implemented in such a way that the VariableAdapter is now generalised 
for any number of dimensions, which is something I discussed months ago 
with Daniele and I thought it was a very good idea.

The second is in geoserver, which supports parsing custom dimensions to 
Date (or other data types) before sending them to the geotools store, 
rather than always sending them as a String:

https://github.com/geoserver/geoserver/pull/2117


If you could have a look at these, that would be great. Thanks in advance.

Kind Regards

Niels


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [JIRA] (GEOT-5637) Support NetCDF >4 dimensions, including runtime

[Niels Charlier (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Niels Charlier created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 GeoTools /  GEOT-5637  
 
 
  Support NetCDF >4 dimensions, including runtime   
 

  
 
 
 
 

 
Issue Type: 
  New Feature  
 
 
Assignee: 
     Niels Charlier  
 
 
Components: 
 netcdf  
 
 
Created: 
 08/Feb/17 8:16 PM  
 
 
Priority: 
  Medium  
 
 
Reporter: 
     Niels Charlier  
 

  
 
 
  
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v1000.747.0#100028-sha1:6f58

Re: [Geotools-devel] [Geoserver-devel] jai-ext initialisation

[Niels Charlier]

Hello Andrea,

I definitely wouldn't want to move all initialisation code to static, if 
anything I'd prefer moving things the other way as Ben suggested.


My question was rather about those specific lines of code (initialising 
the OperationRegistry). My assumption was ImageWorker was going to be on 
the class path anyway, but you have answered my question by saying that 
this is not actually the case.


However, it appears that jai-ext is on the classpath of gs-main in any 
case. At least the following small patch could be an improvement that 
would prevent the issue we came across without the need for double 
initialisation of jai-ext:


https://github.com/geoserver/geoserver/pull/2032/

Does that make sense?

For the rest, I think it is an interesting discussion for the long run 
to think of a more structured way to initialise geotools.


Kind Regards
Niels

On 14-12-16 15:55, Andrea Aime wrote:
On Mon, Dec 12, 2016 at 1:58 PM, Niels Charlier <ni...@scitus.be 
<mailto:ni...@scitus.be>> wrote:


I have another question though - why is geoserver doing this thing
in GeoServerInitStartupListener? I'm not just asking about the
place it is doing, why is it doing this at all? What was the
original idea behind it and does it still count? I think
ImageWorker is on the classpath of geoserver in any case, so
whether it does its own JAI initialisation before or after
ImageWorker, it seems pointless. Or am I wrong?

For most things I believe there is no obvious/simple alternative to 
performing certain inits as the very first action while the app starts up.


Let's have a look line by line:

  * GeoTools initialization, that needs to be done very first thing to
avoid losing logging and JAI logs,

https://github.com/geoserver/geoserver/blob/master/src/main/src/main/java/org/geoserver/GeoserverInitStartupListener.java#L85

<https://github.com/geoserver/geoserver/blob/master/src/main/src/main/java/org/geoserver/GeoserverInitStartupListener.java#L85>
  * Avoid logs on standard error in JAI, also needs to be done first,
or we might get some spurious logs during system init,

https://github.com/geoserver/geoserver/blob/master/src/main/src/main/java/org/geoserver/GeoserverInitStartupListener.java#L88

<https://github.com/geoserver/geoserver/blob/master/src/main/src/main/java/org/geoserver/GeoserverInitStartupListener.java#L88>
  * Setting up JAI alternative registry and tile cache, yep, also
needs to be done very first thing, if not you already know what
the consequences are:

https://github.com/geoserver/geoserver/blob/master/src/main/src/main/java/org/geoserver/GeoserverInitStartupListener.java#L121

<https://github.com/geoserver/geoserver/blob/master/src/main/src/main/java/org/geoserver/GeoserverInitStartupListener.java#L121>
Not setting up these two at all will have dire scalability and
runtime consequences, either under high load or in certain
conditions (e.g., highly oversampled requests)
  * Forcing axis order, also needs to be done before anything starts
using the CRS factories or the order won't be the expected one,

https://github.com/geoserver/geoserver/blob/master/src/main/src/main/java/org/geoserver/GeoserverInitStartupListener.java#L141

<https://github.com/geoserver/geoserver/blob/master/src/main/src/main/java/org/geoserver/GeoserverInitStartupListener.java#L141>
This could actually be avoided by applying everywhere the same
changes you just proposed in the geopackage module, and that would
be applied in several other places as well, plus changing the axis
order logic in WMS 1.3, in WFS, in the GML encoder, and so on...
doable, not sure anyone is willing to spend days to chase all the
points where this happens, and then discoverer 6 months later that
a few have been missed (not to mention, the effect on plugins that
are not in the GeoTools/GeoServer source trees, those would have
to be updated too).
Anyways, worth pursuing imho, just hard to fund.
  * The rest of the inits in that method are also needed to be done
very first thing, but are a bit less obvious to explain. Suffice
it to say that not doing those will have other adverse effects,
either functional, performance or availability related

The JAI initializations should not be moved to the ImageWorker for the 
simple reason that not everything uses the ImageWorker, and its 
initializations are specific to a few operations... if anything, I'd 
move the ImageWorker inits somewhere else instead. However there is no 
obvious place at the moment, GeoTools.init would not have  the 
necessary classes in the classpath.
_Maybe_ a plugin system could be developed to allow per module inits 
that would be called as GeoTools.init is called still, people 
would have to remember to call it.


Not all use cases will need all the inits that GeoServer is 
performing, a desktop appl

Re: [Geotools-devel] [Geoserver-devel] jai-ext initialisation

[Niels Charlier]

Hello,

I think this is a misunderstanding. I did not intend my email as a 
complaint or criticism (and especially not to make myself "feel better", 
I don't see it that way at all). It was merely intended as an entirely 
neutral issue report, like "hey, I found this thing that seemed to have 
slipped in to our project that is something for all of us to look at and 
think about".


Perhaps "dodgy" was a poor word choice, but all I meant with that 
particular sentence was "despite the fact that this isn't causing any 
major issues for anyone, it is still a potential loophole and a 
situation we should maybe consider improving /either way/". By no means 
I was pointing the finger at a particular person(s), I think these 
things just happen in a project like ours and I wanted to report it. 
That is my honest opinion about it, and that is honestly all that what 
was on my mind when I wrote that email.


And yes, I am absolutely more than willing to think along for solutions. 
But I didn't have any solutions yet and I felt I needed more information 
first, or to study it better, and I thought I'd report it in the 
meantime as a open question, invite some brainstorming (as Ben did). 
Sometimes other people know things of the top of their heads that they 
can respond immediately that saves me a lot of time finding out, so that 
is why I send an email before I have a solution. I guess that I should 
have written more specific questions in my email rather than ending with 
the "dodgy" comment. I do apologise for my poor communication in that 
regard, which can be explained by the fact that I wrote it at the end of 
my workday (next time, I'll keep it for the beginning of the next and 
take the time to ask specific questions). I hope that clears it up.


I do like Ben's suggestions, but of course he is looking at the broader 
picture, and particularly from the geotools side. I think any way we can 
get rid of static code in geotools would be an improvement.


I have another question though - why is geoserver doing this thing in 
GeoServerInitStartupListener? I'm not just asking about the place it is 
doing, why is it doing this at all? What was the original idea behind it 
and does it still count? I think ImageWorker is on the classpath of 
geoserver in any case, so whether it does its own JAI initialisation 
before or after ImageWorker, it seems pointless. Or am I wrong?


Kind Regards

Niels


On 12/10/2016 10:48 AM, Andrea Aime wrote:
On Fri, Dec 9, 2016 at 10:19 PM, Ben Caradoc-Davies > wrote:


I think this was a fair comment.


Our community provided a guideline as to what constructive criticism 
is, that is not, it's simply criticism (without the constructive part).


The voting guidelines for anything are clear, one can vote -1 but only 
providing alternative paths, while this is of course just a random 
discussion
the expected approach would be the same, simply venting out criticism 
does not help anybody, besides maybe make the

one writing the mail feel better.

I can understand the frustration of someone that did not put the 
GeoServerInitStartupListener
as the very first thing running at JVM startup, forgetting or being 
unable to do so is going to cause a lot of frustrating debugging (not 
just for JAI
but for other aspects as well), however simple complaints are of no 
help to anyone.


Andrea, I would appreciate your view on whether GeoTools could
benefit from some sort of configuration API. I know little about
JAI and JAIExt, but could a configuration API be used to inject
some sort of manager into GeoTools? Or do dependencies and cycles
mean we will end up reinventing Spring?


I don't have a view on this problem, haven't been bit by it 
significantly and/or when it happened, I could only blame myself
and did not have resource to propose an actual improvement along with 
the resources to implement it

(typical case, forgetting to set the axis order hints right on startup).

Just an observation, initialization of JAI is an issue of itself, 
something like setting up the registry needs to be done
at startup, very first thing, so some control over init order is 
necessary there, what provides this control depends on the technology
used to write the application and its context (command line, OSGI, 
servlet, aws lambda), but I'm skeptical that is actually a GeoTools
problem to solve (we'd have to marry some specific class wiring 
solution).


The highly dynamic nature of JAI (dynamic registry, priorities, 
anything swappable at any time, but not without side effects) makes it
hard to deal with, especially today that we have replaced most parts 
of it. If we ever get to rewrite it, the new version could
use some lessons learned to avoid some of these issues (e.g., it could 
disallow changing the registry past a certain init point).


Regards
Andrea


--
==
GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V 

Re: [Geotools-devel] strange distortion from warp operation in ImageWorker

[Niels Charlier]

Indeed, makes sense that those are the two possible approaches to fix 
the problem.


Regards
Niels

On 22-11-16 11:43, Andrea Aime wrote:
On Mon, Nov 21, 2016 at 5:52 PM, Niels Charlier <ni...@scitus.be 
<mailto:ni...@scitus.be>> wrote:


Do you have an idea what could cause this kind of distortion? I am now
strongly suspecting this a bug in JAI and not resolvable in geotools,
would that be possible?


Mind, this is quite likely the case, there is probably something in 
the warp math
that has fragile numeric behavior when the raster coordinates got up 
on very

high values.

This could likely be fixed in jai-ext.

Another possible approach would be to "fix" image mosaic so that it 
does not

generate these huge coordinates to start with.
Right now it's using a global "grid to world" to represent the output,
but I believe it could be using a "reduced" one, local to the 
requested area,

that would position images in raster space location closer to the origin,
and thus avoid this issue without causing performance regressions.
Just an idea ;-)

Cheers
Andrea



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

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39  339 8844549

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

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica e/o 
nel/i file/s allegato/i sono da considerarsi strettamente riservate. 
Il loro utilizzo è consentito esclusivamente al destinatario del 
messaggio, per le finalità indicate nel messaggio stesso. Qualora 
riceviate questo messaggio senza esserne il destinatario, Vi preghiamo 
cortesemente di darcene notizia via e-mail e di procedere alla 
distruzione del messaggio stesso, cancellandolo dal Vostro sistema. 
Conservare il messaggio stesso, divulgarlo anche in parte, 
distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità 
diverse, costituisce comportamento contrario ai principi dettati dal 
D.Lgs. 196/2003.


The information in this message and/or attachments, is intended solely 
for the attention and use of the named addressee(s) and may be 
confidential or proprietary in nature or covered by the provisions of 
privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New 
Data Protection Code).Any use not in accord with its purpose, any 
disclosure, reproduction, copying, distribution, or either 
dissemination, either whole or partial, is strictly forbidden except 
previous formal approval of the named addressee(s). If you are not the 
intended recipient, please contact immediately the sender by 
telephone, fax or e-mail and delete the information in this message 
that has been received in error. The sender does not give any warranty 
or accept liability as the content, accuracy or completeness of sent 
messages and accepts no responsibility  for changes made after they 
were sent or for other risks which arise as a result of e-mail 
transmission, viruses, etc.



---



--
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] strange distortion from warp operation in ImageWorker

[Niels Charlier]

Hello Andrea,

Thank you for your response.

On 21-11-16 18:07, Andrea Aime wrote:
Yes, a significant one under load testing, as it avoids the generation 
of one
level of tiles in the chain, thus reducing both computation and load 
on the tile cache.

So by turning it off you get the good looking results?


Well actually, this image is actually taken from doing the same getmap 
request but with a mosaic with only one tile instead of thousands.

But turning the reducing off will also give the same (good) result.


It might be due to image layout difference, do you see any between the
normal "warp and then affine" case compared to the reduced warp/affine?


No, I do not see any difference in image layout before or after the 
operations. There is only the difference with the smaller mosaic case 
where the x and y offsets are much smaller... which seems to avoid the 
issue.


Also, I'd suggest to have a look at the code on master, I've made 
changes there,

is the issue still showing up after those changes.

Yes.

Kind Regards
Niels
--
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] strange distortion from warp operation in ImageWorker

[Niels Charlier]

Hello,

We are getting strange distortions when zooming on a very large mosaic 
(see https://osgeo-org.atlassian.net/browse/GEOS-7793), which appear to 
be caused by the JAI warp operation called in ImageWorker (see 
https://github.com/geotools/geotools/blob/master/modules/library/coverage/src/main/java/org/geotools/image/ImageWorker.java#L3989).
 


Strangely enough, this doesn't happen with a single image (or smaller 
mosaic). The only difference I can see, is in the X and Y offset values 
of the image and the affine transformation.

This is the picture before the operation: 
http://www.scitus.be/temp/original.png
this is the good result http://www.scitus.be/temp/good.png
and the bad result http://scitus.be/temp/bad.png

Underneath this email I am also putting the planar image and warp 
transform details (but as you will see, only x and y offset are different).

Do you have an idea what could cause this kind of distortion? I am now 
strongly suspecting this a bug in JAI and not resolvable in geotools, 
would that be possible?

Also, the whole block of code can be avoided by setting the system 
property org.geotools.image.reduceWarpAffine=false
What would be the potential disadvantage of that? (The code must be 
there for a reason... Is this just a performance thing...?)

Kind Regards,
Niels


** DETAILS FOR WORKING VERSION **

[PlanarImage[minX=1600 minY=2395 width=51 height=36 tileGridXOffset=1598 
tileGridYOffset=2393 tileWidth=512 tileHeight=512 
sampleModel=java.awt.image.PixelInterleavedSampleModel@3070002 
colorModel=ColorModel: #pixelBits = 24 numComponents = 3 color space = 
java.awt.color.ICC_ColorSpace@4bd37c5f transparency = 1 has alpha = 
false isAlphaPre = false]]

CONCAT_MT[PARAM_MT["Affine",
 PARAMETER["num_row", 3],
 PARAMETER["num_col", 3],
 PARAMETER["elt_0_0", 0.034539737749169123],
 PARAMETER["elt_0_2", 332894.3361804273],
 PARAMETER["elt_1_1", -0.01734296884752956],
 PARAMETER["elt_1_2", 6551844.388902134]],
   INVERSE_MT[PARAM_MT["Popular Visualisation Pseudo Mercator",
   PARAMETER["semi_major", 6378137.0],
   PARAMETER["semi_minor", 6378137.0],
   PARAMETER["latitude_of_origin", 0.0],
   PARAMETER["central_meridian", 0.0],
   PARAMETER["scale_factor", 1.0],
   PARAMETER["false_easting", 0.0],
   PARAMETER["false_northing", 0.0]]],
   PARAM_MT["Ellipsoid_To_Geocentric",
 PARAMETER["dim", 2],
 PARAMETER["semi_major", 6378137.0],
 PARAMETER["semi_minor", 6356752.314245179]],
   PARAM_MT["Geocentric_To_Ellipsoid",
 PARAMETER["dim", 2],
 PARAMETER["semi_major", 6378137.0],
 PARAMETER["semi_minor", 6356752.314140356]],
   PARAM_MT["Lambert_Conformal_Conic_2SP",
 PARAMETER["semi_major", 6378137.0],
 PARAMETER["semi_minor", 6356752.314140356],
 PARAMETER["central_meridian", 3.0],
 PARAMETER["latitude_of_origin", 46.5],
 PARAMETER["standard_parallel_1", 49.0],
 PARAMETER["false_easting", 70.0],
 PARAMETER["false_northing", 660.0],
 PARAMETER["scale_factor", 1.0],
 PARAMETER["standard_parallel_2", 44.0]],
   PARAM_MT["Affine",
 PARAMETER["num_row", 3],
 PARAMETER["num_col", 3],
 PARAMETER["elt_0_0", 5.0],
 PARAMETER["elt_0_2", -296.0],
 PARAMETER["elt_1_1", -5.0],
 PARAMETER["elt_1_2", 3000.0]]]


** DETAILS FOR NON-WORKING VERSION **

[PlanarImage[minX=536600 minY=272395 width=51 height=36 
tileGridXOffset=536598 tileGridYOffset=272393 tileWidth=512 
tileHeight=512 
sampleModel=java.awt.image.PixelInterleavedSampleModel@3070002 
colorModel=ColorModel: #pixelBits = 24 numComponents = 3 color space = 
java.awt.color.ICC_ColorSpace@4bd37c5f transparency = 1 has alpha = 
false isAlphaPre = false], null, null, null, null, null, null, null, 
null, null]

CONCAT_MT[PARAM_MT["Affine",
 PARAMETER["num_row", 3],
 PARAMETER["num_col", 3],
 PARAMETER["elt_0_0", 0.034539737749169123],
 PARAMETER["elt_0_2", 332894.3361804273],
 PARAMETER["elt_1_1", -0.01734296884752956],
 PARAMETER["elt_1_2", 6551844.388902134]],
   INVERSE_MT[PARAM_MT["Popular Visualisation Pseudo Mercator",
   PARAMETER["semi_major", 6378137.0],
   PARAMETER["semi_minor", 6378137.0],
   PARAMETER["latitude_of_origin", 0.0],
   PARAMETER["central_meridian", 0.0],
   PARAMETER["scale_factor", 1.0],
   PARAMETER["false_easting", 0.0],
   PARAMETER["false_northing", 0.0]]],
   PARAM_MT["Ellipsoid_To_Geocentric",
 PARAMETER["dim", 2],
 PARAMETER["semi_major", 6378137.0],
 PARAMETER["semi_minor", 6356752.314245179]],
   PARAM_MT["Geocentric_To_Ellipsoid",
 PARAMETER["dim", 2],
 PARAMETER["semi_major", 6378137.0],
 PARAMETER["semi_minor", 6356752.314140356]],
   PARAM_MT["Lambert_Conformal_Conic_2SP",
 PARAMETER["semi_major", 6378137.0],
 PARAMETER["semi_minor", 6356752.314140356],
 PARAMETER["central_meridian", 3.0],
 PARAMETER["latitude_of_origin", 46.5],
 PARAMETER["standard_parallel_1", 49.0],

[Geotools-devel] [JIRA] (GEOT-5578) GeometryReducer fails and logs a warning if source CRS is not WGS84

[Niels Charlier (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Niels Charlier created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 GeoTools /  GEOT-5578  
 
 
  GeometryReducer fails and logs a warning if source CRS is not WGS84   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Assignee: 
 Unassigned  
 
 
Components: 
 referencing  
 
 
Created: 
 18/Nov/16 3:39 PM  
 
 
Priority: 
  Medium  
 
 
Reporter: 
 Niels Charlier  
 

  
 
 
 
 

 
 Consider the following lines: https://github.com/geotools/geotools/blob/master/modules/library/render/src/main/java/org/geotools/renderer/lite/gridcoverage2d/GridGeometryReducer.java#L86 It is comparing the values of two envelopes, however they are not necessarily in the same CRS. validArea is always just WGS84 (see https://github.com/geotools/geotools/blob/master/modules/library/render/src/main/java/org/geotools/renderer/crs/ProjectionHandler.java#L106) gg.getEnvelope() is in the native CRS of the coverage.  
 

  
 
 
  
 

 
 
 

 
 
 Add Comment

Re: [Geotools-devel] GeometryReducer

[Niels Charlier]

Hey Andrea,

Thank you for your answer.

The issue was investigating didn't appear to be related to this, so 
unfortunately I cannot spend time fixing it at his moment.


This is still producing a lot of warnings though, so I will make a bug 
report on jira.


Kind Regards
Niels

On 11-11-16 09:09, Andrea Aime wrote:

Hi Niels,
I had a quick look, while I'm not completely sure I believe you're 
right, although the issue does not involve GridGeometryReducer alone.
The javadoc of ProjectionHandler states the valid area in in the 
projection handler source CRS:


https://github.com/geotools/geotools/blob/master/modules/library/render/src/main/java/org/geotools/renderer/crs/ProjectionHandler.java#L642

That would make the usage of GridGeometryReducer valid, except that as 
you have noticed, the valid area bounds are always
in WGS84 instead. So the javadoc should be amended, and the grid 
geometry reducer usage should be fixed accordingly.


The reprojection from the valid area backwards to the source CRS may 
not be so trivial though... I would consider using
the projection handler itself to pre-process the source envelope (by 
turning it into a polygon).


Cheers
Andrea


On Wed, Nov 9, 2016 at 2:46 PM, Niels Charlier <ni...@scitus.be 
<mailto:ni...@scitus.be>> wrote:


Hi Andrea,

I have a question with regards to the GridGeometryReducer class,
which you are credited with.

Consider the following lines:


https://github.com/geotools/geotools/blob/master/modules/library/render/src/main/java/org/geotools/renderer/lite/gridcoverage2d/GridGeometryReducer.java#L86

<https://github.com/geotools/geotools/blob/master/modules/library/render/src/main/java/org/geotools/renderer/lite/gridcoverage2d/GridGeometryReducer.java#L86>

It is comparing the values of two envelopes, however they are not
necessarily in the same CRS.

validArea is always just WGS84 (see

https://github.com/geotools/geotools/blob/master/modules/library/render/src/main/java/org/geotools/renderer/crs/ProjectionHandler.java#L106

<https://github.com/geotools/geotools/blob/master/modules/library/render/src/main/java/org/geotools/renderer/crs/ProjectionHandler.java#L106>)

gg.getEnvelope() is in the native CRS of the coverage.

Is this a bug or am I missing something?

Kind Regards,
Niels




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

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39  339 8844549

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

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica e/o 
nel/i file/s allegato/i sono da considerarsi strettamente riservate. 
Il loro utilizzo è consentito esclusivamente al destinatario del 
messaggio, per le finalità indicate nel messaggio stesso. Qualora 
riceviate questo messaggio senza esserne il destinatario, Vi preghiamo 
cortesemente di darcene notizia via e-mail e di procedere alla 
distruzione del messaggio stesso, cancellandolo dal Vostro sistema. 
Conservare il messaggio stesso, divulgarlo anche in parte, 
distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità 
diverse, costituisce comportamento contrario ai principi dettati dal 
D.Lgs. 196/2003.


The information in this message and/or attachments, is intended solely 
for the attention and use of the named addressee(s) and may be 
confidential or proprietary in nature or covered by the provisions of 
privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New 
Data Protection Code).Any use not in accord with its purpose, any 
disclosure, reproduction, copying, distribution, or either 
dissemination, either whole or partial, is strictly forbidden except 
previous formal approval of the named addressee(s). If you are not the 
intended recipient, please contact immediately the sender by 
telephone, fax or e-mail and delete the information in this message 
that has been received in error. The sender does not give any warranty 
or accept liability as the content, accuracy or completeness of sent 
messages and accepts no responsibility  for changes made after they 
were sent or for other risks which arise as a result of e-mail 
transmission, viruses, etc.



---



--
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] GeometryReducer

[Niels Charlier]

Hi Andrea,

I have a question with regards to the GridGeometryReducer class, which 
you are credited with.

Consider the following lines:

https://github.com/geotools/geotools/blob/master/modules/library/render/src/main/java/org/geotools/renderer/lite/gridcoverage2d/GridGeometryReducer.java#L86

It is comparing the values of two envelopes, however they are not 
necessarily in the same CRS.

validArea is always just WGS84 (see 
https://github.com/geotools/geotools/blob/master/modules/library/render/src/main/java/org/geotools/renderer/crs/ProjectionHandler.java#L106)

gg.getEnvelope() is in the native CRS of the coverage.

Is this a bug or am I missing something?

Kind Regards,
Niels


--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Support two dimensional NetCDF coordinate variables

[Niels Charlier]

Hello Iain,

Unfortunately I am also very new at netcdf :) But it would be great if 
we could work together on this.

It sounds like we are definitely going to need this feature... For us it 
is to have a 2D time coordinate that includes a runtime dimension. I am 
going to do more investigations on the implications for the code in the 
geotools plugin and get back to you.

Regards
Niels

On 12-10-16 12:30, Iain Matcham wrote:
> Hi Niels,
>
> I would be happy to work on this together with you.  Sounds like we 
> have a similar situation of "would like it but can't justify the work 
> right now" :)  I will talk to my boss tomorrow and see if I can use 
> some time to progress this in the near future.
>
> It's been a while since I looked at this, but from memory:
>
> The axes' data are being read fine by netcdf-java, but when the 
> geotools reader parses the file looking for quantities that are 
> eligible for axes, it does not consider anything that is not 
> one-dimensional, thus discarding the true axes in the two-dimensional 
> axis files.
>
> The solution that I had mapped out in my head (that's as far as it 
> got) would be to capture the eligible zero dimensional quantities 
> (rlat,rlon), check for matching two dimensional quantities and if they 
> exist, make them eligible as axes as well. It would require some 
> reworking or extension of the axis definitions as they have a bunch of 
> code checking for regularity which would have to be completely 
> reimagined for two-dim files.
>
> I only really got as far as the investigation and conceptual stage, so 
> there may of course be other complications that I haven't discovered 
> yet.  Also I'm not a netcdf expert ( my first main investigation of 
> the format was this exercise), so you may be able to improve on this!
>
> Kind regards
>
> Iain
>
>
> On 12/10/2016 11:13 p.m., Niels Charlier wrote:
>> Hello Iain,
>>
>> Thank you for your response.
>> It looks like I might need to work on this as well. Perhaps we can 
>> work on it together. But we are still investigating whether we really 
>> need it or not, so I will let you know.
>> I would like to know what you found out in your investigation stage 
>> about the problem. I would expect that changes need to be made to 
>> netcdf-java to support it as well?
>>
>> Kind Regards
>> Niels
>>
>> On 05-10-16 11:55, Iain Matcham wrote:
>>> Hi Niels,
>>>
>>> I did start the work, but then it got down-prioritised at my end, so I
>>> never got much part the preliminary investigation stage.
>>>
>>> As there had been no indication of any interest from my original email
>>> to the list, once my management decided other things were more 
>>> important
>>> I didn't push to keep going on this.  But if this is a feature that you
>>> or others think is worthwhile I am more than happy push my 
>>> management to
>>> be allowed to continue my work on this.
>>>
>>> Thanks
>>> Iain
>>>
>>> On 5/10/2016 10:18 p.m., Niels Charlier wrote:
>>>> Hello Iain,
>>>>
>>>> Did you ever carry out your plans to support two dimension coordinate
>>>> variables?
>>>>
>>>> Kind Regards
>>>>
>>>> Niels
>>>>
>>>>
>>>> On 06/20/2016 04:55 AM, Iain Matcham wrote:
>>>>> Hi
>>>>>
>>>>> I have a number of netcdf files that I am trying to read with
>>>>> gt-netcdf.  However they use two dimensional coordinate variables as
>>>>> described here:
>>>>> http://cfconventions.org/cf-conventions/cf-conventions.html#_two_dimensional_latitude_longitude_coordinate_variables
>>>>>  
>>>>>
>>>>>
>>>>> I understand that gt-netcdf does not currently support these and am
>>>>> happy to look into extending it to do so, but wanted to check 
>>>>> beforehand
>>>>> if this is a good idea or if there are any political or other factors
>>>>> that I might want to consider before diving into this.
>>>>>
>>>>> Thanks
>>>>> Iain
>>>>>
>>>> --
>>>>  
>>>>
>>>> Check out the vibrant tech community on one of the world's most
>>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>>>> ___
>>>> GeoTools-Devel mailing list
>>>> GeoTools-Devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>
>>
>


--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Support two dimensional NetCDF coordinate variables

[Niels Charlier]

Hello Iain,

Thank you for your response.
It looks like I might need to work on this as well. Perhaps we can work 
on it together. But we are still investigating whether we really need it 
or not, so I will let you know.
I would like to know what you found out in your investigation stage 
about the problem. I would expect that changes need to be made to 
netcdf-java to support it as well?

Kind Regards
Niels

On 05-10-16 11:55, Iain Matcham wrote:
> Hi Niels,
>
> I did start the work, but then it got down-prioritised at my end, so I
> never got much part the preliminary investigation stage.
>
> As there had been no indication of any interest from my original email
> to the list, once my management decided other things were more important
> I didn't push to keep going on this.  But if this is a feature that you
> or others think is worthwhile I am more than happy push my management to
> be allowed to continue my work on this.
>
> Thanks
> Iain
>
> On 5/10/2016 10:18 p.m., Niels Charlier wrote:
>> Hello Iain,
>>
>> Did you ever carry out your plans to support two dimension coordinate
>> variables?
>>
>> Kind Regards
>>
>> Niels
>>
>>
>> On 06/20/2016 04:55 AM, Iain Matcham wrote:
>>> Hi
>>>
>>> I have a number of netcdf files that I am trying to read with
>>> gt-netcdf.  However they use two dimensional coordinate variables as
>>> described here:
>>> http://cfconventions.org/cf-conventions/cf-conventions.html#_two_dimensional_latitude_longitude_coordinate_variables
>>>
>>> I understand that gt-netcdf does not currently support these and am
>>> happy to look into extending it to do so, but wanted to check beforehand
>>> if this is a good idea or if there are any political or other factors
>>> that I might want to consider before diving into this.
>>>
>>> Thanks
>>> Iain
>>>
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>> ___
>> GeoTools-Devel mailing list
>> GeoTools-Devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geotools-devel



--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] [netcdf-java] runtime aggregation

[Niels Charlier]

Hello Daniele,

In the meantime, I have gotten feedback from the netcdf-java community 
that it is up to the user to put the aggregated files in the proper order.


That still leaves us with the lack of support for decreasing order in 
geotools. I made a patch and added it to my aggregation support pull 
request:


https://github.com/geotools/geotools/pull/1296/commits/88bc830e570d805a3cd338e2d8dc2abde8d4fab7

https://github.com/geotools/geotools/pull/1296

Regards
Niels

On 30-09-16 12:24, Niels Charlier wrote:

Hi Daniele,

Did you have any more comments on my last email?  Would it make sense 
to convert all Strings to Dates, and sort them , in order to find the 
minimum and maximum? Isn't that a bit expensive (and repetitive) for 
those two methods (you'd be doing it twice while doing it once 
provides all info)? should we perhaps convert and sort all values once 
and store them that way? But that may cause other unwanted side 
effects if they are not in the same order any more as they are in the 
netcdf-java objects (I am not that familiar with the code yet).


Actually, I am now thinking, the fault lies actually with both 
geotools and netcdf-java.
* geotools should be taking into account that the time values might be 
decreasing rather than increasing and should thus, just like 
CoordinateAxis1D.java#L286 
<https://github.com/Unidata/thredds/blob/5.0.0/cdm/src/main/java/ucar/nc2/dataset/CoordinateAxis1D.java#L286>, 
take the maximum/minimum of both _extremes_.
* I think netcdf-java, *at the moment of aggregation, *should 
aggregate the different files in the right order (be it increasing or 
decreasing). I have sent an email to their email list about that.


Do you agree? What are your thoughts?

Regards
Niels

On 28-09-16 13:44, Niels Charlier wrote:
Yeah, still that implies that the order of the files specified in the 
aggregation must be the same as the order of values for the 
aggregated dimension inside those files themselves. I can find no 
such specification though, but maybe I am missing it. It seems that 
in the examples on 
http://www.unidata.ucar.edu/software/thredds/current/netcdf-java/ncml/Aggregation.html, 
the files are always specified in order.


Otherwise we have to the rather expensive operation of going through 
all of the Strings,convert them to Dates, then find the 
minimum/maximum for each time getMimimum() and getMaximum() is 
called. But then again, I wonder if we shouldn't do the same for 
non-time values (regular CoordinateValue).


What do you think?

Regards
Niels

On 28-09-16 11:41, Daniele Romagnoli wrote:

Hi Niels,

On Wed, Sep 28, 2016 at 11:05 AM, Niels Charlier <ni...@scitus.be 
<mailto:ni...@scitus.be>> wrote:


On 23-09-16 17:03, Daniele Romagnoli wrote:

I think that once the aggregation is in place, times can be in
any order as you reported, so I think it's time to revisit the
timeVariable min/max computation (not sure there are other
methods around based on that supposition. I didn't check it yet).

Although, it seems that in netcdf-java's
CoordinateAxis1D.getMinValue() en
CoordinateAxis1D.getMaxValue(), an assumption is made that the
extremes are at the beginning and end.

Good catch. Are you referring to this?
https://github.com/Unidata/thredds/blob/5.0.0/cdm/src/main/java/ucar/nc2/dataset/CoordinateAxis1D.java#L286
https://github.com/Unidata/thredds/blob/5.0.0/cdm/src/main/java/ucar/nc2/dataset/CoordinateAxis1D.java#L295

It does take into account the order may be decreasing as well as
increasing, but not random.

Perhaps we should remain consistent with that?

I would say yes.
Cheers,
Daniele


Regards
Niels




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

Ing. Daniele Romagnoli
Senior Software Engineer

GeoSolutions S.A.S.
Via di Montramito 3/A
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax:  +39 0584 1660272

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

---

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica 
e/o nel/i file/s allegato/i sono da considerarsi strettamente 
riservate. Il loro utilizzo è consentito esclusivamente al 
destinatario del messaggio, per le finalità indicate nel messaggio 
stesso. Qualora riceviate questo messaggio senza esserne il 
destinatario, Vi preghiamo cortesemente di darcene notizia via 
e-mail e di procedere alla distruzione del messaggio stesso, 
cancellandolo dal Vostro sistema. Conservare il messaggio stesso, 
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, 
od utilizzarlo per finalità diverse, costituisce comportamento 
contrario ai principi dettati dal D.Lgs. 196/2003.


The information in this message and/or attachments, is intended 
solely for the attention and use of the named addressee(s) and may 
be confident

Re: [Geotools-devel] Support two dimensional NetCDF coordinate variables

[Niels Charlier]

Hello Iain,

Did you ever carry out your plans to support two dimension coordinate 
variables?

Kind Regards

Niels


On 06/20/2016 04:55 AM, Iain Matcham wrote:
> Hi
>
> I have a number of netcdf files that I am trying to read with
> gt-netcdf.  However they use two dimensional coordinate variables as
> described here:
> http://cfconventions.org/cf-conventions/cf-conventions.html#_two_dimensional_latitude_longitude_coordinate_variables
>
> I understand that gt-netcdf does not currently support these and am
> happy to look into extending it to do so, but wanted to check beforehand
> if this is a good idea or if there are any political or other factors
> that I might want to consider before diving into this.
>
> Thanks
> Iain
>


--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] [netcdf-java] runtime aggregation

[Niels Charlier]

Hi Daniele,

Did you have any more comments on my last email?  Would it make sense to 
convert all Strings to Dates, and sort them , in order to find the 
minimum and maximum? Isn't that a bit expensive (and repetitive) for 
those two methods (you'd be doing it twice while doing it once provides 
all info)? should we perhaps convert and sort all values once and store 
them that way? But that may cause other unwanted side effects if they 
are not in the same order any more as they are in the netcdf-java 
objects (I am not that familiar with the code yet).


Actually, I am now thinking, the fault lies actually with both geotools 
and netcdf-java.
* geotools should be taking into account that the time values might be 
decreasing rather than increasing and should thus, just like 
CoordinateAxis1D.java#L286 
<https://github.com/Unidata/thredds/blob/5.0.0/cdm/src/main/java/ucar/nc2/dataset/CoordinateAxis1D.java#L286>, 
take the maximum/minimum of both _extremes_.
* I think netcdf-java, *at the moment of aggregation, *should aggregate 
the different files in the right order (be it increasing or decreasing). 
I have sent an email to their email list about that.


Do you agree? What are your thoughts?

Regards
Niels

On 28-09-16 13:44, Niels Charlier wrote:
Yeah, still that implies that the order of the files specified in the 
aggregation must be the same as the order of values for the aggregated 
dimension inside those files themselves. I can find no such 
specification though, but maybe I am missing it. It seems that in the 
examples on 
http://www.unidata.ucar.edu/software/thredds/current/netcdf-java/ncml/Aggregation.html, 
the files are always specified in order.


Otherwise we have to the rather expensive operation of going through 
all of the Strings,convert them to Dates, then find the 
minimum/maximum for each time getMimimum() and getMaximum() is called. 
But then again, I wonder if we shouldn't do the same for non-time 
values (regular CoordinateValue).


What do you think?

Regards
Niels

On 28-09-16 11:41, Daniele Romagnoli wrote:

Hi Niels,

On Wed, Sep 28, 2016 at 11:05 AM, Niels Charlier <ni...@scitus.be 
<mailto:ni...@scitus.be>> wrote:


On 23-09-16 17:03, Daniele Romagnoli wrote:

I think that once the aggregation is in place, times can be in
any order as you reported, so I think it's time to revisit the
timeVariable min/max computation (not sure there are other
methods around based on that supposition. I didn't check it yet).

Although, it seems that in netcdf-java's
CoordinateAxis1D.getMinValue() en CoordinateAxis1D.getMaxValue(),
an assumption is made that the extremes are at the beginning and
end.

Good catch. Are you referring to this?
https://github.com/Unidata/thredds/blob/5.0.0/cdm/src/main/java/ucar/nc2/dataset/CoordinateAxis1D.java#L286
https://github.com/Unidata/thredds/blob/5.0.0/cdm/src/main/java/ucar/nc2/dataset/CoordinateAxis1D.java#L295

It does take into account the order may be decreasing as well as
increasing, but not random.

Perhaps we should remain consistent with that?

I would say yes.
Cheers,
Daniele


Regards
Niels




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

Ing. Daniele Romagnoli
Senior Software Engineer

GeoSolutions S.A.S.
Via di Montramito 3/A
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax:  +39 0584 1660272

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

---

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica 
e/o nel/i file/s allegato/i sono da considerarsi strettamente 
riservate. Il loro utilizzo è consentito esclusivamente al 
destinatario del messaggio, per le finalità indicate nel messaggio 
stesso. Qualora riceviate questo messaggio senza esserne il 
destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail 
e di procedere alla distruzione del messaggio stesso, cancellandolo 
dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche 
in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo 
per finalità diverse, costituisce comportamento contrario ai principi 
dettati dal D.Lgs. 196/2003.


The information in this message and/or attachments, is intended 
solely for the attention and use of the named addressee(s) and may be 
confidential or proprietary in nature or covered by the provisions of 
privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New 
Data Protection Code).Any use not in accord with its purpose, any 
disclosure, reproduction, copying, distribution, or either 
dissemination, either whole or partial, is strictly forbidden except 
previous formal approval of the named addressee(s). If you are not 
the intended recipient, please contact immediately the sender by 
telephone, fax or e-mail and delete the information in this

Re: [Geotools-devel] [netcdf-java] runtime aggregation

[Niels Charlier]

Yeah, still that implies that the order of the files specified in the 
aggregation must be the same as the order of values for the aggregated 
dimension inside those files themselves. I can find no such 
specification though, but maybe I am missing it. It seems that in the 
examples on 
http://www.unidata.ucar.edu/software/thredds/current/netcdf-java/ncml/Aggregation.html, 
the files are always specified in order.


Otherwise we have to the rather expensive operation of going through all 
of the Strings,convert them to Dates, then find the minimum/maximum for 
each time getMimimum() and getMaximum() is called. But then again, I 
wonder if we shouldn't do the same for non-time values (regular 
CoordinateValue).


What do you think?

Regards
Niels

On 28-09-16 11:41, Daniele Romagnoli wrote:

Hi Niels,

On Wed, Sep 28, 2016 at 11:05 AM, Niels Charlier <ni...@scitus.be 
<mailto:ni...@scitus.be>> wrote:


On 23-09-16 17:03, Daniele Romagnoli wrote:

I think that once the aggregation is in place, times can be in
any order as you reported, so I think it's time to revisit the
timeVariable min/max computation (not sure there are other
methods around based on that supposition. I didn't check it yet).

Although, it seems that in netcdf-java's
CoordinateAxis1D.getMinValue() en CoordinateAxis1D.getMaxValue(),
an assumption is made that the extremes are at the beginning and end.

Good catch. Are you referring to this?
https://github.com/Unidata/thredds/blob/5.0.0/cdm/src/main/java/ucar/nc2/dataset/CoordinateAxis1D.java#L286
https://github.com/Unidata/thredds/blob/5.0.0/cdm/src/main/java/ucar/nc2/dataset/CoordinateAxis1D.java#L295

It does take into account the order may be decreasing as well as
increasing, but not random.

Perhaps we should remain consistent with that?

I would say yes.
Cheers,
Daniele


Regards
Niels




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

Ing. Daniele Romagnoli
Senior Software Engineer

GeoSolutions S.A.S.
Via di Montramito 3/A
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax:  +39 0584 1660272

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

---

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica e/o 
nel/i file/s allegato/i sono da considerarsi strettamente riservate. 
Il loro utilizzo è consentito esclusivamente al destinatario del 
messaggio, per le finalità indicate nel messaggio stesso. Qualora 
riceviate questo messaggio senza esserne il destinatario, Vi preghiamo 
cortesemente di darcene notizia via e-mail e di procedere alla 
distruzione del messaggio stesso, cancellandolo dal Vostro sistema. 
Conservare il messaggio stesso, divulgarlo anche in parte, 
distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità 
diverse, costituisce comportamento contrario ai principi dettati dal 
D.Lgs. 196/2003.


The information in this message and/or attachments, is intended solely 
for the attention and use of the named addressee(s) and may be 
confidential or proprietary in nature or covered by the provisions of 
privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New 
Data Protection Code).Any use not in accord with its purpose, any 
disclosure, reproduction, copying, distribution, or either 
dissemination, either whole or partial, is strictly forbidden except 
previous formal approval of the named addressee(s). If you are not the 
intended recipient, please contact immediately the sender by 
telephone, fax or e-mail and delete the information in this message 
that has been received in error. The sender does not give any warranty 
or accept liability as the content, accuracy or completeness of sent 
messages and accepts no responsibility  for changes made after they 
were sent or for other risks which arise as a result of e-mail 
transmission, viruses, etc.





--
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] [netcdf-java] runtime aggregation

[Niels Charlier]

On 23-09-16 17:03, Daniele Romagnoli wrote:
I think that once the aggregation is in place, times can be in any 
order as you reported, so I think it's time to revisit the 
timeVariable min/max computation (not sure there are other methods 
around based on that supposition. I didn't check it yet).
Although, it seems that in netcdf-java's CoordinateAxis1D.getMinValue() 
en CoordinateAxis1D.getMaxValue(), an assumption is made that the 
extremes are at the beginning and end. It does take into account the 
order may be decreasing as well as increasing, but not random. Perhaps 
we should remain consistent with that?


Regards
Niels
--
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [JIRA] (GEOT-5528) NetCDF ncml list of aggregated files must be in order

[Niels Charlier (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Niels Charlier created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 GeoTools /  GEOT-5528  
 
 
  NetCDF ncml list of aggregated files must be in order   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Assignee: 
 Niels Charlier  
 
 
Components: 
 netcdf  
 
 
Created: 
 27/Sep/16 3:23 PM  
 
 
Priority: 
  Medium  
 
 
Reporter: 
 Niels Charlier  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v1000.375.1#100014-sha1:51c0833

Re: [Geotools-devel] netcdf runtime dimension question

[Niels Charlier]

Hi Daniele,

Thanks for your answer. I understand it better now.

My first goal was to get these aggregation files actually published. I 
can publish them by ignoring the runtime dimension, but of course, that 
does not create actual support to query the dimension. That is a way 
bigger task, that is going to involve a lot more work. I will discuss 
how to move forward.


Niels


On 23-09-16 15:36, Daniele Romagnoli wrote:

Hi Niels,
Nuno fixed a bug in the NetCDF machinery a couple of days ago. (I have 
merged that PR right now).
At the very beginning of the NetCDF development, we started to support 
what was able with the available NetCDF version (I thin 2.x or 
something similar... a very old one).
Therefore the NetCDF reader also internally deal with a binary index 
containing Time,Zeta based indexes for quick slices retrieval.


https://github.com/geotools/geotools/blob/master/modules/plugin/coverage-multidim/netcdf/src/main/java/org/geotools/imageio/netcdf/Slice2DIndex.java


Basically, re-using the table I have put in the JIRA, for each 2D pair 
a global index may be defined:

global Index =(Time index, Zeta Index)
0 = (0,0)
1 = (0,1)
2 = (0,2)
3 = (1,0)
4 = (1,1)
5 = (1,2)
6 = (2,0)
7 = (2,1)
8 = (2,2)
9 = (3,0)
10= (3,1)
11= (3,2)


The NetCDF internal catalog is similar to the ImageMosaic GranuleCatalog.
For each 2D slice available, it stores a global index, as well as the 
timestamp/date (it T dimension is available) and the elevation value 
(it Z dimension is available) related to that imageIndex.

(https://github.com/geotools/geotools/blob/master/modules/plugin/coverage-multidim/coverage-api/src/main/java/org/geotools/coverage/io/catalog/CoverageSlicesCatalog.java)

So, when requesting a read operation on a specific time and specific 
elevation, the reader performs a query on the CoverageSlicesCatalog to 
get the related imageIndex.
Then the imageIndex is provided to the Slice2DIndexManager in order to 
get the proper integer indexes to be used as values for the 
Section/Ranges to be provided to the underlying UCAR reader.


https://github.com/geotools/geotools/blob/master/modules/plugin/coverage-multidim/netcdf/src/main/java/org/geotools/imageio/netcdf/NetCDFImageReader.java#L584

https://github.com/geotools/geotools/blob/master/modules/plugin/coverage-multidim/netcdf/src/main/java/org/geotools/imageio/netcdf/NetCDFImageReader.java#L651-L658

We also thought about revisiting/removing the binary index machinery 
and include it somehow this information in the CoverageSlicesCatalog 
itself and investigate on the indexing objects automatically generated 
by the UCAR library. However we never had time or resources to work on 
that.
Therefore, right now, an additional real dimension for runtime isn't 
fully supported. (We somehow support different runtimes for different 
NetCDF through ImageMosaic store). Not sure to remember from which 
version UCAR started exposing it as a separate dimension.
You may want to extend the Slice2DIndex machinery or remove that in 
favor of a better management of additional dimensions.


Does it helps?
Cheers,
Daniele







On Fri, Sep 23, 2016 at 2:34 PM, Niels Charlier <ni...@scitus.be 
<mailto:ni...@scitus.be>> wrote:


Hello Daniele,

As you know, I am working on support for aggregation on runtime
dimension in netcdf. I am now looking into what needs to happen in
VariableAdaptor.
I am very new at netcdf, so I do not yet understand everything
that is happening to the fullest extent in this class.

I have found a way to make it work, basically by ignoring the
runtime dimension altogether. Apart from adding it as an ignored
dimension, I also had to take into account the possibility of
there being four dimensions of which one is the runtime dimension.

This is the commit:

https://github.com/NielsCharlier/geotools/commit/5278115bd43a77c6509881d59a582e69c8bbe182

<https://github.com/NielsCharlier/geotools/commit/5278115bd43a77c6509881d59a582e69c8bbe182>

The aggregation files now pass and I can publish the layers. But I
am still wondering if this is the right approach. Or should
perhaps the runtime dimension be treated in the same way as the t-
and z-dimensions? Or should there  actually be logic in
VariableAdaptor for the R-dimension, similar to the logic that
exists for the Z- and T-dimensions?

What is your opinion? Thanks for your assistance.

Kind Regards,
Niels




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

Ing. Daniele Romagnoli
Senior Software Engineer

GeoSolutions S.A.S.
Via di Montramito 3/A
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax:  +39 0584 1660272

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

---

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta el

Re: [Geotools-devel] [netcdf-java] runtime aggregation

[Niels Charlier]

HI Daniele,

Thank you for your quick response.

Two remarks though

- I do seem to get from your explanation that it can also be decreasing 
rather than increasing, which means it should at least be possible to 
work the other way around, which was the case here. There are only two 
files, the latest in time is first. So at least the maximum/minimum of 
the two extremes should be picked.


- I understand this is a convention for variables in general. But does 
this however count also for the order in which aggregated files are 
listed in an aggregation with an already pre-existing dimension (which 
is the case here)? Perhaps the issue is somewhere else in the code, and 
the values should be sorted after reading the list of files.


Kind Regards
Niels

On 23-09-16 15:50, Daniele Romagnoli wrote:

Hi Niels,


On Fri, Sep 23, 2016 at 2:40 PM, Niels Charlier <ni...@scitus.be 
<mailto:ni...@scitus.be>> wrote:


Simone, Daniele,

Do you have an opinion on point (3) of this email?

It seems that one of you have written the code that expects a
chronological order of listed aggregation files.

The logic is in

https://github.com/geotools/geotools/blob/master/modules/plugin/coverage-multidim/netcdf/src/main/java/org/geotools/imageio/netcdf/cv/TimeCoordinateVariable.java

<https://github.com/geotools/geotools/blob/master/modules/plugin/coverage-multidim/netcdf/src/main/java/org/geotools/imageio/netcdf/cv/TimeCoordinateVariable.java>
The getMinimum() and getMaximum() methods.

The problem could easily be resolved by searching for the minimum
and maximum rather than expecting a certain order.
I can't find anything in the specs that says they should be in
order, so would you agree if I changed it to that regards?


I think that we developed this based on a best practice for the 
NetCDF, assuming that coordinate axis/coordinate variables are monotonic.

https://www.unidata.ucar.edu/software/netcdf/docs/BestPractices.html

Quoting the CoordinateSystems section:

/A ***coordinate variable*** is a one-dimensional variable with the 
same name as a dimension, which names the coordinate values of the 
dimension. It must not have any missing data (for example, no 
|_FillValue| or |missing_value| attributes) *and must be strictly 
monotonic (values increasing or decreasing).*

/
/
/
However I'm not against that improvement provided that the time to 
index mapping still work and the search isn't too much expensive 
(maybe we should cache the min and the max?).


Cheers,
Daniele


Niels


On 08-09-16 14:51, Niels Charlier wrote:

Ben, Sean,

I am also including the geotools list in the discussion, because
it regards both libraries.

I got the aggregation file to work. Apart from some obvious bug
fixes and additions to support the "runtime" dimension in
geotools, I had to make a few changes to the xml file.
What is still unclear to me is whether these changes
- are actually required to work (i.e. the aggregation file is
faulty). in that case we need to work on better error reporting
in geotools (possibly also in netcdf-java)
- should not actually be required, in which case we need to fix
these as bugs in either geotools or netcdf-java

I have included the .ncml file in the attachment to demonstrate.
There are three such changes I made:

1. the Conventions global attribute,as discussed before.

2. removal of the "time" variable in the aggregation (see
commented line in attached .ncml file)

This issue is related to the previous one, it is again about
/makeCoordinateSystemsImplicit/ versus
/makeCoordinateSystemsMaximal/.

* If the "time" variable is included as aggregation variable,
it also gets the "runtime" dimension added to its dimensions.
* As a consequence, netcdf-java does not recognise it as an AXIS.
* As a consequence, /makeCoordinateSystemsImplicit /fails to
include it in the CRS's for the actual variables (water_u,
salinity, etc...).
* As a consequence, /makeCoordinateSystemsMaximal /creates a
CRS for these variables. However, it puts the dimensions in the
order of the /dimension variable/ list
   (rather than the variable's own dimensions), which is
completely arbitrary as far as I can see.
* "runtime" ends up as the last axis instead of the first.
This is inconsistent with the order of dimensions in the
variable. Geotools fails on this inconsistency.

I am not sure whether the fault here lies with the .ncml
file, geotools or netcdf-java.


3. changing the order of the list of files in the inner
aggregation tags.
http://hycom_glb_regp01_old_t003.nc>"/>  http://hycom_glb_regp01_old_t000.nc>"/>
instead of  http://hycom_glb_regp01_old_t000.nc>

[Geotools-devel] netcdf runtime dimension question

[Niels Charlier]

Hello Daniele,

As you know, I am working on support for aggregation on runtime 
dimension in netcdf. I am now looking into what needs to happen in 
VariableAdaptor.
I am very new at netcdf, so I do not yet understand everything that is 
happening to the fullest extent in this class.

I have found a way to make it work, basically by ignoring the runtime 
dimension altogether. Apart from adding it as an ignored dimension, I 
also had to take into account the possibility of there being four 
dimensions of which one is the runtime dimension.

This is the commit: 
https://github.com/NielsCharlier/geotools/commit/5278115bd43a77c6509881d59a582e69c8bbe182

The aggregation files now pass and I can publish the layers. But I am 
still wondering if this is the right approach. Or should perhaps the 
runtime dimension be treated in the same way as the t- and z-dimensions? 
Or should there  actually be logic in VariableAdaptor for the 
R-dimension, similar to the logic that exists for the Z- and T-dimensions?

What is your opinion? Thanks for your assistance.

Kind Regards,
Niels


--
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] netcdf issue: VariableAdapter returns wrong time index

[Niels Charlier]

See https://osgeo-org.atlassian.net/browse/GEOT-5515

Consider the following line in VariableAdapter

https://github.com/geotools/geotools/blob/master/modules/plugin/coverage-multidim/netcdf/src/main/java/org/geotools/imageio/netcdf/VariableAdapter.java#L1100

as compared to

https://github.com/geotools/geotools/blob/master/modules/plugin/coverage-multidim/netcdf/src/main/java/org/geotools/imageio/netcdf/VariableAdapter.java#L1076

I believe that, in the getTIndex method, tDimensionsIndex should be used 
instead of zDimensionIndex.


I wanted to ask the module maintainers: what kind of test coverage would 
you expect for this change? Currently this class is not being tested in 
an isolated way, and neither of these two methods are ever called from 
any of the unit tests. I kindly ask for your advise.



Kind Regards
Niels
--
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] App-Schema: Encoding of Filters on Nested Attributes

[Niels Charlier]

Stefano,

Indeed, that makes sense, the optimiser should indeed do the work for 
you. It's good to see there are vast performance improvements. Good work!


Regards
Niels

On 09/13/2016 10:04 PM, Stefano Costa wrote:

Hi Niels,
we went with the "where exists" subquery approach because it was 
easier to translate filters to SQL that way. For example, let's think 
of a filter which is actually a logical combination (OR / AND) of 
multiple filters; each filter could refer to a completely different 
feature chain, and thus, one would have to go trough all the filters 
first to determine the global list of tables that should be joined, 
and then logically combine the WHERE clauses. Using the subquery 
approach felt more natural (at least from a human perspective), it 
allowed us to translate each filter separately and then logically 
combine the translated SQL fragments in a straightforward way.


Performance-wise, I don't expect a big difference, as optimizers 
should be smart enough to translate a WHERE EXISTS subquery into a 
join if needed; I have not done any real performance comparison 
between the two approaches though.


Does this make sense to you?


On Tue, Sep 13, 2016 at 11:17 AM, Niels Charlier <ni...@scitus.be 
<mailto:ni...@scitus.be>> wrote:


Hi Stefano,

I think it is great you added that feature! A vast improvement to
the work that I always had hoped would still be developed.

Out of curiosity, why did you choose the "where exists" clauses
rather than the simple joins that I suggested? You think it has
better performance (I would expect worse on first glance, but more
probably the same because of optimiser),
or was it easier to construct the queries this way?

Kind Regards
Niels


On 11-09-16 16:56, Stefano Costa wrote:

Hi all, I'm writing to solicit feedback from the community about
an improvement to App-Schema's joining implementation that we
have been working on lately. In short, we would like to introduce
support for the SQL encoding of filters on nested attributes,
which, in the current implementation, end up in the post-filter
and are evaluated in memory, after all the features have been
loaded. For those who might be unfamiliar with it, the inner
workings of the current joining implementation are clearly
    illustrated by Niels Charlier in this presentation:

https://www.seegrid.csiro.au/wiki/pub/Infosrvices/GeoserverAppSchemaJoining/joining_presentation.pdf

<https://www.seegrid.csiro.au/wiki/pub/Infosrvices/GeoserverAppSchemaJoining/joining_presentation.pdf>
The aforementioned presentation mentions the fact that filtering
on nested attributes is "currently done with post-filtering", and
suggests a possible strategy for translating them to SQL. What we
have implemented so far is a slight variation of the approach
suggested by Niels. Let's take GeoSciML's MappedFeature
(container) and GeologicUnit (nested) features as example. The
following filter on the gml:description attribute of the nested
GeologicUnit type: 

gsml:specification/gsml:GeologicUnit/gml:description
*sedimentary* 
would be ignored by the current joining implementation (i.e. it
is regarded as a post-filter): SELECT ... FROM
"appschematest"."MAPPEDFEATURE" ORDER BY
"appschematest"."MAPPEDFEATURE"."ID" ASC,
"appschematest"."MAPPEDFEATURE"."PKEY" SELECT ... FROM
"appschematest"."GEOLOGICUNIT" INNER JOIN
"appschematest"."MAPPEDFEATUREPROPERTYFILE" ON (
"MAPPEDFEATUREPROPERTYFILE"."GEOLOGIC_UNIT_ID" =
"GEOLOGICUNIT"."GML_ID") ORDER BY
"appschematest"."MAPPEDFEATUREPROPERTYFILE"."ID" ASC,
"appschematest"."GEOLOGICUNIT"."GML_ID" ASC,
"appschematest"."GEOLOGICUNIT"."PKEY" but would be translated to
the following SQL queries in the new implementation: SELECT ...
FROM "appschematest"."MAPPEDFEATURE" INNER JOIN ( SELECT DISTINCT
"ID" FROM "appschematest"."
MAPPEDFEATURE"
*WHERE EXISTS (*
* SELECT "chain_link_1"."PKEY" FROM "appschematest"."GEOLOGICUNIT"
"chain_link_1" *
* WHERE UPPER("chain_link_1"."TEXTDESCRIPTION") LIKE '%SEDIMENTARY%'  AND
"appschematest"."MAPPEDFEATURE"."GEOLOGIC_UNIT_ID" =
"chain_link_1"."GML_ID")*
) "temp_alias_used_for_filter" ON ( "MAPPEDFEATURE"."ID" =
"temp_alias_used_for_filter"."ID" )
ORDER BY "appschematest"."MAPPEDFEATURE"."ID"

Re: [Geotools-devel] App-Schema: Encoding of Filters on Nested Attributes

[Niels Charlier]

Hi Stefano,

I think it is great you added that feature! A vast improvement to the 
work that I always had hoped would still be developed.


Out of curiosity, why did you choose the "where exists" clauses rather 
than the simple joins that I suggested? You think it has better 
performance (I would expect worse on first glance, but more probably the 
same because of optimiser),

or was it easier to construct the queries this way?

Kind Regards
Niels

On 11-09-16 16:56, Stefano Costa wrote:

Hi all,
I'm writing to solicit feedback from the community about an improvement to
App-Schema's joining implementation that we have been working on lately.

In short, we would like to introduce support for the SQL encoding of
filters on nested attributes, which, in the current implementation, end up
in the post-filter and are evaluated in memory, after all the features have
been loaded.
For those who might be unfamiliar with it, the inner workings of the
current joining implementation are clearly illustrated by Niels Charlier in
this presentation:
https://www.seegrid.csiro.au/wiki/pub/Infosrvices/GeoserverAppSchemaJoining/joining_presentation.pdf

The aforementioned presentation mentions the fact that filtering on nested
attributes is "currently done with post-filtering", and suggests a possible
strategy for translating them to SQL.

What we have implemented so far is a slight variation of the approach
suggested by Niels.

Let's take GeoSciML's MappedFeature (container) and GeologicUnit (nested)
features as example.
The following filter on the gml:description attribute of the nested
GeologicUnit type:



gsml:specification/gsml:GeologicUnit/gml:description
   *sedimentary*


would be ignored by the current joining implementation (i.e. it is regarded
as a post-filter):

SELECT ...
FROM "appschematest"."MAPPEDFEATURE"
ORDER BY "appschematest"."MAPPEDFEATURE"."ID" ASC,
"appschematest"."MAPPEDFEATURE"."PKEY"

SELECT ...
FROM "appschematest"."GEOLOGICUNIT"
INNER JOIN "appschematest"."MAPPEDFEATUREPROPERTYFILE" ON (
"MAPPEDFEATUREPROPERTYFILE"."GEOLOGIC_UNIT_ID" = "GEOLOGICUNIT"."GML_ID")
ORDER BY "appschematest"."MAPPEDFEATUREPROPERTYFILE"."ID" ASC,
"appschematest"."GEOLOGICUNIT"."GML_ID" ASC,
"appschematest"."GEOLOGICUNIT"."PKEY"


but would be translated to the following SQL queries in the new
implementation:

SELECT ...
FROM "appschematest"."MAPPEDFEATURE"
INNER JOIN (
SELECT DISTINCT "ID" FROM "appschematest"."MAPPEDFEATURE"
*WHERE EXISTS (*
* SELECT "chain_link_1"."PKEY" FROM "appschematest"."GEOLOGICUNIT"
"chain_link_1" *
* WHERE UPPER("chain_link_1"."TEXTDESCRIPTION") LIKE '%SEDIMENTARY%'  AND
"appschematest"."MAPPEDFEATURE"."GEOLOGIC_UNIT_ID" =
"chain_link_1"."GML_ID")*
) "temp_alias_used_for_filter" ON ( "MAPPEDFEATURE"."ID" =
"temp_alias_used_for_filter"."ID" )
ORDER BY "appschematest"."MAPPEDFEATURE"."ID" ASC,
"appschematest"."MAPPEDFEATURE"."PKEY"

SELECT ...
FROM "appschematest"."GEOLOGICUNIT"
INNER JOIN "appschematest"."MAPPEDFEATUREPROPERTYFILE" ON (
"MAPPEDFEATUREPROPERTYFILE"."GEOLOGIC_UNIT_ID" = "GEOLOGICUNIT"."GML_ID")
INNER JOIN (
SELECT DISTINCT "ID" FROM "appschematest"."MAPPEDFEATUREPROPERTYFILE"
*WHERE EXISTS (*
* SELECT "chain_link_1"."PKEY" FROM "appschematest"."GEOLOGICUNIT"
"chain_link_1" *
* WHERE UPPER("chain_link_1"."TEXTDESCRIPTION") LIKE '%SEDIMENTARY%'  AND
"appschematest"."MAPPEDFEATUREPROPERTYFILE"."GEOLOGIC_UNIT_ID" =
"chain_link_1"."GML_ID")*
) "temp_alias_used_for_filter" ON ( "MAPPEDFEATUREPROPERTYFILE"."ID" =
"temp_alias_used_for_filter"."ID" )
ORDER BY "appschematest"."MAPPEDFEATUREPROPERTYFILE"."ID" ASC,
"appschematest"."GEOLOGICUNIT"."GML_ID" ASC,
"appschematest"."GEOLOGICUNIT"."PKEY"


We have seen significant performance improvements, especially with the
total number of features in the DB is high (several thousands), but only a
few of them would satisfy the filter.

At present, we don't aim for a comprehensive implementation of nested
filters encoding; as a consequence, our implementation has the following
limitations:
1. only binary comparison, PropertyIsLike and PropertyIs

Re: [Geotools-devel] [netcdf-java] runtime aggregation

[Niels Charlier]

Ben, Sean,

I am also including the geotools list in the discussion, because it 
regards both libraries.


I got the aggregation file to work. Apart from some obvious bug fixes 
and additions to support the "runtime" dimension in geotools, I had to 
make a few changes to the xml file.

What is still unclear to me is whether these changes
- are actually required to work (i.e. the aggregation file is faulty). 
in that case we need to work on better error reporting in geotools 
(possibly also in netcdf-java)
- should not actually be required, in which case we need to fix these as 
bugs in either geotools or netcdf-java


I have included the .ncml file in the attachment to demonstrate. There 
are three such changes I made:


1. the Conventions global attribute,as discussed before.

2. removal of the "time" variable in the aggregation (see commented line 
in attached .ncml file)


This issue is related to the previous one, it is again about 
/makeCoordinateSystemsImplicit/ versus /makeCoordinateSystemsMaximal/.


* If the "time" variable is included as aggregation variable, it 
also gets the "runtime" dimension added to its dimensions.

* As a consequence, netcdf-java does not recognise it as an AXIS.
* As a consequence, /makeCoordinateSystemsImplicit /fails to 
include it in the CRS's for the actual variables (water_u, salinity, 
etc...).
* As a consequence, /makeCoordinateSystemsMaximal /creates a CRS 
for these variables. However, it puts the dimensions in the order of the 
/dimension variable/ list
   (rather than the variable's own dimensions), which is completely 
arbitrary as far as I can see.
* "runtime" ends up as the last axis instead of the first. This is 
inconsistent with the order of dimensions in the variable. Geotools 
fails on this inconsistency.


I am not sure whether the fault here lies with the .ncml file, 
geotools or netcdf-java.



3. changing the order of the list of files in the inner aggregation tags.

 
   instead of

   Otherwise the one with the earliest time coordinates is last in the 
list instead of first... and geotools fails on this. Is this normal?


   This issue is definitely unrelated to netcdf-java, but I am not sure 
whether this is a bug in geotools or in the .ncml file.



Regards
Niels


On 07-09-16 13:23, Niels Charlier wrote:

Ben, Sean,

Changing the Convention has resolved this issue. Thanks both for your 
tips.


I am now dealing with other issues in the same file... will keep you 
updated.


Kind Regards
Niels

On 02-09-16 03:00, Ben Caradoc-Davies wrote:

Niels,

one thing you could try is to change the Conventions global attribute 
of these files to "CF-1.6" to see if this changes the way they are 
handled (if these files are close enough to CF).


Sean, do you expect aggregations to behave the same as single files 
with the same Conventions? It looks like Niels has identified a 
difference.


Kind regards,
Ben.

On 30/08/16 03:29, Sean Arms wrote:

Greetings Niels,

The class DefaultConvention is netCDF-Java's way of trying to handle 
cases
in which a convention is not specified. It tries to be pretty 
forgiving in

terms of files where people have tried to be compliant with some
convention, but didn't set a convention attribute, or knew enough about
some conventions in general to sort of get things in the ball 
park...for
example, setting positive=up on a vertical coordinate, but not 
getting the
rest of the stuff correct (not true for your case, but our code 
tries to

handle the more common case we come across). If a file is actually
following CF, netCDF-Java will use the class CF1Convention. 
Currently we

handle (or try to) around 30 specific conventions (not sure all are
actually documented conventions), but when all else fails, we go to the
default convention.

NcML aggregations in general can get pretty gnarly, and are very 
hard to
get correct. Have you looked into using the Forecast Model Run 
Collection

(FMRC) featureCollection element to serve these data?

https://www.unidata.ucar.edu/software/thredds/current/tds/tutorial/FmrcFeatureCollectionsTutorial.html 



Cheers,

Sean


On Mon, Aug 29, 2016 at 6:11 AM, Niels Charlier <ni...@scitus.be> 
wrote:



Hello,

I am currently working on the netcdf extensions of geotools/geoserver,
although I should say I am fairly new at netcdf, so I am still 
learning. I
am currently trying to get some particular datasets to work with 
geoserver,
and I think I might have hit against some limitations, perhaps even 
a bug,

in netcdf-java, so I wanted to ask you for advice.

We have a .ncml have that aggregate datasets based on 'runtime'. 
This is

an explanation from the client:

*"'runtime' is not a first class coordinate in the data produced by 
our

production groups, so the initial approach to solve this using unidata
mechanisms is to use NCML to aggregate *
*two dataset

[Geotools-devel] [JIRA] (GEOT-5515) NetCDF: VariableAdapter returns wrong time index

[Niels Charlier (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Niels Charlier created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 GeoTools /  GEOT-5515  
 
 
  NetCDF: VariableAdapter returns wrong time index   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Assignee: 
 Unassigned  
 
 
Components: 
 netcdf  
 
 
Created: 
 08/Sep/16 2:37 PM  
 
 
Priority: 
  Medium  
 
 
Reporter: 
 Niels Charlier  
 

  
 
 
 
 

 
 Consider the following block of code in VariableAdapter 

/** 
 
Utility method to retrieve the z-index of a Variable coverageDescriptor stored on 


Unknown macro: {@link NetCDFImageReader} 
 NetCDF Flat Reader  

Unknown macro: {@link HashMap} 
 
 indexMap. 
 
 
@param imageIndex 


Unknown macro: {@link int

[Geotools-devel] [JIRA] (GEOT-5510) Net-cdf doesn't support the runtime dimension

[Niels Charlier (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Niels Charlier created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 GeoTools /  GEOT-5510  
 
 
  Net-cdf doesn't support the runtime dimension   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Assignee: 
 Niels Charlier  
 
 
Components: 
 netcdf  
 
 
Created: 
 05/Sep/16 10:39 AM  
 
 
Priority: 
  Medium  
 
 
Reporter: 
 Niels Charlier  
 

  
 
 
 
 

 
 The Geotools net-cdf module doesn't support the introduction of a runtime dimension in aggregations.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v1000.305.0#100011-sha1:1dc2d9a

[Geotools-devel] [JIRA] (GEOT-5509) Net-cdf doesn't support some date formats

[Niels Charlier (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Niels Charlier created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 GeoTools /  GEOT-5509  
 
 
  Net-cdf doesn't support some date formats   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Assignee: 
 Unassigned  
 
 
Components: 
 netcdf  
 
 
Created: 
 05/Sep/16 10:38 AM  
 
 
Priority: 
  Medium  
 
 
Reporter: 
 Niels Charlier  
 

  
 
 
 
 

 
 Attempting to load the datasets from this page of the official thredds website: 
 
http://www.unidata.ucar.edu/software/thredds/current/netcdf-java/ncml/Aggregation.html 
 Exceptions are thrown because geotools is unable to parse the dates used as reference point of the time dimensions. See the NetCDFUtilities.getAxisFormat method. Unsupported are: 
 
dates starting with a month in letters 
dates with two-digit years 
 both occur in these official dataset samples  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment

Re: [Geotools-devel] wfs-ng vs wfs datastore fight!

[Niels Charlier]

So we are basically done now with all of the remaining WFS-NG technical 
issues raised.


All blocking issues have been resolved and there is a PR pending that 
fixes spatial filters in WFS2.0.


It should be possible now for all users to upgrade easily without any 
major issues.


(see also https://github.com/geotools/geotools/wiki/WFS-to-WFS-NG-upgrade)

Kind Regards
Niels

On 29-07-16 16:00, Niels Charlier wrote:
You're right, I can just put it in main,seeing it already depends on 
wfs-ng.


See https://github.com/geoserver/geoserver/pull/1724

Regards
Niels

On 26-07-16 22:06, Jody Garnett wrote:

Thanks, reviewed merged and closed GEOT-5222.

I am not sure about the test:
- it may be sufficient to copy the test to core (since it is testing 
the functionality of the geoserver catalog)
- it may also be fine as a community module (as you indicated) to 
verify the change of functionality; it can be removed after the 
transition is complete


--
Jody Garnett

On 26 July 2016 at 05:16, Niels Charlier <ni...@scitus.be 
<mailto:ni...@scitus.be>> wrote:


Hi Jody,

I wasn't able this time, I will make up for it next time.

I have new PR for getCount() issue:
https://github.com/geotools/geotools/pull/1252

I also made a branch on my own repo with a community module that
proves backwards compatibility between wfsng and wfs from a
geoserver point of view.
I don't know if this is what @Andrea wanted and if it is sufficient.
I also don't know if it is worth committing this (and creating a
new module just for this little test) or the fact that I did it
is enough:

https://github.com/NielsCharlier/geoserver/tree/wfsng

Regards
Niels



On 26-07-16 04:48, Jody Garnett wrote:

Thanks Niels, I picked up the other wgs-ng patch during the
friday sprint. I was sorry you did not join us as it would  of
been good to collaborate on this.

I am going to start prepping the migration of AbstractDataStore
to a community module in anticipation of your success fixing wfs-ng.

--
Jody Garnett

On 25 July 2016 at 12:35, Niels Charlier <ni...@scitus.be
<mailto:ni...@scitus.be>> wrote:

Hi Jody,

I've added a patch for WFS2.0 in MapServer to the existing PR.

A couple more fixes are coming.

Regards
Niels


On 22-07-16 18:45, Jody Garnett wrote:

Thanks for the positive feedback, Niels has a couple of
pull requests ready and then we should be able to complete
the "migration" ... perhaps later today!

--
Jody Garnett

On 22 July 2016 at 09:12, Pierre Mauduit
<pierre.maud...@camptocamp.com
<mailto:pierre.maud...@camptocamp.com>> wrote:

Hi,


 (perhaps due to lack of use).



FYI we stumbled upon several issues with the classic
wfs module in the geOrchestra extraction webapp (mainly
related to basic-authentication being dropped across
requests, but we are using a quite old geotools version
too). We migrated to wfs-ng in february, and it works
way better in our case (we might have had some weird
behaviour with the WFS namespaces though).

Regards,

-- Pierre





--
What NetFlow Analyzer can do for you? Monitors network bandwidth and 
traffic
patterns at an interface-level. Reveals which users, apps, and 
protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning
reports.http://sdm.link/zohodev2dev


___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
<mailto:GeoTools-Devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/geotools-devel





--
What NetFlow Analyzer can do for you? Monitors network
bandwidth and traffic
patterns at an interface-level. Reveals which users, apps,
and protocols are
consuming the most bandwidth. Provides multi-vendor support
for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using
capacity planning
reports.http://sdm.link/zohodev2dev
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
<mailto:GeoTools-Devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/geotools-devel









--


_

Re: [Geotools-devel] wfs-ng vs wfs datastore fight!

[Niels Charlier]

You're right, I can just put it in main,seeing it already depends on wfs-ng.

See https://github.com/geoserver/geoserver/pull/1724

Regards
Niels

On 26-07-16 22:06, Jody Garnett wrote:

Thanks, reviewed merged and closed GEOT-5222.

I am not sure about the test:
- it may be sufficient to copy the test to core (since it is testing 
the functionality of the geoserver catalog)
- it may also be fine as a community module (as you indicated) to 
verify the change of functionality; it can be removed after the 
transition is complete


--
Jody Garnett

On 26 July 2016 at 05:16, Niels Charlier <ni...@scitus.be 
<mailto:ni...@scitus.be>> wrote:


Hi Jody,

I wasn't able this time, I will make up for it next time.

I have new PR for getCount() issue:
https://github.com/geotools/geotools/pull/1252

I also made a branch on my own repo with a community module that
proves backwards compatibility between wfsng and wfs from a
geoserver point of view.
I don't know if this is what @Andrea wanted and if it is sufficient.
I also don't know if it is worth committing this (and creating a
new module just for this little test) or the fact that I did it is
enough:

https://github.com/NielsCharlier/geoserver/tree/wfsng

Regards
Niels



On 26-07-16 04:48, Jody Garnett wrote:

Thanks Niels, I picked up the other wgs-ng patch during the
friday sprint. I was sorry you did not join us as it would  of
been good to collaborate on this.

I am going to start prepping the migration of AbstractDataStore
to a community module in anticipation of your success fixing wfs-ng.

--
Jody Garnett

On 25 July 2016 at 12:35, Niels Charlier <ni...@scitus.be
<mailto:ni...@scitus.be>> wrote:

Hi Jody,

I've added a patch for WFS2.0 in MapServer to the existing PR.

A couple more fixes are coming.

Regards
Niels


On 22-07-16 18:45, Jody Garnett wrote:

Thanks for the positive feedback, Niels has a couple of pull
requests ready and then we should be able to complete the
"migration" ... perhaps later today!

--
Jody Garnett

On 22 July 2016 at 09:12, Pierre Mauduit
<pierre.maud...@camptocamp.com
<mailto:pierre.maud...@camptocamp.com>> wrote:

Hi,


 (perhaps due to lack of use).



FYI we stumbled upon several issues with the classic wfs
module in the geOrchestra extraction webapp (mainly
related to basic-authentication being dropped across
requests, but we are using a quite old geotools version
too). We migrated to wfs-ng in february, and it works
way better in our case (we might have had some weird
behaviour with the WFS namespaces though).

Regards,

-- Pierre





--
What NetFlow Analyzer can do for you? Monitors network bandwidth and 
traffic
patterns at an interface-level. Reveals which users, apps, and 
protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning
reports.http://sdm.link/zohodev2dev


___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
<mailto:GeoTools-Devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/geotools-devel





--
What NetFlow Analyzer can do for you? Monitors network
bandwidth and traffic
patterns at an interface-level. Reveals which users, apps,
and protocols are
consuming the most bandwidth. Provides multi-vendor support
for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using
capacity planning
reports.http://sdm.link/zohodev2dev
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
<mailto:GeoTools-Devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/geotools-devel







--
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] wfs-ng vs wfs datastore fight!

[Niels Charlier]

Hi Jody,

I wasn't able this time, I will make up for it next time.

I have new PR for getCount() issue: 
https://github.com/geotools/geotools/pull/1252


I also made a branch on my own repo with a community module that proves 
backwards compatibility between wfsng and wfs from a geoserver point of 
view.

I don't know if this is what @Andrea wanted and if it is sufficient.
I also don't know if it is worth committing this (and creating a new 
module just for this little test) or the fact that I did it is enough:


https://github.com/NielsCharlier/geoserver/tree/wfsng

Regards
Niels


On 26-07-16 04:48, Jody Garnett wrote:
Thanks Niels, I picked up the other wgs-ng patch during the friday 
sprint. I was sorry you did not join us as it would  of been good to 
collaborate on this.


I am going to start prepping the migration of AbstractDataStore to a 
community module in anticipation of your success fixing wfs-ng.


--
Jody Garnett

On 25 July 2016 at 12:35, Niels Charlier <ni...@scitus.be 
<mailto:ni...@scitus.be>> wrote:


Hi Jody,

I've added a patch for WFS2.0 in MapServer to the existing PR.

A couple more fixes are coming.

Regards
Niels


On 22-07-16 18:45, Jody Garnett wrote:

Thanks for the positive feedback, Niels has a couple of pull
requests ready and then we should be able to complete the
"migration" ... perhaps later today!

--
Jody Garnett

On 22 July 2016 at 09:12, Pierre Mauduit
<pierre.maud...@camptocamp.com
<mailto:pierre.maud...@camptocamp.com>> wrote:

Hi,


 (perhaps due to lack of use).



FYI we stumbled upon several issues with the classic wfs
module in the geOrchestra extraction webapp (mainly related
to basic-authentication being dropped across requests, but we
are using a quite old geotools version too). We migrated to
wfs-ng in february, and it works way better in our case (we
might have had some weird behaviour with the WFS namespaces
though).

Regards,

-- Pierre





--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning
reports.http://sdm.link/zohodev2dev


___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
<mailto:GeoTools-Devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/geotools-devel





--
What NetFlow Analyzer can do for you? Monitors network bandwidth
and traffic
patterns at an interface-level. Reveals which users, apps, and
protocols are
consuming the most bandwidth. Provides multi-vendor support for
NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using
capacity planning
reports.http://sdm.link/zohodev2dev
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
<mailto:GeoTools-Devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/geotools-devel




--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] wfs-ng vs wfs datastore fight!

[Niels Charlier]

Hi Jody,

I've added a patch for WFS2.0 in MapServer to the existing PR.

A couple more fixes are coming.

Regards
Niels

On 22-07-16 18:45, Jody Garnett wrote:
Thanks for the positive feedback, Niels has a couple of pull requests 
ready and then we should be able to complete the "migration" ... 
perhaps later today!


--
Jody Garnett

On 22 July 2016 at 09:12, Pierre Mauduit 
> 
wrote:


Hi,


 (perhaps due to lack of use).



FYI we stumbled upon several issues with the classic wfs module in
the geOrchestra extraction webapp (mainly related to
basic-authentication being dropped across requests, but we are
using a quite old geotools version too). We migrated to wfs-ng in
february, and it works way better in our case (we might have had
some weird behaviour with the WFS namespaces though).

Regards,

-- Pierre




--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev


___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel



--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] wfs-ng vs wfs datastore fight!

[Niels Charlier]

Thanks Andrea, good idea

On 21-07-16 14:15, Andrea Aime wrote:

I don't know personally, but asked on mapserver-devel:
http://osgeo-org.1560.x6.nabble.com/Support-for-wfs-2-0-on-mapserver-demo-td5277563.html

Cheers
Andrea

On Thu, Jul 21, 2016 at 2:07 PM, Niels Charlier <ni...@scitus.be 
<mailto:ni...@scitus.be>> wrote:


Thanks Andrea,
Could not reproduce the same problems, but I was able to fix
another issue.

The demo does not support WFS 2.0. Do you know if there is a
WFS2.0 server I can use to reproduce that issue?

Kind Regards
Niels


On 18-07-16 10:21, Andrea Aime wrote:

Hi Niels,
unfortunately I have no control over that WFS...  it seems they
have disabled it.
However, it was a recent MapServer version, I'm pretty sure there
are others online,
it's just not easy to find them since ESRI decided to use
mapserver in their REST API
endpoints...

I got one here, don't know if it shows the same misbehaviors as
the Tuscany one did:
http://demo.mapserver.org/cgi-bin/wfs?SERVICE=WFS=GetCapabilities

Cheers
Andrea


On Mon, Jul 18, 2016 at 10:06 AM, Niels Charlier <ni...@scitus.be
<mailto:ni...@scitus.be>> wrote:

Andrea,

This MapServer WFS url doesn't work any more. Now I can't
test what was going wrong there ... Do you know where it went
or if I can somehow test it still?

Regards
Niels


    On 27-06-16 14:44, Niels Charlier wrote:

On 24-06-16 17:10, Andrea Aime wrote:

Anyways, I've found again the links to the caps
documents of the
mapserver and a tinyows in question... no idea if the
problems are
still there, years have passed by and the servers
might have been
upgraded in the meantime:

MapServer WFS:

http://www502.regione.toscana.it/wmsraster/com.rt.wms.RTmap/wms?service=WFS=wmstest=GetCapabilities
TinyOWS WFS:

http://www502.regione.toscana.it/wfsvector/com.rt.wfs.RTmap/wfs?service=WFS=GetCapabilities

TinyOWS one works perfectly, as far as I can see. The
MapServer one is
problematic. The URL you gave me is WFS 2.0 and it cannot
be parsed,
which is a bug but not a blocker because wfs2 was not
supported by the
old module. If I change the version, it does parse the
getcapabilities
but it is however not returning any features even though
they are there,
that is a blocker. I made a jira issue:
https://osgeo-org.atlassian.net/browse/GEOS-7607

Rationale: most of the people I meet find it had to
keep up with our
release process and tend to do long jumps during
upgrades, so it still
seems more likely for users to upgrade from an old
wfs store than from
the newer wfs-ng, also given than the wfs store is
still around,
lowering the pressure for a switch.

Makes sense.

Regards
Niels


--
Attend Shape: An AT Tech Expo July 15-16. Meet us at
AT Park in San
Francisco, CA to explore cutting-edge tech and listen to
tech luminaries
present their vision of the future. This family event has
something for
everyone, including kids. Get more information and
register today.
http://sdm.link/attshape
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
<mailto:GeoTools-Devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/geotools-devel





-- 
==

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

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
phone: +39 0584 962313 <tel:%2B39%200584%20962313>
fax: +39 0584 1660272 <tel:%2B39%200584%201660272>
mob: +39  339 8844549 <tel:%2B39%20%C2%A0339%208844549>

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

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta
elettronica e/o nel/i file/s allegato/i sono da considerarsi
strettamente riservate. Il loro utilizzo è consentito
esclusivamente al destinatario del messaggio, per le finalità
indicate nel messaggio stesso. Qualora riceviate questo messaggio

Re: [Geotools-devel] wfs-ng vs wfs datastore fight!

[Niels Charlier]

Thanks Andrea,
Could not reproduce the same problems, but I was able to fix another issue.

The demo does not support WFS 2.0. Do you know if there is a WFS2.0 
server I can use to reproduce that issue?


Kind Regards
Niels

On 18-07-16 10:21, Andrea Aime wrote:

Hi Niels,
unfortunately I have no control over that WFS...  it seems they have 
disabled it.
However, it was a recent MapServer version, I'm pretty sure there are 
others online,
it's just not easy to find them since ESRI decided to use mapserver in 
their REST API

endpoints...

I got one here, don't know if it shows the same misbehaviors as the 
Tuscany one did:

http://demo.mapserver.org/cgi-bin/wfs?SERVICE=WFS=GetCapabilities

Cheers
Andrea


On Mon, Jul 18, 2016 at 10:06 AM, Niels Charlier <ni...@scitus.be 
<mailto:ni...@scitus.be>> wrote:


Andrea,

This MapServer WFS url doesn't work any more. Now I can't test
what was going wrong there ... Do you know where it went or if I
can somehow test it still?

Regards
Niels


On 27-06-16 14:44, Niels Charlier wrote:

On 24-06-16 17:10, Andrea Aime wrote:

Anyways, I've found again the links to the caps documents
of the
mapserver and a tinyows in question... no idea if the
problems are
still there, years have passed by and the servers might
have been
upgraded in the meantime:

MapServer WFS:

http://www502.regione.toscana.it/wmsraster/com.rt.wms.RTmap/wms?service=WFS=wmstest=GetCapabilities
TinyOWS WFS:

http://www502.regione.toscana.it/wfsvector/com.rt.wfs.RTmap/wfs?service=WFS=GetCapabilities

TinyOWS one works perfectly, as far as I can see. The
MapServer one is
problematic. The URL you gave me is WFS 2.0 and it cannot be
parsed,
which is a bug but not a blocker because wfs2 was not
supported by the
old module. If I change the version, it does parse the
getcapabilities
but it is however not returning any features even though they
are there,
that is a blocker. I made a jira issue:
https://osgeo-org.atlassian.net/browse/GEOS-7607

Rationale: most of the people I meet find it had to keep
up with our
release process and tend to do long jumps during upgrades,
so it still
seems more likely for users to upgrade from an old wfs
store than from
the newer wfs-ng, also given than the wfs store is still
around,
lowering the pressure for a switch.

Makes sense.

Regards
Niels


--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT
Park in San
Francisco, CA to explore cutting-edge tech and listen to tech
luminaries
present their vision of the future. This family event has
something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
<mailto:GeoTools-Devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/geotools-devel





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

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39  339 8844549

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

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica e/o 
nel/i file/s allegato/i sono da considerarsi strettamente riservate. 
Il loro utilizzo è consentito esclusivamente al destinatario del 
messaggio, per le finalità indicate nel messaggio stesso. Qualora 
riceviate questo messaggio senza esserne il destinatario, Vi preghiamo 
cortesemente di darcene notizia via e-mail e di procedere alla 
distruzione del messaggio stesso, cancellandolo dal Vostro sistema. 
Conservare il messaggio stesso, divulgarlo anche in parte, 
distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità 
diverse, costituisce comportamento contrario ai principi dettati dal 
D.Lgs. 196/2003.


The information in this message and/or attachments, is intended solely 
for the attention and use of the named addressee(s) and may be 
confidential or proprietary in nature or covered by the provisions of 
privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New 
Data Protection Code).Any use not in accord with its purpose, any 
disclosure, reproduction, copying, distribution, or either 
dissemination, either whole or partial, is strictl

Re: [Geotools-devel] wfs-ng vs wfs datastore fight!

[Niels Charlier]

Andrea,

This MapServer WFS url doesn't work any more. Now I can't test what was 
going wrong there ... Do you know where it went or if I can somehow test 
it still?

Regards
Niels

On 27-06-16 14:44, Niels Charlier wrote:
> On 24-06-16 17:10, Andrea Aime wrote:
>> Anyways, I've found again the links to the caps documents of the
>> mapserver and a tinyows in question... no idea if the problems are
>> still there, years have passed by and the servers might have been
>> upgraded in the meantime:
>>
>> MapServer WFS:
>> http://www502.regione.toscana.it/wmsraster/com.rt.wms.RTmap/wms?service=WFS=wmstest=GetCapabilities
>> TinyOWS WFS:
>> http://www502.regione.toscana.it/wfsvector/com.rt.wfs.RTmap/wfs?service=WFS=GetCapabilities
>>
> TinyOWS one works perfectly, as far as I can see. The MapServer one is
> problematic. The URL you gave me is WFS 2.0 and it cannot be parsed,
> which is a bug but not a blocker because wfs2 was not supported by the
> old module. If I change the version, it does parse the getcapabilities
> but it is however not returning any features even though they are there,
> that is a blocker. I made a jira issue:
> https://osgeo-org.atlassian.net/browse/GEOS-7607
>
>> Rationale: most of the people I meet find it had to keep up with our
>> release process and tend to do long jumps during upgrades, so it still
>> seems more likely for users to upgrade from an old wfs store than from
>> the newer wfs-ng, also given than the wfs store is still around,
>> lowering the pressure for a switch.
> Makes sense.
>
> Regards
> Niels
>
> --
> Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
> present their vision of the future. This family event has something for
> everyone, including kids. Get more information and register today.
> http://sdm.link/attshape
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel


--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] wfs-ng vs wfs datastore fight!

[Niels Charlier]

On 24-06-16 17:10, Andrea Aime wrote:
> Anyways, I've found again the links to the caps documents of the 
> mapserver and a tinyows in question... no idea if the problems are 
> still there, years have passed by and the servers might have been 
> upgraded in the meantime:
>
> MapServer WFS: 
> http://www502.regione.toscana.it/wmsraster/com.rt.wms.RTmap/wms?service=WFS=wmstest=GetCapabilities
> TinyOWS WFS: 
> http://www502.regione.toscana.it/wfsvector/com.rt.wfs.RTmap/wfs?service=WFS=GetCapabilities
>

TinyOWS one works perfectly, as far as I can see. The MapServer one is 
problematic. The URL you gave me is WFS 2.0 and it cannot be parsed, 
which is a bug but not a blocker because wfs2 was not supported by the 
old module. If I change the version, it does parse the getcapabilities 
but it is however not returning any features even though they are there, 
that is a blocker. I made a jira issue: 
https://osgeo-org.atlassian.net/browse/GEOS-7607

> Rationale: most of the people I meet find it had to keep up with our 
> release process and tend to do long jumps during upgrades, so it still 
> seems more likely for users to upgrade from an old wfs store than from 
> the newer wfs-ng, also given than the wfs store is still around, 
> lowering the pressure for a switch.
Makes sense.

Regards
Niels

--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] wfs-ng vs wfs datastore fight!

[Niels Charlier]

On 24-06-16 15:36, Andrea Aime wrote:
I believe I sent you a list of mapserver and tinyows servers that were 
buggy vs the WFS spec and that the wfs store was
configurable to work with anyways (as you may imagine, going to the 
server owner and asking for an upgrade or a different
interpretation of the specs almost never works... especially if they 
already have apps built on top of it, with their current behavior).

Do you still have the links? It's been so much time...


I don't recall this list. I do remember this: 
https://sourceforge.net/p/geotools/mailman/message/32457750/
where we discussed mapserver/tinyows supported and ported additional 
functionality tests for these servers from wfs to wfs-ng.
This is the last thing I can find about it in my mailbox. Do you recall 
where this information came from or with what medium you sent it to me?


 Eh, in the meantime we discovered that upgrade was botched and fixed 
it at least to some extent.
Configure a wfs data store in a previous version, upgrade to a newer 
newer one, and it did not work anymore.


Are there additional issues apart from the naming issue or the ones in 
JIRA? I have successfully made the transition before.

I wonder if we can put this in a unit test somehow?



Old thread, I need to refresh my memory I believe I meant 
centralized as in a geotools wrapper class that does the renaming
(see that "DataUtilities.makeGmlCompatible(DataStore) -> DataStore " 
suggestion).
not centralized at the GeoServer level, the : issue in GeoServer 
should not be a problem, but it's a serious problem

for those upgrading apps based on geotools instead.
It might then make sense to use that class in the store factory, 
controlled by a parameter I guess (at this point it's very
hard to say if it should be on or off by default, since wfs-ng has 
been out for a few releases...)


Okay. Yeah I have wondered that myself. Offer backwards compatibility to 
wfs users or wfs-ng users? We can't do both any more, we'll have to 
compromise one way or the other.


Regards
Niels
--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] wfs-ng vs wfs datastore fight!

[Niels Charlier]

I'm digging up the WFS/WFS-NG datastore fight and want to sort it out 
once and for all. I am compiling a comprehensive list of what needs to 
happen for WFS-NG to become acceptable:
https://github.com/geotools/geotools/wiki/WFS-to-WFS-NG-upgrade Any 
feedback/additions to this list are more than welcome.


Andrea can I ask you some clarification on this,
On Wed, Apr 20, 2016 at 12:18 PM, Andrea Aime 
> 
wrote:


If you have time, I'd start with backwards compatibility checks,
ability to drop-in replace the old store is mandatory in
a lived projects such as GeoTools and GeoServer.


What do you mean with compatibility checks. I ported all offline and 
online unit/integration tests from the WFS to the WFS-NG module.
What exactly needs to happen in addition to that to prove backwards 
compatibility? Do we need or have people to test with real configurations?


 With respect to the naming colon/underscore issue, I am willing to 
take care of this now as well.
I prefer Andrea's proposed solution (see the link above) because it 
proposes a single solution for all datastores that may not always be 
GML-compatible. But Andrea, how did you envision a user turning this 
option on or off in practice? It is up to the datastores themselves? Or 
is there a single, centralised configuration in Geoserver for all 
datastores? Or ...?


Kind Regards
Niels
--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] ImageMosaic API refactor proposal

[Niels Charlier]

Devon,

Great work, thanks for improving the explanation of my part. I'm glad to 
see the plan is moving forward.


Kind Regards
Niels

On 21-05-16 01:21, Devon Tucker wrote:

Hi all,

I've been working on fleshing this proposal out and adding a bit to 
it. See the conversation on on-the-fly reprojection in ImageMosaic. My 
updated API proposal is on my own Wiki for now, I can update the 
master one but I wanted to solicit early feedback. Please let me know 
if something doesn't make sense. Wanted to throw it out there earlier 
for feedback rather than later:


https://github.com/dvntucker/geotools/wiki/Refactor-ImageMosaic-for-extensibility

Cheers,
Devon

On Fri, Apr 22, 2016 at 1:20 AM, Niels Charlier <ni...@scitus.be 
<mailto:ni...@scitus.be>> wrote:


On 21-04-16 20:01, Jody Garnett wrote:

Thanks for the clarification Niels, I was not aware that Prop was
part of the current API.

Still we have some duplication here right? Should we try running
the property collectors, look at the results, and generate the
schema appropriate to store the results?


Jody, have a look at this:

http://geoserver.geo-solutions.it/multidim/en/imagemosaic/mosaic_indexer.html#imagemosaic-xml-indexer-example
You see that in the current index configuration file, there is a
separate section for the schemas and the property collectors. Both
sections provide a completely different kind of information.

I do not think that there is duplication. You cannot run property
collectors if you do not have a schema yet. The property
collectors are run per feature (granule). The schema is made
before you can even create features. The schema is defined per
coverage inside the store and can differ between them. The
property collectors are unaware of the coverages, and they may
operate for multiple. Once the schema has been created for a
coverage, the features are created and then values might be needed
for each feature. This is the time that (for some properties) the
appropriate property collectors are looked up and called to fill
in those values.
In summary:
the schema -> defines the metadata (table structure) of the index
per coverage
the property collectors -> defines how to grab the data for the
index (from the metadata of the granules)
two different functions altogether.





--
Jody Garnett

On 21 April 2016 at 03:00, Niels Charlier <ni...@scitus.be
<mailto:ni...@scitus.be>> wrote:

On 17-04-16 04:17, Jody Garnett wrote:

This proposal (and email thread) should be orthogonal to
the RnD discussion on setting up a mosaic with multiple
projections.

This mosaic is focused on creating/managing the index
used. One part I cannot wrap my head around is the
workflow behind these two methods - createSchema(String
name, CoordinateReferenceSystem crs) which creates the
FeatureType used for the index, and
Collection getPropertiesCollectors().
It seems these two methods need to be implemented
together, a single PropertyCollector may collect more
than once value on examining a raster. I am not sure how
to line up these collected values with the created schema
without more information.


Just to be clear, the proposal doesn't change anything about
PropertyCollectors work. This would simply continue to work
as it is working right now, until somebody makes a proposal
to change it to something else!

These two things have a completely different function. The
schema defines the structure of the index.

Property Collectors are customisable mechanisms that provides
(some of the) values of the index per granule, taking
information from the file and/or the coverage metadata.

The schema creation includes attributes that are not
collected with a PropertyCollector (such as location), while
one Propery Collector can potentially supply multiple
attribute values.


 We also have String getParameter(Prop prop) defined, but
the class Prop is not included in the proposal.


Prop already exists in the current API.


Suggestions:
- Use a list of PropertiesCollectors to provide order,
which can then be used to determine the Schema?
- Language consistency - raster / granule
- Language consistency - could we use AttributeDescriptor
rather than introduce a new thing called "Prop" ?


You do know that Props are configuration properties, nothing
to do with features?

- Are the class responsibilities clear:
GranuleCatalogManager, GranuleCatalog, GranuleStore,
MosaicHarve

Re: [Geotools-devel] wfs-ng vs wfs datastore fight!

[Niels Charlier]

Andre,

The reason I closed it as "not a bug" was because I knew it was done by 
intentional design (not by me, but by the initial developer of wfs-ng) 
for a particular purpose and therefore I did not consider it a bug. You 
do make good points to criticise this choice, which does affect 
backwards compatibility. I do not personally oppose your alternative 
suggestion.


Regards
Niels

On 04/22/2016 07:48 PM, Andrea Aime wrote:
On Thu, Apr 21, 2016 at 7:52 PM, Jody Garnett > wrote:



> Hum... wfs-ng was supposed to be a drop-in replacement,
not having a upgrade
> path seems to be a serious issue to me.
> Where is it documented?

Quick search got us this:
https://osgeo-org.atlassian.net/browse/GEOT-4883
and we googled some more messages on it. 


A backwards incompable change blocking upgrades presented as a
GeoServer requirement and resolved as "not a bug"...


Reading this issue, and I agree it is not a bug - the new
datastore is behaving as designed in order to preserve valid names
for GML generation.


Jody I believe we have a problem here, in terms of responsibilities. 
Is it really the job of the stores to decide what is valid, and what 
is not?
Not all usage is WFS cascading, stores are used for a number of other 
cases, which might have different naming limitations.


Also from a consistency point of view, did you know that you can 
create a typename like "a:b" using a postgis store?


> create table "a:b" (id serial, geom geometry(POLYGON, 4326));
CREATE TABLE

And then the datastore is happily returning a:b as the typename,
And of course we also have shapefiles, on linux a file name like 
a:b.shp is also completely valid.


With you and Niels claiming that is not a bug, we have a difficult 
situation, as nobody else can just jump in and make
the upgrade path easier, since according to your evaluation, we'd be 
introducing a bug... (and from that same point of view,

then jdbc store and shapefile store are buggy too...).

Unless of course your position is a bit more relaxed, as in, you don't 
consider that a bug, but the behavior returning the native

name is valid too.


For this specific case the old datastore would of required a
similar fix (to prevent type names being of the form
"local_namespace:remote_namespace:typename").

As far as I know GeoServer was already handling the ":" in the
name, and the admin is able to rename layers as they see fit.
Yep, there is code stripping the prefix:

https://github.com/geoserver/geoserver/blob/master/src/main/src/main/java/org/geoserver/catalog/CatalogBuilder.java#L1212


GeoServer may have work arounds, but I do not mind if the new
DataStore is taking more care to produce consistent type names.


See Mark's situation though. I'm also aware of other situations like 
this one that will be broken by an upgrade (systems configured

to work against well known type names in remote servers).

Mind, I checked, GeoServer is not affected, because internally we have 
this little thing that hides from GeoServer the columns and

guess what, replaces them with underscores. See here:

https://github.com/geoserver/geoserver/blob/master/src/main/src/main/java/org/vfny/geoserver/util/DataStoreUtils.java#L74

and then the retyper does this:

https://github.com/geoserver/geoserver/blob/master/src/main/src/main/java/org/geoserver/feature/retype/RetypingDataStore.java#L252

So luckily for GeoServer even if the store did change its behavior, 
nothing changed config wise (we end up seeing a_b as the native
type name regardless of whether the store returns a:b or a_b because 
of the above wrapper).


Given this, I'd still make it possible for GeoTools users to upgrade 
from wfs to wfs-ng without this much hassle by exposing the

actual native type name.
If the worry is about valid type names for GML, I'm more than happy to 
contribute a little utility wrapping store based on the GeoServer one
that does the same thing as RetypingDataStore, but centralized in one 
place, and optional, only for those that actually need to do GML encoding.

A DataUtilities.makeGmlCompatible(DataStore) -> DataStore of sorts.

Cheers
Andrea


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

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39  339 8844549

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

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica e/o 
nel/i file/s allegato/i sono da considerarsi strettamente riservate. 
Il loro utilizzo è consentito esclusivamente al destinatario del 
messaggio, per le finalità indicate nel messaggio 

Re: [Geotools-devel] ImageMosaic API refactor proposal

[Niels Charlier]

On 21-04-16 20:01, Jody Garnett wrote:
Thanks for the clarification Niels, I was not aware that Prop was part 
of the current API.


Still we have some duplication here right? Should we try running the 
property collectors, look at the results, and generate the schema 
appropriate to store the results?


Jody, have a look at this: 
http://geoserver.geo-solutions.it/multidim/en/imagemosaic/mosaic_indexer.html#imagemosaic-xml-indexer-example
You see that in the current index configuration file, there is a 
separate section for the schemas and the property collectors. Both 
sections provide a completely different kind of information.


I do not think that there is duplication. You cannot run property 
collectors if you do not have a schema yet. The property collectors are 
run per feature (granule). The schema is made before you can even create 
features. The schema is defined per coverage inside the store and can 
differ between them. The property collectors are unaware of the 
coverages, and they may operate for multiple. Once the schema has been 
created for a coverage, the features are created and then values might 
be needed for each feature. This is the time that (for some properties) 
the appropriate property collectors are looked up and called to fill in 
those values.

In summary:
the schema -> defines the metadata (table structure) of the index per 
coverage
the property collectors -> defines how to grab the data for the index 
(from the metadata of the granules)

two different functions altogether.





--
Jody Garnett

On 21 April 2016 at 03:00, Niels Charlier <ni...@scitus.be 
<mailto:ni...@scitus.be>> wrote:


On 17-04-16 04:17, Jody Garnett wrote:

This proposal (and email thread) should be orthogonal to the
RnD discussion on setting up a mosaic with multiple projections.

This mosaic is focused on creating/managing the index used.
One part I cannot wrap my head around is the workflow behind
these two methods - createSchema(String name,
CoordinateReferenceSystem crs) which creates the FeatureType
used for the index, and Collection
getPropertiesCollectors().
It seems these two methods need to be implemented together, a
single PropertyCollector may collect more than once value on
examining a raster. I am not sure how to line up these
collected values with the created schema without more information.


Just to be clear, the proposal doesn't change anything about
PropertyCollectors work. This would simply continue to work as it
is working right now, until somebody makes a proposal to change it
to something else!

These two things have a completely different function. The schema
defines the structure of the index.

Property Collectors are customisable mechanisms that provides
(some of the) values of the index per granule, taking information
from the file and/or the coverage metadata.

The schema creation includes attributes that are not collected
with a PropertyCollector (such as location), while one Propery
Collector can potentially supply multiple attribute values.


 We also have String getParameter(Prop prop) defined, but the
class Prop is not included in the proposal.


Prop already exists in the current API.


Suggestions:
- Use a list of PropertiesCollectors to provide order, which
can then be used to determine the Schema?
- Language consistency - raster / granule
- Language consistency - could we use AttributeDescriptor
rather than introduce a new thing called "Prop" ?


You do know that Props are configuration properties, nothing to do
with features?

- Are the class responsibilities clear: GranuleCatalogManager,
GranuleCatalog, GranuleStore, MosaicHarvester, etc...

(It could also be that since I am unfamiliar with the
internals being refactored that I am just struggling with the
language - so if everyone else is okay ...)


Regards
Niels




--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] ImageMosaic API refactor proposal

[Niels Charlier]

On 17-04-16 04:17, Jody Garnett wrote:
> This proposal (and email thread) should be orthogonal to the RnD 
> discussion on setting up a mosaic with multiple projections.
>
> This mosaic is focused on creating/managing the index used. One part I 
> cannot wrap my head around is the workflow behind these two methods 
> - createSchema(String name, CoordinateReferenceSystem crs) which 
> creates the FeatureType used for the index, 
> and Collection getPropertiesCollectors().
> It seems these two methods need to be implemented together, a single 
> PropertyCollector may collect more than once value on examining a 
> raster. I am not sure how to line up these collected values with the 
> created schema without more information.

Just to be clear, the proposal doesn't change anything about 
PropertyCollectors work. This would simply continue to work as it is 
working right now, until somebody makes a proposal to change it to 
something else!

These two things have a completely different function. The schema 
defines the structure of the index.

Property Collectors are customisable mechanisms that provides (some of 
the) values of the index per granule, taking information from the file 
and/or the coverage metadata.

The schema creation includes attributes that are not collected with a 
PropertyCollector (such as location), while one Propery Collector can 
potentially supply multiple attribute values.


>  We also have String getParameter(Prop prop) defined, but the class 
> Prop is not included in the proposal.

Prop already exists in the current API.

>
> Suggestions:
> - Use a list of PropertiesCollectors to provide order, which can then 
> be used to determine the Schema?
> - Language consistency - raster / granule
> - Language consistency - could we use AttributeDescriptor rather than 
> introduce a new thing called "Prop" ?

You do know that Props are configuration properties, nothing to do with 
features?

> - Are the class responsibilities clear: 
> GranuleCatalogManager, GranuleCatalog, GranuleStore, MosaicHarvester, 
> etc...
>
> (It could also be that since I am unfamiliar with the internals being 
> refactored that I am just struggling with the language - so if 
> everyone else is okay ...)
>
>
Regards
Niels

--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] wfs-ng vs wfs datastore fight!

[Niels Charlier]

Issue number (2) was unfortunately introduced when adding the complex 
store last year. Both of these issues can probably be resolved without 
*too* much effort.


Of course we can't know for sure, but I am 95% convinced that once those 
few annoying roadblocks to using wfs-ng are resolved, it will work a lot 
better than wfs. There are *lots* of unit tests, integration tests and 
online tests there to prove it can do the job very well, if properly 
configured.


So it just a matter of investing a little more time to it for likely a 
reward well worth it. I hope to have a look at it myself soon.


Kind Regards
Niels

On 19-04-16 09:47, Andrea Aime wrote:
On Tue, Apr 19, 2016 at 12:32 AM, Jody Garnett > wrote:


I have been monitoring GEOT-5128
 looking to
delete AbstractDataStore and friends - currently in use by the
gt-wfs module. We have a "new" wfs-ng implementation based on
ContentDataStore - that is waiting on a firm thumbs up (or a
series of bug reports) in order to take over duties.


GeoServer has been using wfs-ng for a few months now in the stable 
series (nobody waited for a thumbs up there), so far the experience 
has been negative... or in a way, absent,
the store did not really work at all for some (let's say 50%), and 
does not survive a restart for all others. The tickets have reached 
both the geoserver and geotools devel list, but just in case

you have missed them, here they are:
1) The complex wfs store hijacking the simple one and breaking 
cascading: https://osgeo-org.atlassian.net/browse/GEOT-5361
2) The wfs-ng store does not survive a restart in GeoServer (or any 
other app storing connection params as strings): 
https://osgeo-org.atlassian.net/browse/GEOT-5374


2) is consistently reproducible, 1) is draw of the luck, depends on 
which factory gets listed first.
Between one and the other they have prevented usage of WFS cascading 
in GeoServer up until GeoServer 2.8.3 (which is only a month old).

Direct GeoTools usage would have been affected by 1) only.


Are there any known wfs-ng issues that need to be addressed?
Searching jira


 I
find 56 open issues against the wfs plugin - relatively few
against the wfs-ng plugin (perhaps due to lack of use).


I'd say the two bugs above surely prevented further testing and 
probably discouraged reporters. I can see 5 tickets assigned tdirectly 
the wfs-ng as a module,
and 27 if I count all those that contain the wfs-ng keyword 
(https://osgeo-org.atlassian.net/issues/?jql=project%20%3D%20GEOT%20AND%20text%20~%20%22wfs-ng%22 
) 
.
Can you share how you counted the 56? The ticket tracker is not making 
this job easy for sure.
One plugin is a few months old, the other 10+ year old... so far the 
"bug per month" ratio seems to favor the old code, but...
well, it's not an apples to apples comparison, it could be that wfs-ng 
will accumulate way less now that it can be used, or way more, we have 
no way to know right now.


I'd say at this point we go with wfs-ng anyways... does it at least 
have some backing from the people that wrote and
promoted it? Desire to bring it up to snuff, bug fix and so on? It 
would help to hear that wfs-ng has some life in it :-)


Cheers
Andrea



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

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39  339 8844549

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

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica e/o 
nel/i file/s allegato/i sono da considerarsi strettamente riservate. 
Il loro utilizzo è consentito esclusivamente al destinatario del 
messaggio, per le finalità indicate nel messaggio stesso. Qualora 
riceviate questo messaggio senza esserne il destinatario, Vi preghiamo 
cortesemente di darcene notizia via e-mail e di procedere alla 
distruzione del messaggio stesso, cancellandolo dal Vostro sistema. 
Conservare il messaggio stesso, divulgarlo anche in parte, 
distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità 
diverse, costituisce comportamento contrario ai principi dettati dal 
D.Lgs. 196/2003.


The information in this message and/or attachments, is intended solely 
for the attention and use of the named addressee(s) and may be 
confidential or proprietary in nature or covered by the provisions of 
privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New 
Data 

Re: [Geotools-devel] ImageMosaic API refactor proposal

[Niels Charlier]

Hi Simone,

Thanks for review! In response to your questions

(1) Jody added this note to the proposal and Devon is working on this 
part, so I think either one of them are best placed to explain this part.

(2) Okay, agreed.

Regards
Niels

On 15-04-16 10:39, Simone Giannecchini wrote:
> Ciao Niels,
> we are looking into this and comparing with some work that have in the
> pipeline which might extend the work you are doing with respect to
> harvesting.
>
> I like the general idea pretty much, I have a few quick questions/obs?
>
> -1- Can you clarify this sentence?
>
> "to replace the default direct granule access with a renderable graph
> (for reprojection)"
>
> -2- Stupid thing but in ImageMosaic I would go for add/removeRaster
> rather than *Coverage
>
> I will talk to Andrea and Daniele to add more.
>
> That said, it might be worth to have a look at the code when it start to 
> settle.
>
>
>
> Regards,
> Simone Giannecchini
> ==
> GeoServer Professional Services from the experts!
> Visit http://goo.gl/it488V for more information.
> ==
> Ing. Simone Giannecchini
> @simogeo
> Founder/Director
>
> GeoSolutions S.A.S.
> Via di Montramito 3/A
> 55054  Massarosa (LU)
> Italy
> phone: +39 0584 962313
> fax: +39 0584 1660272
> mob:   +39  333 8128928
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> ---
> AVVERTENZE AI SENSI DEL D.Lgs. 196/2003
> Le informazioni contenute in questo messaggio di posta elettronica e/o
> nel/i file/s allegato/i sono da considerarsi strettamente riservate.
> Il loro utilizzo è consentito esclusivamente al destinatario del
> messaggio, per le finalità indicate nel messaggio stesso. Qualora
> riceviate questo messaggio senza esserne il destinatario, Vi preghiamo
> cortesemente di darcene notizia via e-mail e di procedere alla
> distruzione del messaggio stesso, cancellandolo dal Vostro sistema.
> Conservare il messaggio stesso, divulgarlo anche in parte,
> distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità
> diverse, costituisce comportamento contrario ai principi dettati dal
> D.Lgs. 196/2003.
>
> The information in this message and/or attachments, is intended solely
> for the attention and use of the named addressee(s) and may be
> confidential or proprietary in nature or covered by the provisions of
> privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New
> Data Protection Code).Any use not in accord with its purpose, any
> disclosure, reproduction, copying, distribution, or either
> dissemination, either whole or partial, is strictly forbidden except
> previous formal approval of the named addressee(s). If you are not the
> intended recipient, please contact immediately the sender by
> telephone, fax or e-mail and delete the information in this message
> that has been received in error. The sender does not give any warranty
> or accept liability as the content, accuracy or completeness of sent
> messages and accepts no responsibility  for changes made after they
> were sent or for other risks which arise as a result of e-mail
> transmission, viruses, etc.
>
>
> On Wed, Apr 6, 2016 at 10:33 AM, Niels Charlier <ni...@scitus.be> wrote:
>> Hello Devon,
>>
>> Directory walking is part of the harvesting process, which is at the moment
>> implemented inside the ImageMosaicReader (see the inner class
>> HarvestedResource).
>> In the API, there is a separate MosaicHarvester interface, as well as a very
>> light ImageMosaicReader with all the logic inside the ImageMosaic class.
>> With this API, we can either do one of these two thing to customise
>> harvesting:
>> 1. Write our own reader and use all the mosaic functionality through the
>> ImageMosaic class.
>> 2. Write our own implementation of MosaicHarvester for a customised
>> harvesting process and plug it into the ImageMosaicReader.
>>
>> Does that make any sense?
>>
>> Kind Regards
>> Niels
>>
>>
>> On 06-04-16 01:48, Devon Tucker wrote:
>>
>> For my own part, Niels maybe you could throw in some small examples of how
>> these API changes would be used in practice to accomplish some of the items
>> in the description? For example, how could I customize the directory walking
>> with the new API?
>>
>> Thanks,
>> Devon
>>
>> On Tue, Apr 5, 2016 at 4:44 PM, Devon Tucker <devonrtuc...@gmail.com> wrote:
>>> Hi all,
>>>
>>> 

Re: [Geotools-devel] ImageMosaic API refactor proposal

[Niels Charlier]

Hello Devon,

Directory walking is part of the harvesting process, which is at the 
moment implemented inside the ImageMosaicReader (see the inner class 
HarvestedResource).
In the API, there is a separate MosaicHarvester interface, as well as a 
very light ImageMosaicReader with all the logic inside the ImageMosaic 
class.
With this API, we can either do one of these two thing to customise 
harvesting:
1. Write our own reader and use all the mosaic functionality through the 
ImageMosaic class.
2. Write our own implementation of MosaicHarvester for a customised 
harvesting process and plug it into the ImageMosaicReader.


Does that make any sense?

Kind Regards
Niels

On 06-04-16 01:48, Devon Tucker wrote:
For my own part, Niels maybe you could throw in some small examples of 
how these API changes would be used in practice to accomplish some of 
the items in the description? For example, how could I customize the 
directory walking with the new API?


Thanks,
Devon

On Tue, Apr 5, 2016 at 4:44 PM, Devon Tucker > wrote:


Hi all,

Just noticed that there wasn't a dedicated email thread for this
proposal and figured I'd kick one off since I've also been
involved in it.


https://github.com/geotools/geotools/wiki/Refactor-ImageMosaic-for-extensibility

I think the description gives a pretty good rationale for what we
want to accomplish with this proposal and I'd like to solicit any
discussion, advice, feedback, etc. from everyone.

Cheers,
Devon




--


___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel


--
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] gt-coverage refactorings

[Niels Charlier]

Hi Simone, Daniele, List,

Here is what we currently have for our proposal:

https://github.com/geotools/geotools/wiki/Refactor-ImageMosaic-for-extensibility. 



This is still is discussion phase, we'd like to hear your input :)

Kind Regards
Niels

On 31-03-16 20:14, Niels Charlier wrote:
I have looked at Daniele's PR (superficially) and it looks good, but I 
would expect a proposal is in order to move a lot of API from a plugin 
to a core module.


As far as I can see, there is little or no overlap between the two 
bodies of work at the moment. I don't expect any issues there.


Considering our proposal - will be posting this soonish - we can never 
move everything that demstore depends on from imagemosaic to the 
coverage module, it's nearly everything. I much prefer the idea of 
creating a more public API for imagemosaic itself and documenting this 
(perhaps promoting it to a core module?).


Kind Regards
Niels

On 31-03-16 19:53, Jody Garnett wrote:
Catching up with the geotools codebase for a bit ... and I also owe 
Andrea an update from the gt-dem community module progress.


I see we have two teams looking at refactoring functionality into 
gt-coverage:


Daniele: Your pull request #1131 Supporting vector footprints on GDAL 
plugin <https://github.com/geotools/geotools/pull/1131> is moving 
some functionality from gt-mosaic to gt-coverage around generating 
footprints using GDAL and minor changes to CatalogManager.  I would 
like some feedback on how this affects the code-base stability (with 
respect to upcoming release); and we could help pull together a 
change proposal.


Devon & Niels: Although we have a community module, most of the work 
has taken place on a branch (to hack hooks into gt-image-mosaic 
classes such as CatalogManger). The next step is to regroup and 
produce a change proposal. I assume this change proposal would move 
some functionality from gt-moasic to gt-coverage (or depend on 
gt-mosaic which would involve some clean up and documentation of the 
internals as public api).


The other update is a change in scope - the multi-resolution dem is 
no longer just a dem. It now has to cover both dem and imagery. The 
critical difference between this and gt-moasic ends up being setting 
up a processing chain (renderable graph) for each granule allowing 
content from different projections to be merged (with an appropriate 
speed penalty). I am not sure if the different granules have to be 
coerced into the same band structure or not (something that is more 
challenging for a DEM which may be measured in meters or feet).

--
Jody Garnett


--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140


___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel




--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140


___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel


--
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [JIRA] (GEOT-5392) Refactor ImageMosaic for extensibility

[Niels Charlier (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Niels Charlier created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 GeoTools /  GEOT-5392  
 
 
  Refactor ImageMosaic for extensibility   
 

  
 
 
 
 

 
Issue Type: 
  New Feature  
 
 
Assignee: 
 Niels Charlier  
 
 
Components: 
 imagemosaic plugin  
 
 
Created: 
 31/Mar/16 8:20 PM  
 
 
Priority: 
  Medium  
 
 
Reporter: 
 Niels Charlier  
 

  
 
 
 
 

 
 The goal is to make it possible to use imagemosaic as a base to extend upon to make stores that do similar things, to replace certain implementations with alternative implementations and use only that which we want to use.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment

Re: [Geotools-devel] gt-coverage refactorings

[Niels Charlier]

I have looked at Daniele's PR (superficially) and it looks good, but I 
would expect a proposal is in order to move a lot of API from a plugin 
to a core module.


As far as I can see, there is little or no overlap between the two 
bodies of work at the moment. I don't expect any issues there.


Considering our proposal - will be posting this soonish - we can never 
move everything that demstore depends on from imagemosaic to the 
coverage module, it's nearly everything. I much prefer the idea of 
creating a more public API for imagemosaic itself and documenting this 
(perhaps promoting it to a core module?).


Kind Regards
Niels

On 31-03-16 19:53, Jody Garnett wrote:
Catching up with the geotools codebase for a bit ... and I also owe 
Andrea an update from the gt-dem community module progress.


I see we have two teams looking at refactoring functionality into 
gt-coverage:


Daniele: Your pull request #1131 Supporting vector footprints on GDAL 
plugin  is moving some 
functionality from gt-mosaic to gt-coverage around generating 
footprints using GDAL and minor changes to CatalogManager.  I would 
like some feedback on how this affects the code-base stability (with 
respect to upcoming release); and we could help pull together a change 
proposal.


Devon & Niels: Although we have a community module, most of the work 
has taken place on a branch (to hack hooks into gt-image-mosaic 
classes such as CatalogManger). The next step is to regroup and 
produce a change proposal. I assume this change proposal would move 
some functionality from gt-moasic to gt-coverage (or depend on 
gt-mosaic which would involve some clean up and documentation of the 
internals as public api).


The other update is a change in scope - the multi-resolution dem is no 
longer just a dem. It now has to cover both dem and imagery. The 
critical difference between this and gt-moasic ends up being setting 
up a processing chain (renderable graph) for each granule allowing 
content from different projections to be merged (with an appropriate 
speed penalty). I am not sure if the different granules have to be 
coerced into the same band structure or not (something that is more 
challenging for a DEM which may be measured in meters or feet).

--
Jody Garnett


--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140


___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel


--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [JIRA] (GEOT-5383) imagemosaic resolution unpredictable for multiple resolutions

[Niels Charlier (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Niels Charlier created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 GeoTools /  GEOT-5383  
 
 
  imagemosaic resolution unpredictable for multiple resolutions   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Assignee: 
 Unassigned  
 
 
Attachments: 
 sf-images.zip  
 
 
Components: 
 imagemosaic plugin  
 
 
Created: 
 15/Mar/16 5:41 PM  
 
 
Priority: 
  Medium  
 
 
Reporter: 
 Niels Charlier  
 

  
 
 
 
 

 
 When creating an imagemosaic store, resolution levels are abstracted from the images and stored in the .properties file. However, the outcome is undetermined, depending on which file is harvested first, which depends on the File.list method and thus file system / the environment. For example: an imagemosaic from the two files in the attachment. Depending on your environment, the resulting resolution levels in the properties file may be either Levels=0.0083329982,0.0083329997 or  Levels=30,30 depending on which file your environment lists first.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment

[Geotools-devel] [JIRA] (GEOT-5382) imagemosaic with multiple resolutions crashes when attempting to create the layer

[Niels Charlier (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Niels Charlier created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 GeoTools /  GEOT-5382  
 
 
  imagemosaic with multiple resolutions crashes when attempting to create the layer
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Assignee: 
 Unassigned  
 
 
Attachments: 
 sf.zip  
 
 
Components: 
 imagemosaic plugin  
 
 
Created: 
 15/Mar/16 5:24 PM  
 
 
Priority: 
  High  
 
 
Reporter: 
 Niels Charlier  
 

  
 
 
 
 

 
 1. Create an imagemosaic store from the zip file provided (works fine) 2. Proceed to create the layer -> stack trace  
 

  
 
 
 
 

 
 
 

 
 
 Add Comm

Re: [Geotools-devel] DEMStore community module

[Niels Charlier]

sorry, one was sent to the wrong list, please ignore

On 10-02-16 17:21, Niels Charlier wrote:
> I'd like permission to create a new community module called "demstore".
>
> This is a store specialised for Digital Elevation Models. The idea is to
> merge different granules that may be of different resolution and
> quality. It will be built on top of the mosaicstore with extra features
> such as
> - more complex algorithms to decide order of preference when different
> granules overlap
> - creation of a mask to filter outliers for each granule
>
> There is a possibility that we will propose later to merge this module
> (or parts of the module) with the mosaicstore as the features may be
> useful for mosaics in general.
>
> There will be a module in geotools as well. The geoserver module will be
> mostly a shell, pulling in the geotools module and providing a custom
> GUI store page.
>
> Kind Regards
> Niels
>
> --
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel


--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] DEMStore community module

[Niels Charlier]

I'd like permission to create a new community module called "demstore".

This is a store specialised for Digital Elevation Models. The idea is to 
merge different granules that may be of different resolution and 
quality. It will be built on top of the mosaicstore with extra features 
such as
- more complex algorithms to decide order of preference when different 
granules overlap
- creation of a mask to filter outliers for each granule

There is a possibility that we will propose later to merge this module 
(or parts of the module) with the mosaicstore as the features may be 
useful for mosaics in general.

There will be a module in geotools as well. The geoserver module will be 
mostly a shell, pulling in the geotools module and providing a custom 
GUI store page.

Kind Regards
Niels

--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] geotools unsupported module

[Niels Charlier]

I'd like permission to create a new unsupported module called "demstore".

This is a store specialised for Digital Elevation Models. The idea is to 
merge different granules that may be of different resolution and 
quality. It will be built on top of the mosaicstore with extra features 
such as
- more complex algorithms to decide order of preference when different 
granules overlap
- creation of a mask to filter outliers for each granule

There is a possibility that we will propose later to merge this module 
(or parts of the module) with the mosaicstore as the features may be 
useful for mosaics in general.

There will be a module in geoserver as well. The geoserver module will 
be mostly a shell, pulling in the geotools module and providing a custom 
GUI store page.

Kind Regards
Niels

--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [JIRA] (GEOT-5134) wfs-ng: better exception reporting

[Niels Charlier (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Niels Charlier created an issue 
 
 
 
 
 
 
 
 
 
 


 
 
 
 
 
 
 GeoTools /  GEOT-5134 
 
 
 
  wfs-ng: better exception reporting  
 
 
 
 
 
 
 
 
 

Issue Type:
 
  Improvement 
 
 
 

Assignee:
 

 Unassigned 
 
 
 

Created:
 

 28/May/15 11:14 PM 
 
 
 

Priority:
 
  Medium 
 
 
 

Reporter:
 
 Niels Charlier 
 
 
 
 
 
 
 
 
 
 
A proper way of dealing with exceptions. 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 


 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.5-OD-04-052#65000-sha1:8b5a8f9

[Geotools-devel] [JIRA] (GEOT-5132) wfs-ng 2.0 not encoding spatial filters properly

[Niels Charlier (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Niels Charlier created an issue 
 
 
 
 
 
 
 
 
 
 


 
 
 
 
 
 
 GeoTools /  GEOT-5132 
 
 
 
  wfs-ng 2.0 not encoding spatial filters properly  
 
 
 
 
 
 
 
 
 

Issue Type:
 
  Bug 
 
 
 

Assignee:
 

 Unassigned 
 
 
 

Created:
 

 28/May/15 11:08 PM 
 
 
 

Priority:
 
  Medium 
 
 
 

Reporter:
 
 Niels Charlier 
 
 
 
 
 
 
 
 
 
 
See https://github.com/NielsCharlier/geotools/blob/3982579d0b9e1eb0c2a3ff022943cf3debbef86e/modules/unsupported/wfs-ng/src/test/java/org/geotools/data/wfs/online/v2_0/GeoServerOnlineTest.java#L93 
The spatial filters aren't being encoded properly. 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 


 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.5-OD-04-052#65000-sha1:8b5a8f9

[Geotools-devel] [JIRA] (GEOT-5133) WFS-NG: missing output formats

[Niels Charlier (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Niels Charlier created an issue 
 
 
 
 
 
 
 
 
 
 


 
 
 
 
 
 
 GeoTools /  GEOT-5133 
 
 
 
  WFS-NG: missing output formats  
 
 
 
 
 
 
 
 
 

Issue Type:
 
  Bug 
 
 
 

Assignee:
 

 Unassigned 
 
 
 

Created:
 

 28/May/15 11:13 PM 
 
 
 

Priority:
 
  Medium 
 
 
 

Reporter:
 
 Niels Charlier 
 
 
 
 
 
 
 
 
 
 
On 05/12/2015 11:07 AM, Jan De Moerloose wrote:  I did some more testing with the WFS client and found that the following   formats are not accepted by the parsers:   1) application/gml+xml; version=3.1 (GmlGetFeature, DescribeFeatureType)  2) text/xml; subType=gml/3.1.1/profiles/gmlsf/1.0.0/0 (GmlGetFeature,   DescribeFeatureType)   In the second case subType is written in camel case, which it is also in   the GML 3.1.1 simple features spec, so i assume this is correct. 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 


 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian

Re: [Geotools-devel] WFS-NG: missing output formats

[Niels Charlier]

On 12-05-15 11:11, Andrea Aime wrote:
On Tue, May 12, 2015 at 11:07 AM, Jan De Moerloose 
jan.demoerlo...@geosparc.com mailto:jan.demoerlo...@geosparc.com 
wrote:


Hi,

I did some more testing with the WFS client and found that the
following
formats are not accepted by the parsers:

1) application/gml+xml; version=3.1 (GmlGetFeature,
DescribeFeatureType)
2) text/xml; subType=gml/3.1.1/profiles/gmlsf/1.0.0/0 (GmlGetFeature,
DescribeFeatureType)

In the second case subType is written in camel case, which it is
also in
the GML 3.1.1 simple features spec, so i assume this is correct.



All right I'll put it on the wfs-ng todo list... But this list is rather 
long and I have limited time for this module at this very moment, so if 
it is urgent absolutely feel free to work on it as well.




Another thing i noticed is that the ExceptionReportParserFactory has
disappeared. Is it going to be replaced by something else ?



I removed all unused classes, including this one. It was quite empty as 
well. Better exception reporting is high on the wfs-ng todo list though.


Regards
Niels

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] geofence geoserver integration

[Niels Charlier]

I made a pull request for the changes on geoserver:
https://github.com/geoserver/geoserver/pull/1005

I've put it there already mainly to get commenting and reviewing going. 
But I do hope we can sort out how to get these changes in the official 
branches of geofence and geoserver soon!

Let me know what you think.

Regards
Niels

On 06-04-15 11:55, Niels Charlier wrote:
 Hi Emanuele,

 Are the geofence refactoring commits going to be pulled in the master 
 branch in the official repo?
 Because I almost have a pull ready for gs-geofence-server but it 
 depends on those changes being there.


 Also, I have found a work-around for my eclipse issue. While you can't 
 manipulate the dependency order of included projects from the GUI, 
 there is an order inside the config file behind it (.classpath file in 
 the project dir). The order of the pom doesn't seem to be respected, 
 but I can manually do it. After running maven eclipse:eclipse, I 
 manually edit the .classpath file and move the model-internal 
 dependency above the gs-geofence dependency. That is the best solution 
 for now, but still a bit annoying. There is another really annoying 
 thing in eclipse, there is an application-context.xml in test and it 
 reads it of course.

 Regards
 Niels

 On 02-04-15 13:01, Emanuele Tajariol wrote:
 Hi Niels,

 * Let gs-geofence also use model-internal, but it is probably not 
 desire
 to have all that unnecessary hibernate stuff loaded.
 Exactly: the split model was created only because gs-geofence did 
 import too
 much hibernate stuff inside geoserver.

 * Make them different classes (or in different packages) but use
 interfaces instead for compatibility? Probably would require lots of
 refactoring inside geofence.
 * Can we somehow force geofence-server to use the classes from
 geofence-model-internal even if both are on the classpath? It seems 
 that
 java will always use the _first_ on the classpath, but eclipse doesn't
 recognise an order in project dependencies
 These solutions are quite complex, and would be a workaround for a 
 workaround
 (the split model).
 I guess the simpler way would be to only have a single model module, 
 and to
 remove the hibernate annotations using the hbm files instead.
 I tried to use the hibernate tools for automatically creating the hbm 
 files out
 of the annotations, but they seemed quite bugged. Do you have any 
 experience
 with them?

 Cheers,
 Emanuele


 Alle 12:17:37 di Thursday 2 April 2015, Niels Charlier ha scritto:
 Hi,

 I have a practical problem regarding the difference between
 geofence-model and geofence-model-internal.
 They both contain the same classes, but geofence-model removes the
 hibernate annotations from the build.

 gs-geofence uses geofence-model while gs-geofence-server needs
 gs-geofence-model-internal. I solved this earlier by putting an
 exclusion in the geofence-server profile of the web-app pom. The 
 problem
 is however eclipse. When you do mvn eclipse:eclipse inside web-app, 
 this
 works fine. However, eclipse doesn't add any of the geoserver 
 modules as
 required projects in the build path, but rather as regular external
 jar files, so you miss the relationship between the code and this 
 brings
 inconveniences while programming and debugging.

 To solve that you have to do eclipse:eclipse from the geoserver source
 root. But then eclipse doesn't recognise the exclusion... and keeps
 loading the classes from model. And geofence-server doesn't work 
 without
 the hibernate annotations.

 So, do you guys have any ideas for solutions?
 * Let gs-geofence also use model-internal, but it is probably not 
 desire
 to have all that unnecessary hibernate stuff loaded.
 * Make them different classes (or in different packages) but use
 interfaces instead for compatibility? Probably would require lots of
 refactoring inside geofence.
 * Can we somehow force geofence-server to use the classes from
 geofence-model-internal even if both are on the classpath? It seems 
 that
 java will always use the _first_ on the classpath, but eclipse doesn't
 recognise an order in project dependencies

 Any suggestions?

 Regards
 Niels

 On 27-03-15 17:16, Emanuele Tajariol wrote:
 Hi Niels,

 What does this setting do: Use GeoServer roles to get
 authorizations?

  GeofencePage.useRolesToFilter=Use GeoServer roles to get
  authorizations

 it's related to this proposal:

 https://github.com/geosolutions-it/geofence/wiki/Proposal-%233:-GeoServer 

 - Roles-to-GeoFence-groups-mapping#configuration

 It makes the AccessManager query geofence the authorization not for 
 the
 accessing user, but by the role the user is assigned in GeoServer
 See also method setRuleFilterUserOrRole.

 If the roles in geoserver are exactly the same as in geofence (as the
 current integration work aims to) it should not matter, since the
 resulting auths will be the same.
 I mean: if the useRolesToFilter is set to true, the user-role matching
 will be done

Re: [Geotools-devel] WFS-NG test work

[Niels Charlier]

Hello Sampo,

Thank you for your review and your comments, I have responded to them.

I hope we can push this commit through asap.

Kind Regards
Niels

On 13-03-15 15:01, Sampo Savolainen wrote:

Hi,

Sorry about the radio silence. I've been working on an unrelated big 
project and I haven't had a chance to focus on this. I agree that the 
testing in wfs-ng has not been up to spec and I appreciate your effort 
in getting that house in order. I had a quick look and found nothing 
really wrong with it but I didn't have a chance to actually try it 
out. Comments are in github.


Which version would this be included in? 13.1?


 Sampo

On Fri, Mar 13, 2015 at 11:54 AM, Niels Charlier ni...@scitus.be 
mailto:ni...@scitus.be wrote:


Sampo,

Would you have the time to have a look at that? Or anyone else?

Kind Regards
Niels


On 28-02-15 19:16, Niels Charlier wrote:

Hi,

I have a new patch ready to improve the wfs-ng tests. All of
this was
done with the purpose of creating test cases for the new WFS 2.0
functionality.
I thought the test directory in wfs-ng was such a terrible mess it
needed serious work first.
A summary of what happened in this commit:

   1. Removed a bunch of duplicated test support reference
data xml files,
  and put all of them in one single directory structure
instead of
being spread around.
   2. WFFTestData and DataTestSupport were almost duplicates
from each
other,
  removed the older one and converted all tests to use the
newer one.
   3. There were two separate geoserveronlinetests, one for
wfs1.0 and
one for both wfs1.0 and wfs1.1
   made one abstract online test class and one derived
test class per
server/version combination.
   4. Enabled all of the disabled online test methods and made
them work
with the geoserver tests (release data dir).
   5. Enabled most of the disabled test methods in the
integration test
and made them work for the wfs1.1 geoserver
  integration test case.
   6. Fixed issues with axis order implementation so the
offline and
online axis order tests work.
   7. Created a very clear package/directory structure for all
tests so
that you can very easily see
  which server/wfs-version combinations have tests and
which don't,
offline and online.
   8. Renamed some confusing class names and removed unnecessary
duplicated stuff
  for example there was both a TestHttpClient and
TestHTTPClient.
   9. Added pullparser test which tests the new parser (that
works with
GML3.2).

TODO
   1. make online and offline WFS 2.0 tests. THis should now
be rather
easy with the existing abstract integration and online
  test classes available which only require you to insert
the right
reference data info.
   2. verify the existing online tests for other servers than
geoserver

https://github.com/geotools/geotools/pull/757

Regards
Niels


--
Dive into the World of Parallel Programming The Go Parallel
Website, sponsored
by Intel and developed in partnership with Slashdot Media, is
your hub for all
things parallel software development, from weekly thought
leadership blogs to
news, videos, case studies, tutorials and more. Take a look
and join the
conversation now. http://goparallel.sourceforge.net/
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
mailto:GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel





--
Sampo Savolainen
RD Director, Spatineo Oy
sampo.savolai...@spatineo.com mailto:sampo.savolai...@spatineo.com
+358-407555649
Linnankoskenkatu 16 A 17, 00250 Helsinki, Finland
www.spatineo.com http://www.spatineo.com, twitter.com/#!/spatineo 
http://twitter.com/#%21/spatineo
www.linkedin.com/company/spatineo-inc 
http://www.linkedin.com/company/spatineo-inc


This message may contain privileged and/or confidential information. 
If you

have received this e-mail in error or are not the intended recipient, you
may not use, copy, disseminate, or distribute it; do not open any
attachments, delete it immediately from your system and notify the sender
promptly by e-mail that you have done so.


--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed

Re: [Geotools-devel] Complex feature parsing: wfs-ng and app-schema

[Niels Charlier]

Hello Ben,

I have had a look at this work. There is already quite some need for 
manual merging to get this to work, because a lot has changed in the 
meantime. At this moment I have two main concerns for merge:

(1) The changes regarding AbstractDataStoreFactory and the new 
AbstractDataAccessFactory. In the meantime the class 
AbstractDataStoreFactory has been deprecated and wfs-ng does not depend 
on it any longer (it is an immediate implementation of the factory 
interface), I understand ContentDataStore has taken over some of its 
functionality (?). I have a suspicion that the creation of a new 
AbstractDataAccessFactory has become unnecessary and this will probably 
need to be removed from the pr.

I have CCd Jody for this purpose, @Jody, would you pretty please check 
out only what happens with AbstractDataStoreFactory in this pr 
specifically (no need to check anything else but gt-main changes) and 
give your recommendation on what to do with this?

(2) I am wondering if it is really necessary to let wfs-ng depend on 
app-schema. We have created gt-complex to avoid this. I checked what it 
is using from app-schema and it is the AppSchemaFeatureTypeRegistry and 
EmfAppSchemaReader. We have made the more general FeatureTypeRegistry 
and EmfComplexFeatureReader in gt-complex for general xsd-based complex 
feature creation, the difference is that app-schema injects the GML 
libraries into these (CSW uses non-gml complex features). I wonder if it 
isn't even a better idea copy-paste the GML-injection code into wfs-ng 
(:( ), because it is a bit absurd to force the dependency of the whole 
app-schema module in wfs-ng only for this?? Opinions?

Kind Regards
Niels

On 03-02-15 20:11, Ben Caradoc-Davies wrote:
 Niels and Sampo,

 have you seen Rini's complex feature parsing pull request? This 
 resurrects Adam Brown's GML client library work. Discussion and links 
 here:
 https://github.com/geotools/geotools/pull/406

 We were discussing this at the committee meeting and wondered if you 
 or anyone else had an opinion. I think Niels you used and improved 
 some of Adam's original changes to app-schema (caching and the new 
 gt-complex module). There are some changes in wfs-ng as well. Rini has 
 done most of the work.

 Rini waited patiently and is now on extended leave. It would be great 
 if this could be merged before she gets back. On master, after the 
 feature freeze.

 Kind regards,



--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] WFS-NG test work

[Niels Charlier]

Sampo,

Would you have the time to have a look at that? Or anyone else?

Kind Regards
Niels

On 28-02-15 19:16, Niels Charlier wrote:
 Hi,

 I have a new patch ready to improve the wfs-ng tests. All of this was
 done with the purpose of creating test cases for the new WFS 2.0
 functionality.
 I thought the test directory in wfs-ng was such a terrible mess it
 needed serious work first.
 A summary of what happened in this commit:

1. Removed a bunch of duplicated test support reference data xml files,
   and put all of them in one single directory structure instead of
 being spread around.
2. WFFTestData and DataTestSupport were almost duplicates from each
 other,
   removed the older one and converted all tests to use the newer one.
3. There were two separate geoserveronlinetests, one for wfs1.0 and
 one for both wfs1.0 and wfs1.1
made one abstract online test class and one derived test class per
 server/version combination.
4. Enabled all of the disabled online test methods and made them work
 with the geoserver tests (release data dir).
5. Enabled most of the disabled test methods in the integration test
 and made them work for the wfs1.1 geoserver
   integration test case.
6. Fixed issues with axis order implementation so the offline and
 online axis order tests work.
7. Created a very clear package/directory structure for all tests so
 that you can very easily see
   which server/wfs-version combinations have tests and which don't,
 offline and online.
8. Renamed some confusing class names and removed unnecessary
 duplicated stuff
   for example there was both a TestHttpClient and TestHTTPClient.
9. Added pullparser test which tests the new parser (that works with
 GML3.2).

 TODO
1. make online and offline WFS 2.0 tests. THis should now be rather
 easy with the existing abstract integration and online
   test classes available which only require you to insert the right
 reference data info.
2. verify the existing online tests for other servers than geoserver

 https://github.com/geotools/geotools/pull/757

 Regards
 Niels

 --
 Dive into the World of Parallel Programming The Go Parallel Website, sponsored
 by Intel and developed in partnership with Slashdot Media, is your hub for all
 things parallel software development, from weekly thought leadership blogs to
 news, videos, case studies, tutorials and more. Take a look and join the
 conversation now. http://goparallel.sourceforge.net/
 ___
 GeoTools-Devel mailing list
 GeoTools-Devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/geotools-devel


--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] axis order blues

[Niels Charlier]

Jeroen hit the nail on the head... Users want the ability to choose.. 
but they also want predictability, I would say the latter is even a 
prerequisite for the first. Axis order behaviour and which db system to 
use are orthogonal choices for users. Using a different CRS database 
system should never change axis order behaviour and the documentation 
should always be respected.


Regards
Niels

On 02-03-15 07:52, Dries Jeroen wrote:
Quite a coincidence, I've also been wrestling with axis order last 
week, and also found that the documentation did not appear to be 
correct! The way I expect it to work is for gt-epsg-wkt to be a drop 
in replacement for gt-epsg-hsql, so no difference in axis order, I 
think it's confusing enough as it is. The original reason I personally 
started to use the wkt version is a dependency conflict with hsqldb, I 
also continued to use it because if I use Geotools for instance on 
Hadoop, it sometimes creates a lot of short living processes, and I 
don't want it to do this database setup. Also note that I generally 
only use a couple of predefined reference systems, so there's no need 
to have the full DB.


I would also suggest that we at least try to keep the axis order 
consistent if you use the long form, as that is what most people in 
the OGC community are doing. If a major implementation like 
geotools/geoserver starts to deviate from this in certain 
implementations, than we're back to where we started in the whole axis 
order mess.


best regards,
Jeroen

Jeroen Dries
*TAP* - Centre for Remote Sensing and Earth Observation Processes
VITO NV | Boeretang 200 | 2400 Mol
tel. +32 14 33 55 11 | jeroen.dr...@vito.be mailto:voornaam.n...@vito.be
cid:image001.jpg@01CDCE3A.4E197A50 
http://www.vito.be/cid:image001.jpg@01CD3F0D.B57AA190 
http://www.linkedin.com/company/17947cid:image003.jpg@01CD3F0D.B57AA190 
http://twitter.com/#%21/vitobelgiumcid:image002.jpg@01CD3F0D.B57AA190 https://www.facebook.com/VITObelgium


*Van:* andrea.a...@gmail.com [andrea.a...@gmail.com] namens Andrea 
Aime [andrea.a...@geo-solutions.it]

*Verzonden:* vrijdag 27 februari 2015 12:55
*Aan:* Niels Charlier; Dries Jeroen
*CC:* Ben Caradoc-Davies; geotools-devel@lists.sourceforge.net; Jody 
Garnett

*Onderwerp:* Re: [Geotools-devel] axis order blues

On Fri, Feb 27, 2015 at 12:34 PM, Niels Charlier ni...@scitus.be 
mailto:ni...@scitus.be wrote:



On 27-02-15 11:52, Andrea Aime wrote:

On Fri, Feb 27, 2015 at 11:34 AM, Niels Charlier ni...@scitus.be
mailto:ni...@scitus.be wrote:

Hmm yeah I figured it had something to do with that. Thanks
for the
detailed explanation, Ben.
But my question remains: should gt-epsg-wkt be allowed to
produce the
wrong CRS in the first place?


As far as I remember gt-espg-wkt always had east/north
orientation in all CRS,
and people keep on using it like this.
I'm afraid changing the axis order now would break all existing
users of
this module (e.g., I know of GeoServer customizations that use it
instead of
epsg-hsql because they don't want databases to be created around, and
they don't give a damn about OGC/EPSG axis order, they actually
want everything
east/north)


Isn't it unlikely that those users use the URI syntax. The
geotools documentation claims that when you use the URI syntax the
result is always perfectly predictable... quod non.


As said, there are customized GeoServer versions using it, so the use 
of URI syntax is highly likely.
Jeroen, I believe you're doing that right? Using epsg-wkt in GeoServer 
instead of gt-espg-hsql?
Can you talk about how you're using it, context and so on, also 
related to axis flipping?


Cheers
Andrea

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

Ing. Andrea Aime
@geowolf
Technical Lead

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

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

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica e/o 
nel/i file/s allegato/i sono da considerarsi strettamente riservate. 
Il loro utilizzo è consentito esclusivamente al destinatario del 
messaggio, per le finalità indicate nel messaggio stesso. Qualora 
riceviate questo messaggio senza esserne il destinatario, Vi preghiamo 
cortesemente di darcene notizia via e-mail e di procedere alla 
distruzione del messaggio stesso, cancellandolo dal Vostro sistema. 
Conservare il messaggio stesso, divulgarlo anche in parte, 
distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità 
diverse, costituisce comportamento contrario ai principi dettati dal 
D.Lgs. 196/2003.


The information in this message and/or attachments, is intended

[Geotools-devel] WFS-NG test work

[Niels Charlier]

Hi,

I have a new patch ready to improve the wfs-ng tests. All of this was 
done with the purpose of creating test cases for the new WFS 2.0 
functionality.
I thought the test directory in wfs-ng was such a terrible mess it 
needed serious work first.
A summary of what happened in this commit:

  1. Removed a bunch of duplicated test support reference data xml files,
 and put all of them in one single directory structure instead of 
being spread around.
  2. WFFTestData and DataTestSupport were almost duplicates from each 
other,
 removed the older one and converted all tests to use the newer one.
  3. There were two separate geoserveronlinetests, one for wfs1.0 and 
one for both wfs1.0 and wfs1.1
  made one abstract online test class and one derived test class per 
server/version combination.
  4. Enabled all of the disabled online test methods and made them work 
with the geoserver tests (release data dir).
  5. Enabled most of the disabled test methods in the integration test 
and made them work for the wfs1.1 geoserver
 integration test case.
  6. Fixed issues with axis order implementation so the offline and 
online axis order tests work.
  7. Created a very clear package/directory structure for all tests so 
that you can very easily see
 which server/wfs-version combinations have tests and which don't, 
offline and online.
  8. Renamed some confusing class names and removed unnecessary 
duplicated stuff
 for example there was both a TestHttpClient and TestHTTPClient.
  9. Added pullparser test which tests the new parser (that works with 
GML3.2).

TODO
  1. make online and offline WFS 2.0 tests. THis should now be rather 
easy with the existing abstract integration and online
 test classes available which only require you to insert the right 
reference data info.
  2. verify the existing online tests for other servers than geoserver

https://github.com/geotools/geotools/pull/757

Regards
Niels

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] axis order blues

[Niels Charlier]

Hmm yeah I figured it had something to do with that. Thanks for the 
detailed explanation, Ben.
But my question remains: should gt-epsg-wkt be allowed to produce the 
wrong CRS in the first place?
Should it perhaps not be completely removed from all dependencies and 
replaced by better alternatives

Regards
Niels

On 27-02-15 01:04, Ben Caradoc-Davies wrote:
 Niels,

 I will answer your first question. You are right: this is a classpath 
 difference. The cause is that Maven and Eclipse have different 
 dependency models. Eclipse has no notion of a phase (compile versus 
 test) and no way to exclude transitive dependencies (so test 
 dependencies of other modules always get included on the classpath). 
 gt-epsg-wkt is the problem; how do you make it go away?

 This is the devious workaround I implemented in 2010 to disable 
 gt-epsg-wkt EPSGCRSAuthorityFactory so that gt-xsd-gml3 unit tests 
 pass in Eclipse:
 https://github.com/geotools/geotools/blob/master/modules/extension/xsd/xsd-gml3/src/test/java/org/geotools/referencing/crs/EPSGCRSAuthorityFactory.java
  

 https://jira.codehaus.org/browse/GEOT-3112

 It may be enough to add gt-xsd-gml3 as a test-phase dependency before 
 all other dependencies. Maven will not include it as a dependency for 
 consumers of your module because it is test-phase only. Eclipse will 
 blindly include it at all times and disable gt-epsg-wkt.

 There is no META-INF/services SPI file as this is provided by the real 
 implementations.

 Kind regards,
 Ben.

 On 27/02/15 10:52, Niels Charlier wrote:
 Hi,

 Okay, so according to the geotools documentation CRSes with full URI
 specification don't suffer from axis order confusions. But I have the
 following SRS used in a test:
 urn:x-ogc:def:crs:EPSG:6.11.2:26713
 And here's the thing: when running the test in maven, this is
 North-East, when running the same test in eclipse this is East-North.
 How on earth could that be possible?? What I've been able to figure out
 is that when running in maven the CRS is built by DirectEpsgFactory
 which takes it from a database in epsg-hsql, but in eclipse it is built
 by EPSGCRSAuthorityFactory in epsg-wkt which takes it from a text file
 (which says east-north). So my guess is that this has something to do
 with the different way that maven and eclipse handle module
 dependencies. But still, shouldn't it always be North-East when
 specified with such a URI?

 It almost seems like a pure gamble which axis order you are going to end
 up with in geotools. You can force geotools to always use east-north,
 but you can't do it the other way around! And you can only set that
 setting once in the beginning of running your java instance, changing it
 again doesn't guarantee success because of caching crses.

 Also, I think there is a lot of unnecessary throwing away of axis order
 going on by using srs strings when there are already methods in place to
 use CRS instead. For example in BoundingBoxImpl, the getSrs/setSrs
 methods are deprecated, but they are still used everywhere, even in new
 code, it seems like the deprecations in BoundingBoxImpl are still
 ignored. In the FilterDuplicatorVisitor, from which most filter visitors
 are derived, the boundingbox is rebuilt using setSrs() so all CRS
 information axis order is lost each time a filter is rebuilt with a
 visitor. I think that could be easily changed.



 Regards
 Niels

 --
  

 Dive into the World of Parallel Programming The Go Parallel Website, 
 sponsored
 by Intel and developed in partnership with Slashdot Media, is your 
 hub for all
 things parallel software development, from weekly thought leadership 
 blogs to
 news, videos, case studies, tutorials and more. Take a look and join the
 conversation now. http://goparallel.sourceforge.net/
 ___
 GeoTools-Devel mailing list
 GeoTools-Devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/geotools-devel





--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] axis order blues

[Niels Charlier]

On 27-02-15 11:52, Andrea Aime wrote:
On Fri, Feb 27, 2015 at 11:34 AM, Niels Charlier ni...@scitus.be 
mailto:ni...@scitus.be wrote:


Hmm yeah I figured it had something to do with that. Thanks for the
detailed explanation, Ben.
But my question remains: should gt-epsg-wkt be allowed to produce the
wrong CRS in the first place?


As far as I remember gt-espg-wkt always had east/north orientation in 
all CRS,

and people keep on using it like this.
I'm afraid changing the axis order now would break all existing users of
this module (e.g., I know of GeoServer customizations that use it 
instead of

epsg-hsql because they don't want databases to be created around, and
they don't give a damn about OGC/EPSG axis order, they actually want 
everything

east/north)

Isn't it unlikely that those users use the URI syntax. The geotools 
documentation claims that when you use the URI syntax the result is 
always perfectly predictable... quod non.


Regards
Niels
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] axis order blues

[Niels Charlier]

Hi,

Okay, so according to the geotools documentation CRSes with full URI 
specification don't suffer from axis order confusions. But I have the 
following SRS used in a test:
urn:x-ogc:def:crs:EPSG:6.11.2:26713
And here's the thing: when running the test in maven, this is 
North-East, when running the same test in eclipse this is East-North. 
How on earth could that be possible?? What I've been able to figure out 
is that when running in maven the CRS is built by DirectEpsgFactory 
which takes it from a database in epsg-hsql, but in eclipse it is built 
by EPSGCRSAuthorityFactory in epsg-wkt which takes it from a text file 
(which says east-north). So my guess is that this has something to do 
with the different way that maven and eclipse handle module 
dependencies. But still, shouldn't it always be North-East when 
specified with such a URI?

It almost seems like a pure gamble which axis order you are going to end 
up with in geotools. You can force geotools to always use east-north, 
but you can't do it the other way around! And you can only set that 
setting once in the beginning of running your java instance, changing it 
again doesn't guarantee success because of caching crses.

Also, I think there is a lot of unnecessary throwing away of axis order 
going on by using srs strings when there are already methods in place to 
use CRS instead. For example in BoundingBoxImpl, the getSrs/setSrs 
methods are deprecated, but they are still used everywhere, even in new 
code, it seems like the deprecations in BoundingBoxImpl are still 
ignored. In the FilterDuplicatorVisitor, from which most filter visitors 
are derived, the boundingbox is rebuilt using setSrs() so all CRS 
information axis order is lost each time a filter is rebuilt with a 
visitor. I think that could be easily changed.



Regards
Niels

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Complex feature parsing: wfs-ng and app-schema

[Niels Charlier]

Yeah, I know what that's like, let's try to avoid that!

Regards
Niels

On 04-02-15 20:57, Ben Caradoc-Davies wrote:
 That would be great!

 Rini will be back in October but merging earlier may prevent new 
 conflicts.

 Kind regards,
 Ben.

 On 04/02/15 22:00, Niels Charlier wrote:
 Hi Ben,

 I saw this but there was some comment from Jody about picking it up
 after she returned.
 I'm happy to have a look at it. I'll put it on my todo list.

 Kind Regards
 Niels

 On 03-02-15 20:11, Ben Caradoc-Davies wrote:
 Niels and Sampo,

 have you seen Rini's complex feature parsing pull request? This
 resurrects Adam Brown's GML client library work. Discussion and links
 here:
 https://github.com/geotools/geotools/pull/406

 We were discussing this at the committee meeting and wondered if you
 or anyone else had an opinion. I think Niels you used and improved
 some of Adam's original changes to app-schema (caching and the new
 gt-complex module). There are some changes in wfs-ng as well. Rini has
 done most of the work.

 Rini waited patiently and is now on extended leave. It would be great
 if this could be merged before she gets back. On master, after the
 feature freeze.

 Kind regards,







--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Complex feature parsing: wfs-ng and app-schema

[Niels Charlier]

Hi Ben,

I saw this but there was some comment from Jody about picking it up 
after she returned.
I'm happy to have a look at it. I'll put it on my todo list.

Kind Regards
Niels

On 03-02-15 20:11, Ben Caradoc-Davies wrote:
 Niels and Sampo,

 have you seen Rini's complex feature parsing pull request? This 
 resurrects Adam Brown's GML client library work. Discussion and links 
 here:
 https://github.com/geotools/geotools/pull/406

 We were discussing this at the committee meeting and wondered if you 
 or anyone else had an opinion. I think Niels you used and improved 
 some of Adam's original changes to app-schema (caching and the new 
 gt-complex module). There are some changes in wfs-ng as well. Rini has 
 done most of the work.

 Rini waited patiently and is now on extended leave. It would be great 
 if this could be merged before she gets back. On master, after the 
 feature freeze.

 Kind regards,



--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] Wfs-ng: enable WFS2.0 Transactions

[Niels Charlier]

Hi everyone,

Following up on wfs 2.0 support in wfs-ng, I made a patch to support 
transactions as well:
https://github.com/geotools/geotools/pull/725

The main thing needed was the encoding. Note that an extensive test case 
for this encoding has been added in the commit.

Proper testing of WFS2.0 in wfs-ng itself is what I am working on now... 
I think the existing tests need to be improved and restructured a bit 
first. In the meantime I thought I'd already put this up for review.

Kind Regards
Niels



--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] wfs 2.0 in wfs-ng module

[Niels Charlier]

Hello Jody,

Thanks for working on my pull requests. I will look at all your remarks 
and answer/resolve shortly.


Sorry for the issue with the kml patch I approved. I read and checked 
all the code but in the future I will always make a local build as well 
before merging.


Regards
Niels

On 18-01-15 00:18, Jody Garnett wrote:
Thanks Sampo, it really helps having someone familiar with the 
codebase to provide a review. I will check it over for the usual 
glitches (headers, formatting) and look at including it today.


And thanks to Niels for the hustle getting these pull requests in time.

--
Jody Garnett

On 17 January 2015 at 04:09, Sampo Savolainen 
sampo.savolai...@spatineo.com mailto:sampo.savolai...@spatineo.com 
wrote:


Hi,

I rebuilt the war and the wfs-ng store registers just fine. I
must've botched the earlier geoserver build I tried with.

I'm giving this pull request my full hearted support for inclusion
into GeoTools 13.


 Sampo


 Sampo

On Fri, Jan 16, 2015 at 6:36 PM, Sampo Savolainen
sampo.savolai...@spatineo.com
mailto:sampo.savolai...@spatineo.com wrote:

Thats great news. So what about including this is 2.7?

Btw. Niels, what maven commands do you use to produce the
build? It sounds like I'm missing some options or something.

  Sampo

On Jan 16, 2015 6:10 PM, Niels Charlier ni...@scitus.be
mailto:ni...@scitus.be wrote:

Sampo, it works for me in a tomcat. I think the issue must
be with your setup.

Regards
Niels

On 16-01-15 16:29, Niels Charlier wrote:

I'll give it a try

On 16-01-15 07:38, Sampo Savolainen wrote:

Hi,

This is weird: If I run GeoServer in eclipse
using the Start class in
gs-web-app, the Capabilities is registered fine.
However, if I build the
war and deploy it in tomcat, GeoServer cannot
register the schema. Is there
any chance you have time to check this?


   Sampo

On Thu, Jan 15, 2015 at 9:03 PM, Niels
Charlierni...@scitus.be mailto:ni...@scitus.be
wrote:


I have done so.

Regards
Niels


On 15-01-15 18:21, Sampo Savolainen wrote:


Hi,

Can you push the rebased branch so I
can test the exact same version?

Sampo
On Jan 15, 2015 5:37 PM, Niels
Charlierni...@scitus.be
mailto:ni...@scitus.be wrote:

   Hello Sampo,

I cannot reproduce this error. I
have rebased everything. I can use the
mentioned file to create a
datastore in geoserver.

Regards,
Niels

On 15-01-15 12:02, Sampo
Savolainen wrote:

   Hi,

This should happen when
adding a wfs-ng store using the
mentioned test
GetCapabilities file. If it
works for you, then I guess
something goes
wrong when rebasing the branch.


 Sampo




On Thu, Jan 15, 2015 at 12:42
PM, Niels Charlierni...@scitus.be
mailto:ni...@scitus.be
wrote:

 Hello Sampo,


Can you clarify how I
can reproduce this problem

Re: [Geotools-devel] wfs 2.0 in wfs-ng module

[Niels Charlier]

I'll give it a try

On 16-01-15 07:38, Sampo Savolainen wrote:
 Hi,

 This is weird: If I run GeoServer in eclipse using the Start class in
 gs-web-app, the Capabilities is registered fine. However, if I build the
 war and deploy it in tomcat, GeoServer cannot register the schema. Is there
 any chance you have time to check this?


   Sampo

 On Thu, Jan 15, 2015 at 9:03 PM, Niels Charlier ni...@scitus.be wrote:

 I have done so.

 Regards
 Niels


 On 15-01-15 18:21, Sampo Savolainen wrote:

 Hi,

 Can you push the rebased branch so I can test the exact same version?

 Sampo
 On Jan 15, 2015 5:37 PM, Niels Charlier ni...@scitus.be wrote:

   Hello Sampo,
 I cannot reproduce this error. I have rebased everything. I can use the
 mentioned file to create a datastore in geoserver.

 Regards,
 Niels

 On 15-01-15 12:02, Sampo Savolainen wrote:

   Hi,
 This should happen when adding a wfs-ng store using the mentioned test
 GetCapabilities file. If it works for you, then I guess something goes
 wrong when rebasing the branch.


 Sampo




 On Thu, Jan 15, 2015 at 12:42 PM, Niels Charlier ni...@scitus.be
 wrote:

  Hello Sampo,

 Can you clarify how I can reproduce this problem, if it doesn't occur
 in
 the tests?

 Regards
 Niels


 On 15-01-15 10:59, Sampo Savolainen wrote:

 Hi,

 Yeah, rebasing Niels's branch works.

 Unfortunately something is broken with the schema bindings in this
 branch. I'm unable to register the FMI Capabilities document with
 GeoServer
 (see exception below). The funny thing is, that the gt-xsd-wfs unit
 test
 that parses this document works fine. I also tried adding a parsing
 test
 for it in gt-wfs-ng WFSClientTest.testInit_2_0() and that parses the
 document fine as well.

 ERROR:  'Parsing failed for Constraint: java.lang.RuntimeException:
 Unable to set property: NoValues for eobject: {
 http://www.opengis.net/ows/1.1}DomainType'
 org.geotools.data.DataSourceException: Exception parsing WFS
 capabilities
 at
 org.geotools.data.wfs.internal.GetCapabilitiesResponse.
 parseCapabilities(GetCapabilitiesResponse.java:132)
 at
 org.geotools.data.wfs.internal.GetCapabilitiesResponse.init
 (GetCapabilitiesResponse.java:101)
 at
 org.geotools.data.wfs.internal.GetCapabilitiesRequest.createResponse(
 GetCapabilitiesRequest.java:51)
 at
 org.geotools.data.ows.AbstractOpenWebService.internalIssueRequest(
 AbstractOpenWebService.java:427)
 at
 org.geotools.data.wfs.internal.WFSClient.internalIssueRequest(
 WFSClient.java:280)
 at
 org.geotools.data.wfs.internal.WFSClient.issueRequest(WFSClient.java:
 290)
 at
 org.geotools.data.wfs.internal.WFSClient.issueRequest(WFSClient.java:
 54)
 at
 org.geotools.data.ows.AbstractOpenWebService.negotiateVersion(
 AbstractOpenWebService.java:260)
 at
 org.geotools.data.ows.AbstractOpenWebService.init(
 AbstractOpenWebService.java:110)
 at org.geotools.data.wfs.internal.WFSClient.init(
 WFSClient.java:68)
 at org.geotools.data.wfs.internal.WFSClient.init(
 WFSClient.java:62)
 at
 org.geotools.data.wfs.WFSDataStoreFactory.createDataStore(
 WFSDataStoreFactory.java:454)
 at
 org.geotools.data.wfs.WFSDataStoreFactory.createDataStore(
 WFSDataStoreFactory.java:80)
 at
 org.vfny.geoserver.util.DataStoreUtils.getDataAccess(
 DataStoreUtils.java:89)
 at org.geoserver.catalog.ResourcePool.getDataStore(
 ResourcePool.java:580)
 at
 org.geoserver.catalog.impl.DataStoreInfoImpl.getDataStore(
 DataStoreInfoImpl.java:38)
 ...

 The document in question is in the geotools project:
 modules/extension/xsd/xsd-wfs/src/test/resources/org/geotools/wfs/fmi-
 GetCapabilities_2_0_0.xml

 The problem is probably with how OWS 1.1 bindings are registered
 within
 GeoServer.


  Sampo

 On Wed, Jan 14, 2015 at 5:13 PM, Andrea Aime 
 andrea.a...@geo-solutions.it

   wrote:
 On Wed, Jan 14, 2015 at 3:47 PM, Sampo Savolainen 
 sampo.savolai...@spatineo.com wrote:

Hi,

 As this does not (should not) touch on anything else, I think
 it's a
 candidate for including in the release. Of course there's not much
 time
 left for the freeze window. I'll test this as soon as I can. In
 fact, I
 tried to build this but I couldn't build GeoServer against your
 branch:

 [ERROR] Failed to execute goal
 org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile
 (default-compile) on project gs-main: Compilation failure:
 Compilation
 failure:
 [ERROR]
 /home/v2/git-luna-geoserver/geoserver/src/main/src/main/
 java/org/geoserver/config/GeoServerDataDirectory.java:[1248,32]
 error: cannot find symbol
 [ERROR] method validateRelativeURL(URL)
 [ERROR]
 /home/v2/git-luna-geoserver/geoserver/src/main/src/main/
 java/org/geoserver/config/GeoServerDataDirectory.java:[1242,12]
 error: method does not override or implement a method from a
 supertype
 [ERROR] - [Help 1]

 Do you know if the current GeoServer master borked or does your
 branch
 need rebasing?

  It's Niels branch

Re: [Geotools-devel] wfs 2.0 in wfs-ng module

[Niels Charlier]

Sampo, it works for me in a tomcat. I think the issue must be with your 
setup.

Regards
Niels

On 16-01-15 16:29, Niels Charlier wrote:
 I'll give it a try

 On 16-01-15 07:38, Sampo Savolainen wrote:
 Hi,
 
 This is weird: If I run GeoServer in eclipse using the Start class in
 gs-web-app, the Capabilities is registered fine. However, if I build the
 war and deploy it in tomcat, GeoServer cannot register the schema. Is there
 any chance you have time to check this?
 
 
Sampo
 
 On Thu, Jan 15, 2015 at 9:03 PM, Niels Charlierni...@scitus.be  wrote:
 
 I have done so.
 
 Regards
 Niels
 
 
 On 15-01-15 18:21, Sampo Savolainen wrote:
 
 Hi,
 
 Can you push the rebased branch so I can test the exact same version?
 
 Sampo
 On Jan 15, 2015 5:37 PM, Niels Charlierni...@scitus.be  wrote:
 
Hello Sampo,
 I cannot reproduce this error. I have rebased everything. I can use 
 the
 mentioned file to create a datastore in geoserver.
 
 Regards,
 Niels
 
 On 15-01-15 12:02, Sampo Savolainen wrote:
 
Hi,
 This should happen when adding a wfs-ng store using the mentioned 
 test
 GetCapabilities file. If it works for you, then I guess something 
 goes
 wrong when rebasing the branch.
 
 
  Sampo
 
 
 
 
 On Thu, Jan 15, 2015 at 12:42 PM, Niels Charlierni...@scitus.be
 wrote:
 
   Hello Sampo,
 
 Can you clarify how I can reproduce this problem, if it doesn't 
 occur
 in
 the tests?
 
 Regards
 Niels
 
 
 On 15-01-15 10:59, Sampo Savolainen wrote:
 
 Hi,
 
  Yeah, rebasing Niels's branch works.
 
  Unfortunately something is broken with the schema bindings 
  in this
 branch. I'm unable to register the FMI Capabilities document with
 GeoServer
 (see exception below). The funny thing is, that the gt-xsd-wfs 
 unit
 test
 that parses this document works fine. I also tried adding a 
 parsing
 test
 for it in gt-wfs-ng WFSClientTest.testInit_2_0() and that parses 
 the


--
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] wfs 2.0 in wfs-ng module

[Niels Charlier]

I have done so.

Regards
Niels

On 15-01-15 18:21, Sampo Savolainen wrote:
 Hi,

 Can you push the rebased branch so I can test the exact same version?

 Sampo
 On Jan 15, 2015 5:37 PM, Niels Charlier ni...@scitus.be wrote:

 Hello Sampo,

 I cannot reproduce this error. I have rebased everything. I can use the
 mentioned file to create a datastore in geoserver.

 Regards,
 Niels

 On 15-01-15 12:02, Sampo Savolainen wrote:

 Hi,

 This should happen when adding a wfs-ng store using the mentioned test
 GetCapabilities file. If it works for you, then I guess something goes
 wrong when rebasing the branch.


Sampo




 On Thu, Jan 15, 2015 at 12:42 PM, Niels Charlier ni...@scitus.be wrote:

 Hello Sampo,
 Can you clarify how I can reproduce this problem, if it doesn't occur in
 the tests?

 Regards
 Niels


 On 15-01-15 10:59, Sampo Savolainen wrote:

 Hi,

Yeah, rebasing Niels's branch works.

Unfortunately something is broken with the schema bindings in this
 branch. I'm unable to register the FMI Capabilities document with
 GeoServer
 (see exception below). The funny thing is, that the gt-xsd-wfs unit test
 that parses this document works fine. I also tried adding a parsing test
 for it in gt-wfs-ng WFSClientTest.testInit_2_0() and that parses the
 document fine as well.

ERROR:  'Parsing failed for Constraint: java.lang.RuntimeException:
 Unable to set property: NoValues for eobject: {
 http://www.opengis.net/ows/1.1}DomainType'
 org.geotools.data.DataSourceException: Exception parsing WFS
 capabilities
at
 org.geotools.data.wfs.internal.GetCapabilitiesResponse.
 parseCapabilities(GetCapabilitiesResponse.java:132)
at
 org.geotools.data.wfs.internal.GetCapabilitiesResponse.init
 (GetCapabilitiesResponse.java:101)
at
 org.geotools.data.wfs.internal.GetCapabilitiesRequest.createResponse(
 GetCapabilitiesRequest.java:51)
at
 org.geotools.data.ows.AbstractOpenWebService.internalIssueRequest(
 AbstractOpenWebService.java:427)
at
 org.geotools.data.wfs.internal.WFSClient.internalIssueRequest(
 WFSClient.java:280)
at
 org.geotools.data.wfs.internal.WFSClient.issueRequest(WFSClient.java:
 290)
at
 org.geotools.data.wfs.internal.WFSClient.issueRequest(WFSClient.java:54)
at
 org.geotools.data.ows.AbstractOpenWebService.negotiateVersion(
 AbstractOpenWebService.java:260)
at
 org.geotools.data.ows.AbstractOpenWebService.init(
 AbstractOpenWebService.java:110)
at org.geotools.data.wfs.internal.WFSClient.init(WFSClient.java:68)
at org.geotools.data.wfs.internal.WFSClient.init(WFSClient.java:62)
at
 org.geotools.data.wfs.WFSDataStoreFactory.createDataStore(
 WFSDataStoreFactory.java:454)
at
 org.geotools.data.wfs.WFSDataStoreFactory.createDataStore(
 WFSDataStoreFactory.java:80)
at
 org.vfny.geoserver.util.DataStoreUtils.getDataAccess(
 DataStoreUtils.java:89)
at org.geoserver.catalog.ResourcePool.getDataStore(
 ResourcePool.java:580)
at
 org.geoserver.catalog.impl.DataStoreInfoImpl.getDataStore(
 DataStoreInfoImpl.java:38)
 ...

The document in question is in the geotools project:
 modules/extension/xsd/xsd-wfs/src/test/resources/org/geotools/wfs/fmi-
 GetCapabilities_2_0_0.xml

The problem is probably with how OWS 1.1 bindings are registered within
 GeoServer.


 Sampo

 On Wed, Jan 14, 2015 at 5:13 PM, Andrea Aime 
 andrea.a...@geo-solutions.it

 wrote:
On Wed, Jan 14, 2015 at 3:47 PM, Sampo Savolainen 
 sampo.savolai...@spatineo.com wrote:

   Hi,
As this does not (should not) touch on anything else, I think it's a
 candidate for including in the release. Of course there's not much time
 left for the freeze window. I'll test this as soon as I can. In fact, I
 tried to build this but I couldn't build GeoServer against your branch:

[ERROR] Failed to execute goal
 org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile
 (default-compile) on project gs-main: Compilation failure: Compilation
 failure:
 [ERROR]
 /home/v2/git-luna-geoserver/geoserver/src/main/src/main/
 java/org/geoserver/config/GeoServerDataDirectory.java:[1248,32]
 error: cannot find symbol
 [ERROR] method validateRelativeURL(URL)
 [ERROR]
 /home/v2/git-luna-geoserver/geoserver/src/main/src/main/
 java/org/geoserver/config/GeoServerDataDirectory.java:[1242,12]
 error: method does not override or implement a method from a supertype
 [ERROR] - [Help 1]

Do you know if the current GeoServer master borked or does your
 branch
 need rebasing?

 It's Niels branch that needs rebasing
 Cheers
 Andrea

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

Ing. Andrea Aime
@geowolf
 Technical Lead

GeoSolutions S.A.S.
 Via Poggio alle Viti 1187
 55054  Massarosa (LU)
 Italy
 phone: +39 0584 962313 %2B39%200584%20962313
 fax: +39 0584 1660272 %2B39%200584%201660272
 mob: +39 339 8844549 %2B39%20%C2%A0339%208844549

http://www.geo-solutions.it
 http

Re: [Geotools-devel] wfs 2.0 in wfs-ng module

[Niels Charlier]

Hello Sampo,

I cannot reproduce this error. I have rebased everything. I can use the 
mentioned file to create a datastore in geoserver.

Regards,
Niels

On 15-01-15 12:02, Sampo Savolainen wrote:
 Hi,

 This should happen when adding a wfs-ng store using the mentioned test
 GetCapabilities file. If it works for you, then I guess something goes
 wrong when rebasing the branch.


   Sampo




 On Thu, Jan 15, 2015 at 12:42 PM, Niels Charlier ni...@scitus.be wrote:

   Hello Sampo,

 Can you clarify how I can reproduce this problem, if it doesn't occur in
 the tests?

 Regards
 Niels


 On 15-01-15 10:59, Sampo Savolainen wrote:

 Hi,

   Yeah, rebasing Niels's branch works.

   Unfortunately something is broken with the schema bindings in this
 branch. I'm unable to register the FMI Capabilities document with GeoServer
 (see exception below). The funny thing is, that the gt-xsd-wfs unit test
 that parses this document works fine. I also tried adding a parsing test
 for it in gt-wfs-ng WFSClientTest.testInit_2_0() and that parses the
 document fine as well.

   ERROR:  'Parsing failed for Constraint: java.lang.RuntimeException:
 Unable to set property: NoValues for eobject: {
 http://www.opengis.net/ows/1.1}DomainType'
 org.geotools.data.DataSourceException: Exception parsing WFS capabilities
   at
 org.geotools.data.wfs.internal.GetCapabilitiesResponse.parseCapabilities(GetCapabilitiesResponse.java:132)
   at
 org.geotools.data.wfs.internal.GetCapabilitiesResponse.init(GetCapabilitiesResponse.java:101)
   at
 org.geotools.data.wfs.internal.GetCapabilitiesRequest.createResponse(GetCapabilitiesRequest.java:51)
   at
 org.geotools.data.ows.AbstractOpenWebService.internalIssueRequest(AbstractOpenWebService.java:427)
   at
 org.geotools.data.wfs.internal.WFSClient.internalIssueRequest(WFSClient.java:280)
   at
 org.geotools.data.wfs.internal.WFSClient.issueRequest(WFSClient.java:290)
   at
 org.geotools.data.wfs.internal.WFSClient.issueRequest(WFSClient.java:54)
   at
 org.geotools.data.ows.AbstractOpenWebService.negotiateVersion(AbstractOpenWebService.java:260)
   at
 org.geotools.data.ows.AbstractOpenWebService.init(AbstractOpenWebService.java:110)
   at org.geotools.data.wfs.internal.WFSClient.init(WFSClient.java:68)
   at org.geotools.data.wfs.internal.WFSClient.init(WFSClient.java:62)
   at
 org.geotools.data.wfs.WFSDataStoreFactory.createDataStore(WFSDataStoreFactory.java:454)
   at
 org.geotools.data.wfs.WFSDataStoreFactory.createDataStore(WFSDataStoreFactory.java:80)
   at
 org.vfny.geoserver.util.DataStoreUtils.getDataAccess(DataStoreUtils.java:89)
   at org.geoserver.catalog.ResourcePool.getDataStore(ResourcePool.java:580)
   at
 org.geoserver.catalog.impl.DataStoreInfoImpl.getDataStore(DataStoreInfoImpl.java:38)
 ...

   The document in question is in the geotools project:
 modules/extension/xsd/xsd-wfs/src/test/resources/org/geotools/wfs/fmi-GetCapabilities_2_0_0.xml

   The problem is probably with how OWS 1.1 bindings are registered within
 GeoServer.


Sampo

 On Wed, Jan 14, 2015 at 5:13 PM, Andrea Aime andrea.a...@geo-solutions.it
 wrote:
   On Wed, Jan 14, 2015 at 3:47 PM, Sampo Savolainen 
 sampo.savolai...@spatineo.com wrote:

 Hi,

   As this does not (should not) touch on anything else, I think it's a
 candidate for including in the release. Of course there's not much time
 left for the freeze window. I'll test this as soon as I can. In fact, I
 tried to build this but I couldn't build GeoServer against your branch:

   [ERROR] Failed to execute goal
 org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile
 (default-compile) on project gs-main: Compilation failure: Compilation
 failure:
 [ERROR]
 /home/v2/git-luna-geoserver/geoserver/src/main/src/main/java/org/geoserver/config/GeoServerDataDirectory.java:[1248,32]
 error: cannot find symbol
 [ERROR] method validateRelativeURL(URL)
 [ERROR]
 /home/v2/git-luna-geoserver/geoserver/src/main/src/main/java/org/geoserver/config/GeoServerDataDirectory.java:[1242,12]
 error: method does not override or implement a method from a supertype
 [ERROR] - [Help 1]

   Do you know if the current GeoServer master borked or does your branch
 need rebasing?

   It's Niels branch that needs rebasing

 Cheers
 Andrea

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

   Ing. Andrea Aime
   @geowolf
 Technical Lead

   GeoSolutions S.A.S.
 Via Poggio alle Viti 1187
 55054  Massarosa (LU)
 Italy
 phone: +39 0584 962313 %2B39%200584%20962313
 fax: +39 0584 1660272 %2B39%200584%201660272
 mob: +39  339 8844549 %2B39%20%C2%A0339%208844549

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

   *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

 Le informazioni contenute in questo messaggio di posta elettronica e/o
 nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
 loro utilizzo è consentito esclusivamente al destinatario del messaggio,
 per le finalità

Re: [Geotools-devel] wfs 2.0 in wfs-ng module

[Niels Charlier]

Hi Sampo,

Your testing is important actually, so that we can be absolutely 100% 
sure there is no regression with regards to your work.


For WFS2.0/GML3.2 I use the geotools PullParser rather than the 
gt-wfs-ng's own internal parser. I think ideally we should get rid of 
the internal parser all together, but that requires more work to make 
sure we do not introduce any regressions in the older wfs/GML versions 
since there are some specifics implemented in that internal parser.


Next release would of course be great but I am not sure how realistic 
that is. For me personally I don't really mind if this change is 
postponed until next release if we need more time to perfect it, as long 
as we can move forward with integrating this work shortly. If others are 
enthousiastic about integrating this in the next stable release, I am 
available to do what it is possible.


Regards
Niels

On 14-01-15 14:51, Sampo Savolainen wrote:

Hi,

This is really good timing. We just noticed some issues regarding GML 
feature parsing when using my cascaded stored query support. I'll try 
your branch tomorrow and report back. In the meanwhile I'd like to 
know if you are proposing this feature for the next stable release?



 Sampo

On Tue, Jan 13, 2015 at 5:27 PM, Niels Charlier ni...@scitus.be 
mailto:ni...@scitus.be wrote:


Hello List,

I finished something I started last year but never finished:
enable WFS
2.0 in the wfs-ng module. Some of the work I had already prepared was
sitting in a separate branch called wfs-ng-improvements-2.0. Some
of the
work done in this branch had in the meantime been done a second
time by
Sampo Savolainen. I took me quite a bit of work merging with the
latest
version, because some things were done differently with the same
purpose.  I removed most of that stuff from my version, attempting to
keep only improvements from my work.

I managed to get WFS 2.0 getfeature requests to work in wfs-ng now
though, with preservations: it has been tested only with geoserver as
server and not extensively). But it looks very promising. I have
made a
pull request for this.

https://github.com/geotools/geotools/pull/681

Transactions do not yet work, but I believe they can made to work as
well with very minor changes. The wfs-ng module's unit tests are a bit
of a mess though, this requires more work. I created tests for some of
the specific issues that I solved, but the whole (testing getfeature
in wfs 2.0 for different servers) is still to be done properly.

Kind Regards
Niels


--
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in
Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely
compliant.
http://p.sf.net/sfu/gigenet
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
mailto:GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel




--
Sampo Savolainen
RD Director, Spatineo Oy
sampo.savolai...@spatineo.com mailto:sampo.savolai...@spatineo.com
+358-407555649
Linnankoskenkatu 16 A 17, 00250 Helsinki, Finland
www.spatineo.com http://www.spatineo.com, twitter.com/#!/spatineo 
http://twitter.com/#%21/spatineo
www.linkedin.com/company/spatineo-inc 
http://www.linkedin.com/company/spatineo-inc


This message may contain privileged and/or confidential information. 
If you

have received this e-mail in error or are not the intended recipient, you
may not use, copy, disseminate, or distribute it; do not open any
attachments, delete it immediately from your system and notify the sender
promptly by e-mail that you have done so.


--
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] wfs 2.0 in wfs-ng module

[Niels Charlier]

Hello List,

I finished something I started last year but never finished: enable WFS 
2.0 in the wfs-ng module. Some of the work I had already prepared was 
sitting in a separate branch called wfs-ng-improvements-2.0. Some of the 
work done in this branch had in the meantime been done a second time by 
Sampo Savolainen. I took me quite a bit of work merging with the latest 
version, because some things were done differently with the same 
purpose.  I removed most of that stuff from my version, attempting to 
keep only improvements from my work.

I managed to get WFS 2.0 getfeature requests to work in wfs-ng now 
though, with preservations: it has been tested only with geoserver as 
server and not extensively). But it looks very promising. I have made a 
pull request for this.

https://github.com/geotools/geotools/pull/681

Transactions do not yet work, but I believe they can made to work as 
well with very minor changes. The wfs-ng module's unit tests are a bit 
of a mess though, this requires more work. I created tests for some of 
the specific issues that I solved, but the whole (testing getfeature 
in wfs 2.0 for different servers) is still to be done properly.

Kind Regards
Niels

--
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel