Discussion :

[mga_geo]

Entre les deux url "http://gpp3-wxs.ign.fr/${CLEF}/geoportail/v/wms?request=GetCapabilities&service=WMS" et "http://gpp3-wxs.ign.fr/${CLEF}/geoportail/r/wms?request=GetCapabilities&service=WMS", le format de la réponse diffère:
- une ligne (raster)
- plusieurs lignes avec formatage lisible (vecteur)
Est-il possible de s'aligner sur le format raster ?

[dgrichard]

Le service WMS vecteur est assuré par Geoserver, qui -- c'est à vérifier-- ne sait pas rendre les capacités de service sur une seule ligne ...
Le service WMS rasteur est assuré par un développement IGN, qui rend les capacités de service en format compacte pour alléger le réseau

As-tu ouvert un ticket Jira sur ce sujet pour qu'on jette un oeil ...

[mga_geo]

Depuis de nombreuses années, la charge des réseaux ne provient plus des flux "texte" et même du côté client, une tuile a plus d'impact que quelques espaces et autres ...

[dgrichard]

Depuis de nombreuses années, la charge des réseaux ne provient plus des flux "texte" et même du côté client, une tuile a plus d'impact que quelques espaces et autres ...

Pas vraiment :

un service tuilé est configuré pour répondre à des dizaine de milliers de requêtes et l'image finale peut être (ou doit) compressée pour, à l'oeil nu, être plus légère sans dégradation importante.

Une capacité de service de plusieurs milliers de lignes (disons 10000) invoquée systématiquement par les SIG lors du chargement du dictionnaire génère un traffic important que l'on doit compresser en retirant les saut de ligne (10ko en moins si \n ou \r, 20ko si \r\n, les espaces --plusieurs dizaines de ko si l'indentation est importante--). Bref, la compression des capacités fait partie de la charge réseau finale ... charge que l'on paie, autant y mettre de l'information utile

Dans la même veine : si on diffusait l'API en non compressée (2Mo pour l'étendue avec un flux équivalent à 50% du portail) on exploserait la bande passante. Heureusement, on compresse l'API (500ko) ...

Les fichiers texte permettent ou supportent bon nombre de concepts basés sur l'interopérabilité (SOAP par exemple) : leur poids (équivalent à un âne mort) de ces fichiers textes encombre et ralentit les traitements (analyse des fichiers par les machines, transferts plus long, etc ...).

Côté client, un fichier texte de plusieurs centaines de kilo finit par peser très lourd, même si les tuiles pèsent plus lourd, leur prise en compte par les clients est "innée" contrairement aux fichiers textes à analyser, mettre en page, etc ... L'avènement du Web 2.0 était basé sur ce paradigme : n'envoyer et mettre à jour que la partie de l'information utile, pas toute la page web ... qui est du texte

Bref, d'accord avec toi que l'emprise média du réseau est très forte, ce n'est pas une raison pour ne pas gagner quelques secondes de transfert et traitement sur des quantités infimes