24

Is it valid to have a properties element with a featureCollection-element as parent?

This is, according to geojson.org valid:

{ "type": "FeatureCollection",
  "features": [
              { "type": "Feature",
                "geometry": {"type": "Point", "coordinates": [102.0, 0.5]},
                "properties": {"prop0": "value0"}
              }
              ]
}

But I can't find is it is valid nor if it is in-valid to have this:

{ "type": "FeatureCollection",
  "properties" : { "description" : "This is the geometry for..." }
  "features": [
              { "type": "Feature",
                "geometry": {"type": "Point", "coordinates": [102.0, 0.5]},
                "properties": {"prop0": "value0"}
              }
              ]
}

According to the answer underneath it is not in-valid to put it there, but programs/scripts won't know its there.

So, let me rephrase the question: (Where) Is it possible to put some descriptive information about the property as a total??

stUrb
  • 2,269
  • 8
  • 24
  • 23

5 Answers5

19

The short answer is no - it is not valid to have a properties element on a FeatureCollection object:

https://www.rfc-editor.org/rfc/rfc7946#section-7.1

The GeoJSON "geometry" and "properties" members define a Feature object. FeatureCollection and Geometry objects, respectively, MUST NOT contain a "geometry" or "properties" member.

Community
  • 1
Neil
  • 383
  • 2
  • 4
  • 5
    From my reading, the wording on this mandates that you cannot name a member of a FeatureCollection "properties" like the OP does, but it does not preclude you from calling it something else like "metadata" or "description". I have used several top level members in web maps that rely on geojson. Good update, @Niel. – nronnei Jan 17 '17 at 15:54
  • 2
    @nronnei Yes, and this is explicitly allowed in section 6.1 of RFC7946 which says "Members not described in this specification ('foreign members') MAY be used in a GeoJSON document." and after a bit of hemming and hawing gives an example approving the addition of an arbitrary user-defined .title field to a feature. – natevw Feb 14 '21 at 01:36
12

2.3. Feature Collection Objects

A GeoJSON object with the type "FeatureCollection" is a feature collection object.

An object of type "FeatureCollection" must have a member with the name "features". The value corresponding to "features" is an array. Each element in the array is a feature object as defined above.

I think this clearly implies that if the object has additional members that doesn't make it invalid.

Ecmascript objects are very open.

So yes, you can have a properties element at the top level of a feature collection, but don't expect any tools to know its there, or to copy it, ...

Julian
  • 252
  • 2
  • 5
  • 1
    O.K. Fair enough :) But what is the place to store information about the collection itself instead of the feature? – stUrb May 12 '12 at 08:24
  • There isn't one in the spec. – Calvin May 17 '13 at 10:09
  • Because FeatureCollection is a first class object any properties will be about the collection, not any feature. Either add as many as you like, or add a "metadata" property whose value is a map. – Julian May 19 '14 at 15:39
  • Another way of thinking about it is that you need to sub-class FeatureCollection for your needs. That's really a metaphor rather than a programming construct here though because ECMAscript doesn't think of objects quite that way. – Julian May 20 '14 at 08:30
  • 1
    The spec does allow Foreign Members in section 6.1. https://tools.ietf.org/html/draft-ietf-geojson-03#section-6. So it is legal, but the behaviour will be application dependent. – intotecho May 16 '16 at 06:33
  • Thanks! I was working from http://geojson.org/geojson-spec.html. – Julian Jun 23 '16 at 04:36
  • This answer could work in practice but violates at least the final specification. As the answer by @Neil points out the spec says: "FeatureCollection and Geometry objects, respectively, MUST NOT contain a 'geometry' or 'properties' member." – natevw Feb 14 '21 at 01:29
2

I too think that a top level 'properties' would be useful, one at the feature collection level.

But the work around that I did was to make an additional feature for the feature collection, populate the properties as desired, and just set the geometry object to NULL. From my reading of the spec, this seems allowed and stays within the standard.

Pman
  • 79
  • 4
1

I don't have enough reputation yet to comment, so I will post in the form of an answer in support of https://gis.stackexchange.com/a/25309/217561

There are at least three sections of the spec that are relevant. As https://gis.stackexchange.com/users/7207/julian points out, the description of FeatureCollection doesn't mention "properties".

I think https://gis.stackexchange.com/a/209263/217561 is overlooking "respectively" in the spec which to me indicates that a FeatureCollection cannot have a "geometry" and a Geometry cannot have a "properties".

Further as https://gis.stackexchange.com/users/9181/natevw's comment indicates the spec states that other members not defined in the spec are valid but may not be interpreted by clients and could reduce interoperability.

To me this all adds up to the conclusion that adding a "properties" member to a FeatureCollection is a valid way to add collection level information and is aligned with the conventions of geojson.

Jonathan Millman
  • 11
  • 3
0

You can insert a Polygon feature without any coordinates and set your properties as you like:

{
  "type": "FeatureCollection",
  "features": [
    {
      "type": "Feature",
      "geometry": {
        "type": "Polygon",
        "coordinates": [          
        ]
      },
      "properties": {
        "description": "This is the geometry for..."
      }
    },
    {
      // Other features
    }
  ]
}
Gürol Canbek
  • 101
  • 2