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

2016-08-18 Thread Mark Prins 
thank you Niels!
This sounds really good, tied up in other work for 6 weeks or so, so will
have to wait to give this a shot.

Mark



-- 
Disclaimer;
This message is just a reflection of what I thought at the time of sending.
The message may contain information that is not intended for you or that
you don't understand.
--
___
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!

2016-08-17 Thread Jody Garnett 
That is great Niels - thank you very much!

I am inspired to factor out abstract datastore for the code-sprint. Are you
attending foss4g yourself?

--
Jody Garnett

On 17 August 2016 at 11:19, Niels Charlier  wrote:

> 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  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  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 
>>> 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 
>>> listGeoTools-Devel@lists.sourceforge.nethttps://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
>>>
>>>
>>
>>
>
>
>
> --
>
>
>
> ___
> GeoTools-Devel mailing 
>

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

2016-08-17 Thread Andrea Aime 
Hi Niels,
that's great, thanks for the update!

Cheers
Andrea


On Wed, Aug 17, 2016 at 11:19 AM, Niels Charlier  wrote:

> 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  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  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 
>>> 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 
>>> listGeoTools-Devel@lists.sourceforge.nethttps://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
>>>
>>>
>>
>>
>
>
>
> --
>
>
>
> ___
> GeoTools-Devel mailing 
> listGeoTools-Devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/geotools-devel
>
>
>
>

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

2016-08-17 Thread 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 > 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 > 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
> 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









--


___
GeoTools-Devel mailing list

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

2016-07-29 Thread 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 > 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 > 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
> 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







--
___
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!

2016-07-26 Thread Jody Garnett 
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  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  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 
>> 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 
>> listGeoTools-Devel@lists.sourceforge.nethttps://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
>>
>>
>
>
--
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!

2016-07-26 Thread 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 > 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
> 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




--
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!

2016-07-25 Thread Jody Garnett 
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  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 
> 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 
> listGeoTools-Devel@lists.sourceforge.nethttps://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
>
>
--
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!

2016-07-25 Thread 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!

2016-07-22 Thread Jody Garnett 
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

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

2016-07-21 Thread 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 > 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 > 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

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

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

2016-07-21 Thread Andrea Aime 
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  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  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
>>> 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

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

2016-07-21 Thread 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 > 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

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

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

2016-07-18 Thread Andrea Aime 
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  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
>> 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.

---
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and

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

2016-07-18 Thread 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!

2016-06-27 Thread 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!

2016-06-24 Thread Andrea Aime 
On Fri, Jun 24, 2016 at 4:43 PM, Niels Charlier  wrote:

> 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?
>

Hmm... dunno, I definitely intended to send them, but it could be that I
did not after all.
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

I believe something changed, the mapserver one is now a 7.0, it was not
even released back then.
Anyways, they should still be two good tests against other WFS
implementations. I never managed to find the time and do the test myself,
sorry...

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?
>

You'd need a old store config file for the wfs store, but then inject its
parameters in a wfs-ng that has a mock http client configured, and then I
guess see if the requests do work?
The worst issue we found in Jira was the one about wfs-ng not surviving a
geoserver restart, that one is hopefully fixed by now:
https://osgeo-org.atlassian.net/browse/GEOS-7437

I cannot think of other issues off the top of my head.


>
>
>
> 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.
>

Is there any chance to recognize that the store configuration was meant for
the old wfs, and act accordingly?
I checked but I don't see one.
Thinking about it, I'd treat the current wfs-ng behavior as a bug (it's
unlike any other store), but add a parameter, a system hint or a static
method that could flip a switch and give the old behavior to those that
have already upgraded to wfs-ng and need to retain its current behavior.
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.

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.

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

2016-06-24 Thread 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!

2016-06-24 Thread Andrea Aime 
On Fri, Jun 24, 2016 at 3:22 PM, Niels Charlier  wrote:

> 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.
>

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...


>
> Andrea can I ask you some clarification on this,
>
> On Wed, Apr 20, 2016 at 12:18 PM, Andrea Aime <
> andrea.a...@geo-solutions.it> 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?
>

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.


>
>  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 ...?
>

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...)

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.

---
--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT

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

2016-06-24 Thread 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] wfs-ng vs wfs datastore fight!

2016-04-28 Thread Mark Prins 
On 26-04-16 14:21, Andrea Aime wrote:
> Thanks Niels,
> Mark, I believe this opens the road for you to re-open that ticket (or
> create a new one) and
> possibly present a pull request to create an upgrade path for yourself
> (and everybody
> else using the wfs store directly).
>

It will take some time before I get around to this, but while we're at 
it the solution would IMO basically comprise:

  - adding a hint or connection param "use_wfs_legacy_naming"
  - making WFSDataStore#createTypeNames() [1] work with the hint while 
cooking up the names
  - some tests
  - some docs

I may have missed something here and something might break...
Currently the connection param looks easier to implement

[1] 
https://github.com/geotools/geotools/blob/42c4cc0c3d850b1dea50c07108f171aace35a798/modules/unsupported/wfs-ng/src/main/java/org/geotools/data/wfs/WFSDataStore.java#L108





> Cheers
> Andrea
>
>
> On Sat, Apr 23, 2016 at 12:18 AM, Niels Charlier  > wrote:
>
> 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:
>>
>> 
>>

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

2016-04-26 Thread Andrea Aime 
Thanks Niels,
Mark, I believe this opens the road for you to re-open that ticket (or
create a new one) and
possibly present a pull request to create an upgrade path for yourself (and
everybody
else using the wfs store directly).

Cheers
Andrea


On Sat, Apr 23, 2016 at 12:18 AM, Niels Charlier  wrote:

> 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
>

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

2016-04-22 Thread 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] wfs-ng vs wfs datastore fight!

2016-04-22 Thread Andrea Aime 
On Fri, Apr 22, 2016 at 7:48 PM, Andrea Aime 
wrote:

> 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.
>

Actually, given that wfs-ng has been available for a few releases now,
probably the best option is to have
a configuration parameter that allows controlling this mapping behavior

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.

---
--
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!

2016-04-22 Thread Andrea Aime 
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 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

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

2016-04-22 Thread Mark Prins 
2016-04-22 9:18 GMT+02:00 Andrea Aime :

> On Thu, Apr 21, 2016 at 2:27 PM, Mark Prins  wrote:
>
>> > 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.
>>
>> This happened over christmas so it's gone a bit hazy by now, we upgraded
>> from 9.x to 14.x during that period, (late yes, but we were tied to
>> supporting Java 6)
>>
>
> Could you share with us a bit more about how the change affected your
> application?
> Your request of keeping support for the old wfs store seems to imply
> switching
> to wfs-ng would be a significant rework of your application
>
>
Sure,

In our application we have an admin define a view/map service (eg. WMS),
while the capabilities are retrieved we also try to discover a WFS (to use
for attribute info, tables, graphs etc.), if not discoverable the admin may
specify one himself (even a different service).

We store the WFS typenames in a table in our backend like so:

id;  description;geom-attr; type_name;
;writable; source id
"68";"Bedrijventerrein_kavels"; "geom";"Economie:Bedrijventerrein_kavels";
FALSE;14
"70";"EcMo_Wonen_regios";   "geom";"Economie:EcMo_Wonen_regios";
FALSE;14
"79";"BeschikbarePandenOpBedrijventerreinen";"geom";"IBIS_BeschikbarePandenOpBedrijventerreinen";FALSE;16
"80";"";"geom";"bedrijvenkavels_tijdelijk";
 TRUE;11


"Economie:Bedrijventerrein_kavels" being the typename reported by the WFS,
a test case illustrating this [0]. We use this typename to request features
from the WFS [1],

If I recall correctly wfs-ng reports "Economie_EcMo_Wonen_regios" as a
typename (instead of "Economie:EcMo_Wonen_regios") which breaks when just
using that in a getfeatures request also because the underscore is a
legitimate character in both layer name and namespace name (contrary to the
colon) it becomes impossible to determine which part is which (not possible
to use a simple split on ':' anymore). Our stored type_name is used in
various places in our application.

We can/should probably expand our model to store typename and namespace
separately to use this new naming convention and update the code to use
that. And cook up a migration script for our users.


[0]
https://github.com/flamingo-geocms/flamingo/blob/master/viewer-admin/src/test/java/nl/b3p/viewer/admin/stripes/WFSTypeNamingTest.java#L199
[1] eg.
https://github.com/flamingo-geocms/flamingo/blob/master/viewer-config-persistence/src/main/java/nl/b3p/viewer/config/services/WFSFeatureSource.java#L246



-- 
Disclaimer;
This message is just a reflection of what I thought at the time of sending.
The message may contain information that is not intended for you or that
you don't understand.
--
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!

2016-04-22 Thread Andrea Aime 
On Thu, Apr 21, 2016 at 2:27 PM, Mark Prins  wrote:

> > 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.
>
> This happened over christmas so it's gone a bit hazy by now, we upgraded
> from 9.x to 14.x during that period, (late yes, but we were tied to
> supporting Java 6)
>

Could you share with us a bit more about how the change affected your
application?
Your request of keeping support for the old wfs store seems to imply
switching
to wfs-ng would be a significant rework of your application

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.

---
--
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!

2016-04-21 Thread Jody Garnett 
> > 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.

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.

I'd suggest to make this name mapping optional and disable by default to
> preserve backwards compatibility.
>

The drop-in replacement metric is being a trouble here, care was taken to
allow this to drop in and use the same connection parameters. I would
understand if the data store has some differences.

Is this change visible to GeoServer users? I guess it may be if the
geotools provided type name is recorded in the geoeserver configuration ...
and that value is fixed (there is no way to edit it as I have discovered
when renaming tables in PostGIS).

Jody
--
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!

2016-04-21 Thread Andrea Aime 
On Thu, Apr 21, 2016 at 2:27 PM, Mark Prins  wrote:

> On 19-04-16 20:29, Andrea Aime wrote:
> > Hi Mark,
> > comments inline
> >
> > We've had to revert the upgrading of gt-wfs -> gt-wfs-ng due to the
> > naming convention change, we cache/store the namespace:typename of
> > featuretypes in our software and our things broke down all over the
> > place. Though documented, this really bit me in the ass, I expected
> our
> > upgrade to go a bit smoother.
> >
> >
> > 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"...

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

I'd suggest to make this name mapping optional and disable by default to
preserve backwards compatibility.

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.

---
--
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!

2016-04-21 Thread Mark Prins 
On 19-04-16 20:29, Andrea Aime wrote:
> Hi Mark,
> comments inline
>
> We've had to revert the upgrading of gt-wfs -> gt-wfs-ng due to the
> naming convention change, we cache/store the namespace:typename of
> featuretypes in our software and our things broke down all over the
> place. Though documented, this really bit me in the ass, I expected our
> upgrade to go a bit smoother.
>
>
> 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.

This happened over christmas so it's gone a bit hazy by now, we upgraded 
from 9.x to 14.x during that period, (late yes, but we were tied to 
supporting Java 6)

  Mark

--
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!

2016-04-20 Thread Andrea Aime 
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.
>

In a "long lived" projects... the point being that there is a significant
amount of users doing upgrades
and expecting things to keep on working (like Mark tried to do).

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.

---
--
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!

2016-04-20 Thread Andrea Aime 
On Wed, Apr 20, 2016 at 12:08 PM, Niels Charlier  wrote:

> 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.
>

Those two are solved already (by me and Ben).


>
> 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.
>

No objection here, my point is that wfs-ng has been pushed into GeoServer
as a replacement for the old wfs too soon, and without actual testing
outside the unit tests.


>
> 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.
>

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.

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.

---
--
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!

2016-04-20 Thread 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] wfs-ng vs wfs datastore fight!

2016-04-19 Thread Andrea Aime 
Hi Mark,
comments inline

We've had to revert the upgrading of gt-wfs -> gt-wfs-ng due to the
> naming convention change, we cache/store the namespace:typename of
> featuretypes in our software and our things broke down all over the
> place. Though documented, this really bit me in the ass, I expected our
> upgrade to go a bit smoother.
>

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?

I am wondering if this is also going to break all GeoServer upgrades for
data dirs that were using the old wfs store (if type names changed, there
is a good
chance they might)?
I believe an upgrade was not tested at all, otherwise we woudln't have seen
https://osgeo-org.atlassian.net/browse/GEOT-5374
(starting from an existing data dir the param should have been a string,
it's like a restart)

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.

---
--
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!

2016-04-19 Thread Mark Prins 
On 19-04-16 00:32, 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.

We've had to revert the upgrading of gt-wfs -> gt-wfs-ng due to the 
naming convention change, we cache/store the namespace:typename of 
featuretypes in our software and our things broke down all over the 
place. Though documented, this really bit me in the ass, I expected our 
upgrade to go a bit smoother.

A big plus for the gt-wfs-ng is the updated http library which fixes 
some issues.

I'm assuming this question bubbles up from the wish to drop gt-wfs from 
the library, I for one would like for it to be still around in 15.x

Mark


--
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!

2016-04-19 Thread Andrea Aime 
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 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.

---
--
Find and fix application

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

2016-04-18 Thread Jody Garnett 
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.

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).

--
Jody Garnett
--
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