Trying again, how to do geolocation using asWKT -- addresses #266

[ptsefton]

@marc-portier asking you to review as you may have advice about how to add projection info to the asWKT string value

(We can't do anything more complicated using @value constructs as tools don't support this (yet))

[marc-portier]

We are using WKT in our LOD publishing of marineregions.org and we just slice-in the in front of the WKT.

you can play around with e.g.
http://marineregions.org/mrgid/64446.jsonld
or http://marineregions.org/mrgid/64446.ttl

and maybe pull them through https://www.easyrdf.org/converter

possible serialisations then end up looking like

        "http://www.w3.org/ns/dcat#centroid": [
            {
                "@value": "<http://www.opengis.net/def/crs/OGC/1.3/CRS84> POINT (-4.57203 54.18818)",
                "@type": "http://www.opengis.net/ont/geosparql#wktLiteral"
            }
        ],

or:

    "@context": {
        "dcat:centroid": {
            "@type": "gsp:wktLiteral"
        },
    ...
    "dcat:centroid": "<http://www.opengis.net/def/crs/OGC/1.3/CRS84> POINT (-4.57203 54.18818)",

afaik the above is accepted practice in RDF-land, how well that transitions into actual support in GIS-land is unknown to me

so in the end I don't know what 'tools' you refer to, nor if any of the above will help you satisfy their needs / overcome their limitations, but you might be able to slide in some glue logic between how you receive this as proper RDF (jsonld) and how you pass this further down any GIS chain...

[marc-portier]

The usage of asWKT in your suggested commits made me check further on how your context would declare it.
Found:

  "asWKT": "http://www.opengis.net/ont/geosparql#asWKT"

that could be extended to

  "asWKT": {
        "@id": "http://www.opengis.net/ont/geosparql#asWKT",
        "@type": "http://www.opengis.net/ont/geosparql#wktLiteral"

see also :

• https://opengeospatial.github.io/ogc-geosparql/geosparql11/geo.ttl
• http://www.opengis.net/spec/geosparql/1.1/req/geometry-extension/wkt-literal

which kind of settles at least that this CRS inclusion into a wkt-literal is at least also something that seems to have some standing in the GIS-community itself -- so "some" tools could be expected to know or catch up with this?

anyway, from there I wondered further down via websearch to arrive at
ESIPFed/science-on-schema.org#105 (posting dated 2020 - discussion into 2022)

which mentions the usage of additional predicate 'crs' in the gsp namespace:

        "geosparql:crs": {
            "@id": "http://www.opengis.net/def/crs/OGC/1.3/CRS84"
        }

which however does not seem to actually exist :(

at least not in https://opengeospatial.github.io/ogc-geosparql/geosparql11/geo.ttl#crs
(i.e. as http://www.opengis.net/ont/geosparql#crs)

weird coincidence is that I know the poster of this message, so I am sending a personal message for him to maybe jot down an update or new insights on the topic...

[stain]

Approved - there will be a merge conflict with #291 in context.jsonld but easy to fix.

[stain]

@marc-portier Do you think it's important our context defines the Literal "@type": "http://www.opengis.net/ont/geosparql#wktLiteral" ? We're not using the rest of geosparql objects, only the Geometry, and ontology-wise this literal type is anyway implied.

[marc-portier]

@stain sorry about missing out the earlier question --> but I agree, no need for the @type

@ptsefton --> reading up the final suggested changes I am surprised we are now not mentioning (neither through note or sample) the (optional) inclusion of the <CRS-epsgi-uri> at the start of the WKT?

[marc-portier]

would surely prefer if we have an examples showing the inclusion of the at the start of the WKT

we could make it optional, and describe the benefits / drawbacks of including it or not:

• with --> benefit == fuller semantics, explicit statement of how to interpret the numbers
• without --> benefit == no need to split it out at client side before feeding into wkt driven visualiser that is not aware of this part (at the cost of facing that its built in default crs is not matching the one from the data)

if you agree, I can propose some addition through an extra commit into this branch for that

[ptsefton]

Yes sorry Marc that was missed it you could add it that would be great. On 29 Mar 2024 08:29, Marc Portier ***@***.***> wrote: @marc-portier commented on this pull request. would surely prefer if we have an examples showing the inclusion of the at the start of the WKT we could make it optional, and describe the benefits / drawbacks of including it or not: * with --> benefit == fuller semantics, explicit statement of how to interpret the numbers * without --> benefit == no need to split it out at client side before feeding into wkt driven visualiser that is not aware of this part (at the cost of facing that its built in default crs is not matching the one from the data) if you agree, I can propose some addition through an extra commit into this branch for that — Reply to this email directly, view it on GitHub<#288 (review)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAFYTWB7Y2C4N6ZTT5OTLUTY2R4SRAVCNFSM6AAAAABDVXRVWKVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMYTSNRXGQYDAMJSGA>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[marc-portier]

Yes sorry Marc that was missed it you could add it that would be great.

done