Suite

Représenter le temps dans GeoJSON ?

Représenter le temps dans GeoJSON ?


Je modélise un itinéraire de bus comme une série de points de cheminement. La plupart de ces waypoints ont juste une latitude et une longitude et représentent des points le long d'une route. Cependant, lorsque le bus arrive à un arrêt de bus, le point de cheminement est associé à une heure d'arrivée et de départ. Ces informations pourraient potentiellement être pertinentes pour tracer cet itinéraire, par exemple, si je devais animer la progression du bus.

Comme je vais exposer ces modèles via une API, je souhaite rester conforme aux normes en utilisant le format GeoJSON. Ce sera la première fois que j'utilise GeoJSON. Je sais que les trois premières coordonnées d'un point GeoJSON sont [longitude, latitude, altitude]. Selon Tom Macwright, GeoJSON prend en charge les coordonnées multidimensionnelles. Cependant, je n'ai trouvé aucune information sur les normes au-delà de ces trois.

Je prévois de représenter les temps en ticks (ticks JavaScript, c'est-à-dire nombre de millisecondes depuis minuit le 1er janvier 1970). Je souhaite utiliser la norme suivante :

{ "type": "Point", "coordinates": [longitude, latitude, null, ArrivalTime, DepartTime] }
  • Ce format entrera-t-il en conflit avec n'importe quelle norme GeoJSON ?
  • Les données d'altitude n'ont aucun sens pour moi. Ai-je besoin du "null" pour me conformer à GeoJSON ?

La spécification GeoJSON actuelle est geojson.org/geojson-spec.html et elle définit les "positions" comme

Une position est représentée par un tableau de nombres. Il doit y avoir au moins deux éléments, et peut-être plus. L'ordre des éléments doit suivre l'ordre x, y, z (abscisse, ordonnée, altitude pour les coordonnées dans un système de référence de coordonnées projetées, ou longitude, latitude, altitude pour les coordonnées dans un système de référence de coordonnées géographiques). N'importe quel nombre d'éléments supplémentaires est autorisé -- l'interprétation et la signification d'éléments supplémentaires dépassent le cadre de cette spécification.

La nouvelle version brouillon https://tools.ietf.org/html/draft-butler-geojson-06 est un peu plus explicite :

Une position est représentée par un tableau de nombres. Il DOIT y avoir deux éléments ou plus. Les deux premiers éléments seront la longitude et la latitude, ou l'abscisse et l'ordonnée au nord, précisément dans cet ordre et en utilisant des nombres décimaux. L'altitude ou l'élévation PEUT être incluse comme troisième élément facultatif.

Des éléments de position supplémentaires PEUVENT être inclus mais DOIVENT suivre les trois spécifiés ci-dessus et PEUVENT être ignorés par le logiciel. L'interprétation et la signification d'éléments supplémentaires dépassent le cadre de cette spécification.

Cela signifie que GeoJSON définit uniquement que deux premiers éléments de position sont X et Y et s'il y a un troisième élément, cela doit signifier l'élévation. Il peut y avoir d'autres éléments qui peuvent signifier n'importe quoi. C'est à vous de définir ce qu'ils signifient et comment ils doivent être traités. Un lecteur GeoJSON de base qui ne sait pas quoi faire avec des éléments supplémentaires devrait simplement les ignorer sans générer d'erreur.

Cependant, si vos données sont des points, je pense que vous pourriez aussi bien écrire les heures en tant qu'attributs normaux comme dans cet exemple https://github.com/kgeographer/catalhoyuk/blob/master/geotemporal_fig.json?short_path=b3b33df. Les coordonnées multidimensionnelles conviendront mieux si vous envisagez de présenter vos lignes de bus sous forme de chaînes de lignes, car un itinéraire de bus ne serait alors qu'une seule caractéristique géométrique qui ne peut avoir qu'une seule heure d'arrivée et de départ.


À mon avis, la "bonne" méthode consisterait à utiliser des propriétés à moins que vous ne considériez vos horodatages comme des coordonnées dans l'espace-temps.

Cela signifie qu'au lieu de géométries brutes, vous utiliseriez des caractéristiques, des objets appropriés réels qui ont des géométries et un attribut facultatif (les propriétés).

L'insertion d'attributs dans le tableau de coordonnées ne fait qu'inviter des problèmes avec tous les logiciels impliqués. Si vous utilisez les propriétés, tous les logiciels doivent les interpréter correctement comme telles. QGIS par exemple les affichera dans la table attributaire.

Voir http://geojson.org/geojson-spec.html#feature-objects

Par exemple quelque chose comme ceci (aucune garantie pour la syntaxe correcte) :

{ "type": "Feature", "geometry": { "type": "Point", "coordinates": [123456, 234567] }, "properties": { "arrivalTime": 12345678, "departureTime": 23456789 } }

En regardant autour, j'ai également trouvé des événements GeoJSON, un projet en cours de construction chez MapBox. Cela m'a semblé le plus approprié car il applique le concept général d'"événement" (c'est cool en termes de possibilité de s'appliquer à différents sujets qui ont besoin d'une représentation spatio-temporelle). La mise en œuvre est assez simple. Il existe deux types de base pour le chronométrage : intervalle et instant. Comme indiqué dans la documentation, la syntaxe pour instant:

{ "geometry": { "coordinates": [ 0.0, 0.0 ], "type": "Point" }, "id": "1", "properties": {"foo": "bar"}, "type" : "Fonctionnalité", "quand": { "start": "2014-04-24", "type": "Instant" } }

Syntaxe pour intervalle:

{ "geometry": { "coordinates": [ 0.0, 0.0 ], "type": "Point" }, "id": "1", "properties": {"foo": "bar"}, "type" : "Fonctionnalité", "quand": { "start": "2014-04-24", "end": "2014-04-26", "type": "Interval" } }

Lorsque l'effort GeoJSON Events s'est arrêté, j'ai commencé à travailler sur GeoJSON-T (https://github.com/kgeographer/geojson-t). Mettez-le "à l'épreuve" avec une application pilote Linked Traces. (http://linkedtraces.org). En cela, un élément "quand" peut vivre non seulement au niveau de la fonctionnalité, mais pour chaque géométrie dans une GeometryCollection. Cela permet entre autres de représenter des trajets, en changeant de forme au fil du temps.

Le développement de GeoJSON-T a été suspendu, mais a évolué vers le format Linked Places pour lier les répertoires géographiques (https://github.com/LinkedPasts/linked-places). Ainsi par exemple,

"features": [ { "@id": "http://mygaz.org/places/p_12345", "type": "Feature", "properties":{ "title": "Abingdon (UK)", " ccode": "GB" }, "geometry": { "type": "GeometryCollection", "geometries": [ { "type": "Point", "coordinates": [-1.2879,51.6708], "geo_wkt": "POINT(-1.2879 51.6708)", "quand": {"timespans":[ {"start":{"in":"1600"},"end":{"in":"1699"}}]} , "src": "tgn:7011944" }, { "type": "Point", "coordonnées": [-1.31,51.64], "geo_wkt": "POLYGONE ((-1.3077 51.6542, -1.2555 51.6542, -1.2555 51.6908, -1.3077 51.6908, -1.3077 51.6542))", "quand": {"timespans":[{"start":{"in":"1700"}}]} } ] }, "quand": { " timespans": [ { "start": {"in":"0676"},"end": {"in":"1066"} } ], "periods": [ { "name": "Période anglo-saxonne , 449-1066", "@id": "periodo:p06c6g3whtg" }, { "name": "Anglo-Saxon (culture ou style)", "@id": "http://chronontology.dainst.org/ period/O5r960WKERYr" } ], "label": "objet factice 'quand' illustrant la période, la durée et la séquence nommées", "duration": "P100Y" },