[migration:résolu] J'attaque les questions pgsql

[sly]

Je commence à faire quelques essais avec postgresql et GIS surtout.

J'en suis à mettre quelques polygones en provenance de osm voir comment on peut faire des requêtes croisées entre les points de notre base et ces polygones.

La question conversion de nos polygones massifs/cartes suisses qui ne sont pas dans osm et les convertir en GIS est toujours d'actualité.

Je laisserais quelques démos de requêtes de type recherche/appartenance/etc. pour qu'on puisse voir où ça peut servir

[yip]

La question conversion de nos polygones massifs/cartes suisses qui ne sont pas dans osm et les convertir en GIS est toujours d'actualité.

100% des polys etait déja convertis sur la base de prod.
j'y avais passé 30 heures mais j'ai toujours les macros. Si tu peux faire les polygones "sourcés" comme les administratifs, je m'occupe du custom comme les massifs et les cartes suisses (carrées), j'ai besoin des tables de correspondance pour ça.

Je laisserais quelques démos de requêtes de type recherche/appartenance/etc. pour qu'on puisse voir où ça peut servir

dans ma branche, certaines sont deja en GIS (recherche, liste_point(s) ... ), avec le gis de mysql, donc le GIS foireux a la MBR, j'ai preferer programmer sans tenir compte des resultats approximatifs, mais pour que le code soit portable chez PG.
(function = ST_function chez PG, en tout cas, undocumented mais il connait . )?
Ce devrait etre des fonctions GIS portables (mais alors ce qu'il y a autour ....)

[sly]

La question conversion de nos polygones massifs/cartes suisses qui ne sont pas dans osm et les convertir en GIS est toujours d'actualité.

100% des polys etait déja convertis sur la base de prod.
j'y avais passé 30 heures mais j'ai toujours les macros. Si tu peux faire les polygones "sourcés" comme les administratifs, je m'occupe du custom comme les massifs et les cartes suisses (carrées), j'ai besoin des tables de correspondance pour ça.

ok. (Les tables de correspondances y sont nom ?)

dans ma branche, certaines sont deja en GIS (recherche, liste_point(s) ... ), avec le gis de mysql, donc le GIS foireux a la MBR, j'ai preferer programmer sans tenir compte des resultats approximatifs, mais pour que le code soit portable chez PG.
(function = ST_function chez PG, en tout cas, undocumented mais il connait . )?
Ce devrait etre des fonctions GIS portables (mais alors ce qu'il y a autour ....)

- Je n'ai pas pu convertir le gis mysql vers pg (migrateur ne savait pas faire) (champs gis à refaire en geom)
- fonctions gis : oui, il ne faut utiliser que celles en st_*