Message posté par : Alban Kraus
----------------------------------------
Bonjour,
-----------------
BHaas écrit :
Le soucis que je rencontre c'est que lors de la création des points de rencontre (via PGAdmin) mes points se retrouvent au milieu de l'océan Atlantique.
Pourtant d'après les propriétés de la couche le système de projection est bien le Lambert 93 (ESPG: 2154).
-----------------
Si vos données se retrouvent au large du golfe de Guinée, le diagnostic est clair : vous tentez d'afficher comme du Lambert-93 des données qui sont en réalité des latitudes-longitudes. Si vous associez, dans les propriétés de la couche, le SRS EPSG:4326, vos points se retrouvent-ils au bon endroit ?
-----------------
BHaas écrit :
Je me suis demandé si le problème ne venait pas de ma couche de base servant au calcul des points mais ce n'est pas le cas, les données apparaissent bien là où elles sont supposées être et avec le bon EPSG.
-----------------
Il me semble que le monde du transport aime beaucoup les données en latitude-longitude. Voudriez-vous vérifier très attentivement toutes les étapes de l'intégration en base PostGIS :
* Comment sont exprimées les coordonnées dans votre jeu de données initial ? (si c'est du GTFS, ce sont forcément des latitudes-longitudes)
* Comment les avez-vous chargées en base PostGIS ? Avez-vous bien spécifié le SRS des données sources et demandé explicitement une transformation vers Lambert-93 ?
* Dans votre base de données PostGIS, avez-vous verrouillé vos colonnes de géométrie pour n'accepter que des géométries se présentant comme étant exprimées en Lambert-93 ?
-----------------
BHaas écrit :
J'ai utilisé la requête sql: SELECT UpdateGeometrySRID('bus_lignes_pt', 'geom', 2154); pour vérifier que le SRID était bien le 2154
-----------------
Non, cette requête force les données à se présenter comme étant du Lambert-93, mais ne modifie pas les coordonnées. Un peu comme si vos données étaient capables de parler, avant : « Bonjour, je suis (0.152, 45.146) et je suis en 4326 » après « Bon, ben je suis (0.152, 45.146) et je suis en 2154 ».
Vous auriez plutôt souhaité utiliser :
-----------------
Code :
ALTER TABLE bus_lignes_pt ALTER COLUMN geom SET DATA TYPE GEOMETRY(Point, 2154);
-----------------
qui vous aurait renvoyé une erreur si les géométries n'étaient pas en 2154. Ou :
-----------------
Code :
SELECT DISTINCT ST_SRID(geom) FROM bus_lignes_pt;
-----------------
qui vous aurait affiché le (ou les différents) SRID de vos données.
Vous souhaitant un bon débogage,
----------------------------------------
Le message est situé https://georezo.net/forum/viewtopic.php?pid=375084#p375084
Pour vous désabonner connectez-vous sur le forum puis Profil / Abonnement
--
Association GeoRezo - le portail géomatique
https://georezo.net
Message posté par : BHaas (b.haassig(a)gmail.com)
----------------------------------------
Bonjour à toutes et à tous,
Un peu de contexte:
Je travail à la modélisation de lignes de bus, pour éviter de me retrouver avec des lignes superposées je suis le tuto suivant: https://geotribu.fr/articles/2021/2021-04-07_carte_reseau_bus/#creer-des-po…
Le soucis que je rencontre c'est que lors de la création des points de rencontre (via PGAdmin) mes points se retrouvent au milieu de l'océan Atlantique.
Pourtant d'après les propriétés de la couche le système de projection est bien le Lambert 93 (ESPG: 2154).
Je me suis demandé si le problème ne venait pas de ma couche de base servant au calcul des points mais ce n'est pas le cas, les données apparaissent bien là où elles sont supposées être et avec le bon EPSG.
J'ai utilisé la requête sql: SELECT UpdateGeometrySRID('bus_lignes_pt', 'geom', 2154); pour vérifier que le SRID était bien le 2154 et ca n'a rien changé.
Le problème doit avoir un lien avec la première étape de calcul puisque les données de bases sont bonnes mais je ne trouve pas d'où provient l'erreur et comment la corriger.
Est-ce que quelqu'un à déjà rencontré ce genre de problème ?
PS: Je n'ai pas trouvé de section dédiée aux questions SQL désolé je poste au mauvais endroit
----------------------------------------
Le message est situé https://georezo.net/forum/viewtopic.php?pid=375082#p375082
Pour vous désabonner connectez-vous sur le forum puis Profil / Abonnement
--
Association GeoRezo - le portail géomatique
https://georezo.net
Message posté par : AlineC
----------------------------------------
Ca y est, j'y suis arrivé !
Bizarrement le filtre que j'avais mis sur ma couche commune (insee=@atlas_pagename) ne marchait pas vendredi soir mais marchait ce matin !
Et après, les étiquettes étaient toujours visibles ! Je pense que c'est parce que c'était des étiquettes à partir d'une table jointe. J'ai donc rajouté mon filtre dans chaque symbologie. Et cette fois ci, le rendu est comme je le souhaitas.
Je testerais peut-être aussi la solution de conejo avec le code intersect.
Merci à toutes/tous
----------------------------------------
Le message est situé https://georezo.net/forum/viewtopic.php?pid=375081#p375081
Pour vous désabonner connectez-vous sur le forum puis Profil / Abonnement
--
Association GeoRezo - le portail géomatique
https://georezo.net
Message posté par : Jean Cascalès
----------------------------------------
Bonjour,
Dans les ensembles de règles de l'onglet Symbologie, si on veut différencier la commune de l'atlas par rapport aux autres communes, il faut écrire
Code:
-----------------
Citation :
$id=@atlas_featureid
-----------------
----------------------------------------
Le message est situé https://georezo.net/forum/viewtopic.php?pid=375066#p375066
Pour vous désabonner connectez-vous sur le forum puis Profil / Abonnement
--
Association GeoRezo - le portail géomatique
https://georezo.net
