Est-il valide d'avoir un élément properties dans un geoJSON featureCollection?

Est-il valide d'avoir un élément properties avec un élément featureCollection comme parent?

C'est, selon geojson.org valide:

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

Mais je ne trouve pas si c'est valide ni s'il est invalide d'avoir ceci:

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

Selon la réponse ci-dessous, il n'est pas valide de le mettre ici, mais les programmes / scripts ne le sauront pas.

Alors, permettez-moi de reformuler la question: (Où) Est-il possible de mettre des informations descriptives sur la propriété comme un total ??

geojson

— stUrb
source

Réponses:

2.3. Objets de collection d'entités

Un objet GeoJSON avec le type "FeatureCollection" est un objet de collection d'entités.

Un objet de type "FeatureCollection" doit avoir un membre avec le nom "features". La valeur correspondant à "features" est un tableau. Chaque élément du tableau est un objet caractéristique tel que défini ci-dessus.

Je pense que cela implique clairement que si l'objet a des membres supplémentaires, cela ne le rend pas invalide.

Les objets Ecmascript sont très ouverts.

Alors oui, vous pouvez avoir un élément de propriétés au niveau supérieur d'une collection d'entités, mais ne vous attendez pas à ce que des outils le sachent ou le copient, ...

— julien
source

OK Assez bien :) Mais quel est l'endroit pour stocker des informations sur la collection elle-même au lieu de la fonctionnalité?

— stUrb

Il n'y en a pas dans la spécification.

— Calvin

Parce que FeatureCollection est un objet de première classe, toutes les propriétés concerneront la collection, pas n'importe quelle fonctionnalité. Soit en ajouter autant que vous le souhaitez, soit ajouter une propriété de "métadonnées" dont la valeur est une carte.

— Julian

Une autre façon de penser est que vous devez sous-classer FeatureCollection selon vos besoins. C'est vraiment une métaphore plutôt qu'une construction de programmation ici, car ECMAscript ne pense pas les objets de cette façon.

— Julian

La spécification autorise les membres étrangers dans la section 6.1. tools.ietf.org/html/draft-ietf-geojson-03#section-6 . C'est donc légal, mais le comportement dépendra de l'application.

— intotecho

La réponse courte est non - il n'est pas valide d'avoir un propertiesélément sur un FeatureCollectionobjet:

https://tools.ietf.org/html/rfc7946#section-7.1

Les membres "géométrie" et "propriétés" de GeoJSON définissent un objet Feature. Les objets FeatureCollection et Geometry, respectivement, NE DOIVENT PAS contenir de membre "geometry" ou "properties".

— Neil
source

De ma lecture, le libellé de ce mandat que vous ne pouvez pas nommer un membre d'un FeatureCollection "properties" comme l'OP fait, mais il ne vous empêche pas de l' appeler autre chose comme "metadata"ou "description". J'ai utilisé plusieurs membres de haut niveau dans des cartes Web qui s'appuient sur geojson. Bonne mise à jour, @Niel.

— nronnei

Je pense moi aussi qu'une «propriété» de premier niveau serait utile, une au niveau de la collection d'entités.

Mais le travail que j'ai fait a consisté à créer une fonctionnalité supplémentaire pour la collection d'entités, à remplir les propriétés comme vous le souhaitez et à définir simplement l'objet géométrique sur NULL. D'après ma lecture de la spécification, cela semble autorisé et reste dans la norme.

— Pman
source