-
Notifications
You must be signed in to change notification settings - Fork 2
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
Axis order #152
Comments
Eric, |
I wished you'd told me it was decided to follow geojson convention ("always" x,y). Although I understand the issue of axis order (abscisse first is just a mathematical convention) |
The gist of “years” of discussion about this issue has been to “tell the truth” since many software packages profess to follow the CRS axis order but do not. At least the the GeoJSON specification is explicit that everything follows EPSG:4326 except that it uses long,lat order. This is not the case with WKT, so if the coordinates are to be encoded in long,lat order, a coordinate system consistent with that, such as CRS84, must be provided. Otherwise not everyone knows the secret handshake, as below.
… On Feb 22, 2018, at 5:22 AM, Eric Boisvert ***@***.***> wrote:
I wished you'd told me it was decided to follow geojson convention ("always" x,y). Although I understand the issue of axis order (abscisse first is just a mathematical convention)
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub <#152 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AExWhqsnt1UibQ1HE89Xt3mpgqQ9tKaQks5tXT_ugaJpZM4SKzp1>.
|
There are not many things in this world that fill me with rage... but this, this is one of them. Since the WKT standard allows use of any CRS, we need to specify one. When I implement it in the other demo files I will. @afeliachi -- can you add CRS84 to your examples or switch the order and put 4326 on them? |
Deep breaths Dave. Deep breaths.
|
@dblodgett-usgs: will do. |
For the record... r-spatial/sf#653 |
Also, not that according to: https://www.w3.org/2015/spatial/wiki/Coordinate_Reference_Systems under GeoSPARQL,
So what @afeliachi did is technically sound? Should we still add http://www.opengis.net/def/crs/OGC/1.3/CRS84 to our gsp:wktLiterals? I did not do it for #159 and the package I'm using (see comment above) also emits lon/lat axis order for EPSG:4326. |
True, the CRS84 default is not in the WKT specification, but it is in Req. 10 of the GeoSPARQL spec. As long as the WKT literal without a CRS occurs in an asWKT property, i.e. clearly as a gsp:wktLiteral, a default is indeed specified.
… On Feb 27, 2018, at 12:03 PM, David Blodgett ***@***.***> wrote:
Also, not that according to: https://www.w3.org/2015/spatial/wiki/Coordinate_Reference_Systems <https://www.w3.org/2015/spatial/wiki/Coordinate_Reference_Systems> under GeoSPARQL,
In the WKT representation of geometry, GeoSPARQL uses the concept of a default CRS: “The URI http://www.opengis.net/def/crs/OGC/1.3/CRS84 <http://www.opengis.net/def/crs/OGC/1.3/CRS84> shall be assumed as the spatial reference system for geo:wktLiterals that do not specify an explicit spatial reference system URI.”
So what @afeliachi <https://github.com/afeliachi> did is technically sound? Should we still add http://www.opengis.net/def/crs/OGC/1.3/CRS84 <http://www.opengis.net/def/crs/OGC/1.3/CRS84> to our gsp:wktLiterals? I did not do it for #159 <#159> and the package I'm using (see comment above) also emits lon/lat axis order for EPSG:4326.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub <#152 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AExWhjiSf_i6UX9dSLUakj22T5Mcxd7jks5tZDVYgaJpZM4SKzp1>.
|
@dblodgett-usgs @lieberjosh thank you. I misread the Req. 11 in the WKT specification and I was going to edit the wktLiterals. With @sgrellet with decided to consider them under CRS84, thus no modification is needed. |
question: I see in BRGM examples this geometry
"gsp:asWKT":"POINT(2.3597603712661 49.9506859240222)"
which is long, lat if this is in France
OGC 11-052r4 req 12 says that "Coordinate tuple within geo:wtkLiteral shall be interpreted using the axis order defined in the spatial reference system". I assume the example above is EPSG:4326. Has this been overruled or is this EPSG:CRS84 ? I know GeoJson is limited to 4326 and sticks to long,lat,
Sorry if this has been discussed elsewhere (sorry, there is so much simultaneous on this github, it's hard to track)
The text was updated successfully, but these errors were encountered: