Proposition de schéma de tags pour améliorer la cartographie des arbres

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Proposition de schéma de tags pour améliorer la cartographie des arbres

Frédéric Rodrigo-2
Bonjour,

Suite aux discussions très intéressantes sur le la façon de tagger les
bâtiments qui penchent (à l'extérieur, comme à l'intérieur) et également
aux éclairages pertinents de Mr. Verdy sur la question, il m'a paru
clair qu'il était possible de se baser sur ce même principe pour
l'appliquer à la micro-cartographie des arbres.

Jusqu'à présent pour cartographie un arbre on utilise : natural=tree
adjoint éventuellement de tags pour en décrire la nature, le genre ou
l'espèce (genus=*, species=*, taxon=*).
Une autre partie des tag permettent de d'écrire l'instance de l'arbre :
circumference=*, height=*  et même l'age. Cependant cela ne permet
toujours d'avoir une idée plus précise de ce à quoi ressemble l'arbre.

Une tentative de cartographie des arbres en 3D est disponible sur le
wiki, où l'on peut décrire la forme générale de l'arbre et l'inclinaison
du tronc, mais ce n'est pas suffisant :
http://wiki.openstreetmap.org/wiki/Tree_table

Ce que je propose, donc en partant de l'idée des bâtiments inclinés,
c'est de décrire les arbres de façon arborescente (je sais elle est
facile ;) ).

On commence donc par décrire le tronc, longueur, direction et
l'inclinaison :
- tree:trunk:length=* (en m par défaut, mais d'autres unités restent
bien sûr possible, c'est important)
- tree:trunk:direction=* (en degré par rapport au nord, dans le sens
anti-horaire, c'est plus naturel par rapport à l'orientation de la
végétation vis-à-vis de la course du soleil, mais c'est du détail), si
le tronc est parfaitement droit, et donc que la direction est de 0° on
peut l'omettre.
- tree:trunk:inclination=* (en degré, idem omettable si pas
d'inclinaison, l’inclinaison doit être absolue par rapport à
l'horizontale, et pas rapport à l'inclinaison du sol bien sûr !)
À noter pour Omsose, s'il y a une inclinaison il y a forcément une
direction (et réciproquement).

Puis les branches ou la suite du tronc :
- tree:trunk:trunk:length=*
- tree:trunk:trunk:direction=* (en degré par rapport au nord,
c'est-à-dire de façon absolue, ou alors de façon relative à la direction
du segment précédent en préfixant le nombre par « + » ou « - »).
- tree:trunk:trunk:inclination=*, idem, simple combinaison de
tree:trunk:trunk:direction=* et tree:trunk:inclination=*.

Et pour chaque branche :
- tree:trunk:branch[X]:length=*
- tree:trunk:branch[X]:direction=*
- tree:trunk:branch[X]:inclination=*
Il faut remplacer X par un numéro d'ordre sur le nœud, pas besoin
d'ordre particulier, juste besoin de les numéroter pour pouvoir suivre
la branche. Cela dépend des espèces, certaines espèces n'ont pas plus
d'une seule branche par nœud, on peut dans ce cas également ne pas
mentionner le numéro d'ordre.

L'avantage c'est que l'on peut ainsi continuer ou s'arrêter quand on
veut, on est en plein dans l'idée simple d'OSM, contribution itérative.
Un premier contributeur ne cartographie que les grosses branches, puis
un autre peut aller plus loin ou mettre à jour parce que de nouvelles
branches ont poussées.

Pour l'exemple :
tree:trunk:length=4.32
tree:trunk:direction=7.7
tree:trunk:inclination=2.4
tree:trunk:trunk:length=1.28
tree:trunk:trunk:direction=-1.8
tree:trunk:trunk:inclination=+2.6
tree:trunk:branch[1]:length=0.8
tree:trunk:branch[1]:direction=+5.7
tree:trunk:branch[1]:inclination=-9.8
tree:trunk:branch[1]:branch[1]:length=0.5
tree:trunk:branch[1]:branch[1]:direction=+6.8
tree:trunk:branch[1]:branch[1]:inclination=+3.2
tree:trunk:branch[1]:branch[2]:length=0.5
tree:trunk:branch[1]:branch[2]:direction=+6.8
tree:trunk:branch[1]:branch[2]:inclination=+3.2
tree:trunk:branch[2]:length=0.6
tree:trunk:branch[2]:direction=-9.4
tree:trunk:branch[2]:inclination=+4.6
tree:trunk:branch[2]:branch:length=0.2
tree:trunk:branch[2]:branch:direction=+4.9
tree:trunk:branch[2]:branch:inclination=+4.8
tree:trunk:trunk:trunk:length=0.8
tree:trunk:trunk:trunk:direction=+8.6
tree:trunk:trunk:trunk:inclination=-7.8

L'avantage de cette façon de faire est de pouvoir rester concis, un seul
nœud suffit, pas besoin de cartographier les branches avec des ways.

Certains vont penser que ce n'est que pour le rendu, mais on peut faire
bien plus de choses avec, par exemple du calcul d'itinéraires ou
d’ensoleillement par ombre porté sur le feuillage en fonction de
l'espèce de l'arbre.

J'espère que des moteurs 3D comme F4 pourront rapidement prendre en
compte cette approche, le résultat sera quand même beaucoup plus réaliste.

Je suis ouvert à vos remarques avant de faire une proposition en bon et
due forme sur le wiki puis sur la liste tagging.

Note, il faudra maintenant aller mapper avec des boussoles, des niveaux
et des compas ; mais nos chers smartphones font déjà tout ça !

Frédéric.

_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: Proposition de schéma de tags pour améliorer la cartographie des arbres

Vincent de Château-Thierry
Chalut,

Le 01/04/2015 00:02, Frédéric Rodrigo a écrit :

> On commence donc par décrire le tronc, longueur, direction et
> l'inclinaison :
> - tree:trunk:length=* (en m par défaut, mais d'autres unités restent
> bien sûr possible, c'est important)

> Puis les branches ou la suite du tronc :
> - tree:trunk:trunk:length=*

> Et pour chaque branche :
> - tree:trunk:branch[X]:length=*

On va enfin pouvoir décrire les soles pleureu(ses|rs) :D

Mais il manque les racines, dans ton schéma. Je propose des indices
négatifs, à l'image des layers :

root[-2]:root[-1]:tree:trunk:...

Comme ça on peut creuser. Voire trouver de l'eau.

> L'avantage de cette façon de faire est de pouvoir rester concis, un seul
> nœud suffit, pas besoin de cartographier les branches avec des ways.
>
> Certains vont penser que ce n'est que pour le rendu, mais on peut faire
> bien plus de choses avec, par exemple du calcul d'itinéraires ou
> d’ensoleillement par ombre porté sur le feuillage en fonction de
> l'espèce de l'arbre.

Pour le calcul d'itinéraire, cette approche permet enfin de parcourir
les arêtes. Il était temps, je vote pour.

> J'espère que des moteurs 3D comme F4 pourront rapidement prendre en
> compte cette approche, le résultat sera quand même beaucoup plus réaliste.
>
> Je suis ouvert à vos remarques avant de faire une proposition en bon et
> due forme sur le wiki puis sur la liste tagging.

Sur le wiki ? Aqua bon.

> Note, il faudra maintenant aller mapper avec des boussoles, des niveaux
> et des compas ; mais nos chers smartphones font déjà tout ça !
>
> Frédéric.

vincent

_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: Proposition de schéma de tags pour améliorer la cartographie des arbres

FrViPofm
In reply to this post by Frédéric Rodrigo-2
Le 01/04/2015 00:02, Frédéric Rodrigo a écrit :

> Bonjour,
>
> Suite aux discussions très intéressantes sur le la façon de tagger les
> bâtiments qui penchent (à l'extérieur, comme à l'intérieur) et
> également aux éclairages pertinents de Mr. Verdy sur la question, il
> m'a paru clair qu'il était possible de se baser sur ce même principe
> pour l'appliquer à la micro-cartographie des arbres.
>
> Jusqu'à présent pour cartographie un arbre on utilise : natural=tree
> adjoint éventuellement de tags pour en décrire la nature, le genre ou
> l'espèce (genus=*, species=*, taxon=*).
> Une autre partie des tag permettent de d'écrire l'instance de l'arbre
> : circumference=*, height=*  et même l'age. Cependant cela ne permet
> toujours d'avoir une idée plus précise de ce à quoi ressemble l'arbre.
>
> Une tentative de cartographie des arbres en 3D est disponible sur le
> wiki, où l'on peut décrire la forme générale de l'arbre et
> l'inclinaison du tronc, mais ce n'est pas suffisant :
> http://wiki.openstreetmap.org/wiki/Tree_table
>
> Ce que je propose, donc en partant de l'idée des bâtiments inclinés,
> c'est de décrire les arbres de façon arborescente (je sais elle est
> facile ;) ).
>
> On commence donc par décrire le tronc, longueur, direction et
> l'inclinaison :
> - tree:trunk:length=* (en m par défaut, mais d'autres unités restent
> bien sûr possible, c'est important)
> - tree:trunk:direction=* (en degré par rapport au nord, dans le sens
> anti-horaire, c'est plus naturel par rapport à l'orientation de la
> végétation vis-à-vis de la course du soleil, mais c'est du détail), si
> le tronc est parfaitement droit, et donc que la direction est de 0° on
> peut l'omettre.
> - tree:trunk:inclination=* (en degré, idem omettable si pas
> d'inclinaison, l’inclinaison doit être absolue par rapport à
> l'horizontale, et pas rapport à l'inclinaison du sol bien sûr !)
> À noter pour Omsose, s'il y a une inclinaison il y a forcément une
> direction (et réciproquement).
>
> Puis les branches ou la suite du tronc :
> - tree:trunk:trunk:length=*
> - tree:trunk:trunk:direction=* (en degré par rapport au nord,
> c'est-à-dire de façon absolue, ou alors de façon relative à la
> direction du segment précédent en préfixant le nombre par « + » ou « -
> »).
> - tree:trunk:trunk:inclination=*, idem, simple combinaison de
> tree:trunk:trunk:direction=* et tree:trunk:inclination=*.
>
> Et pour chaque branche :
> - tree:trunk:branch[X]:length=*
> - tree:trunk:branch[X]:direction=*
En fonction du nord géographique ou magnétique ?

> - tree:trunk:branch[X]:inclination=*
> Il faut remplacer X par un numéro d'ordre sur le nœud, pas besoin
> d'ordre particulier, juste besoin de les numéroter pour pouvoir suivre
> la branche. Cela dépend des espèces, certaines espèces n'ont pas plus
> d'une seule branche par nœud, on peut dans ce cas également ne pas
> mentionner le numéro d'ordre.
>
> L'avantage c'est que l'on peut ainsi continuer ou s'arrêter quand on
> veut, on est en plein dans l'idée simple d'OSM, contribution
> itérative. Un premier contributeur ne cartographie que les grosses
> branches, puis un autre peut aller plus loin ou mettre à jour parce
> que de nouvelles branches ont poussées.
Et chaque année on ajoute les nouvelles branches... Simple comme schéma.
À moins qu'un bon bot qui enregistre la météo au jour le jour pour
l'emplacement fasse le calcul de croissance lui-même et produise un
fichier de mise à jour. Parce qu'on fait de l'intégration, hein ! pas de
l'import de données.

>
> Pour l'exemple :
> tree:trunk:length=4.32
> tree:trunk:direction=7.7
> tree:trunk:inclination=2.4
> tree:trunk:trunk:length=1.28
> tree:trunk:trunk:direction=-1.8
> tree:trunk:trunk:inclination=+2.6
> tree:trunk:branch[1]:length=0.8
> tree:trunk:branch[1]:direction=+5.7
> tree:trunk:branch[1]:inclination=-9.8
> tree:trunk:branch[1]:branch[1]:length=0.5
> tree:trunk:branch[1]:branch[1]:direction=+6.8
> tree:trunk:branch[1]:branch[1]:inclination=+3.2
> tree:trunk:branch[1]:branch[2]:length=0.5
> tree:trunk:branch[1]:branch[2]:direction=+6.8
> tree:trunk:branch[1]:branch[2]:inclination=+3.2
> tree:trunk:branch[2]:length=0.6
> tree:trunk:branch[2]:direction=-9.4
> tree:trunk:branch[2]:inclination=+4.6
> tree:trunk:branch[2]:branch:length=0.2
> tree:trunk:branch[2]:branch:direction=+4.9
> tree:trunk:branch[2]:branch:inclination=+4.8
> tree:trunk:trunk:trunk:length=0.8
> tree:trunk:trunk:trunk:direction=+8.6
> tree:trunk:trunk:trunk:inclination=-7.8
>
> L'avantage de cette façon de faire est de pouvoir rester concis, un
> seul nœud suffit, pas besoin de cartographier les branches avec des ways.
>
> Certains vont penser que ce n'est que pour le rendu, mais on peut
> faire bien plus de choses avec, par exemple du calcul d'itinéraires ou
> d’ensoleillement par ombre porté sur le feuillage en fonction de
> l'espèce de l'arbre.
>
> J'espère que des moteurs 3D comme F4 pourront rapidement prendre en
> compte cette approche, le résultat sera quand même beaucoup plus
> réaliste.
>
> Je suis ouvert à vos remarques avant de faire une proposition en bon
> et due forme sur le wiki puis sur la liste tagging.
Et pourquoi pas une fractale pour décrire l'écorce ?
Ça simplifiera pour les différents niveaux de zoom.
>
> Note, il faudra maintenant aller mapper avec des boussoles, des
> niveaux et des compas ; mais nos chers smartphones font déjà tout ça !
>
> Frédéric.
--
FrViPofm

_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: Proposition de schéma de tags pour améliorer la cartographie des arbres

verdy_p
In reply to this post by Vincent de Château-Thierry
On peut typer les "branches" et aller jusqu'aux les bourgeons, nervures et découpes externes des feuilles, ou des pétales des fleurs ou leurs étamines et pistils, les épines des branches, feuilles ou fruits, ou les radicules, rhizomes ?
et la position des greffons d'une autre espèce que le porteur?
et typer les branches mortes/brisées/sciées, les feuilles seches qui vont tomber, leur poids, leur hygrométrie, les maladies, les traitements appliqués ?
et la stabilité et l'emplacement des points d'accroche (câbles ou poteaux de soutien, tiges naturelles enroulées sur un grillage ou un tuteur, et les types de tuteurs?
et les trous et nids d'oiseaux et insectes ou nichages de petits rongeurs au pied de l'arbre entre les racines, ou les meilleures branches où viennent se prélasser les mammiferes (fauves, singes et même humains) ?
et encore les meilleurs endroits pour appuyer une échelle pour y aller ou pour la cueillette ou construire une cabane?
et la production fruitiere, de seve, et leur poids et qualité gustative ou esthétique?
et celle de bois et écorces de coupe, ou petits bois, pour le chauffage et le prix moyen à la stere (en plusieurs devises tant qu'à faire et sur plusieurs marchés, avec les frais de transaction, de change, les taxes et le transport par kilo ou par tonne)
et la consommation de CO2 diurne et sa production nocturne (avec relevés calendaires réguliers sur plusieurs années) et des autres gaz produits (aromatiques ou de dégradation) ainsi que les éléments puisées ou injectés dans le sol et l'eau, la composition de la sève?
- allons plus loin, comptons et cartographions les cellules des différents organes, et les éléments internes (filaments, chloroplastes, ribosomes, ... avec leur génome respectif si nécessaire) et pourquoi pas le génôme nucléaire complet, les mutations gène par gène, et la conformation spatiale des gènes et protéines, et la position des ponts sulfurés, inter-amines ou acido-basiques, et les pôles électromagnétiques du génome et de ses copies extranucléaires, le tout selon la température, l'hygrométrie, les saturations en minéraux?
;-)

Le 1 avril 2015 00:29, Vincent de Château-Thierry <[hidden email]> a écrit :
Chalut,

Le 01/04/2015 00:02, Frédéric Rodrigo a écrit :

On commence donc par décrire le tronc, longueur, direction et
l'inclinaison :
- tree:trunk:length=* (en m par défaut, mais d'autres unités restent
bien sûr possible, c'est important)

Puis les branches ou la suite du tronc :
- tree:trunk:trunk:length=*

Et pour chaque branche :
- tree:trunk:branch[X]:length=*

On va enfin pouvoir décrire les soles pleureu(ses|rs) :D

Mais il manque les racines, dans ton schéma. Je propose des indices négatifs, à l'image des layers :

root[-2]:root[-1]:tree:trunk:...

_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: Proposition de schéma de tags pour améliorer la cartographie des arbres

Jean-Christophe Becquet
Le 01/04/2015 01:56, Philippe Verdy a écrit :
> cartographions les cellules des différents organes

Avec IPv6, ont pourra sans doute bientôt attribuer une adresse à chaque
cellule sur le réseau et l'interroger directement ;-)

JCB
--
Richard Stallman : Toutes les libertés dépendent des libertés informatiques
http://www.apitux.org/index.php?2006/04/19/158-richard-stallman-toutes-les-libertes-dependent-des-libertes-informatique

==============APITUX : le choix du logiciel libre==============

APITUX - Jean-Christophe Becquet
BP 32 - 04001 Digne-les-Bains Cedex
06 25 86 07 92 - [hidden email] - http://www.apitux.com/
SIRET : 452 887 441 00031 - APE : 6202A

===============================================================

_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: Proposition de schéma de tags pour améliorer la cartographie des arbres

Pieren
Je sens une pointe de sarcasme dans certaines réponses... sauf
Philippe qui a bien compris (et qui nous fait des poissons d'avril
toute l'année, sacré farceur).

Pieren

_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: Proposition de schéma de tags pour améliorer la cartographie des arbres

Jo-2
Ah, dommage que ce n'est pas sérieux. J'étais complètement pour... J'espère que vous n'avez pas oublié les branches coupées, ou on met ceux-là sur OHM?

Jo

2015-04-01 18:02 GMT+02:00 Pieren <[hidden email]>:
Je sens une pointe de sarcasme dans certaines réponses... sauf
Philippe qui a bien compris (et qui nous fait des poissons d'avril
toute l'année, sacré farceur).

Pieren

_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr


_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: Proposition de schéma de tags pour améliorer la cartographie des arbres

verdy_p
Sur OHM vraiment? Symbole de résistance contre OSM ?

Ou à l'inverse sur COULOMB, symbole de conductance : « Coulons OSM ! », dirait Google (qui voudrait bien nous voir aller jusqu'à cartographier les pattes de mouche, histoire de bien plomber le projet), on pourrait aussi dire « Coulons Google », sauf que je ne pense pas que ce soit même dans notre intérêt collectif de tuer toute concurrence

On commence à le voir sur Wikipedia où les contributions se tarissent un peu alors qu'il n'y a jamais eu autant de lecteurs, la qualité globale diminue avec moins de relecteurs, et où les vraies évolutions et innovations sont de plus en plus compliquées et lourdes "administrativement" parlant. On le voit aussi sur la presse en général, tuée par les sites web d'informations sans relecture, sans source. Mais il n'y a plus aucune encyclopédie vivante sur papier, en même en ligne hors de Wikipédia (on n'a pas le choix que de le préserver mais c'est dommage maintenant qu'il soit aussi figé dans son premier moule, on n'a pas encore un système collaboratif de relecture reconnue, fonctionnant domaine par domaine, hors des rares comités scientifiques quasi inaccessibles et des publications spécialisées et chères, qui ont en plus du mal à survivre économiquement face au web beaucoup plus réactif).

Tant qu'il y a de la concurrence et qu'elle s'équilibre sainement, l'innovation joue à fond et les progrès vont bien plus vite et plus de monde en bénéficie.

OSM a recréé une saine concurrence permettant aux sources des anciens monopoles géographiques d'Etat d'être totalement tués par Google, en leur permettant de collaborer à fond, pas en sens unique où Google aurait même voulu faire d'eux des consommateurs de données au lieu d'en être producteurs. Mais je pense qu'on doit laisser leur place aussi à Google ou Bing, et on redonne aussi un espace aux collectivités publiques, et qu'on doit accorder encore une place importante aux producteurs de données sourçables, par des échanges réciproques, où tout ne viendra pas seulement des utilisateurs individuels sans réelle supervision de la qualité globale des données

(Je ne peux pas faire confiance juste à Google pour faire cette relecture de "qualité" par la "pertinence" mesurée en ligne juste par ses propres outils statistiques, car elle est trop orientée selon ses objectifs commerciaux; pour cela Google est prêt à dissimuler des données et fausser la réalité, en présentant des vues très clairement biaisées du monde ou juste pour faire plaisir instantanément à chaque utilisateur et ne rien lui apprendre d'autre que ce que Google peut lui vendre, et en tout cas rien de durable : ce risque est trop important dans un monde de monopole puisque alors Google serait devenue la seule source, influençant trop les données de toutes les autres).

Même avec un duopole ce n'est pas suffisant, une concurrence saine, durable, innovante, performante et efficace, n'existe pas tant qu'il n'y a pas au moins 3 acteurs majeurs, quel que soit le domaine.

Pareil en politique ou dans l'économie en général : on a besoin d'un troisième camp, même quand il dérange, ou déroge aux "règles communes" élaborées par les deux autres camps, une opposition unique ne peut pas fonctionner durablement (même avec un système "démocratique" d'alternance), le piège étant l'immobilisme de ces règles communes et leur inadaptabilité ou incapacité même à voir et analyser les problèmes tels qu'ils sont.

Une vraie démocratie fait la séparation des pouvoirs (législatifs, administratifs, judiciaires et résolution des litiges par un tiers réellement neutre, pouvoir de contrôle, capacité d'informations et d'analyse par un tiers, donc non opacité des décisions et de l'action de ceux qui peuvent en prendre mais doivent aussi être eux-mêmes responsables), mais ne fonctionne pas sur ce principe dans un duopole où personne ne peut être neutre. Et encore moins dans un monopole où plus rien ne bouge jusqu'à son effondrement brutal dans un désordre complet où tous les abus deviennent possibles dans l'impunité la plus totale.

Le 2 avril 2015 07:16, Jo <[hidden email]> a écrit :
Ah, dommage que ce n'est pas sérieux. J'étais complètement pour... J'espère que vous n'avez pas oublié les branches coupées, ou on met ceux-là sur OHM?

_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr