Vendredi 9 Février 2018
6 réponses
4.6K vues
Utilisateur d'Archicad je l'utilise via un environnement client/serveur c'est à dire comme une boite mail Gmail : https://fr.wikipedia.org/wiki/Client-serveur
La technologie de collaboration BIM Archicad permet de collaborer en simultanée sur un unique fichier accessible via une connexion internet
On réserve pour modification : un trait, le gestionnaire des calques, un mur, des dalles, etc. ... Bref tout ou très précisément ce dont on a besoin
A l'image d'une bibliothèque communale, on a une adresse et une carte d'adhérent, ensuite on ajoute un livre ou on prend un livre selon sa disponibilité de celui-ci... C'est ainsi via Archicad si un élément est déjà réservé par un collaborateur à l'autre bout de la planète, on peut en faire la demande et 3 secondes plus tard on peut éditer l'élément
D'un point de vue matériel, aucune ressource matériel complémentaire du poste informatique de création BIM n'est nécessaire pour collaborer sur une maquette unique via Archicad : un ordi + une connexion internet et c'est tout
Qu'en est il via Revit ?
A - Peut-on collaborer sur un même fichier partagé en temps réel ?
B - Quel type de collaboration est possible (sous ensembles répartis par collaborateur, ou dito Archicad, etc. ...) ?
C - Quel environnement matériel conditionne la collaboration possible via Revit ?
D - Quel environnement logiciel conditionne la collaboration via Revit ?
La définition de client-serveur est à l'image d'un répertoire de contact partagé au sein d'une entreprise ou comparable au calendrier ou à une boite mail Gmail... Archicad fonctionne exactement sur ce principe. qu'en est il de Revit techniquement ?
Yohann
La technologie de collaboration BIM Archicad permet de collaborer en simultanée sur un unique fichier accessible via une connexion internet
On réserve pour modification : un trait, le gestionnaire des calques, un mur, des dalles, etc. ... Bref tout ou très précisément ce dont on a besoin
A l'image d'une bibliothèque communale, on a une adresse et une carte d'adhérent, ensuite on ajoute un livre ou on prend un livre selon sa disponibilité de celui-ci... C'est ainsi via Archicad si un élément est déjà réservé par un collaborateur à l'autre bout de la planète, on peut en faire la demande et 3 secondes plus tard on peut éditer l'élément
D'un point de vue matériel, aucune ressource matériel complémentaire du poste informatique de création BIM n'est nécessaire pour collaborer sur une maquette unique via Archicad : un ordi + une connexion internet et c'est tout
Qu'en est il via Revit ?
A - Peut-on collaborer sur un même fichier partagé en temps réel ?
B - Quel type de collaboration est possible (sous ensembles répartis par collaborateur, ou dito Archicad, etc. ...) ?
C - Quel environnement matériel conditionne la collaboration possible via Revit ?
D - Quel environnement logiciel conditionne la collaboration via Revit ?
La définition de client-serveur est à l'image d'un répertoire de contact partagé au sein d'une entreprise ou comparable au calendrier ou à une boite mail Gmail... Archicad fonctionne exactement sur ce principe. qu'en est il de Revit techniquement ?
Yohann
-1
Undo
Votes
A - Peut-on collaborer sur un même fichier partagé en temps réel ?
Oui via "Collaboration for Revit. L'outil est sympa
C - Quel environnement matériel conditionne la collaboration possible via Revit ?
Directement depuis Revit c'est possible via le cloud.
0
Undo
Votes
Bonsoir Remy,
La question n'est pas du tout de savoir si c'est possible (c'est évident) mais c'est de savoir comment très précisemment :
Je parle d'environnement client serveur, quid de Revit ? Est-ce un environnement client-serveur ?
Je parle de réservation d'élément ou de réservation de sous ensemble, quid de revit ? Quid à l'usage très concrètement ?
Je parle de ressource matériel, quid de revit ? (proxi, serveur local, etc. ...)
Je parle de ressource informatique, quid de revit ?
Je suis en mesure de répondre à toutes ces questions pour Archicad mais quid de Revit ?
A bientôt,
Yohann
La question n'est pas du tout de savoir si c'est possible (c'est évident) mais c'est de savoir comment très précisemment :
Je parle d'environnement client serveur, quid de Revit ? Est-ce un environnement client-serveur ?
Je parle de réservation d'élément ou de réservation de sous ensemble, quid de revit ? Quid à l'usage très concrètement ?
Je parle de ressource matériel, quid de revit ? (proxi, serveur local, etc. ...)
Je parle de ressource informatique, quid de revit ?
Je suis en mesure de répondre à toutes ces questions pour Archicad mais quid de Revit ?
A bientôt,
Yohann
0
Undo
Votes
Personne ne pratique ou plutôt ne sait comment fonctionne le travail collaboratif à priori
J'en conclue que ce n'est pas aussi "possible" qu'annoncé et reste avec mes nombreuses questions en suspend
J'en conclue que ce n'est pas aussi "possible" qu'annoncé et reste avec mes nombreuses questions en suspend
0
Undo
Votes
Bonjour,
Je lis quid beaucoup... (désolé, je devais faire cette blague pourrie). Et désolé pour le retard de réponse, je ne vois ce post que maintenant. J'espère qu'elle sera toujours d'actualité pour vous.
Vous demandez à savoir précisément comment cela fonctionne sous Revit. Donc, plutôt que de répondre point par point "bêtement", je vais présenter le contexte et principe du travail collaboratif sous Revit en tâchant d'être le plus exhaustif possible, afin que vous puissiez vous faire une idée des conditions et limites d'utilisation.
En prologue, Précisons que Revit inclut les fonctions nécessaires au travail collaboratif, sans nécessiter de fonctions ou outils complémentaires. La collaboration requiert une connexion internet et la présence du logiciel sur la machine de chaque intervenant (sauf à installer Revit dans un environnement Citrix XenApp ou XenDesktop). Donc, de ce point de vue, les conditions matérielles et logicielles sont exactement les mêmes, qu'il s'agisse de travailler en autonomie ou en collaboration. Comme si vous utilisez Archicad "tout seul dans votre coin".
Lorsque la fonction de collaboration est activée sur un projet, Revit génère ce qui s'appelle un fichier central. ce fichier doit être stocké sur un serveur local (installé dans l'agence, par exemple) ou sur un serveur distant, suivant la structure (organisation et/ou répartition géographique) du groupe de travail. Dans tous les cas, il doit être accessible à tous les intervenants sur la maquette. Il peut être nécessaire de requérir à l'installation d'un serveur Revit Server dans ce cas, mais cela ne modifie cependant pas le flux de travail et les conditions matérielles/logicielles par poste de travail ; Je n'en parlerai donc pas plus longuement ici.
A partir de ce fichier central, chaque intervenant génère son propre fichier de travail, enregistré sur sa machine. Ces fichiers sont appelés fichiers locaux, et sont l'exacte copie du fichier central à un instant t.
Dès lors, il n'est plus question de modifier le fichier central. Chaque intervenant accède aux informations de ce fichier partagé et envoie ces propres informations par le biais d'une fonction de synchronisation des données, depuis sa copie locale. Il est donc possible pour un intervenant de travailler sur son fichier local tout en étant déconnecté du réseau puis de se reconnecter ultérieurement pour synchroniser ses données avec le fichier central. Sans rentrer dans trop de détails, cela peut tout de même engendrer des problèmes, puisqu'il existe réellement plusieurs copies simultanées de la même maquette.
Afin de structurer le projet et d'attribuer des droits aux utilisateurs, un fichier partagé se décompose en sous-projets. Il s'agit ici de créer des jeux de travail, où chacun d'eux héberge un ou plusieurs objets de la maquette. Si, en théorie, il n'existe pas de contrainte imposée par Revit quant à la création et au nommage des sous-projets, il s'agit d'un point de vue logique du projet de créer des sous-projets conformes à la structure du groupe de travail. Il peut donc exister un sous-projet Architecture, un second Structure, un troisième VRD, etc. Tout autant qu'il peut exister un sous-projet Poteaux, un second Dalles, etc.
Ces sous-projets contiennent en eux-mêmes plusieurs intérêts. Le premier est donc de structurer les objets de la maquette de manière logique. Le second est d'administrer les droits de propriétés et d'emprunts durant une session de travail. L'intervenant qui crée un sous-projet devient de facto le propriétaire de ce sous-projet. Tant qu'il n'a pas libéré les droits d'utilisation (lors de sa synchronisation avec le central), personne d'autre ne peut modifier ce sous-projet. Tout objet appartient forcément à un et un seul sous-projet. Lorsqu'un intervenant souhaite modifier un objet dont il n'est pas propriétaire, et si les droits n'ont pas été libérés, il peut envoyer une requête à l'actuel propriétaire ou emprunteur pour obtenir l'autorisation de modification. S'il reçoit une réponse positive, il devient le nouvel emprunteur, jusqu'à la prochaine demande d'un nouvel intervenant ou jusqu'à ce qu'il libère les droits.
L'acceptation/refus de la requête n'est pas automatique. Elle est subordonnée à une action réalisée par le propriétaire/emprunteur de l'objet. Donc, si le propriétaire n'a pas libéré ses droits avant de partir en vacances, les autres utilisateurs ne pourront pas modifier ledit objet, et le projet prend du retard (oui, j'exagère )
En ce sens, on ne peut pas parler d'environnement client/serveur. Donc, la collaboration à plusieurs est possible, mais requiert une rigueur de travail accrue, notamment en ce qui concerne les droits sur chaque sous-projet et objets afférents et les attributions des tâches de chacun. Je précise que toute modification d'un objet (par exemple, placer une fenêtre dans un mur consiste en partie à modifier le mur) requiert de prendre les droits sur cet objet (en l’occurrence, en plus de la propriété de la fenêtre, vous devez obtenir les droits de modification du mur).
J'espère que tout ceci vous parait assez clair et précis (et indigeste ?)
Je lis quid beaucoup... (désolé, je devais faire cette blague pourrie). Et désolé pour le retard de réponse, je ne vois ce post que maintenant. J'espère qu'elle sera toujours d'actualité pour vous.
Vous demandez à savoir précisément comment cela fonctionne sous Revit. Donc, plutôt que de répondre point par point "bêtement", je vais présenter le contexte et principe du travail collaboratif sous Revit en tâchant d'être le plus exhaustif possible, afin que vous puissiez vous faire une idée des conditions et limites d'utilisation.
En prologue, Précisons que Revit inclut les fonctions nécessaires au travail collaboratif, sans nécessiter de fonctions ou outils complémentaires. La collaboration requiert une connexion internet et la présence du logiciel sur la machine de chaque intervenant (sauf à installer Revit dans un environnement Citrix XenApp ou XenDesktop). Donc, de ce point de vue, les conditions matérielles et logicielles sont exactement les mêmes, qu'il s'agisse de travailler en autonomie ou en collaboration. Comme si vous utilisez Archicad "tout seul dans votre coin".
Lorsque la fonction de collaboration est activée sur un projet, Revit génère ce qui s'appelle un fichier central. ce fichier doit être stocké sur un serveur local (installé dans l'agence, par exemple) ou sur un serveur distant, suivant la structure (organisation et/ou répartition géographique) du groupe de travail. Dans tous les cas, il doit être accessible à tous les intervenants sur la maquette. Il peut être nécessaire de requérir à l'installation d'un serveur Revit Server dans ce cas, mais cela ne modifie cependant pas le flux de travail et les conditions matérielles/logicielles par poste de travail ; Je n'en parlerai donc pas plus longuement ici.
A partir de ce fichier central, chaque intervenant génère son propre fichier de travail, enregistré sur sa machine. Ces fichiers sont appelés fichiers locaux, et sont l'exacte copie du fichier central à un instant t.
Dès lors, il n'est plus question de modifier le fichier central. Chaque intervenant accède aux informations de ce fichier partagé et envoie ces propres informations par le biais d'une fonction de synchronisation des données, depuis sa copie locale. Il est donc possible pour un intervenant de travailler sur son fichier local tout en étant déconnecté du réseau puis de se reconnecter ultérieurement pour synchroniser ses données avec le fichier central. Sans rentrer dans trop de détails, cela peut tout de même engendrer des problèmes, puisqu'il existe réellement plusieurs copies simultanées de la même maquette.
Afin de structurer le projet et d'attribuer des droits aux utilisateurs, un fichier partagé se décompose en sous-projets. Il s'agit ici de créer des jeux de travail, où chacun d'eux héberge un ou plusieurs objets de la maquette. Si, en théorie, il n'existe pas de contrainte imposée par Revit quant à la création et au nommage des sous-projets, il s'agit d'un point de vue logique du projet de créer des sous-projets conformes à la structure du groupe de travail. Il peut donc exister un sous-projet Architecture, un second Structure, un troisième VRD, etc. Tout autant qu'il peut exister un sous-projet Poteaux, un second Dalles, etc.
Ces sous-projets contiennent en eux-mêmes plusieurs intérêts. Le premier est donc de structurer les objets de la maquette de manière logique. Le second est d'administrer les droits de propriétés et d'emprunts durant une session de travail. L'intervenant qui crée un sous-projet devient de facto le propriétaire de ce sous-projet. Tant qu'il n'a pas libéré les droits d'utilisation (lors de sa synchronisation avec le central), personne d'autre ne peut modifier ce sous-projet. Tout objet appartient forcément à un et un seul sous-projet. Lorsqu'un intervenant souhaite modifier un objet dont il n'est pas propriétaire, et si les droits n'ont pas été libérés, il peut envoyer une requête à l'actuel propriétaire ou emprunteur pour obtenir l'autorisation de modification. S'il reçoit une réponse positive, il devient le nouvel emprunteur, jusqu'à la prochaine demande d'un nouvel intervenant ou jusqu'à ce qu'il libère les droits.
L'acceptation/refus de la requête n'est pas automatique. Elle est subordonnée à une action réalisée par le propriétaire/emprunteur de l'objet. Donc, si le propriétaire n'a pas libéré ses droits avant de partir en vacances, les autres utilisateurs ne pourront pas modifier ledit objet, et le projet prend du retard (oui, j'exagère
)En ce sens, on ne peut pas parler d'environnement client/serveur. Donc, la collaboration à plusieurs est possible, mais requiert une rigueur de travail accrue, notamment en ce qui concerne les droits sur chaque sous-projet et objets afférents et les attributions des tâches de chacun. Je précise que toute modification d'un objet (par exemple, placer une fenêtre dans un mur consiste en partie à modifier le mur) requiert de prendre les droits sur cet objet (en l’occurrence, en plus de la propriété de la fenêtre, vous devez obtenir les droits de modification du mur).
J'espère que tout ceci vous parait assez clair et précis (et indigeste ?)
0
Undo
Votes
Non pas du tout indigeste
Très clair et de plus servi avec un brin d'humour
Merci beaucoup pour ces précisions
J'avais trouvé ces informations via Linkedin mais vous les confirmez très bien ici
Encore merci
Très clair et de plus servi avec un brin d'humour
Merci beaucoup pour ces précisions
J'avais trouvé ces informations via Linkedin mais vous les confirmez très bien ici
Encore merci
Mohamed KHETTAB
updated the category from
to
Collaboration, coordination et communication — 1 year ago
There are no replies made for this post yet.
