ows4R will switch off s2 by default (s2 is not ISO/OGC compliant)

[eblondel]

sf now uses s2 as default geometry library with sf::sf_use_s2(TRUE). This will be set as FALSE when loading ows4R which provides an interface to OGC standard web-services, and then should rely on all underlying ISO/OGC standards which includes the actual Simple Features standard for handling geometry validity.

Apart the fact that this choice is clearly misleading with the original name of sf package which backbone is supposed to be the Simple Feature (aka "sf") ISO / OGC standard, although not referenced explicitely by the author, by through this wiki summary: https://en.wikipedia.org/wiki/Simple_Features having this set by default causes discrepancies with how the data is actually fetched and modeled on the backend (still using OGC standards, independently of their spatial reference system: as geographic coordinates - WGS84 - or projected)

Apparently s2 uses its own geometry data model, which is not ISO/OGC, and despites of the capabilities of s2 (that is not the purpose here), this model is not adapted for users working with spatial data infrastructures backed by OGC services and underlying standards.

Long story short: a geometry that is valid according to OGC, is not necessarily valid according to s2. THis prevents from reproducing geo-processes (unions, intersections) when s2 is activated.

For consistency with the umbrella of ows4R which is OGC focused, the OGC geometry model has to be used, so s2 should be turned off.

Example to highlight the issues of geometry validity with "sf" (ISO/OGC Simple Feature) vs. "s2":

require(ows4R)
require(sf)
require(testthat)

#wfs connector as example
WFS = WFSClient$new(
  url = "https://www.fao.org/fishery/geoserver/fifao/wfs",
  serviceVersion = "1.0.0",
  logger = "INFO"
)

#s2 TRUE
sf::sf_use_s2(TRUE)
sf = WFS$getFeatures("fifao:country_bounds", cql_filter = URLencode("ISO3CD IN('FRA','ESP','ITA')"))
testthat::expect_true(all(sf::st_is_valid(sf))) #fails although all geometries are OGC valid

#s2 FALSE
sf::sf_use_s2(FALSE) 
sf = WFS$getFeatures("fifao:country_bounds", cql_filter = URLencode("ISO3CD IN('FRA','ESP','ITA')"))
testthat::expect_true(all(sf::st_is_valid(sf))) #ok

[eblondel]

Referencing the suggest on s2 default setting in sf r-spatial/sf#2141

[edzer]

Apparently s2 uses its own geometry data model, which is not ISO/OGC

Emmanuel, can you tell me for coordinates in OGC:CRS84 whether LINESTRING(0 80, 180 80) intersects with POINT(0 90) or with POINT(90 80)? The SFA standard says that points are connected by a straight line, but which one is the (more) straight line? GeoJSON is explicit about this (section 5.1: the second option). I would say none of them is straight when following the Earth's surface, but the shorter one is more straight than the longer one. s2 gives you the first as answer, GEOS the second.

Tagging r-spatial/sf#2141 and #106

[eblondel]

@edzer You point out limits of how GIS coordinates have been modeled in time, and handled through standards. Standards have their limitations, standardization bodies, technical committees and working groups, their members (which include software providers and "client" organizations) and GIS data managers know that, and that's why they make evolving the standards in time, whatever component is targeted (data - as we discuss here -, metadata or services).

I'm not questioning s2 capability. You highlight an example to try to demonstrate that s2 is right. That behing spherical based,
it surely address limitation of the GIS standards set-up so far and then the libraries that rely on it (like GEOS). The point here is not to know if it is right,, it's the fact that it's not standard; and where I highlighted it "clashes" somehow with the the legacy behaviour and how the library sf is introduced to users (Simple Features is not s2, s2 is not Simple Features).

As matter of facts, all these standards are widely used, internationally recognized, and most organizations whatever their scale, are building on this, despite of their known limitations. In Europe, INSPIRE builds on this. Countries set-up up national spatial data infrastructures based on OGC standards. International organizations and their country members (like UN) build spatial data infrastructures based on OGC standards.
Handling data through SDI components is relying on OGC as backbone (still, in spite of the limitations). If I have a valid geometry in Postgis or a GeoPackage, I'm sure this geometry wil be valid a Web Feature Service or OGC API. Java based middleware that will interoperate with these WFS, based on JTS, will keep the same geometry validity. But for sf, to inherit the same behavior, I can but with s2 switched off, otherwise the chain is broken.

They are other examples of features in the spatial community (not in R) that were brought by software companies that went beyond the standard, as kind-of precursors to catalyze and shake the standard evolving , whenever it was needed, but in general extending them (case of OGC WMS vendor params not handled in the standard specifications, but progressively introduced by the communities both open-source and enterprise solutions). In general standards are assets, but we also have to cope with their limitations, and surely the drawback of this is that standardization takes time. Meanwhile, business geospatial processes that operate over these SDI need to rely on the same backbone to be operated and sustained. Introducing s2 in these chains break this backbone, because all other components are just not relying on s2 data model. In this overall SDI context, while using sf (and we use it a lot) there is no alternative than switching off s2 and rely on legacy OGC libraries like GEOS.

Your inputs would be probably very useful as contributions through standardization bodies to shape the new generation of standards that would overcome the limitations that you highlight.

[edzer]

As I asked on #28: which OGC document describes how "OGC valid" is defined for unprojected, ellipsoidal coordinates, and, associated with that, which OGC document explains whether the straight line LINESTRING(0 80, 180 80) with OGC:CRS84 coordinates passes through the North Pole or not?

I'm asking this because I believe you are conflating formal (OGC) standards with de facto standards (e.g., the things GIS software has always done over the last 6 decades). I hope you can prove me wrong.

[eblondel]

I will look into it. As i told you i have no pretentions to say you are wrong or right. Im not fan of any form of "radicalism" wrong vs right, opt in or opt out (if you see what i mean). My job is to find consensus, and i suggested you for good reasons to keep s2 but as plugin and not the default behavior. You disagreed. I already said that my purpose was not criticize s2 and judge what approach is "right". What i see is that s2 disrupts and blocks spatial data management more than it solved it in the current landscape of SDIs. The radical change you did it by switching with s2, probably based on good reasons as you say for the pure geometrical data handling, but they are also good reasons thinking in the broader view of how data is managed today (through SDIs) not to do so by default, but to propose it as extension. Maybe they are just assumptions that were inherited through ogc best practices, that remains to be confirmed, in which case these assumptions would be from the whole GIS community. I will certainly consult experts involved in the OGC to see if they can shed light on this. Cheers Le jeu. 13 avr. 2023 à 08:31, Edzer Pebesma ***@***.***> a écrit :

…

As I asked on #28 <#28>: which OGC document describes how "OGC valid" is defined for unprojected, ellipsoidal coordinates, and, associated with that, which OGC document explains whether the straight line LINESTRING(0 80, 180 80) with OGC:CRS84 coordinates passes through the North Pole or not? I'm asking this because I believe you are conflating formal (OGC) standards with *de facto* standards (e.g., the things GIS software has always done over the last 6 decades). I hope you can prove me wrong. — Reply to this email directly, view it on GitHub <#106 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKDK3AC6KKM3JZ4DTL322DXA6MVLANCNFSM6AAAAAAW36VKBI> . You are receiving this because you modified the open/close state.Message ID: ***@***.***>

[eblondel]

For the time being, for practical and functional reasons, and as matter to guarantee backward compatibility and interoperability, i will switch off s2 in dependent packages that relate to SDI management, and will advocate this to partners whenever they have the same data validation issues, see above example. Le jeu. 13 avr. 2023 à 09:35, Emmanuel Blondel ***@***.***> a écrit :

…

I will look into it. As i told you i have no pretentions to say you are wrong or right. Im not fan of any form of "radicalism" wrong vs right, opt in or opt out (if you see what i mean). My job is to find consensus, and i suggested you for good reasons to keep s2 but as plugin and not the default behavior. You disagreed. I already said that my purpose was not criticize s2 and judge what approach is "right". What i see is that s2 disrupts and blocks spatial data management more than it solved it in the current landscape of SDIs. The radical change you did it by switching with s2, probably based on good reasons as you say for the pure geometrical data handling, but they are also good reasons thinking in the broader view of how data is managed today (through SDIs) not to do so by default, but to propose it as extension. Maybe they are just assumptions that were inherited through ogc best practices, that remains to be confirmed, in which case these assumptions would be from the whole GIS community. I will certainly consult experts involved in the OGC to see if they can shed light on this. Cheers Le jeu. 13 avr. 2023 à 08:31, Edzer Pebesma ***@***.***> a écrit : > As I asked on #28 <#28>: which > OGC document describes how "OGC valid" is defined for unprojected, > ellipsoidal coordinates, and, associated with that, which OGC document > explains whether the straight line LINESTRING(0 80, 180 80) with > OGC:CRS84 coordinates passes through the North Pole or not? > > I'm asking this because I believe you are conflating formal (OGC) > standards with *de facto* standards (e.g., the things GIS software has > always done over the last 6 decades). I hope you can prove me wrong. > > — > Reply to this email directly, view it on GitHub > <#106 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAKDK3AC6KKM3JZ4DTL322DXA6MVLANCNFSM6AAAAAAW36VKBI> > . > You are receiving this because you modified the open/close state.Message > ID: ***@***.***> >

[eblondel]

📦 in 0.3-5, on CRAN https://cran.r-project.org/package=ows4R