Description de l’offre :
Nature du poste : Cartographe / Sigiste
Entreprise : Enedis, site d’Aubière (63)
Type de contrat : CDD intĂ©rim de 3 mois renouvelable jusqu’Ă 15 mois maximum, 35h/semaine
Date de prise de fonction : mi- novembre
DĂ©tails de la mission :
Enedis recherche un cartographe/sigiste, dans le cadre de projets d’amĂ©lioration de la qualitĂ© de sa base de donnĂ©es cartographiques.
Le poste Ă pourvoir consiste Ă mettre Ă jour et/ou Ă contrĂ´ler la qualitĂ© de la base de donnĂ©e patrimoniale des rĂ©seaux Ă©lectriques Ă partir d’outils spĂ©cifiques Ă l’Entreprise, ainsi que d’assurer la traçabilitĂ© des opĂ©rations dans les outils de gestion.
Profil recherché :
De formation Bac +5 dans le domaine du SIG ou des DAO/CAO avec une bonne connaissance des spĂ©cificitĂ©s de l’information gĂ©ographique.
La pratique des outils de type DAO/CAO, en particulier MicroStation, serait un plus
SĂ©rieux(se), motivĂ©e(e) et organisĂ©(e) avec un bon sens relationnel et l’esprit d’Ă©quipe.
Pour postuler :
Merci d’adresser votre CV avant le 26/10/18 Ă l’adresse suivante : audrey-externe.martinat-canifet AT enedis-grdf.fr
SAUNIER Infra, bureau d'études techniques dans les métiers des infrastructures et de l'environnement créé en 1952 à GAP, recherche un(e) Technicien-dessinateur-projeteur-topographe (H/F) en CDI.
Poste et missions : sous la tutelle d'un chef de projet ou d'un chargĂ© d'affaires de pĂ´les techniques en VRD, Hydraulique, Environnement, vous aurez pour mission d'effectuer et participer, dans le cadre d’opĂ©rations d’Ă©tudes ou de maĂ®trise d’œuvre, Ă : des prestations topographiques, la production de plans CAO/ DAO sous AUTOCAD 2D ou 3D, sous COVADIS ou sous SIG sous la responsabilitĂ© de diffĂ©rents ingĂ©nieurs, la rĂ©alisation de pièces graphiques (profils en long, en travers,…) ou techniques (mĂ©trĂ©s, calcul de terrassements,… ).
Si vous disposez des compétences requises, des missions de conception de projets VRD, d'eau, d'assainissement vous seront confiées ainsi que la rédaction des dossiers de consultation.
Connaissances supplémentaires appréciées : - marchés publics, - suivi de chantier / la rédaction des dossiers d'études et de consultation d'entreprises.
Profil recherché : De formation BAC +2/3 minimum, de type Topographe -TP ou similaire, avec idéalement une spécialisation en SIG. Expérience souhaitée d'au moins 5 ans (minimum 2 ans)
CDI à pourvoir dès que possible
Contact : M.PELLEGRIN Laurent : lpellegrin AT saunier-infra.fr
Bonjour Ă tous,
je travaille avec plusieurs dalles Pleiades. Au lieu d'effectuer un traitement dalle par dalle, je souhaite générer des dalles plus importantes (3x3 par exemple) avant de les faire ingérer par les algos OTB. Pour cela 2 méthodes :
- La fusion de tiles avec l'algo OTB idoine
- La création préalable de fichiers VRT qui serviront d'entrée aux algos OTB
Ma question : savez-vous comment OTB travaille avec un VRT ? le traitement est-il effectué dalle / dalle ou bien OTB procède t-il à une fusion des tiles en RAM de manière à traiter l'ensemble des dalles à la fois ?
Merci pour votre aide
Bonjour,
Dans le cadre de la réalisation de standards 2017 de PLU "anciens" (élaborés avec l'ancien code) : si certaines informations/prescriptions se trouvent abrogés ou sont devenus des SUP, est-ce que la bonne démarche est de les exclure des données géographiques? quid des pièces écrites s'il y a des pièces écrites spécifiques à ces éléments?
Cordialement,
Charlotte Trosseille
Bonjour Ă tous,
je souhaite faire différentes carto d'évolution de variables climatiques (températures moyennes, cumul des pluies, etc.) à l'échelle de territoires, en partant des données de projection mises à disposition sur DRIAS.
Le site met à dispo les informations par points, à partir d'un ensemble de « 143*134 points, numérotés de 0 à 19161 (origine en 41.4 N / 4.1 W, résolution 8 km) », appelée grille Safran.
À l'échelle d'un territoire, lorsque je récupère un petit nombre de points, je peux assez facilement recréer une grille vecteur autour de ces points en créant une grille de 8 km, en décalant les xmin, xmax, ymin, ymax de 4 000 pour que les points soient centrés. Cette grille, en y faisant une jonction spatiale avec le point à l'intérieur de chaque polygone, me permet une représentation graphique des évolutions à partir d'une maille de 8km*8km.
Seulement, je vois bien que le décalage ne doit pas être exactement de 8 km, car même sur un territoire limité (disons un gros EPCI), je sens un léger décalage de la grille par endroit.
Ce n'est pas gênant, puisque vu la maille et le degré de précision des projections, on est plus là pour donner un ordre d'idée des évolutions qu'une analyse locale précise.
Cela dit, pour gagner du temps et ne pas recréer ma grille à chaque fois autour d'un territoire, j'ai pensé à récupérer tous les points de France et créer ma grille, créer une carte de France pour chaque indicateur qui m'intéresse, et je n'aurai plus qu'à faire une extraction à chaque fois à partir du territoire qui m'intéresse.
Sauf que là , le petit décalage se sent, puisque nulle part ou presque le point est un centroïde, et la grille se décale partout.
J'imagine qu'il doit y avoir une notion de lien avec la projection (L93) et le fait que la terre est ronde ? Des trucs que je ne maitrise pas du tout en fait :) Parce que si je calcule la distance entre deux points au nord-ouest de ma carte avec la formule du théorème de Pythagore, et que je fais la même chose avec deux points au sud-est, je n'ai pas la même distance (respectivement 7 994,991518 mètres et 7 991,387593 mètres).
De là , comment puis-je assez facilement recréer une grille de polygones carrés autour de chaque point qui ne se décale pas et qui s'assure à chaque fois de mettre la limite de son polygone à mi chemin avec le point suivant, et ainsi la rendre exploitable ?
À moins que la grille elle-même soit téléchargeable, mais je doute, je n'ai rien trouvé sur le site, et j'imagine qu'en mettant à disposition la grille de points, ils considèrent que cela suffit évidemment.
Pour info, pour chaque point de la grille, j'ai les infos suivantes :
idPoint E_LambIIe N_Lamb2e E_Lamb93 N_Lamb93 Longitude Latitude Altitude
Merci par avance !
Groflo
[edit : d'ailleurs pour ceux qui voudrait faire un test, voir ce lien qui donne accès à la grille de points.]
[edit 2 : une alternative que je viens de trouver serait de changer le symbole des points directement, sans recréer de couches, en modifiant leur forme de point par une forme de carré de 8 000 mètres de côté. S'il y a ainsi de micro décalage dans les chevauchements, ils sent presque invisibles pour l'essentiel et résolvent le problème du décalage grandissant vis-à -vis des points, puisque c'est chaque point qui est directement une zone de 8km*8km !
Et en voyant l'image, je me rends compte que la grille est un peu « penchée », ce qui doit expliquer le décalage quand je crée une grille vecteur qui elle, crée une grille « droite », dans l'axe est-ouest / nord-sud.
Cela dit, si certains ont tout de mĂŞme une solution vraiment propre Ă me proposer, je prends ! Merci]
Bonjour,
Les couches créées à partir de requêtes apparaissent vide à la réouverture du projet.
Peut-être parce que ces couches sont des couches dites temporaires et ne sont donc pas sauvegardées d'une session à l'autre. Vous pouvez soit les enregistrer en dur sur votre disque soit utiliser le plugin "Memory layer saver" qui conservera la mémoire de ces couches temporaires dans un fichier de même nom à côté de votre projet .qgs (avec l'extension mldata, je crois)
Bonjour Ă tous,
Ecologue marin, je souhaite utiliser pour le recueil de mes données récoltées en mer (coord geo) l'application Navionics, qui me permet d'avoir à dispo un fond bathy pour la navigation.
NAVIONICS me permet d'enregistrer des points seulement en DMS (donc conversion en degrés décimaux de rigueur pour exploitation sous QGIS)...et d'enregistrer la trace de ma prospetion...mais je n'arrive pas à la harger sous QGIS.
J ai trouvé un plugin permettant de convertir des données .shp en .kmz/kml, mais pas l'inverse...
Auriez vous l'âme salvatrice aujourd'hui et sous le coude une solution?
Mille mercis pour votre précieuse aide...
La RĂ©union vous salue!
Tu le fais une fois pour tous les terrains. Ensuite, tu utilises une sélection spatiale pour sélectionner toutes les mailles qui touchent à un polygone, tu inverses la sélection et tu supprimes toutes les mailles inutiles. Un clip ferait aussi le travail, mais il couperait les mailles en fonction du contour des terrains
Bonjour Ă tous,
Je profite de ce topic pour rebondir sur ma problématique du moment.
Écologue marin dans la zone Sud Ouest Oéan Indien, j'ai recours à QGIS pour des analyses spatiales...mais loin d'être une experte!
J'ai utilisé Navionics pour relever les coordonnées GPS de mes observations (mammifères marins) à Mohéli (Comores)...d'habitude, j'ai recours à un GPS Garmin classique.
- Données DMS converties en DD (degrés décimaux) pour exploitation carto sous QGIS
- Fichier excel converti en CSV
- Syst de projection : UTM38S - EPSG 2999 (Grande Comore)
Problème :mon nuage de points s'affiche seulement lorsque je zoome sur la couche (clic droit sur ma couche de points), mais je perds alors le fond ortho Google Sat (via QuickMapServices).
Est-ce que j'ai oublié une étape? Ou est-ce que ces fonds ne permettent pas la superposition des points?
Le cas échéant, connaissez vous un site/bibliothèque numérique me permettant d'acquérir des images géoréférencées de préférence (format TIFF par exemple) et libres de droit pour la zone sud ouest Océan Indien (Comores, Seychelles, Madagascar etc.)?
Mille mercis pour votre précieuse aide...
Bonjour Ă tous,
Autodidacte sur Qgis donc il est possible que je fasse les choses mal, mais j'ai bonne espoir que vous puissiez m'aider.
En fait, je cherche un moyen à augmenter la taille des points, si plusieurs lignes de mon enregistrement en csv, ont les mêmes coordonnées.
Je m'explique.
Je possède un listing sur excel en csv référençant différents types de tombes (je travaille en archéologie). Sur une même commune, il arrive souvent qu'il y ai plusieurs tombes datées de différentes périodes.
De fait, dans mon classeur csv, ces tombes apparaissent sur différentes lignes, pour autant elles ont les mêmes coordonnées.
Je voudrais donc les cumuler afin d'avoir un point proportionnellement plus gros suivant le nombre de ces enregistrement comme si j'avais une colonne indiquant le nombre de tombes par commune avec l'outil gradué de Qgis.
https://www.casimages.com/i/181022023532998624.jpg.html
J'espère avoir été à peu près clair...
Je vous remercie d'avance, A.
Bonjour,
Nouvel utilisateur de ce produit, je dois refaire chaque fois mon travail de la veille. Les couches créées à partir de requêtes apparaissent vide à la réouverture du projet. Seules sont visibles les couches importées de fichiers TAB.
Quelqu'un a t il une idée pour faire réapparaître le contenu des couches pourtant présentes (idem pour les groupes) ?
Merci par avance.
Bonjour,
dans la configuration que nous avons mis en place avec l'aide de Dalibo, nous utilisons la method sspi dans le fichier hba.conf pour l'authent avec l'active directory.
Ce protocole étant intégré à QGis, il n'y a plus besoin de saisir les login/mot de passe dans QGis à condition d'avoir une correspondance entre les login AD et les rôles PG. Attention, il faut que les connexions PG déclarées dans QGis, soient enregistrées sans login ni mot de passe.
Attention, il faut mettre en place une règle dans le pg_ident.conf pour la correspondance entre le login AD et le role PG (le login AD comprend également le nom de domaine en plus du login utilisateur).
L'expertise de Dalibo a été très intéressante dans la mise en place de cette fonctionnalité, je vous conseillerai (si vous avez un petit budget, 1 journée de presta) de voir directement avec eux.
Bonne journée
Xavier
Bonjour Ă tous,
J'ai donc une couche d'entrée contenant 300 000 données. L'un de ces champs ("Nom") est un champ texte contenant environ 300 chaînes de caractères différentes. Quand j'affiche toutes les données sur la carte, on n'y voit plus rien car elles se recouvrent toutes les unes les autres.
Je cherche donc à supprimer les données ayant la même valeur dans un champ texte si ces données sont trop proches géographiquement.
Pour essayer d'automatiser le nettoyage des données, j'ai essayé en utilisant le modeleur de traitements.
- Je crée d'abord une matrice de distance pour cette couche.
- Ensuite, je sélectionne dans cette matrice toutes les distances inférieures à une certaine valeur (nommons la D).
- Je joins ensuite Ă la matrice la valeur du champ "Nom" correspondant Ă chaque ID de la matrice.
- Je me retrouve avec une table de type "InputID","TargetID", "Distance", "NomID1", "NomID2".
- Je sélectionne alors les données répondant aux critères suivant : "NomID1" = "NomID2" ET "DIstance" < D.
- Je me retrouve alors avec une liste de mes valeurs en double et proches géographiquement.
Cependant, je ne sais pas comment ensuite dire Ă QGis de conserver une seule des valeurs en double proches (j'ai parfois 5 valeurs en double proche).
De plus, dans cette table des "presque doublons", chaque doublon apparaît 2 fois, une fois avec l'identifiant de l'une des données en "InputID" et celui de l'autre donnée en "TargetID", et une seconde fois avec les identifiants inversés (le premier dans "TargetID" et le second dans "InputID").
Voilà , si vous pouvez me dépanner je suis preneur :) J'espère que mes explications sont assez claires.
Merci d'avance !
Bonjour,
je ne connais pas vraiment votre structure de LDAP, difficile de voir sur la déclaration du pg_hba.conf est juste. En revanche, ce mode d'accès ne crée pas les utilisateurs du LDAP dans la base PG, il faut le faire séparément.
L'utilitaire ldap2pg de Dalibo fait le job, et plutôt bien.. Attention toutefois, paramétrer les règles de synchronisation nécessite de bien maitriser les concepts LDAP et la structuration des groupes souhaités. Je vous conseille de vous faire accompagner pour cette partie.
Bonjour,
Je suis également en cours d'analyse du standard 1.1 pour l'implémenter dans ma structure.
Voici quelques remarques générales (d'un géomaticien) et précisions sur les interrogations déjà soulevées :
Remarques générales
# Classes d'objet et attributs
* précisions x,y,z
(p31, 32,34,35,36) Le type déclaré prévoit de gérer les infos au millimétre. Est ce une nécessité d'être aussi fin. le cm n'était t-il pas suffisant ?
* l'attribut filGen (p14) décrivant "la profondeur moyenne de la génératrice supérieur de la canalisation" est considéré comme une spécialisation de la classe d'objet <Canalisation AE>. Ceci nous interroge car cet attribut devrait plutot relever d'une propriété générique de canalisation AEP et ASS. Par ailleurs, sauf à considérer que cet attribut est destiné à faciliter rapidement un accès à l'information (étiquettage ?), le terme profondeur est dangereux car relatif à la surface donc la gestion peut être indépendante de celui qui a en charge le réseau. Il aurait mieux valu utiliser la référence de l'altitude (ngf) de la génératrice supérieure qui doit pouvoir être déduite des z amont et aval de la cana.
* l'attribut DIAMETRE (p30 et p33) des tables RAEPA_APPARAEP_P et RAEPA_APPARASS_P n'est pas référencé dans la partie conceptuelle. Il devrait être placé au niveau de la sous classe appareillage ou alors être supprimé des tables implémentées.
* l'attribut LONGCANA décrivant la longueur de la canalisation en mètre est de type entier dans la partie implémentée (p29 et p33) mais décimal dans la partie conceptuelle (p13). Le type entier sous entend une simplification de mesures (pour étiquettage ?) et tend à renvoyer à l'emploi de la géométrie pour une mesure calculée décimale. Est ce bien ceci qui est sous entendu ?
# Domaines de valeurs / liste
Les domaines de valeur posent des problématiques de reclassement des données existantes et 2 cas se rencontrent :
* le domaine RAEPA est plus riche, plus détaillé que les données sources.
C'est par exemple le cas de la liste des matériaux (p20) qui est extremement riche et très très fine (ex : 4 valeurs possibles pour du béton). N'aurait il pas mieux valu avoir soit une liste à emboitements (ex : 10=béton, 11=béton âme tôle, 12=béton armé, 20=PVC, 21=PVC ancien, 22=PVC BO ...) soit employer un type et sous-type comme dans d'autre standard (ex : prescriptions et information des documents d'urbanisme). Cette finesse engendre un reclassement avec une perte d'information car pour une valeur "béton" dans les données actuelles, la migration stricto census au standard RAEPA, la fait passer à 99=autre.
* le domaine RAEPA est plus "ramassé" que les donnée sources
La problématique est donc celle d'une reventilation dans le standard (et l'ajout d'un sous type pour conserver l'info plus fine de départ). Par exemple, comment reclassé un ouvrage de sépateur d'hydrocarbure ? Il s'agit d'un ouvrage de traitement des eaux usées et la correspondance la plus proche dans le domaine <Ouvrage ASS> (p22) semble être la 02=Station d'épuration. Je pense que le standard devrait plus expliciter les sous types d'ouvrage ou d'appareillage que chaque valeurs du domaine peut recouvrir ou NON.
Précisions sur les questionnements précédents
- pour les raccords je les ai ajouté dans la table appareillage avec un nouveau type créé : raccord
Pour ma part, à ce stade, j'en déduis qu'un noeud dépourvu d'un appareillage ou d'un ouvrage est donc un raccord. Ceci reste à examiner après discussions avec des gens du métier AEP/ASS.
- IDNINIA :Identifiant du noeud de début (AMONT) de la canalisation correspondant à un appareillage
- IDNINIO : Identifiant du noeud de début de la canalisation correspondant à un ouvrage
- IDNTERMA : Identifiant du noeud de fin (AVAL) de la canalisation correspondant Ă un appareillage
- IDNTERMO : Identifiant du noeud de fin de la canalisation correspondant Ă un ouvrage
Du point de vue de la modélisation, normalement ces information sont directement héritées et déduites de la classe noeud
- pour la cana principale, je pense que ce champ est fait pour les branchements particuliers
MĂŞme analyse pour ma part. Info Ă ne renseigner que dans le cas d'une canalisation de branchement, surtout en cas de piquage (noeud pas forcement coupant)
Sur les gabarits prêts à emploi, attention mais le téléchargement complet du "paquet" transmet la doc du v1.0 du standard et non la v1.1. Pour ma part, il ne me semble pas y avoir eu de modifications de ce dernier depuis février 2017.
Cordialement
Florent
Le Groupe INTM, dans le cadre d'un remplacement cherche pour une de ses Ă©quipes un:
1. Consultant AMOA, 4-5 ans d'expérience capable de faire de la cartographie et qui connait la gestion de projet.
Le client se trouve à proximité des transport en petite couronne parisienne.
Poste est à pourvoir au plus tard début Décembre. Si vous avez plus d'un mois de préavis, je vous prie de ne pas postuler.
Envoyez vos candidatures Ă rafael.boavida AT intm.fr
Ce message étant très vieux, tout visiteur perdu par ici pourra consulter entre autres un fil plus récent (de 2013) :
Comparaison des formats ecw et jpeg2000
- https://georezo.net/forum/viewtopic.php?id=88200
ainsi qu'un fil encore plus récent :
https://georezo.net/forum/viewtopic.php … 78#p289078
En espérant que cela puisse aider.
étant arrivé sur ce message en cul-de-sac à partir d'une discussion plus "récente" de mai 2016 dans laquelle l'auteur d'ici nico-29 avait indiqué qu'il n'avait pas eu de réponse ici-même, cette dernière comportait en tout cas depuis ce mois de mai 2016 une réponse :
https://georezo.net/forum/viewtopic.php … 60#p282460
Bonjour,
Pour info, sujet chez les voisins aussi http://www.forumsig.org/showthread.php/ … -seule-%29