opengeospatial/owscontext

OWS Context SWG version of the JSON encoding work

OWS Context

This repository contains the SWG files and it is organized according to the following structure :

.
├── core
│   └── documents
│       └── specification
└── [encoding]
    ├── dev
    │   ├── [name1]
    │   ├── [name2]
    │   ├── ...
    └── documents
        ├── reports
        ├── specification
        └── tutorials

SWG Public Web Site is published at http://www.owscontext.org/

For the web site source code files please change the branch to gh_pages

owscontext's Issues

Protocol specific data and metadata in feature properties are harmful to interoperability

Hi, I came across this project via https://twitter.com/terradue/status/643799926766481408 and have looked at your JSON examples. I appreciate the all the standard Atom-inspired metadata (authors, contributors, updated, etc) but I believe that putting these in a feature's property object is not the best practice.

The items are completely opaque to Leaflet, of course.

And to change this situation, to add the semantics of authors and links and offerings to Leaflet (or other map libraries), will require either

1. Fixing these terms within the libraries, meaning that applications can't make other kinds of references to "authors" in their feature properties without name conflicts, or
2. Leaflet will need to become namespace aware, through JSON-LD or something.

Mapbox's simplestyle spec (supported by GitHub) puts us in a bad position with respect to 1 above. It introduces many possible name conflicts ("width", "color", all these names are squatted on by styling now). The owscontext proposal would add to the existing conflicts. Making an awkward situation worse. On 2 above, making a JSON-LD version of Leaflet is a bit of a lift.

I see two alternative places in GeoJSON for the context metadata, two places that don't depend on 2 (above) and don't make the situation of 1 worse.

a. Put owscontext metadata in Feature.owscontext instead of Feature.properties. In JSON, every object is a namespace and so this is the JSON native style of namespacing data elements.
b. Put owscontext metadata directly under Feature alongside id and geometry and properties.

Myself, I'm inclined toward b. updated, title, etc should be siblings of id in GeoJSON just like they are in Atom. And these properties are globally useful, not just for owscontext. I'd like to see them used by every GeoJSON publisher.

Now, there is the issue of GDAL's GeoJSON driver. It throws away all Feature data other than geometry and properties – a terrible design decision – and will need to be updated if we're every going to get away from just dumping everything into Feature.properties.

Further development of json owscontext

This repository has not been updated for a long time.
So I'm interested if there any new developments for this Standard and how to use it with clients.

It would also be good to see a list of clients who use this standard.
In my work we have tried to use it @dlr-eoc/services-ogc, however we are not sure if it is still used by others and if we should continue to use it

Inconsistency in GeoJSON encoding for "creator"

Section 7.1.1.9 creator does not conform to Table 7 as specified in the data type and value column of Table 1 for “creator”. Section 7.1.1.9 indicates one may specify .properties.creator. However, that is not shown as a possibility in either Table 1 or Table 7. Table 1 and Table 7 directs one to specify .properties.generator and/or .properties.display NOT .properties.creator as showing in 7.1.1.9.

clean project and update version scheme

Review project and update with current structure

• update folder structure
• update dependendencies
• update version schem
• check that conformance classes are properly capture
• check that is properly integrated

OWS Context document Specification Reference not clear on GeoJSON

The conceptual model element specReference is the Specification Reference (requirements class) identifying that this is an OWC Context document and its version. Currently this mapped both in ATOM and GeoJSON to the link element using the relation profile

In GeoJSON this becames

{
  "type": "FeatureCollection",
  "id": "http://www.opengis.net/owc/1.0/examples/geojson/1",
  "properties" : {
    "links" : {
      "profiles" : [
        "http://www.opengis.net/spec/owc-geojson/1.0/req/core"
        ],
    ...
    },
  "features": [{
    ...
    }]
  }

I had several comments that this is not evident to spot on a GeoJSON document (see discussion on #2) and that we might need think on clarifying this.

misspelling in GeoJSON encoding

Section 7.1.2.17 minScaleDenominator in the example section denominator is misspelled.

introduce geopackage as an offering

As discussed at https://github.com/pka/qgpkg/blob/master/ows_geopackage_extension.md and opengeospatial/geopackage#270 it would be interesting to have geopackage as an offering similar to KML/GML. Challenge is how to reference a specific table in the geopackage, I like the proposal by @pepijnve to include the table-name with a hash

a geopackage offering could thus be expressed as

<owc:offering
 code="http://www.opengis.net/spec/owc-atom/1.0/req/gpkg">
 <owc:content type="application/x-sqlite" href="http://example.com/package.gpkg#table=MyPoints" />
</owc:offering>