J'aimerais savoir si je suis le seul a qui ça fait bizarre de "casser" les objets geom dès qu'on veut les sortir de la base ?
(casser = AsGML, Astext..., leur enlever leur signification de géométrie, pour les transformer en chaines et floats qui ne veulent rien dire.
Ces mêmes floats seront ensuite retransformés en géométrie chez le client)
Grace à ce type d'objet, on a gagné une couche d'abstraction.
malheureusement on la reperds aussitôt en les décapsulant aussi sec, pour les traiter a l'ancienne avec des X et des Y.
Comme si on s'en servait juste pour faire des intersects et Within de temps a autre (avantage),
et on luttait contre le reste du temps avec des AsX et AsText pour retrouver le fonctionnement d'avant.
Désolé j'arrive pas à m'y faire. ça me semble pas naturel. pas PostGIS-friendly en fait.
De voir toute l'énergie dépensée dans cette phase de décapsulage, ça me fait bizarre, comme un anachronisme.
Ya sans doute pas de solution parfaite, c'est peut-etre inévitable, mais ça vous fait pas un petit pincement ?
De l'utilité de PostGIS
-
sly
- Messages : 5041
- Enregistré le : 29 févr. 2004, 17:59
- Localisation : Chambéry - Savoie
non ;-)
Pensée philo-technique du soir :
J'ai l'impression que toute l'informatique se résume à ce schéma, et je pense que ça s'explique relativement bien, chaque outil a son modèle de donnée pour les traiter efficacement selon les besoins qu'on veut de cet outil et lorsque l'on veut faire communiquer deux outils entre eux on passe par un modèle de donnée fait pour l'échange.
Dans mon bidulephone, j'ai un carnet de contact téléphonique, je n'ai fichtre aucune idée de comment il stocke ça en interne (et je m'en fiche un peu, bien que je suppose que ça doit être une base binaire avec index, redondance et que sais-je encore qui lui permette d'être performant) et lorsque je veux transférer ça dans mon logiciel sur mon ordinateur (thunderbird, qui lui stoque dans une base sqlite dont le schéma est prévu pour être performant dans son cadre d'utilisation) je demande au premier de m'exporter au format "vcard" une copie de sa base, que je transmets à thunderbird qui lit le vcard et s'empresse de le stocker dans son sqlite.
L'analogie me semble similaire entre postGIS et OpenLayers. Chacun gère en interne sa sauce (PG avec index, format binaire et OL avec son parseur de géométrie et sans doute une représentation en RAM des géométries), et ça n'a pas de sens à mon avis d'espérer copier d'un modèle interne de l'un vers l'autre car leurs besoins sont différents et la représentation suit ce besoin.
C'est pourquoi PG autant que OL savent gérer un format d'échange commun qu'il faut sortir de l'un pour faire manger à l'autre, et en plus, on a largement l’embarra du choix : géoJSON, GML, WKT, WKB qu'il nous faut choisir selon les additifs qu'on souhaite placer pour éviter d'avoir plusieurs canaux de communication (d'où GML plutôt que WKB pour faire passer nos icones et nos styles, mais on pourrait sans doute choisir WKB)
Ça ne me semble pas étrange car :
Le tinyows faisait d'ailleurs exactement ça, faire un ST_GeomFromGML http://lists.maptools.org/pipermail/tin ... 00085.html
Mapnik que j'utilise et qui fonctionne pourtant de local à local (par d'internet entre les deux) demande le format WKB qui est plus concis encore que GML et un peu plus rapide à parser, mais ne touche jamais en direct les géométries stockées dans les fichiers de PG.
Le format WKB c'est ce que tu obtiens en ne demandant aucune conversion à PG, mais même s'il ne sont pas clairement visible, les X et les Y sont là quand même ;-)
Pensée philo-technique du soir :
J'ai l'impression que toute l'informatique se résume à ce schéma, et je pense que ça s'explique relativement bien, chaque outil a son modèle de donnée pour les traiter efficacement selon les besoins qu'on veut de cet outil et lorsque l'on veut faire communiquer deux outils entre eux on passe par un modèle de donnée fait pour l'échange.
Dans mon bidulephone, j'ai un carnet de contact téléphonique, je n'ai fichtre aucune idée de comment il stocke ça en interne (et je m'en fiche un peu, bien que je suppose que ça doit être une base binaire avec index, redondance et que sais-je encore qui lui permette d'être performant) et lorsque je veux transférer ça dans mon logiciel sur mon ordinateur (thunderbird, qui lui stoque dans une base sqlite dont le schéma est prévu pour être performant dans son cadre d'utilisation) je demande au premier de m'exporter au format "vcard" une copie de sa base, que je transmets à thunderbird qui lit le vcard et s'empresse de le stocker dans son sqlite.
L'analogie me semble similaire entre postGIS et OpenLayers. Chacun gère en interne sa sauce (PG avec index, format binaire et OL avec son parseur de géométrie et sans doute une représentation en RAM des géométries), et ça n'a pas de sens à mon avis d'espérer copier d'un modèle interne de l'un vers l'autre car leurs besoins sont différents et la représentation suit ce besoin.
C'est pourquoi PG autant que OL savent gérer un format d'échange commun qu'il faut sortir de l'un pour faire manger à l'autre, et en plus, on a largement l’embarra du choix : géoJSON, GML, WKT, WKB qu'il nous faut choisir selon les additifs qu'on souhaite placer pour éviter d'avoir plusieurs canaux de communication (d'où GML plutôt que WKB pour faire passer nos icones et nos styles, mais on pourrait sans doute choisir WKB)
Ça ne me semble pas étrange car :
Je ne pense pas qu'il existe, en premier lieu, "d'objet géométrique" stocké dans les fichiers de PG, pas au sens un "truc" que connaîtrait quelqu'un d'autre que PG, il n'y a qu'une représentation interne, et représentation interne qu'il ne nous est même pas possible d'atteindre.yip a écrit :J'aimerais savoir si je suis le seul a qui ça fait bizarre de "casser" les objets geom dès qu'on veut les sortir de la base ?
Le tinyows faisait d'ailleurs exactement ça, faire un ST_GeomFromGML http://lists.maptools.org/pipermail/tin ... 00085.html
Mapnik que j'utilise et qui fonctionne pourtant de local à local (par d'internet entre les deux) demande le format WKB qui est plus concis encore que GML et un peu plus rapide à parser, mais ne touche jamais en direct les géométries stockées dans les fichiers de PG.
Le format WKB c'est ce que tu obtiens en ne demandant aucune conversion à PG, mais même s'il ne sont pas clairement visible, les X et les Y sont là quand même ;-)
Code : Tout sélectionner
test=> select geom from points_gps limit 1;
geom
----------------------------------------------------
0101000020E610000000000000000018400000000000804740
(1 ligne)
test=> select st_asEWKB(geom) from points_gps limit 1;
st_asewkb
------------------------------------------------------
\x0101000020e610000000000000000018400000000000804740
(1 ligne)
-
yip
- Messages : 387
- Enregistré le : 08 mars 2004, 23:32
Merci de la longue réponse Sly.
rien n'est figé, et des couches au modèle se rajoutent régulièrement.
Au début, les cartes de WRI etaient des PNG sur disque, le modèle de donnée commun etait "les pixels en partant du haut a gauche".
Maintenant le modèle de donnée commun est "une coordonnée WGS84". mais en descendant dans les couches, on trouvera toujours des pixels.
Plus tard, ce sera peut-être "le regard de l'utilisateur"
, mais il y aura encore des WGS84, et dessous tout en bas, des pixels.
Ceux ci etaient pourtant au sommet des couches il y a 10 ans. Et le jour où on a laissé tomber les pixels pour passer a la couche du dessus, les degrés, on y a gagné.
Il me semble qu'on vient de franchir une étape comme ça.
Tous les outils GIS font des AsGML/AsWK* a un moment ou a un autre ...
Les datas sont forcement représentés sous forme de float et d'octet.
le AsGML (de la surcouche-scripts PGIS) lui même fait surement appel a des fonctions de conversions blob->decimal (de la couche PostGres) qui elle-mêmes ont des pointeurs C++ sur des dumps? (de la couche libc6 ?)...
C'est trop terre à terre. Chacune fait de l'abstraction pour celle du dessous.
PG et OL, C'est la même chose que Apache et Firefox. Pour dialoguer, les 2 se base sur le standard TCP.
On s'occupe pourtant pas de savoir s'ils se sont concertés pour les JumboTrames ou les buffers d'ACKnowledge
On a donné a bouffer nos pages HTML à apache, et FF se demerde pour les recevoir et les afficher.
ça marche bien parce qu’il sont du même niveau dans le modèle OSI.
Que ça se fasse par pigeon voyageur ou par rsync, tant que les 2 se comprennent ...
Il y a quand même une difference. OL sait traiter avec la couche de transport (disons GML) mais pas PG.
Ils sont pas au même niveau...
PG ne sait pas générer une couche de transport(il doit pas être fait pour).
Tout ce qu'il sait faire c'est faire un peu de formatage pour faciliter le travail, mais pas au point de gagner une couche. c'est du dirty-hack.
La fonction PG query_as_xml, accompagnée d'une feuille XSLT pourrait a la limite generer cette couche, mais elle se marrie mal avec PostGis, et ça a l'air crade aussi.
Pour moi, on a donc là une inégalité de niveau dans le modèle.(pô grave, juste pour montrer le truc).
On a tout intêret a bosser toujours au niveau le plus haut, et laisser faire les couches du dessous comme elles l'entendent.
par exemple, on touche à HTML, pas au HTTP->TCP (HTML ne veut rien dire pour un routeur)
on va coder en langage objet, pas a sa représentation interne, forcément séquentielle (un CPU est séquentiel, à un moment, le code est transformé)
on s'occupe de Degrés, pas de pixels (les degrés n'existent pas pour un ordi, les pixels, si)...
La reflexion que j'avais c'etait quelles sont les couches que couvrent nos outils, jusqu'à quel point on doit descendre dans les couches du dessous pour rattraper les inégalités... en essayant de ne pas penser technique au début.
Avec le "Grand Bond en Avant", il me semble qu'on a gagnés une couche d'abstraction, mais qu'on ne l'exploite pas a fond. Ceci dit j'arrive pas bien a mettre le doigt dessus
Oui, avec la difference que les niveaux sont variables.J'ai l'impression que toute l'informatique se résume à ce schéma, et je pense que ça s'explique relativement bien, chaque outil a son modèle de donnée pour les traiter efficacement selon les besoins qu'on veut de cet outil et lorsque l'on veut faire communiquer deux outils entre eux on passe par un modèle de donnée fait pour l'échange.
rien n'est figé, et des couches au modèle se rajoutent régulièrement.
Au début, les cartes de WRI etaient des PNG sur disque, le modèle de donnée commun etait "les pixels en partant du haut a gauche".
Maintenant le modèle de donnée commun est "une coordonnée WGS84". mais en descendant dans les couches, on trouvera toujours des pixels.
Plus tard, ce sera peut-être "le regard de l'utilisateur"
, mais il y aura encore des WGS84, et dessous tout en bas, des pixels.Ceux ci etaient pourtant au sommet des couches il y a 10 ans. Et le jour où on a laissé tomber les pixels pour passer a la couche du dessus, les degrés, on y a gagné.
Il me semble qu'on vient de franchir une étape comme ça.
Evidemment, en interne tous les outils descendent dans les couches et analysent les data. les X et les Y sont forcément qqpart je me doute, quand même....Le format WKB c'est ce que tu obtiens en ne demandant aucune conversion à PG, mais même s'il ne sont pas clairement visible, les X et les Y sont là quand même
Tous les outils GIS font des AsGML/AsWK* a un moment ou a un autre ...
Les datas sont forcement représentés sous forme de float et d'octet.
le AsGML (de la surcouche-scripts PGIS) lui même fait surement appel a des fonctions de conversions blob->decimal (de la couche PostGres) qui elle-mêmes ont des pointeurs C++ sur des dumps? (de la couche libc6 ?)...
C'est trop terre à terre. Chacune fait de l'abstraction pour celle du dessous.
(aucun de ces formats ne gère de style, a part KML. On est en fait passés par 2 standards: GML et SLD. Il y a 2 canaux de toute façon => Firebug. et c'est pas plus mal pour séparer le data et la mise en forme)C'est pourquoi PG autant que OL savent gérer un format d'échange commun qu'il faut sortir de l'un pour faire manger à l'autre, et en plus, on a largement l’embarra du choix : géoJSON, GML, WKT, WKB qu'il nous faut choisir selon les additifs qu'on souhaite placer pour éviter d'avoir plusieurs canaux de communication (d'où GML plutôt que WKB pour faire passer nos icones et nos styles, mais on pourrait sans doute choisir WKB)
PG et OL, C'est la même chose que Apache et Firefox. Pour dialoguer, les 2 se base sur le standard TCP.
On s'occupe pourtant pas de savoir s'ils se sont concertés pour les JumboTrames ou les buffers d'ACKnowledge
On a donné a bouffer nos pages HTML à apache, et FF se demerde pour les recevoir et les afficher.
ça marche bien parce qu’il sont du même niveau dans le modèle OSI.
Que ça se fasse par pigeon voyageur ou par rsync, tant que les 2 se comprennent ...
Il y a quand même une difference. OL sait traiter avec la couche de transport (disons GML) mais pas PG.
Ils sont pas au même niveau...
PG ne sait pas générer une couche de transport(il doit pas être fait pour).
Tout ce qu'il sait faire c'est faire un peu de formatage pour faciliter le travail, mais pas au point de gagner une couche. c'est du dirty-hack.
La fonction PG query_as_xml, accompagnée d'une feuille XSLT pourrait a la limite generer cette couche, mais elle se marrie mal avec PostGis, et ça a l'air crade aussi.
Pour moi, on a donc là une inégalité de niveau dans le modèle.(pô grave, juste pour montrer le truc).
On a tout intêret a bosser toujours au niveau le plus haut, et laisser faire les couches du dessous comme elles l'entendent.
par exemple, on touche à HTML, pas au HTTP->TCP (HTML ne veut rien dire pour un routeur)
on va coder en langage objet, pas a sa représentation interne, forcément séquentielle (un CPU est séquentiel, à un moment, le code est transformé)
on s'occupe de Degrés, pas de pixels (les degrés n'existent pas pour un ordi, les pixels, si)...
La reflexion que j'avais c'etait quelles sont les couches que couvrent nos outils, jusqu'à quel point on doit descendre dans les couches du dessous pour rattraper les inégalités... en essayant de ne pas penser technique au début.
Avec le "Grand Bond en Avant", il me semble qu'on a gagnés une couche d'abstraction, mais qu'on ne l'exploite pas a fond. Ceci dit j'arrive pas bien a mettre le doigt dessus
-
sly
- Messages : 5041
- Enregistré le : 29 févr. 2004, 17:59
- Localisation : Chambéry - Savoie
Je comprend un peu mieux à quoi tu faisais allusion en disant "gagner une couche" j'ai juste l'impression qu'on ira pas bien plus haut à moins de perdre de la flexibilité en l'état actuel des outils qu'on a explorés.yip a écrit : Avec le "Grand Bond en Avant", il me semble qu'on a gagnés une couche d'abstraction, mais qu'on ne l'exploite pas a fond. Ceci dit j'arrive pas bien a mettre le doigt dessus ;)
Mais continuons à être ouverts aux nouveautés ;-)