[Geoserver-devel] Cloud native, dockerized, geoserver microservices project

Hi all,

I’d like to introduce this project to all developers. Some might know about it already from a couple PSC meetings ago https://github.com/camptocamp/geoserver-microservices.

First and foremost, let me note that I’ve taken the liberty to use, at least for the time being, the org.geoserver.cloud namespace, name the project “Cloud Native GeoServer”, and use directly other material from GeoServer - like the LICENSE.md, CODE_OF_CONDUCT.md, and CONTRIBUTING.md files - because both Camptocamp and the customer funding it intend to donate it in its entirety to the GeoServer community. So, following further discussion, may it not be acceptable to be somehow incorporated to GeoServer’s code-base, I’ll take care of remedying that.

In terms of donating the code, my preference would be for it to become a sibling project inside GeoServer’s github organization, being in nature a separate project that “uses” GeoServer components, and moving any module that extends GeoServer’s capabilities, as community modules, so they can also be used in its traditional form.

Secondly, let me encourage any interested party in participating by asking questions, trying it out, submitting bug reports, providing patches of course, etc. Read the project’s README, and let me know if there’s anything to clear up.

I haven’t set up a mailing list or other sort of discussion forum other than the github issues itself. May this project become part of the GeoServer community, we could decide together the best course of action.

Needless to say that this is very much work in progress, I’m glad and confident to send this email having it proved a feasible approach to build a microservices-architecture incarnation of our beloved GeoServer.

Best regards,

···

Gabriel Roldán

Hi Gabriel ! that is really good! Now taking a look at repo…it sounds really interesting !

Congrats !

Jose

On Sun, Sep 6, 2020 at 12:24 AM Gabriel Roldan <gabriel.roldan@anonymised.com> wrote:

Hi all,

I’d like to introduce this project to all developers. Some might know about it already from a couple PSC meetings ago https://github.com/camptocamp/geoserver-microservices.

First and foremost, let me note that I’ve taken the liberty to use, at least for the time being, the org.geoserver.cloud namespace, name the project “Cloud Native GeoServer”, and use directly other material from GeoServer - like the LICENSE.md, CODE_OF_CONDUCT.md, and CONTRIBUTING.md files - because both Camptocamp and the customer funding it intend to donate it in its entirety to the GeoServer community. So, following further discussion, may it not be acceptable to be somehow incorporated to GeoServer’s code-base, I’ll take care of remedying that.

In terms of donating the code, my preference would be for it to become a sibling project inside GeoServer’s github organization, being in nature a separate project that “uses” GeoServer components, and moving any module that extends GeoServer’s capabilities, as community modules, so they can also be used in its traditional form.

Secondly, let me encourage any interested party in participating by asking questions, trying it out, submitting bug reports, providing patches of course, etc. Read the project’s README, and let me know if there’s anything to clear up.

I haven’t set up a mailing list or other sort of discussion forum other than the github issues itself. May this project become part of the GeoServer community, we could decide together the best course of action.

Needless to say that this is very much work in progress, I’m glad and confident to send this email having it proved a feasible approach to build a microservices-architecture incarnation of our beloved GeoServer.

Best regards,

Gabriel Roldán


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

Morning Gabe:

Just getting back after a long weekend, I look forward to reviewing your repo and approach (although you covered some of this in geoserver meetings in the last month).

It is good to know the intention to include in the community, perhaps a proposal can be started now to collect notes and feedback. The CODE_OF_CONDUCT.md presently lists Simone as a contact person, perhaps you can fill you in your contact details there while this is under development. A proposal is also useful to establish what work/resources is needed so the geoserver community is in a position to accept.

When the time comes, for large contributions like this, we will no doubt ask that the parties involved fill in a “Software Grant and Corporate Contributor License Agreement” naming the project in order to donate it to OSGeo. This is how GeoServer and GeoWebCache were placed in the care of OSGeo.

Thanks for both starting this off Gabriel, and doing so with open communication.


Jody Garnett

On Sat, 5 Sep 2020 at 20:24, Gabriel Roldan <gabriel.roldan@anonymised.com> wrote:

Hi all,

I’d like to introduce this project to all developers. Some might know about it already from a couple PSC meetings ago https://github.com/camptocamp/geoserver-microservices.

First and foremost, let me note that I’ve taken the liberty to use, at least for the time being, the org.geoserver.cloud namespace, name the project “Cloud Native GeoServer”, and use directly other material from GeoServer - like the LICENSE.md, CODE_OF_CONDUCT.md, and CONTRIBUTING.md files - because both Camptocamp and the customer funding it intend to donate it in its entirety to the GeoServer community. So, following further discussion, may it not be acceptable to be somehow incorporated to GeoServer’s code-base, I’ll take care of remedying that.

In terms of donating the code, my preference would be for it to become a sibling project inside GeoServer’s github organization, being in nature a separate project that “uses” GeoServer components, and moving any module that extends GeoServer’s capabilities, as community modules, so they can also be used in its traditional form.

Secondly, let me encourage any interested party in participating by asking questions, trying it out, submitting bug reports, providing patches of course, etc. Read the project’s README, and let me know if there’s anything to clear up.

I haven’t set up a mailing list or other sort of discussion forum other than the github issues itself. May this project become part of the GeoServer community, we could decide together the best course of action.

Needless to say that this is very much work in progress, I’m glad and confident to send this email having it proved a feasible approach to build a microservices-architecture incarnation of our beloved GeoServer.

Best regards,

Gabriel Roldán


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

Hi Jody,

Morning Gabe:

Just getting back after a long weekend, I look forward to reviewing your repo and approach (although you covered some of this in geoserver meetings in the last month).

It is good to know the intention to include in the community, perhaps a proposal can be started now to collect notes and feedback.

Yeah, that’s probably the best course of action, just looking for consensus, let’s see if someone else chimes in.

The CODE_OF_CONDUCT.md presently lists Simone as a contact person, perhaps you can fill you in your contact details there while this is under development.

Done, good catch.

A proposal is also useful to establish what work/resources is needed so the geoserver community is in a position to accept.

When the time comes, for large contributions like this, we will no doubt ask that the parties involved fill in a “Software Grant and Corporate Contributor License Agreement” naming the project in order to donate it to OSGeo. This is how GeoServer and GeoWebCache were placed in the care of OSGeo.

Sounds absolutely reasonable.

Thanks for both starting this off Gabriel, and doing so with open communication.

No problem. As mentioned on the PSC meetings, I waited until I was confident the approach is proved feasible, given basically the complexity of it all when it comes to splitting out such a monster into smaller pieces. Of course, there’s a lot to figure out yet, but some of the biggest questions have been answered in the prototype phase, so, cool.

···

Gabriel Roldán

Hi all,

Internal priority shifts stalled the continuation of this discussion until now. We at Camptocamp managed to release the second stable prototype of the Cloud Native GeoServer project and are now in a position and willing to proceed with donating it to the GeoServer community.

Here’s the current project URL: https://github.com/camptocamp/geoserver-microservices

While I’m working to generate more documentation, it’d be good to gather your feedback.

Two courses of action have been mentioned previously: making a proposal (which I take as a GSIP), and that the parties involved fill in a “Software Grant and Corporate Contributor License Agreement” naming the project in order to donate it to OSGeo.

Given the project can’t be put as a community module (technically it’s a separate, spring-boot project, and conceptually it’s not a GeoServer extension but a complete overhaul on its configuration and deployment mechanisms), the logical choice would be to host it as a sibling project at GeoServer’s Github organization.

So as for the proposal, I’m not sure a GSIP fits, although there’re valuable components developed under this new project that could well be subject of GSIPs to make their way upstream, such as improvements in the design of the catalog/config subsystem, event-based synchronization, and Jackson-databind bindings for all Catalog and Config objects, including GeoTools Filters.
Yet, since there’s probably no other prescribed process to support this sort of donation, at least to the best of my knowledge, we could probably abuse/extend the GSIP scope. What are the precedents in that regard? Has the landing of GeoFence as a sibling project gone through something similar?

As for granting rights to OSGeo, Camptocamp is willing to do so, so if you could point out how to proceed, I’d be glad to pursue it, once the PSC establishes the contribution can proceed.

That’s it for now,
looking forward to your comments.

Gabriel.

···

Gabriel Roldán

Two courses of action have been mentioned previously: making a proposal (which I take as a GSIP), and that the parties involved fill in a “Software Grant and Corporate Contributor License Agreement” naming the project in order to donate it to OSGeo.

A CLA is the minimum condition of a donation, indeed.
A GSIP is the official way to propose and explain changes and large additions to the project, so it could be a good fit, but I guess not a requirement.

Proposals have originally been added to ensure there was a clear idea of what to do, and all the necessary resources to actually do it.
If this is a one-off donation, the resourcing aspect is less important, the CLA is however of paramount importance, to avoid having
another Stratus-like project bit-rotting around, that GeoServer core devs cannot touch, in case an opportunity for reuse shows up.

Given the project can’t be put as a community module (technically it’s a separate, spring-boot project, and conceptually it’s not a GeoServer extension but a complete overhaul on its configuration and deployment mechanisms), the logical choice would be to host it as a sibling project at GeoServer’s Github organization.

Agreed.

So as for the proposal, I’m not sure a GSIP fits, although there’re valuable components developed under this new project that could well be subject of GSIPs to make their way upstream, such as improvements in the design of the catalog/config subsystem, event-based synchronization, and Jackson-databind bindings for all Catalog and Config objects, including GeoTools Filters.

Those should be subject to further GSIPs indeed, in case you want to migrate those bits to the main project.

Yet, since there’s probably no other prescribed process to support this sort of donation, at least to the best of my knowledge, we could probably abuse/extend the GSIP scope. What are the precedents in that regard? Has the landing of GeoFence as a sibling project gone through something similar?

Good point, I could not find a proposal for it. GeoFence back at the time gathered limited interest, we did not have much discussion about it.
I’ve found a mailing list thread: https://sourceforge.net/p/geoserver/mailman/geoserver-devel/thread/1534616.ijsF6tZBgt%40saxicola/#msg32882096
The thread also mentions a PSC meeting, but could not find the meeting notes related to it.

One important aspect of GeoFence is that it came as a packaged deal with some dedicated people to move the project forward.

What I would like to know is if the donation is a “one time drop” or it comes with plans for the future from the original developers,
and if they are available for its maintenance in the short to medium term. If not, that’s totally fine too, as long as we have a CLA.
In that case, if I may, I’d suggest to concentrate as much time as possible on documentation. I don’t know about other developers,
but personally, I’m not familiar with any of the technologies mentioned in the microservice project README.

Not worried about learning mind, I’ve just come out of a few months spent on DGGS concepts and a new OLAP database,
but the OGC testbed gave me opportunity and time to learn those new bits, which I did not have yet on the techs you’re mentioning above.

Cheers
Andrea

···

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

Hi Andrea,

thanks for the insightful reply.
Comments inline.

On Sat, 13 Feb 2021 at 10:27, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Fri, Feb 12, 2021 at 5:09 PM Gabriel Roldan <gabriel.roldan@anonymised.com> wrote:

Two courses of action have been mentioned previously: making a proposal (which I take as a GSIP), and that the parties involved fill in a “Software Grant and Corporate Contributor License Agreement” naming the project in order to donate it to OSGeo.

A CLA is the minimum condition of a donation, indeed.

Communicated to the project manager. Waiting for definitive confirmation, I don’t know if Camptocamp has signed a CLA already though.

A GSIP is the official way to propose and explain changes and large additions to the project, so it could be a good fit, but I guess not a requirement.

Settled then, I’ll be creating a GSIP and pointing to the project’s documentation.

Proposals have originally been added to ensure there was a clear idea of what to do, and all the necessary resources to actually do it.
If this is a one-off donation, the resourcing aspect is less important, the CLA is however of paramount importance, to avoid having
another Stratus-like project bit-rotting around, that GeoServer core devs cannot touch, in case an opportunity for reuse shows up.

My understanding is the project was intended to be donated to the community from its inception, and Camptocamp is going to keep using it with the current and other customers, which will provide funding and hence resourcing both for maintenance and continued development. The donation comes in the spirit that it’ll be useful to other parties and in the hope of establishing a healthy relationship with the community, feeding on GeoServer, and contributing back to the upstream project.

Given the project can’t be put as a community module (technically it’s a separate, spring-boot project, and conceptually it’s not a GeoServer extension but a complete overhaul on its configuration and deployment mechanisms), the logical choice would be to host it as a sibling project at GeoServer’s Github organization.

Agreed.

Nice.

So as for the proposal, I’m not sure a GSIP fits, although there’re valuable components developed under this new project that could well be subject of GSIPs to make their way upstream, such as improvements in the design of the catalog/config subsystem, event-based synchronization, and Jackson-databind bindings for all Catalog and Config objects, including GeoTools Filters.

Those should be subject to further GSIPs indeed, in case you want to migrate those bits to the main project.

Yes, I’ll start by splitting them into community modules where appropriate. There’s a good chance of being able of reusing them, confining the spring-boot aspects (auto-configuration and the like) to this project. Took care that even the Catalog/Config improvements can start being community modules to ease the discussion and testing while/if they make their way to core.

Yet, since there’s probably no other prescribed process to support this sort of donation, at least to the best of my knowledge, we could probably abuse/extend the GSIP scope. What are the precedents in that regard? Has the landing of GeoFence as a sibling project gone through something similar?

Good point, I could not find a proposal for it. GeoFence back at the time gathered limited interest, we did not have much discussion about it.
I’ve found a mailing list thread: https://sourceforge.net/p/geoserver/mailman/geoserver-devel/thread/1534616.ijsF6tZBgt%40saxicola/#msg32882096
The thread also mentions a PSC meeting, but could not find the meeting notes related to it.

One important aspect of GeoFence is that it came as a packaged deal with some dedicated people to move the project forward.

What I would like to know is if the donation is a “one time drop” or it comes with plans for the future from the original developers,
and if they are available for its maintenance in the short to medium term.

As mentioned above, not a one-time drop. For the immediate future, there’s a commitment on maintenance and bug fixing, and for the medium term, there’s the intention of further development.
I’ll be talking to my manager though to be extra sure about this.

If not, that’s totally fine too, as long as we have a CLA.
In that case, if I may, I’d suggest to concentrate as much time as possible on documentation. I don’t know about other developers,
but personally, I’m not familiar with any of the technologies mentioned in the microservice project README.

Totally agree, and exactly the path we’re taking. For the moment, documentation is being added to the project’s site here https://camptocamp.github.io/geoserver-microservices/
What’s published there so far is insufficient but there’s more structured technical documentation in the works. I’ll try to sync the GSIP timing with enough documentation there.

Cheers,
Gabriel.

Not worried about learning mind, I’ve just come out of a few months spent on DGGS concepts and a new OLAP database,
but the OGC testbed gave me opportunity and time to learn those new bits, which I did not have yet on the techs you’re mentioning above.

Cheers
Andrea

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

Gabriel Roldán

Great to progress on this Gabe, thanks for keeping communication going.

Attending a GeoServer meeting and requesting a repository (like was done for GeoFence and GeoServer Docker) is a good way to go. I could not see in email how GeoFence was added some years ago beyond an initial email to the list from Andrea.


Jody Garnett

On Fri, 12 Feb 2021 at 08:07, Gabriel Roldan <gabriel.roldan@anonymised.com> wrote:

Hi all,

Internal priority shifts stalled the continuation of this discussion until now. We at Camptocamp managed to release the second stable prototype of the Cloud Native GeoServer project and are now in a position and willing to proceed with donating it to the GeoServer community.

Here’s the current project URL: https://github.com/camptocamp/geoserver-microservices

While I’m working to generate more documentation, it’d be good to gather your feedback.

Two courses of action have been mentioned previously: making a proposal (which I take as a GSIP), and that the parties involved fill in a “Software Grant and Corporate Contributor License Agreement” naming the project in order to donate it to OSGeo.

Given the project can’t be put as a community module (technically it’s a separate, spring-boot project, and conceptually it’s not a GeoServer extension but a complete overhaul on its configuration and deployment mechanisms), the logical choice would be to host it as a sibling project at GeoServer’s Github organization.

So as for the proposal, I’m not sure a GSIP fits, although there’re valuable components developed under this new project that could well be subject of GSIPs to make their way upstream, such as improvements in the design of the catalog/config subsystem, event-based synchronization, and Jackson-databind bindings for all Catalog and Config objects, including GeoTools Filters.
Yet, since there’s probably no other prescribed process to support this sort of donation, at least to the best of my knowledge, we could probably abuse/extend the GSIP scope. What are the precedents in that regard? Has the landing of GeoFence as a sibling project gone through something similar?

As for granting rights to OSGeo, Camptocamp is willing to do so, so if you could point out how to proceed, I’d be glad to pursue it, once the PSC establishes the contribution can proceed.

That’s it for now,
looking forward to your comments.

Gabriel.

On Wed, 9 Sept 2020 at 13:48, Gabriel Roldan <gabriel.roldan@anonymised.com…403…> wrote:

Hi Jody,

On Tue, 8 Sep 2020 at 23:27, Jody Garnett <jody.garnett@anonymised.com> wrote:

Morning Gabe:

Just getting back after a long weekend, I look forward to reviewing your repo and approach (although you covered some of this in geoserver meetings in the last month).

It is good to know the intention to include in the community, perhaps a proposal can be started now to collect notes and feedback.

Yeah, that’s probably the best course of action, just looking for consensus, let’s see if someone else chimes in.

The CODE_OF_CONDUCT.md presently lists Simone as a contact person, perhaps you can fill you in your contact details there while this is under development.

Done, good catch.

A proposal is also useful to establish what work/resources is needed so the geoserver community is in a position to accept.

When the time comes, for large contributions like this, we will no doubt ask that the parties involved fill in a “Software Grant and Corporate Contributor License Agreement” naming the project in order to donate it to OSGeo. This is how GeoServer and GeoWebCache were placed in the care of OSGeo.

Sounds absolutely reasonable.

Thanks for both starting this off Gabriel, and doing so with open communication.

No problem. As mentioned on the PSC meetings, I waited until I was confident the approach is proved feasible, given basically the complexity of it all when it comes to splitting out such a monster into smaller pieces. Of course, there’s a lot to figure out yet, but some of the biggest questions have been answered in the prototype phase, so, cool.


Jody Garnett

On Sat, 5 Sep 2020 at 20:24, Gabriel Roldan <gabriel.roldan@anonymised.com> wrote:

Hi all,

I’d like to introduce this project to all developers. Some might know about it already from a couple PSC meetings ago https://github.com/camptocamp/geoserver-microservices.

First and foremost, let me note that I’ve taken the liberty to use, at least for the time being, the org.geoserver.cloud namespace, name the project “Cloud Native GeoServer”, and use directly other material from GeoServer - like the LICENSE.md, CODE_OF_CONDUCT.md, and CONTRIBUTING.md files - because both Camptocamp and the customer funding it intend to donate it in its entirety to the GeoServer community. So, following further discussion, may it not be acceptable to be somehow incorporated to GeoServer’s code-base, I’ll take care of remedying that.

In terms of donating the code, my preference would be for it to become a sibling project inside GeoServer’s github organization, being in nature a separate project that “uses” GeoServer components, and moving any module that extends GeoServer’s capabilities, as community modules, so they can also be used in its traditional form.

Secondly, let me encourage any interested party in participating by asking questions, trying it out, submitting bug reports, providing patches of course, etc. Read the project’s README, and let me know if there’s anything to clear up.

I haven’t set up a mailing list or other sort of discussion forum other than the github issues itself. May this project become part of the GeoServer community, we could decide together the best course of action.

Needless to say that this is very much work in progress, I’m glad and confident to send this email having it proved a feasible approach to build a microservices-architecture incarnation of our beloved GeoServer.

Best regards,

Gabriel Roldán


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

Gabriel Roldán

Gabriel Roldán

Great to progress on this Gabe, thanks for keeping communication going.

Attending a GeoServer meeting and requesting a repository (like was done for GeoFence and GeoServer Docker) is a good way to go.

Stressing it’s a good way to go, not the only way. Official votes are still taken by mail, Skype meetings are only a way to communicate
faster (I think OSGeo board works differently, but this is not the board).

I could not see in email how GeoFence was added some years ago beyond an initial email to the list from Andrea.

There were two threads on the list about it specifically, one has been derailed by naming discussions.
The second mail refers to a discussion at the Skype meeting too.
Made a more substantial effort, here is a more complete set of references, including meeting minutes where GeoFence was named:

There is not much to track, a sustained communication attempt on the part of GeoSolutions seems evident, but not much discussion

about it in the end.

Cheers
Andrea

···

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

Very good!

Cheers
Andrea

···

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