-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ows4R will switch off s2 by default (s2 is not ISO/OGC compliant) #106
Comments
Referencing the suggest on s2 default setting in sf r-spatial/sf#2141 |
Emmanuel, can you tell me for coordinates in Tagging r-spatial/sf#2141 and #106 |
@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, 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. 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. |
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 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. |
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: ***@***.***>
|
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: ***@***.***>
>
|
📦 in 0.3-5, on CRAN https://cran.r-project.org/package=ows4R |
sf now uses s2 as default geometry library with
sf::sf_use_s2(TRUE)
. This will be set asFALSE
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":
The text was updated successfully, but these errors were encountered: