[Geoserver-devel] XML alternative format for view parameters enhancement proposal

GeoServer GeoServer Developer
1

Dear community,

This is an idea proposal to enhance GeoServer view parameters to allow an XML format with more complex values definitions without the limit on not using reserved characters as the current plain format.

Current GeoServer view params documentation:
https://docs.geoserver.org/master/en/user/data/database/sqlview.html#using-a-parametric-sql-view

Motivation:
To have the ability of sending complex values into view parameters, like comma separated sublists, semicolon and comma separated inner sub-parameters, CSV sets, JSON/XML, etc.

Proposed XML alternative format:
The XML alternative format will include the following tags:

  • : defines a layer parameters, using the same layers order as the regular view parameters format.
  • : To be included inside the element. Defines a parameter on its nested element value, setting its parameter name using the “name” attribute.

Example:
&viewParams=538008302,244060802,53800850522,44acv,rrp;1,0;0,7;22,1

Current format support and backward compatibility:
The new alternative format will be only activated when a well formed XML including the Layer and Parameter tags are provided as value for the viewParams URL parameter in the request.
If this condition criteria is not accomplished, the regular view parameter format will be used, respecting backward compatibility and regular use cases.

Implementation hints:
Before writing the complete plan/proposal I would like to know the community feedback about this enhancement idea, but summarizing we should have:

  • New KVP parser implementation for XML formatted view parameters.
  • New tests checking this new implementation and checking backward compatibility.
  • A new section on GeoServer documentation covering this new format.

Naturally, any feedback to this enhancement is welcome. Thanks!!!

···

Regards,

Fernando Mino

==

GeoServer Professional Services from the experts!

Visit http://bit.ly/gs-services-us for more information.

==

Fernando Mino

Software Engineer

@fmy2kec

GeoSolutions Group
phone: +39 0584 962313

fax: +39 0584 1660272

https://www.geosolutionsgroup.com/

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.

2

Hi Fernando,
overall looks like a good addition, but I have a couple of comments, please see them below:

Dear community,

This is an idea proposal to enhance GeoServer view parameters to allow an XML format with more complex values definitions without the limit on not using reserved characters as the current plain format.

Current GeoServer view params documentation:
https://docs.geoserver.org/master/en/user/data/database/sqlview.html#using-a-parametric-sql-view

Motivation:
To have the ability of sending complex values into view parameters, like comma separated sublists, semicolon and comma separated inner sub-parameters, CSV sets, JSON/XML, etc.

Right, JSON support in RDBS is becoming more and more efficient, and I can see this being handy to pass down complex JSON expressions.

Proposed XML alternative format:
The XML alternative format will include the following tags:

  • : defines a layer parameters, using the same layers order as the regular view parameters format.

-1 here, I would recommend not relying on the order, but instead tying a parameter to a layer based on an XML tag, for example:

22,44

  • : To be included inside the element. Defines a parameter on its nested element value, setting its parameter name using the “name” attribute.

Example:
&viewParams=538008302,244060802,53800850522,44acv,rrp;1,0;0,7;22,1

I’m assuming that the values will then be used as-is in the downstream SQL query? In terms of XML encoding, this will follow a similar path to other XML parameters currently support in GeoServer? We will be able to escape reserved characters, the XML prefix and namespace will be optional?

Current format support and backward compatibility:
The new alternative format will be only activated when a well formed XML including the Layer and Parameter tags are provided as value for the viewParams URL parameter in the request.
If this condition criteria is not accomplished, the regular view parameter format will be used, respecting backward compatibility and regular use cases.

I would suggest adding a new parameter, viewParamsFormat to define the view parameters format explicitly, looks to me like it will be more efficient than trying each time to parsing n XML The parameter would be optional, and if not provided the default URL encoding would be used.

···

Regards,

Nuno Oliveira

==
GeoServer Professional Services from the experts!

Visit http://bit.ly/gs-services-us for more information.

Nuno Miguel Carvalho Oliveira
@nmcoliveira
Technical Lead / Project Manager

GeoSolutions Group
phone: +39 0584 962313
fax: +39 0584 1660272

https://www.geosolutionsgroup.com/
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.

3

Hi Nuno, thanks a lot for your feedback, replying to your inputs:

Proposed XML alternative format:
The XML alternative format will include the following tags:

  • : defines a layer parameters, using the same layers order as the regular view parameters format.

-1 here, I would recommend not relying on the order, but instead tying a parameter to a layer based on an XML tag, for example:

22,44

Indeed having explicit layer name makes sense, since we can have layers without parameters and using the name as identification we can set only the ones we want. The updated example:

&viewParams=538008302,244060802,53800850522,44acv,rrp;1,0;0,7;22,1

  • : To be included inside the element. Defines a parameter on its nested element value, setting its parameter name using the “name” attribute.

Example:
&viewParams=538008302,244060802,53800850522,44acv,rrp;1,0;0,7;22,1

I’m assuming that the values will then be used as-is in the downstream SQL query? In terms of XML encoding, this will follow a similar path to other XML parameters currently support in GeoServer? We will be able to escape reserved characters, the XML prefix and namespace will be optional?

  • Yes the values will be used in the internal SQL query parameters.
  • Yes we will use the same approach as already existing Filter KVP parsers, layers parsers.
  • We will use the same escape strategy as current view parameters implementation for all the values.
  • Yes, the XML prefix and namespace are optional.

Current format support and backward compatibility:
The new alternative format will be only activated when a well formed XML including the Layer and Parameter tags are provided as value for the viewParams URL parameter in the request.
If this condition criteria is not accomplished, the regular view parameter format will be used, respecting backward compatibility and regular use cases.

I would suggest adding a new parameter, viewParamsFormat to define the view parameters format explicitly, looks to me like it will be more efficient than trying each time to parsing n XML The parameter would be optional, and if not provided the default URL encoding would be used.

This makes sense and is indeed more efficient. I will add it to the plan making the viewParamsFormat parameter optional using the regular view params format as the default (allowing backward compatibility). Example to activate the XML parsing:

&viewParamsFormat=xml

···

Regards,

Fernando Mino

==

GeoServer Professional Services from the experts!

Visit http://bit.ly/gs-services-us for more information.

==

Fernando Mino

Software Engineer

@fmy2kec

GeoSolutions Group
phone: +39 0584 962313

fax: +39 0584 1660272

https://www.geosolutionsgroup.com/

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.

4

Hi all,
I can understand the desire to use a more structured format rather than fiddling with escape codes when dealing with
complex view params. At the same time, there is a practical limit… let’s look at content and size of your example:

538008302,244060802,53800850522,44acv,rrp;1,0;0,7;22,1

The XML most often cited downside is verbosity, and the above is already 250 chars. URLs have a practical size limit of 2000 chars, adding a few more params in there (or other request parameters) and you’ll quickly get to the maximum… at which point you can still do the request, but it’s going to have to switch to a POST request with form-url-encoded body.

Also, the idea of naming layers is at odds with OGC protocols: everything in a GetMap request is positionals, each multi-value parameter is an array of values (layers, styles, filters and so on) where the values are corresponding by position. Having one parameter breaking the well established pattern is weird, not to mention, you’ll have to maintain the positional approach for the current format.

Cheers
Andrea

···

Regards,

Andrea Aime

==
GeoServer Professional Services from the experts!

Visit http://bit.ly/gs-services-us for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions Group
phone: +39 0584 962313

fax: +39 0584 1660272

mob: +39 333 8128928

https://www.geosolutionsgroup.com/

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

5

Hi Andrea,
thank you for the feedback, find my replies below:

On Mon, Jul 4, 2022 at 5:25 PM Andrea Aime <andrea.aime@anonymised.com…6887…> wrote:

Hi all,
I can understand the desire to use a more structured format rather than fiddling with escape codes when dealing with
complex view params. At the same time, there is a practical limit… let’s look at content and size of your example:

538008302,244060802,53800850522,44acv,rrp;1,0;0,7;22,1

The XML most often cited downside is verbosity, and the above is already 250 chars. URLs have a practical size limit of 2000 chars, adding a few more params in there (or other request parameters) and you’ll quickly get to the maximum… at which point you can still do the request, but it’s going to have to switch to a POST request with form-url-encoded body.

Right, I guess for complex use cases switch to POST encoding will need to be done anyway, that say, we could shorten a bit the syntax:

538008302,244060802,538008505

22,44

acv,rrp;1,0;0,7;22,1

From 250 to 180.

Also, the idea of naming layers is at odds with OGC protocols: everything in a GetMap request is positionals, each multi-value parameter is an array of values (layers, styles, filters and so on) where the values are corresponding by position. Having one parameter breaking the well established pattern is weird, not to mention, you’ll have to maintain the positional approach for the current format.

Right, I didn’t think about the storage Java side, I guess relying on the order will help reduce the size even more:

538008302,244060802,538008505

22,44

,

acv,rrp;1,0;0,7;22,1

Down to 126 chars.

Kind regards,
Nuno Oliveira

Cheers
Andrea

On Mon, Jul 4, 2022 at 5:20 PM Fernando Mino <fernando.mino@anonymised.com> wrote:

Hi Nuno, thanks a lot for your feedback, replying to your inputs:

Proposed XML alternative format:
The XML alternative format will include the following tags:

  • : defines a layer parameters, using the same layers order as the regular view parameters format.

-1 here, I would recommend not relying on the order, but instead tying a parameter to a layer based on an XML tag, for example:

22,44

Indeed having explicit layer name makes sense, since we can have layers without parameters and using the name as identification we can set only the ones we want. The updated example:

&viewParams=538008302,244060802,53800850522,44acv,rrp;1,0;0,7;22,1

  • : To be included inside the element. Defines a parameter on its nested element value, setting its parameter name using the “name” attribute.

Example:
&viewParams=538008302,244060802,53800850522,44acv,rrp;1,0;0,7;22,1

I’m assuming that the values will then be used as-is in the downstream SQL query? In terms of XML encoding, this will follow a similar path to other XML parameters currently support in GeoServer? We will be able to escape reserved characters, the XML prefix and namespace will be optional?

  • Yes the values will be used in the internal SQL query parameters.
  • Yes we will use the same approach as already existing Filter KVP parsers, layers parsers.
  • We will use the same escape strategy as current view parameters implementation for all the values.
  • Yes, the XML prefix and namespace are optional.

Current format support and backward compatibility:
The new alternative format will be only activated when a well formed XML including the Layer and Parameter tags are provided as value for the viewParams URL parameter in the request.
If this condition criteria is not accomplished, the regular view parameter format will be used, respecting backward compatibility and regular use cases.

I would suggest adding a new parameter, viewParamsFormat to define the view parameters format explicitly, looks to me like it will be more efficient than trying each time to parsing n XML The parameter would be optional, and if not provided the default URL encoding would be used.

This makes sense and is indeed more efficient. I will add it to the plan making the viewParamsFormat parameter optional using the regular view params format as the default (allowing backward compatibility). Example to activate the XML parsing:

&viewParamsFormat=xml

Regards,

Fernando Mino

==

GeoServer Professional Services from the experts!

Visit http://bit.ly/gs-services-us for more information.

==

Fernando Mino

Software Engineer

@fmy2kec

GeoSolutions Group
phone: +39 0584 962313

fax: +39 0584 1660272

https://www.geosolutionsgroup.com/

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.

On Mon, Jul 4, 2022 at 4:57 AM Nuno Oliveira <nuno.oliveira@anonymised.com> wrote:

Hi Fernando,
overall looks like a good addition, but I have a couple of comments, please see them below:

On Fri, Jul 1, 2022 at 10:13 PM Fernando Mino <fernando.mino@anonymised.com> wrote:

Dear community,

This is an idea proposal to enhance GeoServer view parameters to allow an XML format with more complex values definitions without the limit on not using reserved characters as the current plain format.

Current GeoServer view params documentation:
https://docs.geoserver.org/master/en/user/data/database/sqlview.html#using-a-parametric-sql-view

Motivation:
To have the ability of sending complex values into view parameters, like comma separated sublists, semicolon and comma separated inner sub-parameters, CSV sets, JSON/XML, etc.

Right, JSON support in RDBS is becoming more and more efficient, and I can see this being handy to pass down complex JSON expressions.

Proposed XML alternative format:
The XML alternative format will include the following tags:

  • : defines a layer parameters, using the same layers order as the regular view parameters format.

-1 here, I would recommend not relying on the order, but instead tying a parameter to a layer based on an XML tag, for example:

22,44

  • : To be included inside the element. Defines a parameter on its nested element value, setting its parameter name using the “name” attribute.

Example:
&viewParams=538008302,244060802,53800850522,44acv,rrp;1,0;0,7;22,1

I’m assuming that the values will then be used as-is in the downstream SQL query? In terms of XML encoding, this will follow a similar path to other XML parameters currently support in GeoServer? We will be able to escape reserved characters, the XML prefix and namespace will be optional?

Current format support and backward compatibility:
The new alternative format will be only activated when a well formed XML including the Layer and Parameter tags are provided as value for the viewParams URL parameter in the request.
If this condition criteria is not accomplished, the regular view parameter format will be used, respecting backward compatibility and regular use cases.

I would suggest adding a new parameter, viewParamsFormat to define the view parameters format explicitly, looks to me like it will be more efficient than trying each time to parsing n XML The parameter would be optional, and if not provided the default URL encoding would be used.

Implementation hints:
Before writing the complete plan/proposal I would like to know the community feedback about this enhancement idea, but summarizing we should have:

  • New KVP parser implementation for XML formatted view parameters.
  • New tests checking this new implementation and checking backward compatibility.
  • A new section on GeoServer documentation covering this new format.

Naturally, any feedback to this enhancement is welcome. Thanks!!!

Regards,

Fernando Mino

==

GeoServer Professional Services from the experts!

Visit http://bit.ly/gs-services-us for more information.

==

Fernando Mino

Software Engineer

@fmy2kec

GeoSolutions Group
phone: +39 0584 962313

fax: +39 0584 1660272

https://www.geosolutionsgroup.com/

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.

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

–

Regards,

Nuno Oliveira

==
GeoServer Professional Services from the experts!

Visit http://bit.ly/gs-services-us for more information.

Nuno Miguel Carvalho Oliveira
@nmcoliveira
Technical Lead / Project Manager

GeoSolutions Group
phone: +39 0584 962313
fax: +39 0584 1660272

https://www.geosolutionsgroup.com/
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.

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

–

Regards,

Andrea Aime

==
GeoServer Professional Services from the experts!

Visit http://bit.ly/gs-services-us for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions Group
phone: +39 0584 962313

fax: +39 0584 1660272

mob: +39 333 8128928

https://www.geosolutionsgroup.com/

http://twitter.com/geosolutions_it

Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni circostanza inerente alla presente email (il suo contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato se potesse darmene notizia.

This email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. We remind that - as provided by European Regulation 2016/679 “GDPR” - copying, dissemination or use of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this email by mistake, please notify us immediately by telephone or e-mail

–

Regards,

Nuno Oliveira

==
GeoServer Professional Services from the experts!

Visit http://bit.ly/gs-services-us for more information.

Nuno Miguel Carvalho Oliveira
@nmcoliveira
Technical Lead / Project Manager

GeoSolutions Group
phone: +39 0584 962313
fax: +39 0584 1660272

https://www.geosolutionsgroup.com/
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.

6

Hi Andre and Nuno,

Thanks a lot for your feedback.

Indeed reducing the verbosity of the tag names will help a lot. Nuno’s example format looks nice:

538008302,244060802,538008505

22,44

,

acv,rrp;1,0;0,7;22,1

Also I agree positional layer parameters should be respected, in case of no parameters for a layer we should just add an empty tag on the layer position:

···

Regards,

Fernando Mino

==

GeoServer Professional Services from the experts!

Visit http://bit.ly/gs-services-us for more information.

==

Fernando Mino

Software Engineer

@fmy2kec

GeoSolutions Group
phone: +39 0584 962313

fax: +39 0584 1660272

https://www.geosolutionsgroup.com/

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.

7

Following this technical profile for the new XML view params format and fixing the XML to comply the XML standard I am updating the new format usage query parameters example as:

&viewParamsFormat=xml
&viewParams=

538008302,244060802,538008505

22,44

acv,rrp;1,0;0,7;22,1

XML tags/attributes definition:

  • VP: the root xml element tag for View Params. This was added to comply with the XML format validation.
  • PS: the parameters set XML element for the positional layer. If there are no parameters for the current layer this must be set as empty element
  • P: the parameter definition XML element, including the parameter name as the n attributer and the value as the XML element child value text.
  • n: the parameter name attribute inside the ‘P’ parameter definition element.

Note: If a layer doesn’t have parameters to set we just set an empty PS element as seen on the example:

···

Regards,

Fernando Mino

==

GeoServer Professional Services from the experts!

Visit http://bit.ly/gs-services-us for more information.

==

Fernando Mino

Software Engineer

@fmy2kec

GeoSolutions Group
phone: +39 0584 962313

fax: +39 0584 1660272

https://www.geosolutionsgroup.com/

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.

8

The XML most often cited downside is verbosity, and the above is already 250 chars. URLs have a practical size limit of 2000 chars, adding a few more params in there (or other request parameters) and you’ll quickly get to the maximum… at which point you can still do the request, but it’s going to have to switch to a POST request with form-url-encoded body.

Right, I guess for complex use cases switch to POST encoding will need to be done anyway, that say, we could shorten a bit the syntax:

538008302,244060802,538008505

22,44

acv,rrp;1,0;0,7;22,1

From 250 to 180.

I though for a moment you were just saving typing in email until you provided a character count.

If you reached the level of proposing shortening the tag names to save characters; if that is your challenge it is time to make the POST request. Or accept a different protocol (ogcapi is needed for your use case).

9

If XML is really not earning its keep switch to json or similar that preserves nesting: 110

{Layer1:{mnsi:‘538008302,244060802,538008505’},Layer2:{mnsi:‘22,44’},Layer3:{csvInput:‘acv,rrp;1,0;0,7;22,1’}}

Even adding quotes: 122

{‘Layer1’:{‘mnsi’:‘538008302,244060802,538008505’},‘Layer2’:{‘mnsi’:‘22,44’},‘Layer3’:{‘csvInput’:‘acv,rrp;1,0;0,7;22,1’}}

Or if you love XML treat it like the maven properties (not able to validate but succinct): 152

538008302,244060802,53800850522,44acv,rrp;1,0;0,7;22,1

···

–
Jody Garnett

10

Considering Andrea’s feedback on using position rather than layer name: 130 characters

538008302,244060802,53800850522,44acv,rrp;1,0;0,7;22,1

Or json-lite: 85 chracters

{mnsi:[‘538008302,244060802,538008505’,‘22,44’,],csvInput:[,‘acv,rrp;1,0;0,7;22,1’]}

···

Or json-quote: 95

{‘mnsi’:[‘538008302,244060802,538008505’,‘22,44’,‘’],‘csvInput’:[‘’,‘’,‘acv,rrp;1,0;0,7;22,1’]}

The quoting of " and ’ in a URL will make any of these hard to read so I encourage us to figure out any other approach.

Jody Garnett

–
Jody Garnett

11

Thanks for taking these ideas to the email list for discussion - much easier to design up front.

  • Your goal was to have “more” “better” view parameters :slight_smile:

  • To keep with the style of WMS it is good to use position (order) rather than a layer name

  • Encoding XML or JSON reduces readability of the URL a lot…

XML … allows for more complex value definitions - but still has a limit on reserved characters - it is just different reserved characters :slight_smile: The same thing for JSON.

How do you plan to look ahead when parsing KVP? Presently the KVP processing tends to split on “&”

Existing format is:

viewparams=p1:v1;p2:v2,p1:v2;p2:v3

Your escaped example is:

&viewparams=mnsi:538008302,244060802,538008505,mnsi:22,44,csvInput:acv,rrp;1,0;0,7;22,1&bbox=

Is it worth using a naming convention “viewparam-=”

&viewparam-mnsi=538008302,244060802,538008505,22,44,&viewparam-csvInput=,acv,rrp;1,0;0,7;22,1=&bbox

Unfortunately “,” is established as the separator for all the other parameters (styles= etc…) so it is hard to avoid escaping that. I think you could do better to support | rather than (or

)

&viewparam-mnsi=538008302,244060802,538008505|22,44|&viewparam-csvInput=||acv,rrp;1,0;0,7;22,1=&bbox

···

–
Jody Garnett

Or json-quote: 95

{‘mnsi’:[‘538008302,244060802,538008505’,‘22,44’,‘’],‘csvInput’:[‘’,‘’,‘acv,rrp;1,0;0,7;22,1’]}

The quoting of " and ’ in a URL will make any of these hard to read so I encourage us to figure out any other approach.

Jody Garnett

–
Jody Garnett