Skip to content
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

Consider adding geospatial relations echoing the predicates from DE-9IM #1375

Closed
danbri opened this issue Sep 19, 2016 · 12 comments
Closed

Consider adding geospatial relations echoing the predicates from DE-9IM #1375

danbri opened this issue Sep 19, 2016 · 12 comments
Labels
schema.org vocab General top level tag for issues on the vocabulary

Comments

@danbri
Copy link
Contributor

danbri commented Sep 19, 2016

  • https://en.wikipedia.org/wiki/DE-9IM has a list of topological relationship types between 2d-geometrically described places
    • "The Dimensionally Extended nine-Intersection Model (DE-9IM) is a topological model and a standard used to describe the spatial relations of two regions (two geometries in two-dimensions, R2), in Geometry, Point-set topology, Geospatial topology, and fields related to computer spatial analysis. "
  • http://schema.org/GeoShape is the closest schema.org currently gets to having a type for geo-spatial geometry.

It would be useful (as discussed 2016-09-19) at W3C/OGC Spatial Data on the Web WG meeting in Lisbon if these could be used within schema.org.

@danbri
Copy link
Contributor Author

danbri commented Sep 19, 2016

Suggest:

* geospatiallyEquals
* geospatiallyDisjoint
* geospatiallyTouches
* geospatiallyContains
* geospatiallyCovers
* geospatiallyIntersects
* geospatiallyWithin
* geospatiallyCoveredBy 
* geospatiallyCrosses 
* geospatiallyOverlaps

with text based on Wikipedia's summaries, and allowing each to link either geometries or places.

@danbri danbri added the schema.org vocab General top level tag for issues on the vocabulary label Sep 19, 2016
@danbri
Copy link
Contributor Author

danbri commented Sep 19, 2016

Ok I have made a FIRST CUT with DELIBERATE MISTAKES for discussion in Schema.org and W3C circles.

Further things to consider:

  • I included a GeospatialGeometry definition to avoid editing the existing deployed GeoShape (which could become a subtype)
  • It tries to make these relations applicable both at the geometry and at the place level. Of all the relations, "equals" is the hardest to consider without concrete geometry.
  • Text is based heavily on Wikipedia, no proper citation to underlying standards yet.
  • We haven't got inverseOf relations or subPropertyOf relations yet (although schema.org understands these). Also we don't have "symmetric property" in schema.org's meta model yet, although that could be useful here.
  • It was suggested that similar temporal relations could be added (see Working Draft)

@danbri
Copy link
Contributor Author

danbri commented Sep 19, 2016

@rvguha
Copy link
Contributor

rvguha commented Sep 19, 2016

Who is this vocab targeted at? Who will mark things up and who will use it?

guha

@danbri
Copy link
Contributor Author

danbri commented Sep 19, 2016

It's part of an effort to get existing professional geospatial systems to expose modern Web-based views rather than just GIS-specific standards. Those tools support such relations out of the box. (stopgap reply for now, typing on a phone)

@thadguidry
Copy link
Contributor

thadguidry commented Sep 19, 2016 via email

@rvguha
Copy link
Contributor

rvguha commented Sep 19, 2016

Ok, sounds like a good idea.

guha

@danbri
Copy link
Contributor Author

danbri commented Feb 19, 2019

I have heard rumour of an application that may use this. In the meantime the names are needlessly verbose, let's just write them as 'geoXyz' instead of 'geospatiallyXyz'. I'll make that fix directly, and do not plan to preserve a history for the old property names unless someone speaks up here and says they're important.

@RichardWallis
Copy link
Contributor

Implemented in release 3.5

@nicholascar
Copy link

@danbri @rvguha please note that GeoSPARQL 1.1 is in drafting right now and that you might like to either influence that work with lessons from shcema.org or adopt patterning: https://github.com/opengeospatial/ogc-geosparql

@danbri
Copy link
Contributor Author

danbri commented Mar 7, 2021 via email

@nicholascar
Copy link

I still don’t really understand why there needs to be a version of sparql for geo.

Two main reasons:

  1. to support processing of complex geometry objects in RDF given as literals, such multi-polygons.

To get reasonable results when using complex geometries, or even geometries using different reference systems, you need to hand off operations to spatial code libraries, so GeoSPARQL extends SPARQL functions with common spatial operations like sfWithin to calculate whether one geometry is inside another. Implementers then implement sfWithin using common tools.

  1. to provide a powerful Feature/Geometry representation ontology

schema.org does some spatial modelling but doesn't cater for:

  • well-known spatial literal formats (KML, GeoJSON, WKT)
  • complex geometries (multi-polygons, mixed geometries)
  • multiple coordinate reference systems

Pretty much all common spatial libraries do handle these things so GeoSPARQL allows for their representation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
schema.org vocab General top level tag for issues on the vocabulary
Projects
None yet
Development

No branches or pull requests

5 participants