Clarify formatting for a bounding coordinate box

[BrentFrakes]

In your documentation ( https://project-open-data.cio.gov/v1.1/schema/#spatial), please provide an example of how one would describe the following: "(1) a bounding coordinate box for the dataset represented in latitude / longitude pairs where the coordinates are specified in decimal degrees and in the order of: minimum longitude, minimum latitude, maximum longitude, maximum latitude"

If I am interpreting that you lat/lon pairs, I'm assuming you want LowerLeft, UpperLeft, LowerRight, Upper Right?

Also, are longitudes negative for the western hemisphere?

[BrentFrakes]

Or are you wanting this: {"type": "Polygon", "coordinates": [[[-97.562131, 26.035513], [-82.574911, 26.035513], [-82.574911, 30.375579], [-97.562131, 30.375579]]]}

If so, are we allowed to have multiple polygons as bounding areas?

[ajturner]

What is described is also typically referred to as WSEN (West South East North), so global is [-180,-90,180,90]

That's simple and functional and anything beyond that should use GeoJSON

[akuckartz]

See also https://github.com/OpenGovLD/specs/issues/70 and https://github.com/opennorth/popolo-spec/issues/70

[philipashlock]

@BrentFrakes did you mean to close this? It looks like the documentation and examples still need to be improved to provide more clarity here.

We might want to have a separate page that expands on these options a little more starting with the simple example @ajturner provided, eg:

{"spatial":[-109.813,36.424,-101.475,41.574]}

We could also have an explanation of when GeoJSON would be a appropriate, eg a polygon (or multiple) that's more complex than a bounding box - and examples of such. Currently the documentation says GML, but since we're using JSON here, GeoJSON would certainly make more sense as a recommended approach for adding more complex features.

For example

{
  "spatial": {
    "type": "Feature",
    "properties": {
      "GEO_ID": "0400000US11",
      "STATE": "11",
      "NAME": "District of Columbia",
      "LSAD": "",
      "CENSUSAREA": 61.048000
    },
    "geometry": {
      "type": "Polygon",
      "coordinates": [
        [
          [
            -77.038598,
            38.791513
          ],
          [
            -77.038898,
            38.800813
          ],

most coordinates removed from example for brevity

          [
            -76.992697,
            38.828213
          ],
          [
            -76.999997,
            38.821913
          ],
          [
            -77.001397,
            38.821513
          ],
          [
            -77.038598,
            38.791513
          ]
        ]
      ]
    }
  }
}

Also wanted to note related discussion for the INSPIRE DCAT profile: https://ies-svn.jrc.ec.europa.eu/projects/metadata/wiki/INSPIRE_profile_of_DCAT-AP_-_Reference#Geographic-bounding-box

[ajturner]

@philipashlock I particularly like providing the properties if it includes a derefernceable URL - particularly if that URL has content negotiation and allows me to ask for the geometry in the format and precision that I request (e.g. KML, GeoJSON, GML, et al.) That permits small payload size, ability to "join" data to boundaries.

And at the least case, falling back to Bounding Box extent is a good suggestion.

[akuckartz]

In resolving this issue please collaborate with the relevant other specification projects and do not reinvent wheels: https://github.com/schemaorg/schemaorg/issues/8 http://www.w3.org/2014/spatial/charter