Json-LD instances test : need hasGeometry and asWKT aliases to declare geometry

[afeliachi]

Link to issue #136 . For WKT to be used as a main representation for extended geometries, hasGeometry and asWKT aliases should be added to ELFIE contexts. But where : elf-index.jsonld or elf-all.jsonld ?

[dblodgett-usgs]

Didn't we decide against using hasGeometry at all because it was cumbersome to work with in the tool chain that we are targeting?

[afeliachi]

Sorry I didn't know that you decided to go against using geosparql. Was it a discussed issue here? Can you point me to it please? AFAIK most of spatial tools undrestand and process WKT literals, in addition to all the benefits of GeoSparql .

[dblodgett-usgs]

There was a conversation about it on a telecon. @sgrellet had formed an opinion about it.

[afeliachi]

I've actually discussed the matter with @sgrellet. We were pretty confident towards using gsp WKT literals. I'll discuss it again with him when we meet.

[dblodgett-usgs]

OK. There may have been some misunderstanding.

[sgrellet]

the idea is that for non ponctual objects (river, aquifer) we will need to use gsp to pass the geometry. otherwise I don't really see how we could define what is the 'preview Geom' (point) for a river or an aquifer. ex : https://opengeospatial.github.io/ELFIE/FR/HY-WaterBody/sgwi/E6390710.

Having a 'side-car' full geometry file was apparently recently mentioned in one of the recent webconf I didn't attend. We don't understand the rationale of this here. May be worth going quickly over this next webconf ? Sorry for this.

[dblodgett-usgs]

We decided to allow inline specification of an accurate geometry using geosparql/WKT. However, recognizing that the WKT hasGeometry is not as ubiquitous as schema.org/geo we are going to use schema.org/geoCoordinates (point) for a reference point and reference a geojson document as the @id of a geojson json-ld relation within the schema.org/geoShape element.

We will note that this is an issue that needs resolution in the ER. The WKT spec is a bit too "heavy" compared to geojson and json-ld won't allow encoding geojson inline. Additionally, line and polygon in schema.org/geoShape are underspecified leading us to just linking to geoJson directly from the geoShape for the sake of doing something that can highlight linking to files or a WFS request that returns geojson.

-- this response is a bit wandering, but hopefully it makes sense? We will discuss on Wednesday for sure.

[dblodgett-usgs]

related to #148 and others.

[dblodgett-usgs]

@abhritchie -- I don't see gsp: in the elf.jsonld -- was that on purpose?

[afeliachi]

+1

[dblodgett-usgs]

+1 == you want it in there too?

[afeliachi]

Yes. For the moment I left the declaration of the the gsp: prefix on the sample files. Since our decision is to include gsp geometries as representation for detailed geometries, it would be logical to have gsp: in elf.jsonld

[dblodgett-usgs]

Alright. For the time being, let's just leave as-is. We can add it after things have settled down.

[afeliachi]

I agree. With @sgrellet, we noticed that yesterday and agreed to leave it as-is for the moment.

[abhritchie]

Sorry, was an accidental omission, not a decision. Will fix when you guys let me know it is safe to do so.

[dblodgett-usgs]

Go ahead as far as I'm concerned.

Sent from my iPhone

On Mar 16, 2018, at 5:56 PM, Alistair Ritchie notifications@github.com wrote:

Sorry, was an accidental omission, not a decision. Will fix when you guys let me know it is safe to do so.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[abhritchie]

Done and committed to master.