Agrégateur de flux

Nombre de message(s) précédent(s) : 518

Bonjour la multitude,

je suis à la recherche de PLU appliquant le nouveau code de l'urbanisme (post-2015, donc), c'est-à-dire sans la structure par articles.
Il n'est pas nécessaire qu'ils soient déjà sur le GPU. Un envoi par courriel est bienvenu s'il ledit PLU n'est pas en ligne. Le fichier .shp est n'est pas une absolue nécessité à ce stade.

L'objet est de tester puis d'entraîner notre petite machine learning SmartPLU pour qu'elle soit applicable à ce type de PLU.

Merci

Nombre de message(s) précédent(s) : 1

Bonjour,

Il faut regarder quels sont les droits restants et les enlever.

Regardez du coté des privilèges par défaut, notamment ceux du role postgres comme a l'air de l'indiquer le message.

Dans psql, la commande \ddp montre ces privilèges pour différents objets.

un "ALTER DEFAULT PRIVILEGES..." pourra sûrement régler le pb.

Nicolas

Nombre de message(s) précédent(s) : 1

En complément, voici la réponse de SIRAP:

Il y a deux aspects :
1. Edipocket restitue directement les informations délivrées par votre terminal  : c'est le cas notamment des indicateurs E_HRMS (err max horizontal), E_VRMS (err max vertical) et tout les DOP (y compris les PDOP, HDOP, VDOP et TDOP).
2. Edipocket assure la projection des coordonnées délivrées par le terminal (tjrs en coordonnées polaires) vers le RGF ainsi que la conversion de la hauteur à l'altitude. Dans les deux cas Edipocket utilise les grilles de l'IGN (celle du ntf_r93.gsb pour la planimétrie et celle que vous avez choisie pour l'altimétrie IGN69:RAF09 ou IGN69:RAC09).

Pour le deuxième aspects nous pouvons vous indiquer que la librairie utilisée est PROJLIB. De mémoire elle a été validée par l'IGN en 2009 (à 10E-9 me semble t il)

Finalement ça ne m'avance pas beaucoup, sauf que les erreurs E_HRMS et V_HRMS sont bien des erreurs "brutes" qui ne tiennent pas compte de ce que j'ai spécifié dans Edipocket.

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

Nombre de message(s) précédent(s) : 517

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]

Nombre de message(s) précédent(s) : 1

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!

Nombre de message(s) précédent(s) : 2

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

Nombre de message(s) précédent(s) : 2

merci je vais regarder ça

Nombre de message(s) précédent(s) : 8

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.

Nombre de message(s) précédent(s) : 2

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 !

Nombre de message(s) précédent(s) : 1

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.

Nombre de message(s) précédent(s) : 5

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