[gdal-dev] Logics of CPLGetXMLValue and CPLFetchBool

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

[gdal-dev] Logics of CPLGetXMLValue and CPLFetchBool

Ari Jolma-2
I thought it would be perhaps good to have CPLGetXMLBoolean since we
have CPLFetchBool and many of the option values needed by the new WCS
driver are boolean flags and the option values end up in the service
XML. It would twist the brain a bit less if one could simply use
CPLGetXMLBoolean.

The logic of CPLFetchBool is that it is true if a key exists but is not
defined or if the value is not something considered untrue ('NO', etc).
The logic of CPLGetXMLValue is that it returns the given default in the
case the element/attribute is not found or if it is found but is empty,
i.e., not defined.

Thus the return value of CPLGetXMLBoolean can't use CPLGetXMLValue if it
follows the logic of CPLFetchBool. That is true is existence and no denial.

What say?

Ari


_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Logics of CPLGetXMLValue and CPLFetchBool

Even Rouault-2

On mercredi 15 novembre 2017 10:58:23 CET Ari Jolma wrote:

> I thought it would be perhaps good to have CPLGetXMLBoolean since we

> have CPLFetchBool and many of the option values needed by the new WCS

> driver are boolean flags and the option values end up in the service

> XML. It would twist the brain a bit less if one could simply use

> CPLGetXMLBoolean.

>

> The logic of CPLFetchBool is that it is true if a key exists but is not

> defined or if the value is not something considered untrue ('NO', etc).

> The logic of CPLGetXMLValue is that it returns the given default in the

> case the element/attribute is not found or if it is found but is empty,

> i.e., not defined.

>

> Thus the return value of CPLGetXMLBoolean can't use CPLGetXMLValue if it

> follows the logic of CPLFetchBool. That is true is existence and no denial.

>

 

Why not

CPLGetXMLBoolean(node) == CPLTestBool(CPLGetXMLValue(node,NULL,"NO")) ?

 

 

--

Spatialys - Geospatial professional services

http://www.spatialys.com


_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Logics of CPLGetXMLValue and CPLFetchBool

Ari Jolma-2

Even Rouault kirjoitti 15.11.2017 klo 13:40:

On mercredi 15 novembre 2017 10:58:23 CET Ari Jolma wrote:


>

> Thus the return value of CPLGetXMLBoolean can't use CPLGetXMLValue if it

> follows the logic of CPLFetchBool. That is true is existence and no denial.

>

 

Why not

CPLGetXMLBoolean(node) == CPLTestBool(CPLGetXMLValue(node,NULL,"NO")) ?


Ah, but I want to test with node *and* path. Node will be the top level node of the service XML.

Anyway, I think I need to start with

CSLFetchNameValueDef(poOpenInfo->papszOpenOptions

and based on that explicitly set the element value to "TRUE" if the option exists and is not false. Then I can rely on the value of the element being "TRUE" if it is set.

Ari


 

 

--

Spatialys - Geospatial professional services

http://www.spatialys.com



_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Logics of CPLGetXMLValue and CPLFetchBool

Ari Jolma-2
Ari Jolma kirjoitti 15.11.2017 klo 15:51:

Even Rouault kirjoitti 15.11.2017 klo 13:40:

On mercredi 15 novembre 2017 10:58:23 CET Ari Jolma wrote:


>

> Thus the return value of CPLGetXMLBoolean can't use CPLGetXMLValue if it

> follows the logic of CPLFetchBool. That is true is existence and no denial.

>

 

Why not

CPLGetXMLBoolean(node) == CPLTestBool(CPLGetXMLValue(node,NULL,"NO")) ?


Ah, but I want to test with node *and* path. Node will be the top level node of the service XML.

Anyway, I think I need to start with

CSLFetchNameValueDef(poOpenInfo->papszOpenOptions

and based on that explicitly set the element value to "TRUE" if the option exists and is not false. Then I can rely on the value of the element being "TRUE" if it is set.

I think the best approach is

CPLGetXMLBoolean(node, path) ==

node = CPLGetXMLNode(node, path);
if node == NULL return FALSE;
value = CPLGetXMLValue(node, NULL, "");
if value == "" return TRUE;
return CPLTestBool(value);

This should return TRUE if the node exists and does not contain something that is considered untrue in GDAL, which is consistent with how CPLFetchBool() behaves.

Ari



Ari


 

 

--

Spatialys - Geospatial professional services

http://www.spatialys.com




_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev