[Geoserver-devel] New approach to GEOS-7301

Hi,

I recently created a ticket with a pull request to make GetFeature queries faster for data stores where counting features is slow. https://osgeo-org.atlassian.net/browse/GEOS-7301

In my pull request I proposed adding a new field to FeatureTypeInfo that would allow GeoServer to skip counting features altogether (under certain conditions) that would make things faster, but break strict compatibility with some types of queries. However I only later noted there is a flag already which does this in part: skipNumberMatched. I updated the ticket with a new proposal that I’ld like to get some comments on:

"I was looking at the existing flag in FeatureTypeInfo, skipNumberMatched. The implementation looks very close to what I’m trying to achieve here, but the current accepted implementation does not make GeoServer skip counting all features. More specifically, I’m referring to these rows of code:

https://github.com/geoserver/geoserver/blob/2e19a4ebe7f9c3698ac3eecf002da76bff0aa506/src/wfs/src/main/java/org/geoserver/wfs/GetFeature.java#L531

https://github.com/geoserver/geoserver/blob/2e19a4ebe7f9c3698ac3eecf002da76bff0aa506/src/wfs/src/main/java/org/geoserver/wfs/GetFeature.java#L552

Would you be willing to accept a patch where those counts are skipped if both:

  • primary feature of the query has skipNumberMatched = true, and

  • there is only a single query in the GetFeature request (paging

… ?

This would simplify this patch to only affecting GetFeature.java and remove the need for a new field in FeatureTypeInfo."

Can you think of any new problems with this approach (meaning that I should stick with adding a new flag to FeatureTypeInfo) or should I update my pull request based on this idea?

Sampo

···

Sampo Savolainen
Managing Director, Spatineo Oy
sampo.savolainen@…3889…
+358-407555649
Linnankoskenkatu 16 A 17, 00250 Helsinki, Finland
www.spatineo.com, twitter.com/#!/spatineo
www.linkedin.com/company/spatineo-inc

This message may contain privileged and/or confidential information. If you
have received this e-mail in error or are not the intended recipient, you
may not use, copy, disseminate, or distribute it; do not open any
attachments, delete it immediately from your system and notify the sender
promptly by e-mail that you have done so.

Hi Sampo,
if I understand your proposal correctly, you’re suggesting to break both standard and backwards compatibility, which
is not something I’m too keen to accept :-p
Unless I’m misunderstanding… been reviewing/fixing/merging pull requests all weekend and I’m pretty tired by now
(anyone reading: really need some help there btw).

The “number matched” count is available on in WFS 2.0, it’s a second count that’s used to notify the total number
of matched features in a paging situation.

So… we cannot have it skip also normal feature counting, that has a different meaning.

I checked if there is a way not to report the feature count, stating the value
is “unknown”. As far as I can see, in WFS 1.1 the numberOfFeatures attribute is optional:
http://schemas.opengis.net/wfs/1.1.0/wfs.xsd

However, it seems that in wfs 2.0 there is no salvation, the local count is mandatory:
http://schemas.opengis.net/wfs/2.0/wfs.xsd

In particular:

<xsd:attribute name=“numberMatched” type=“wfs:nonNegativeIntegerOrUnknown” use=“required”/>
<xsd:attribute name=“numberReturned” type=“xsd:nonNegativeIntegeruse=“required”/>

Another possible approach for very slow simple feature collections should be to dump

them on disk to avoid hitting the database again, it’s something we do in sorting/z-ordering in geotools for shapefiles
and friends, using a highly optimized binary feature serializer:
https://github.com/geotools/geotools/blob/master/modules/library/main/src/main/java/org/geotools/data/sort/SimpleFeatureIO.java

The sorting logic keeps a certain amount of features in memory (up to 1000 normally), past that they get dumped on disk
instead. Could be an option I guess, but yep, it would still require an extra flag in FeatureTypeInfo.

Cheers
Andrea

···

On Thu, Nov 12, 2015 at 3:31 PM, Sampo Savolainen <sampo.savolainen@anonymised.com> wrote:

Hi,

I recently created a ticket with a pull request to make GetFeature queries faster for data stores where counting features is slow. https://osgeo-org.atlassian.net/browse/GEOS-7301

In my pull request I proposed adding a new field to FeatureTypeInfo that would allow GeoServer to skip counting features altogether (under certain conditions) that would make things faster, but break strict compatibility with some types of queries. However I only later noted there is a flag already which does this in part: skipNumberMatched. I updated the ticket with a new proposal that I’ld like to get some comments on:

"I was looking at the existing flag in FeatureTypeInfo, skipNumberMatched. The implementation looks very close to what I’m trying to achieve here, but the current accepted implementation does not make GeoServer skip counting all features. More specifically, I’m referring to these rows of code:

https://github.com/geoserver/geoserver/blob/2e19a4ebe7f9c3698ac3eecf002da76bff0aa506/src/wfs/src/main/java/org/geoserver/wfs/GetFeature.java#L531

https://github.com/geoserver/geoserver/blob/2e19a4ebe7f9c3698ac3eecf002da76bff0aa506/src/wfs/src/main/java/org/geoserver/wfs/GetFeature.java#L552

Would you be willing to accept a patch where those counts are skipped if both:

  • primary feature of the query has skipNumberMatched = true, and

  • there is only a single query in the GetFeature request (paging

… ?

This would simplify this patch to only affecting GetFeature.java and remove the need for a new field in FeatureTypeInfo."

Can you think of any new problems with this approach (meaning that I should stick with adding a new flag to FeatureTypeInfo) or should I update my pull request based on this idea?

Sampo

Sampo Savolainen
Managing Director, Spatineo Oy
sampo.savolainen@anonymised.com
+358-407555649
Linnankoskenkatu 16 A 17, 00250 Helsinki, Finland
www.spatineo.com, twitter.com/#!/spatineo
www.linkedin.com/company/spatineo-inc

This message may contain privileged and/or confidential information. If you
have received this e-mail in error or are not the intended recipient, you
may not use, copy, disseminate, or distribute it; do not open any
attachments, delete it immediately from your system and notify the sender
promptly by e-mail that you have done so.



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

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

Ing. Andrea Aime

@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

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

AVVERTENZE AI SENSI DEL D.Lgs. 196/2003

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

The information in this message and/or attachments, is intended 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.


Hi,

Currently, GeoServer has the flag skipNumberMatched for FeatureTypeInfo, which can be used to disable calculating the number of matched results. So what I’m proposing is not at all new for GeoServer. However there are still some places (the ones I mentioned) where GetFeature might calculate the number of features even when this flag is enabled and the information is not necessary to enforce paging semantics. By my logic think we can safely skip counting features in those two places when skipNumberMatched is true and there is only one query in the GetFeature request (=because we don’t need to figure out which queries and offsets should be included in this page).

If you can confirm my hypothesis, this issue / patch can be treated as just an improvement to the existing skipNumberMatched feature that does not change query / paging semantics in any shape or form.

Sampo

···

On Sun, Nov 15, 2015 at 11:20 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

Hi Sampo,
if I understand your proposal correctly, you’re suggesting to break both standard and backwards compatibility, which
is not something I’m too keen to accept :-p
Unless I’m misunderstanding… been reviewing/fixing/merging pull requests all weekend and I’m pretty tired by now
(anyone reading: really need some help there btw).

The “number matched” count is available on in WFS 2.0, it’s a second count that’s used to notify the total number
of matched features in a paging situation.

So… we cannot have it skip also normal feature counting, that has a different meaning.

I checked if there is a way not to report the feature count, stating the value
is “unknown”. As far as I can see, in WFS 1.1 the numberOfFeatures attribute is optional:
http://schemas.opengis.net/wfs/1.1.0/wfs.xsd

However, it seems that in wfs 2.0 there is no salvation, the local count is mandatory:
http://schemas.opengis.net/wfs/2.0/wfs.xsd

In particular:

<xsd:attribute name=“numberMatched” type=“wfs:nonNegativeIntegerOrUnknown” use=“required”/>
<xsd:attribute name=“numberReturned” type=“xsd:nonNegativeIntegeruse=“required”/>

Another possible approach for very slow simple feature collections should be to dump

them on disk to avoid hitting the database again, it’s something we do in sorting/z-ordering in geotools for shapefiles
and friends, using a highly optimized binary feature serializer:
https://github.com/geotools/geotools/blob/master/modules/library/main/src/main/java/org/geotools/data/sort/SimpleFeatureIO.java

The sorting logic keeps a certain amount of features in memory (up to 1000 normally), past that they get dumped on disk
instead. Could be an option I guess, but yep, it would still require an extra flag in FeatureTypeInfo.

Cheers
Andrea

On Thu, Nov 12, 2015 at 3:31 PM, Sampo Savolainen <sampo.savolainen@anonymised.com> wrote:

Hi,

I recently created a ticket with a pull request to make GetFeature queries faster for data stores where counting features is slow. https://osgeo-org.atlassian.net/browse/GEOS-7301

In my pull request I proposed adding a new field to FeatureTypeInfo that would allow GeoServer to skip counting features altogether (under certain conditions) that would make things faster, but break strict compatibility with some types of queries. However I only later noted there is a flag already which does this in part: skipNumberMatched. I updated the ticket with a new proposal that I’ld like to get some comments on:

"I was looking at the existing flag in FeatureTypeInfo, skipNumberMatched. The implementation looks very close to what I’m trying to achieve here, but the current accepted implementation does not make GeoServer skip counting all features. More specifically, I’m referring to these rows of code:

https://github.com/geoserver/geoserver/blob/2e19a4ebe7f9c3698ac3eecf002da76bff0aa506/src/wfs/src/main/java/org/geoserver/wfs/GetFeature.java#L531

https://github.com/geoserver/geoserver/blob/2e19a4ebe7f9c3698ac3eecf002da76bff0aa506/src/wfs/src/main/java/org/geoserver/wfs/GetFeature.java#L552

Would you be willing to accept a patch where those counts are skipped if both:

  • primary feature of the query has skipNumberMatched = true, and

  • there is only a single query in the GetFeature request (paging

… ?

This would simplify this patch to only affecting GetFeature.java and remove the need for a new field in FeatureTypeInfo."

Can you think of any new problems with this approach (meaning that I should stick with adding a new flag to FeatureTypeInfo) or should I update my pull request based on this idea?

Sampo

Sampo Savolainen
Managing Director, Spatineo Oy
sampo.savolainen@anonymised.com
+358-407555649
Linnankoskenkatu 16 A 17, 00250 Helsinki, Finland
www.spatineo.com, twitter.com/#!/spatineo
www.linkedin.com/company/spatineo-inc

This message may contain privileged and/or confidential information. If you
have received this e-mail in error or are not the intended recipient, you
may not use, copy, disseminate, or distribute it; do not open any
attachments, delete it immediately from your system and notify the sender
promptly by e-mail that you have done so.



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

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

Ing. Andrea Aime

@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

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

AVVERTENZE AI SENSI DEL D.Lgs. 196/2003

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

The information in this message and/or attachments, is intended 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.


Sampo Savolainen
Managing Director, Spatineo Oy
sampo.savolainen@anonymised.com
+358-407555649
Linnankoskenkatu 16 A 17, 00250 Helsinki, Finland
www.spatineo.com, twitter.com/#!/spatineo
www.linkedin.com/company/spatineo-inc

This message may contain privileged and/or confidential information. If you
have received this e-mail in error or are not the intended recipient, you
may not use, copy, disseminate, or distribute it; do not open any
attachments, delete it immediately from your system and notify the sender
promptly by e-mail that you have done so.

Hi Adrea,

Do you have any comments on my email last week?

Sampo

···

On Thu, Nov 19, 2015 at 12:44 PM, Sampo Savolainen <sampo.savolainen@anonymised.com89…> wrote:

Hi,

Currently, GeoServer has the flag skipNumberMatched for FeatureTypeInfo, which can be used to disable calculating the number of matched results. So what I’m proposing is not at all new for GeoServer. However there are still some places (the ones I mentioned) where GetFeature might calculate the number of features even when this flag is enabled and the information is not necessary to enforce paging semantics. By my logic think we can safely skip counting features in those two places when skipNumberMatched is true and there is only one query in the GetFeature request (=because we don’t need to figure out which queries and offsets should be included in this page).

If you can confirm my hypothesis, this issue / patch can be treated as just an improvement to the existing skipNumberMatched feature that does not change query / paging semantics in any shape or form.

Sampo

On Sun, Nov 15, 2015 at 11:20 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

Hi Sampo,
if I understand your proposal correctly, you’re suggesting to break both standard and backwards compatibility, which
is not something I’m too keen to accept :-p
Unless I’m misunderstanding… been reviewing/fixing/merging pull requests all weekend and I’m pretty tired by now
(anyone reading: really need some help there btw).

The “number matched” count is available on in WFS 2.0, it’s a second count that’s used to notify the total number
of matched features in a paging situation.

So… we cannot have it skip also normal feature counting, that has a different meaning.

I checked if there is a way not to report the feature count, stating the value
is “unknown”. As far as I can see, in WFS 1.1 the numberOfFeatures attribute is optional:
http://schemas.opengis.net/wfs/1.1.0/wfs.xsd

However, it seems that in wfs 2.0 there is no salvation, the local count is mandatory:
http://schemas.opengis.net/wfs/2.0/wfs.xsd

In particular:

<xsd:attribute name=“numberMatched” type=“wfs:nonNegativeIntegerOrUnknown” use=“required”/>
<xsd:attribute name=“numberReturned” type=“xsd:nonNegativeIntegeruse=“required”/>

Another possible approach for very slow simple feature collections should be to dump

them on disk to avoid hitting the database again, it’s something we do in sorting/z-ordering in geotools for shapefiles
and friends, using a highly optimized binary feature serializer:
https://github.com/geotools/geotools/blob/master/modules/library/main/src/main/java/org/geotools/data/sort/SimpleFeatureIO.java

The sorting logic keeps a certain amount of features in memory (up to 1000 normally), past that they get dumped on disk
instead. Could be an option I guess, but yep, it would still require an extra flag in FeatureTypeInfo.

Cheers
Andrea

Sampo Savolainen
Managing Director, Spatineo Oy
sampo.savolainen@anonymised.com89…
+358-407555649
Linnankoskenkatu 16 A 17, 00250 Helsinki, Finland
www.spatineo.com, twitter.com/#!/spatineo
www.linkedin.com/company/spatineo-inc

This message may contain privileged and/or confidential information. If you
have received this e-mail in error or are not the intended recipient, you
may not use, copy, disseminate, or distribute it; do not open any
attachments, delete it immediately from your system and notify the sender
promptly by e-mail that you have done so.

On Thu, Nov 12, 2015 at 3:31 PM, Sampo Savolainen <sampo.savolainen@anonymised.com> wrote:

Hi,

I recently created a ticket with a pull request to make GetFeature queries faster for data stores where counting features is slow. https://osgeo-org.atlassian.net/browse/GEOS-7301

In my pull request I proposed adding a new field to FeatureTypeInfo that would allow GeoServer to skip counting features altogether (under certain conditions) that would make things faster, but break strict compatibility with some types of queries. However I only later noted there is a flag already which does this in part: skipNumberMatched. I updated the ticket with a new proposal that I’ld like to get some comments on:

"I was looking at the existing flag in FeatureTypeInfo, skipNumberMatched. The implementation looks very close to what I’m trying to achieve here, but the current accepted implementation does not make GeoServer skip counting all features. More specifically, I’m referring to these rows of code:

https://github.com/geoserver/geoserver/blob/2e19a4ebe7f9c3698ac3eecf002da76bff0aa506/src/wfs/src/main/java/org/geoserver/wfs/GetFeature.java#L531

https://github.com/geoserver/geoserver/blob/2e19a4ebe7f9c3698ac3eecf002da76bff0aa506/src/wfs/src/main/java/org/geoserver/wfs/GetFeature.java#L552

Would you be willing to accept a patch where those counts are skipped if both:

  • primary feature of the query has skipNumberMatched = true, and

  • there is only a single query in the GetFeature request (paging

… ?

This would simplify this patch to only affecting GetFeature.java and remove the need for a new field in FeatureTypeInfo."

Can you think of any new problems with this approach (meaning that I should stick with adding a new flag to FeatureTypeInfo) or should I update my pull request based on this idea?

Sampo

Sampo Savolainen
Managing Director, Spatineo Oy
sampo.savolainen@anonymised.com
+358-407555649
Linnankoskenkatu 16 A 17, 00250 Helsinki, Finland
www.spatineo.com, twitter.com/#!/spatineo
www.linkedin.com/company/spatineo-inc

This message may contain privileged and/or confidential information. If you
have received this e-mail in error or are not the intended recipient, you
may not use, copy, disseminate, or distribute it; do not open any
attachments, delete it immediately from your system and notify the sender
promptly by e-mail that you have done so.



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

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

Ing. Andrea Aime

@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

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

AVVERTENZE AI SENSI DEL D.Lgs. 196/2003

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

The information in this message and/or attachments, is intended 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.


Sampo Savolainen
Managing Director, Spatineo Oy
sampo.savolainen@anonymised.com
+358-407555649
Linnankoskenkatu 16 A 17, 00250 Helsinki, Finland
www.spatineo.com, twitter.com/#!/spatineo
www.linkedin.com/company/spatineo-inc

This message may contain privileged and/or confidential information. If you
have received this e-mail in error or are not the intended recipient, you
may not use, copy, disseminate, or distribute it; do not open any
attachments, delete it immediately from your system and notify the sender
promptly by e-mail that you have done so.

Hi Sampo,
I haven’t had time to re-read it (looked at it when you sent it 6 days ago), but I don’t see how it counters any argument in my previous mail. So… nothing to add, that’s why I did not follow up

Cheers
Andrea

···

On Wed, Nov 25, 2015 at 1:03 PM, Sampo Savolainen <sampo.savolainen@anonymised.com> wrote:

Hi Adrea,

Do you have any comments on my email last week?

Sampo

On Thu, Nov 19, 2015 at 12:44 PM, Sampo Savolainen <sampo.savolainen@…3889…> wrote:

Hi,

Currently, GeoServer has the flag skipNumberMatched for FeatureTypeInfo, which can be used to disable calculating the number of matched results. So what I’m proposing is not at all new for GeoServer. However there are still some places (the ones I mentioned) where GetFeature might calculate the number of features even when this flag is enabled and the information is not necessary to enforce paging semantics. By my logic think we can safely skip counting features in those two places when skipNumberMatched is true and there is only one query in the GetFeature request (=because we don’t need to figure out which queries and offsets should be included in this page).

If you can confirm my hypothesis, this issue / patch can be treated as just an improvement to the existing skipNumberMatched feature that does not change query / paging semantics in any shape or form.

Sampo

Sampo Savolainen
Managing Director, Spatineo Oy
sampo.savolainen@anonymised.com
+358-407555649
Linnankoskenkatu 16 A 17, 00250 Helsinki, Finland
www.spatineo.com, twitter.com/#!/spatineo
www.linkedin.com/company/spatineo-inc

This message may contain privileged and/or confidential information. If you
have received this e-mail in error or are not the intended recipient, you
may not use, copy, disseminate, or distribute it; do not open any
attachments, delete it immediately from your system and notify the sender
promptly by e-mail that you have done so.

On Sun, Nov 15, 2015 at 11:20 AM, Andrea Aime <andrea.aime@anonymised.com.1268…> wrote:

Hi Sampo,
if I understand your proposal correctly, you’re suggesting to break both standard and backwards compatibility, which
is not something I’m too keen to accept :-p
Unless I’m misunderstanding… been reviewing/fixing/merging pull requests all weekend and I’m pretty tired by now
(anyone reading: really need some help there btw).

The “number matched” count is available on in WFS 2.0, it’s a second count that’s used to notify the total number
of matched features in a paging situation.

So… we cannot have it skip also normal feature counting, that has a different meaning.

I checked if there is a way not to report the feature count, stating the value
is “unknown”. As far as I can see, in WFS 1.1 the numberOfFeatures attribute is optional:
http://schemas.opengis.net/wfs/1.1.0/wfs.xsd

However, it seems that in wfs 2.0 there is no salvation, the local count is mandatory:
http://schemas.opengis.net/wfs/2.0/wfs.xsd

In particular:

<xsd:attribute name=“numberMatched” type=“wfs:nonNegativeIntegerOrUnknown” use=“required”/>
<xsd:attribute name=“numberReturned” type=“xsd:nonNegativeIntegeruse=“required”/>

Another possible approach for very slow simple feature collections should be to dump

them on disk to avoid hitting the database again, it’s something we do in sorting/z-ordering in geotools for shapefiles
and friends, using a highly optimized binary feature serializer:
https://github.com/geotools/geotools/blob/master/modules/library/main/src/main/java/org/geotools/data/sort/SimpleFeatureIO.java

The sorting logic keeps a certain amount of features in memory (up to 1000 normally), past that they get dumped on disk
instead. Could be an option I guess, but yep, it would still require an extra flag in FeatureTypeInfo.

Cheers
Andrea

Sampo Savolainen
Managing Director, Spatineo Oy
sampo.savolainen@anonymised.com89…
+358-407555649
Linnankoskenkatu 16 A 17, 00250 Helsinki, Finland
www.spatineo.com, twitter.com/#!/spatineo
www.linkedin.com/company/spatineo-inc

This message may contain privileged and/or confidential information. If you
have received this e-mail in error or are not the intended recipient, you
may not use, copy, disseminate, or distribute it; do not open any
attachments, delete it immediately from your system and notify the sender
promptly by e-mail that you have done so.

On Thu, Nov 12, 2015 at 3:31 PM, Sampo Savolainen <sampo.savolainen@anonymised.com> wrote:

Hi,

I recently created a ticket with a pull request to make GetFeature queries faster for data stores where counting features is slow. https://osgeo-org.atlassian.net/browse/GEOS-7301

In my pull request I proposed adding a new field to FeatureTypeInfo that would allow GeoServer to skip counting features altogether (under certain conditions) that would make things faster, but break strict compatibility with some types of queries. However I only later noted there is a flag already which does this in part: skipNumberMatched. I updated the ticket with a new proposal that I’ld like to get some comments on:

"I was looking at the existing flag in FeatureTypeInfo, skipNumberMatched. The implementation looks very close to what I’m trying to achieve here, but the current accepted implementation does not make GeoServer skip counting all features. More specifically, I’m referring to these rows of code:

https://github.com/geoserver/geoserver/blob/2e19a4ebe7f9c3698ac3eecf002da76bff0aa506/src/wfs/src/main/java/org/geoserver/wfs/GetFeature.java#L531

https://github.com/geoserver/geoserver/blob/2e19a4ebe7f9c3698ac3eecf002da76bff0aa506/src/wfs/src/main/java/org/geoserver/wfs/GetFeature.java#L552

Would you be willing to accept a patch where those counts are skipped if both:

  • primary feature of the query has skipNumberMatched = true, and

  • there is only a single query in the GetFeature request (paging

… ?

This would simplify this patch to only affecting GetFeature.java and remove the need for a new field in FeatureTypeInfo."

Can you think of any new problems with this approach (meaning that I should stick with adding a new flag to FeatureTypeInfo) or should I update my pull request based on this idea?

Sampo

Sampo Savolainen
Managing Director, Spatineo Oy
sampo.savolainen@anonymised.com
+358-407555649
Linnankoskenkatu 16 A 17, 00250 Helsinki, Finland
www.spatineo.com, twitter.com/#!/spatineo
www.linkedin.com/company/spatineo-inc

This message may contain privileged and/or confidential information. If you
have received this e-mail in error or are not the intended recipient, you
may not use, copy, disseminate, or distribute it; do not open any
attachments, delete it immediately from your system and notify the sender
promptly by e-mail that you have done so.



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

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

Ing. Andrea Aime

@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

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

AVVERTENZE AI SENSI DEL D.Lgs. 196/2003

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

The information in this message and/or attachments, is intended 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.


==
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 Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

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

AVVERTENZE AI SENSI DEL D.Lgs. 196/2003

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

The information in this message and/or attachments, is intended 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.


I am catching up on email, and kind of wish we had an example to point to.

Is it worth writing up a proposal page so you can clearly describe “places you mentioned” where counting is still required?

My take on Andrea’s response is that the GML format is forcing us to count features for WFS 2.0 GetFeature. I do not think he was rejecting your approach, just pointing out a limitation of the specification.

Can I confirm that this feature counting is specific to GML output? Like if you were outputting geojson you would not need to count features?

···

On 25 November 2015 at 04:03, Sampo Savolainen <sampo.savolainen@anonymised.com> wrote:

Hi Adrea,

Do you have any comments on my email last week?

Sampo


Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741551&iu=/4140


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


Jody Garnett

On Thu, Nov 19, 2015 at 12:44 PM, Sampo Savolainen <sampo.savolainen@anonymised.com> wrote:

Hi,

Currently, GeoServer has the flag skipNumberMatched for FeatureTypeInfo, which can be used to disable calculating the number of matched results. So what I’m proposing is not at all new for GeoServer. However there are still some places (the ones I mentioned) where GetFeature might calculate the number of features even when this flag is enabled and the information is not necessary to enforce paging semantics. By my logic think we can safely skip counting features in those two places when skipNumberMatched is true and there is only one query in the GetFeature request (=because we don’t need to figure out which queries and offsets should be included in this page).

If you can confirm my hypothesis, this issue / patch can be treated as just an improvement to the existing skipNumberMatched feature that does not change query / paging semantics in any shape or form.

Sampo

Sampo Savolainen
Managing Director, Spatineo Oy
sampo.savolainen@anonymised.com
+358-407555649
Linnankoskenkatu 16 A 17, 00250 Helsinki, Finland
www.spatineo.com, twitter.com/#!/spatineo
www.linkedin.com/company/spatineo-inc

This message may contain privileged and/or confidential information. If you
have received this e-mail in error or are not the intended recipient, you
may not use, copy, disseminate, or distribute it; do not open any
attachments, delete it immediately from your system and notify the sender
promptly by e-mail that you have done so.

On Sun, Nov 15, 2015 at 11:20 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

Hi Sampo,
if I understand your proposal correctly, you’re suggesting to break both standard and backwards compatibility, which
is not something I’m too keen to accept :-p
Unless I’m misunderstanding… been reviewing/fixing/merging pull requests all weekend and I’m pretty tired by now
(anyone reading: really need some help there btw).

The “number matched” count is available on in WFS 2.0, it’s a second count that’s used to notify the total number
of matched features in a paging situation.

So… we cannot have it skip also normal feature counting, that has a different meaning.

I checked if there is a way not to report the feature count, stating the value
is “unknown”. As far as I can see, in WFS 1.1 the numberOfFeatures attribute is optional:
http://schemas.opengis.net/wfs/1.1.0/wfs.xsd

However, it seems that in wfs 2.0 there is no salvation, the local count is mandatory:
http://schemas.opengis.net/wfs/2.0/wfs.xsd

In particular:

<xsd:attribute name=“numberMatched” type=“wfs:nonNegativeIntegerOrUnknown” use=“required”/>
<xsd:attribute name=“numberReturned” type=“xsd:nonNegativeIntegeruse=“required”/>

Another possible approach for very slow simple feature collections should be to dump

them on disk to avoid hitting the database again, it’s something we do in sorting/z-ordering in geotools for shapefiles
and friends, using a highly optimized binary feature serializer:
https://github.com/geotools/geotools/blob/master/modules/library/main/src/main/java/org/geotools/data/sort/SimpleFeatureIO.java

The sorting logic keeps a certain amount of features in memory (up to 1000 normally), past that they get dumped on disk
instead. Could be an option I guess, but yep, it would still require an extra flag in FeatureTypeInfo.

Cheers
Andrea

Sampo Savolainen
Managing Director, Spatineo Oy
sampo.savolainen@anonymised.com89…
+358-407555649
Linnankoskenkatu 16 A 17, 00250 Helsinki, Finland
www.spatineo.com, twitter.com/#!/spatineo
www.linkedin.com/company/spatineo-inc

This message may contain privileged and/or confidential information. If you
have received this e-mail in error or are not the intended recipient, you
may not use, copy, disseminate, or distribute it; do not open any
attachments, delete it immediately from your system and notify the sender
promptly by e-mail that you have done so.

On Thu, Nov 12, 2015 at 3:31 PM, Sampo Savolainen <sampo.savolainen@anonymised.com> wrote:

Hi,

I recently created a ticket with a pull request to make GetFeature queries faster for data stores where counting features is slow. https://osgeo-org.atlassian.net/browse/GEOS-7301

In my pull request I proposed adding a new field to FeatureTypeInfo that would allow GeoServer to skip counting features altogether (under certain conditions) that would make things faster, but break strict compatibility with some types of queries. However I only later noted there is a flag already which does this in part: skipNumberMatched. I updated the ticket with a new proposal that I’ld like to get some comments on:

"I was looking at the existing flag in FeatureTypeInfo, skipNumberMatched. The implementation looks very close to what I’m trying to achieve here, but the current accepted implementation does not make GeoServer skip counting all features. More specifically, I’m referring to these rows of code:

https://github.com/geoserver/geoserver/blob/2e19a4ebe7f9c3698ac3eecf002da76bff0aa506/src/wfs/src/main/java/org/geoserver/wfs/GetFeature.java#L531

https://github.com/geoserver/geoserver/blob/2e19a4ebe7f9c3698ac3eecf002da76bff0aa506/src/wfs/src/main/java/org/geoserver/wfs/GetFeature.java#L552

Would you be willing to accept a patch where those counts are skipped if both:

  • primary feature of the query has skipNumberMatched = true, and

  • there is only a single query in the GetFeature request (paging

… ?

This would simplify this patch to only affecting GetFeature.java and remove the need for a new field in FeatureTypeInfo."

Can you think of any new problems with this approach (meaning that I should stick with adding a new flag to FeatureTypeInfo) or should I update my pull request based on this idea?

Sampo

Sampo Savolainen
Managing Director, Spatineo Oy
sampo.savolainen@anonymised.com
+358-407555649
Linnankoskenkatu 16 A 17, 00250 Helsinki, Finland
www.spatineo.com, twitter.com/#!/spatineo
www.linkedin.com/company/spatineo-inc

This message may contain privileged and/or confidential information. If you
have received this e-mail in error or are not the intended recipient, you
may not use, copy, disseminate, or distribute it; do not open any
attachments, delete it immediately from your system and notify the sender
promptly by e-mail that you have done so.



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

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

Ing. Andrea Aime

@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

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

AVVERTENZE AI SENSI DEL D.Lgs. 196/2003

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

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


On Thu, Nov 26, 2015 at 4:58 AM, Jody Garnett <jody.garnett@anonymised.com>
wrote:

I am catching up on email, and kind of wish we had an example to point to.

Is it worth writing up a proposal page so you can clearly describe "places
you mentioned" where counting is still required?

My take on Andrea's response is that the GML format is forcing us to count
features for WFS 2.0 GetFeature. I do not think he was rejecting your
approach, just pointing out a limitation of the specification.

Yes. It means whatever implementation we do has either lazy count, similar
to number matched, or we have a way to reach to the output
format and check its specific needs (something that would be useful for the
other need we'd might have, checking if the output
format has axis order assumptions... e.g., don't think anybody is happy
with us producing lat/lon ordered data in anything
but GML).

Can I confirm that this feature counting is specific to GML output? Like
if you were outputting geojson you would not need to count features?

Yes and no, we have a sequence of pull requests that introduced counts in
GeoJson output format, so someone definitely
needs it (to the point they contributed code for it). Generally speaking,
counting is useful for anyone in need of doing paging.
But I guess it could be made optional with a new config flag, of course,
only for the formats where it can be made optional.

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 Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

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

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

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

The information in this message and/or attachments, is intended 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.

-------------------------------------------------------

Hi,

I’ve finally got my head around Andrea’s objections and you are absolutely right. Refactoring the number of features returned as a lazily populated number, similar to the total count, seems a sane way to achieve this. But I’m a bit worried that if the feature count is added to the JSON output, then the performance benefits of this would be lost also for that format. I did some rudimentary tests in the environment I’m working with (oracle backed feature, features derived from views) and doing the extra select count() adds ~50% to the response time of the queries.

Do you have any idea what is the use case for having the count in the GML / JSON response? In GML, having the count as an attribute in the root element kills any possibility of fully streaming the results. Only a streaming parser could take advantage of the count before the full response is read. For GML, there is a guarantee that the consumer will receive the root element before the features. But I don’t think GeoJSON defines any order in which fields in JSON objects need to be presented in, so there would be no guarantee for the consumer that they would receive the number of features before actually streaming the features themselves. And when you have the features, you have the count.

Sampo

···

On Thu, Nov 26, 2015 at 9:21 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Thu, Nov 26, 2015 at 4:58 AM, Jody Garnett <jody.garnett@anonymised.com> wrote:

I am catching up on email, and kind of wish we had an example to point to.

Is it worth writing up a proposal page so you can clearly describe “places you mentioned” where counting is still required?

My take on Andrea’s response is that the GML format is forcing us to count features for WFS 2.0 GetFeature. I do not think he was rejecting your approach, just pointing out a limitation of the specification.

Yes. It means whatever implementation we do has either lazy count, similar to number matched, or we have a way to reach to the output
format and check its specific needs (something that would be useful for the other need we’d might have, checking if the output
format has axis order assumptions… e.g., don’t think anybody is happy with us producing lat/lon ordered data in anything
but GML).

Can I confirm that this feature counting is specific to GML output? Like if you were outputting geojson you would not need to count features?

Yes and no, we have a sequence of pull requests that introduced counts in GeoJson output format, so someone definitely
needs it (to the point they contributed code for it). Generally speaking, counting is useful for anyone in need of doing paging.
But I guess it could be made optional with a new config flag, of course, only for the formats where it can be made optional.

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 Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

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

AVVERTENZE AI SENSI DEL D.Lgs. 196/2003

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

The information in this message and/or attachments, is intended 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.


Sampo Savolainen
Managing Director, Spatineo Oy
sampo.savolainen@anonymised.com
+358-407555649
Linnankoskenkatu 16 A 17, 00250 Helsinki, Finland
www.spatineo.com, twitter.com/#!/spatineo
www.linkedin.com/company/spatineo-inc

This message may contain privileged and/or confidential information. If you
have received this e-mail in error or are not the intended recipient, you
may not use, copy, disseminate, or distribute it; do not open any
attachments, delete it immediately from your system and notify the sender
promptly by e-mail that you have done so.