UMN MapServer est un serveur cartographique prenant en charge un grand nombre de formats de fichier. Il est possible de l'utiliser en mode CGI ou à travers des langages de script tels que PHP, Ruby, Java, C#, etc à l'aide de mapScript. MapServer constitue donc un environnement de développement d'outils plus qu'un outil en lui même prêt à être installé et à être utilisé directement.
Cet article a pour but de présenter les différentes nouveautés et corrections importantes de cette nouvelle version. Cette présentation n'est pas forcément exhaustive et il est préférable de se tourner vers le site officiel de MapServer. Ce document est composé de diverses traductions des RFC et documentation écrite suite à ces changements. Il se peut que certaines parties n'aient pas été développées, la documentation n'ayant pas encore été mise à jour !
Au niveau des nouveautés de cette version majeure, nous trouvons la simplification des templates pour la gestion des rendu des requêtes (MS RFC 36), l'ajout et l'amélioration des Références Spatiales (MS RFC 37), la gestion native de Microsoft SQL Server 2008 (MS RFC 38), la gestion du webservice WCS 1.1.x (MS RFC 41), la gestion de la redirection des cookies (MS RFC 42) et la génération des tuiles directe pour l'API de Google Map (MS RFC 43).
D'autres améliorations sont également présentes :
- amélioration des performances pour la prise en charge des gros shapefile ;
- amélioration des performances pour le rendu d'AGG (d'une manière assez important dans certain cas) ;
- contour des étiquettes floues pour AGG ;
- opacité au niveau des styles pour AGG ;
- gestion de la quantification et des palette pour les modes PNG et RGBA ;
- gestion de SOS 1.0.0 ;
- gestion de WFS 1.1.0 ;
- gestion de l'authentification par proxie et http pour les requêtes WMS en cascade ;
- calcul des points des étiquettes pré-découpées (aide dans la génération de tuile) ;
- prise en charges des attributs des balises des templates étendue (par exemple shpext, mapext).
Date des sorties versions intermédiaires
- Sortie prévue : 17-07-2008
- Versions béta : 14-06-2008, 18-06-2008, 02-07-2008
- Prochaine version : 5.4, 2009
Nouveautés
Simplification des templates pour la gestion des rendu des requêtes
- RFC 36
- Développeur : Steve Lime
Deux constats ont été fait :
- Pour l'instant un pilote comme GML n'est pas disponible au CGI pour représenter des résultats de requête ;
- Le schéma de template (HEADER/TEMPLATE/FOOTER) pour les requêtes n'est pas "user friendly" ni ne permet la génération multiple de formats. Nous avons une couche => une définition de template.
Les solutions sont les suivantes :
1. Utiliser un objets de format de sortie pour définir les formats qui peuvent être utilisé pour les retours des résultats des requêtes en plus du dessin des images. Par exemple :
<code mapserver>
OUTPUTFORMAT
NAME 'gml3'
DRIVER GML3
MIMETYPE 'text/xml; subtype=gml/3.2.1'
END
</code>
2. Utiliser la propriété //QUERYFORMAT// de l'objet WEB pour référencer les formats : 'QUERYFORMAT gml3'. Cette propriété apporte un type-mime mais il peut être utilisé pour également référencer un format.
3. Permet également des modes applicable (par exemple §WFS, WMS, SOS) pour utiliser les formats de type DRIVER/TEMPLATE (c'est à dire avertir dans les réponses GetCapabilities, géré à travers l'API [e.g. request=GetFeature&outputFormat=text/xml; subtype=gml/3.2.1]), mappé à partir de OUTPUTFORMAT/MIMETYPE. Pour l'instant le pilote WCS nécessite que le développeur définisse explicitement les formats de sortie gérés, les autres services peuvent faire la même chose et peuvent référencer les sorties en template.
3. Permet également des modes applicable (par exemple §WFS, WMS, SOS) pour utiliser les formats de type DRIVER/TEMPLATE (c'est à dire avertir dans les réponses GetCapabilities, géré à travers l'API [e.g. request=GetFeature&outputFormat=text/xml; subtype=gml/3.2.1]), mappé à partir de OUTPUTFORMAT/MIMETYPE. Pour l'instant le pilote WCS nécessite que le développeur définisse explicitement les formats de sortie gérés, les autres services peuvent faire la même chose et peuvent référencer les sorties en template.
4. Définir un paramètre //DRIVER// dans l'objet //TEMPLATE//. Cela invoquera le schéma de template de requête normal. Par exemple :
<code mapserver>
OUTPUTFORMAT
NAME 'kml'
DRIVER TEMPLATE
MIMETYPE 'application/vnd.google-earth.kml+xml'
TEMPLATE 'myTemplate.kml'
END
OUTPUTFORMAT
NAME 'geojson'
DRIVER TEMPLATE
MIMETYPE 'application/json; subtype=geojson'
TEMPLATE 'myTemplate.js'
END
</code>
5. Notez que dans les exemples ci-dessus nous référençons un fichier, L'auteur propose de gérer un seul système de template pour les requêtes en plus du mécanisme en court. Il propose ainsi 4 nouvelles balises : [resultset], [feature], [join] (pour des jointures one-to-many), et [include] (pour gérer le partage de code entre les templates). Tous seront des bloques. Un exemple serait :
<code javascript>
[include src="templates/header.html"]
[resultset name=lakes]
... contenu des anciennes couches HEADER, si une couche n'a pas de résultat ce bloc disparaitra ...
[feature]
... répéter ce bloc pour chaque objet dans le pool de résultat ...
[join name=join1]
...répéter ce bloc pour chaque ligne de jointure ...
[/join]
[/feature]
... contenu des anciennes couches FOOTER vient ici ...
[/resultset]
[resulset name=streams]
... contenu des anciennes couches HEADER, si une couche n'a pas de résultat ce bloc disparaitra ...
[feature]
...répéter ce bloc pour chaque objet dans le pool de résultat ...
[/feature]
... contenu des anciennes couches FOOTER vient ici ...
[/resultset]
[include src="templates/footer.html"]
</code>
Un exemple spécifique à GML 3 donnerait :
<code xml>
<?xml version="1.0" encoding="ISO-8859-1"?>
[resultset layer=mums]
<MapServerUserMeetings xmlns="http://localhost/ms_ogc_workshop" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:gml="http://www.opengis.net/gml" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://localhost/ms_ogc_workshop ./mums.xsd">
<gml:description>This is a GML document which provides locations of all MapServer User Meeting that have taken place</gml:description>
<gml:name>MapServer User Meetings</gml:name>
<gml:boundedBy>
<gml:Envelope>
<gml:coordinates>-93.093055556,44.944444444 -75.7,45.4166667</gml:coordinates>
</gml:Envelope>
</gml:boundedBy>
[feature]
<gml:featureMember>
<Meeting>
<gml:description>[desc]</gml:description>
<gml:name>[name]</gml:name>
<gml:location>
<gml:Point srsName="http://www.opengis.net/gml/srs/epsg.xml#4326">
<gml:pos>[x] [y]</gml:pos>
</gml:Point>
</gml:location>
<year>[year]</year>
<venue>[venue]</venue>
<website>[url]</website>
</Meeting>
</gml:featureMember>
[/feature]
<dateCreated>2007-08-13T17:17:32Z</dateCreated>
</MapServerUserMeetings>
[resultset]
</code>
Un exemple GeoJSON donnerait :
<code javascript>
[resultset layer=foo] {
"type": "FeatureCollection",
"features": [
[feature trim=',']
{
"type": "Feature",
"id": "[id]",
"geometry": {
"type": "PointLineString",
"coordinates": [
{
"type": "Point",
"coordinates":
}
]
},
"properties": {
"description": "[description]",
"venue": "[venue]",
"year": "[year]"
}
},
[/feature]
]
}
[/resultset]
</code>
Cela permettra des fichiers textes relativement complexe de n'importe quel sorte d'être compilé pour de multiple couche. Toutes les balises de templtes normales seront encore gérées mais celle normalement valable pour les résultats de requête seront seulement valide dans une balise //[feature]...[/feature]//. Ces balises fonctionneront avec le système existant mais ne seront pas aussi utile qu'avec la première idée de template.
<note>
Il est souvent problématique d'avoir des caractères finaux de séparation d'enregistrement après l'enregistrement final. Par exemple, dans le template JSON ci-dessus la virgule finale dans le bloc //[feature]// cause des problèmes avec Internet Explorer. Un attribut "trim" permettra de demander au processeur de template de supprimer cette chaîne à la fin de la sortie pour le dernier objet calculé.
</note>
<note>
Une balise //resultset// peut être appliquée à de nombreuses couches l'attribut //name// prendra une liste de couches séparées par des virgules. L'ordre de la liste est l'ordre dans lequel ils seront représentés. Il est possible que des groupes soient utilisés mais il semble que cela soit un cas d'utilisation assez rare.
</note>
<note>
Une balise //resultset// prendra également un attribut //maxresults// afin que le nombre d'objets récupérés puisse être limité.
</note>
Ajout et l'amélioration des Références Spatiales
- RFC 37
- Développeur : Howard Butler
1 Objectif
Fournir à Mapserver la possibilité de définir ses informations de PROJECTION à partir de sources diverses, incluant directement la source de données elle-même, une tentative de diminuer le fardeau de la gestion des informations des systèmes de coordonnées sur les utilisateurs.
Ces améliorations sont disponible en option et n'interfèrent pas avec les méthodes des définitions précédente de PROJECTION.
Ces améliorations sont disponible en option et n'interfèrent pas avec les méthodes des définitions précédente de PROJECTION.
2 Historique des Références Spatiales dans MapServer
La gestion des références spatiales de MapServer manque assez de vitalité du fait du nombre de standards. Bien que la plupart des sources de données de MapServer interagissent avec la gestion décrivant la référence spatiale des couches contenues, MapServer a historiquement supprimé l'information dans le flux ou l'a complètement ignoré.
Le dispositif de reprojection de MapServer ignore le fait que l'objet PROJECTION des objets LAYER est différent de celle de l'objet MAP. Lorsque c'est le cas, MapServer reprojète les données de l'objet LAYER vers la projection définie dans l'objet MAP pendant la création de la carte. Les services OGC interagissent aussi ici, et lorsqu'une référence spatiale est définie comme "disponible" en utilisant le mécanisme des METADATA, un client peut demander des cartes dans une référence spatiale différente que celle définie par défaut, ce qui démarre le dispositif de reprojection.
Le dispositif de reprojection de MapServer ignore le fait que l'objet PROJECTION des objets LAYER est différent de celle de l'objet MAP. Lorsque c'est le cas, MapServer reprojète les données de l'objet LAYER vers la projection définie dans l'objet MAP pendant la création de la carte. Les services OGC interagissent aussi ici, et lorsqu'une référence spatiale est définie comme "disponible" en utilisant le mécanisme des METADATA, un client peut demander des cartes dans une référence spatiale différente que celle définie par défaut, ce qui démarre le dispositif de reprojection.
2.1 Définition
MapServer a historiquement utilisé deux approches différentes pour définir les références spatiales de ses données -- les codes EPSG/ESRI de la forme :
<code mapserver>
PROJECTION
"init=epsg:4326"
END
</code>
et les définitions formatées en proj-4 de la forme :
<code mapserver>
PROJECTION
"proj=cea"
"lon_0=0"
"lat_ts=45"
"x_0=0"
"y_0=0"
"ellps=WGS84"
"units=m"
"no_defs"
END
</code>
Une troisième option plutôt inconnus est disponible exclusivement pour les webservices WMS -- la définition //EPSG AUTO//, où MapServer tente de déterminer la référence spatiale à partir des données elles-mêmes. Cette méthode ne fonctionne pour l'instant seulement pour les sources de données GDAL et OGR, et est seulement disponible quand GDAL/OGR est lié dans MapServer.
2.2 Observations des performances
L'histoire des références spatiales actuelle de MapServer est concentrée sur deux choses -- une description simple et s'assurant que la reprojection non nécessaire des données n'ait pas lieu. MapServer actuellement utilise proj4 directement pour réaliser sa reprojection de données, et cela implique la définition des systèmes de coordonnées au format proj4. Pour les personnes désirant de meilleur performance mais ayant besoin de reprojeter leur données, définir ses références spatiales au format proj4 est un must.
Alternativement, la définition des codes EPSG/ESRI des références spatiales de MapServer permet à celui-ci de se décharger de la description proj4 sur proj4 lui-même, avec une simple recherche de fichier des tables. Cependant, ce mécanisme est actuellement un goulot d'étranglement, puisque chaque recherche nécessite un passage sur un fichier pour rechercher les correspondances de l'identifiant données et de retourner la définition proj4.
Alternativement, la définition des codes EPSG/ESRI des références spatiales de MapServer permet à celui-ci de se décharger de la description proj4 sur proj4 lui-même, avec une simple recherche de fichier des tables. Cependant, ce mécanisme est actuellement un goulot d'étranglement, puisque chaque recherche nécessite un passage sur un fichier pour rechercher les correspondances de l'identifiant données et de retourner la définition proj4.
2.3 Usage
L'usage de ces deux mécanismes peut être un cauchemar pour les utilisateurs. D'abord, la plupart des descriptions des références spatiales que les personnes utilisent sont de type WKT -- pas proj4. Bien qu'il soit simple de définir une information PROJECTION pour les données avec une valeur connue d'un code EPSG, les projections personnalisées ou celles qui ne sont généralement pas disponible dans la base de données EPSG nécessitent que l'utilisateur traduise d'une manière ou d'une autre leur WKT au format proj4 et le copie dans leur mapfile.
De plus, un site Internet((http://spatialreference.org)) a été développé pour faciliter ce travail mais est clairement une solution de dépannage et non une solution permanente au problème. Il n'est pas pratique de développer les références spatiales pour chaque couche dans un mapfile pour chaque carte dessinée à partir d'un site Internet. spatialreference.org fournit des outils de conversions pour permettre aux utilisateurs de copier leur WKT et de recevoir un bloc PROJECTION de MapServer, mais cette approche rejette encore le travail sur les utilisateurs.
De plus, un site Internet((http://spatialreference.org)) a été développé pour faciliter ce travail mais est clairement une solution de dépannage et non une solution permanente au problème. Il n'est pas pratique de développer les références spatiales pour chaque couche dans un mapfile pour chaque carte dessinée à partir d'un site Internet. spatialreference.org fournit des outils de conversions pour permettre aux utilisateurs de copier leur WKT et de recevoir un bloc PROJECTION de MapServer, mais cette approche rejette encore le travail sur les utilisateurs.
3 Définition de la fonctionnalité
Deux mots-clé ont été ajoutés au bloc PROJECTION pour déclencher ce nouveau comportement. Sans ces mots-clé, MapServer continuera encore à se comporter comme avant, estimant que la projection en entrée est soit un code EPSG soit une définition proj4.
<code mapserver>
PROJECTION
TYPE TYPEENUM
VALUE "Une définition"
END
</code>
Les énumérations de TYPE suivantes seraient gérées :
- NATIVE
- PROJ4
- EPSG
- FILE
- OGCWKT
- ESRIWKT
VALUE est alors définie comme une définition de référence spatiale sous la forme définie par l'énumération. Voyez ci-dessous pour quelques exemples :
<code mapserver>
# Utilise la projection de la définition de couche comme définition de projection
# Cela peut ne pas être disponible pour toutes les sources de données ou types de couche
# (shapefile, SDE, OGR, etc.).
PROJECTION
TYPE NATIVE
END
</code>
<code mapserver>
# Utilise une définition de proj4 (c'est essentiellement le même que d'habitude sauf
# qu'il est définie d'une autre manière)
PROJECTION
TYPE PROJ4
VALUE "+proj=longlat +ellps=WGS84 +datum=WGS84 +no_defs"
END
</code>
<code mapserver>
# Utilisez un code EPSG
PROJECTION
TYPE EPSG
VALUE "4326"
END
</code>
<code mapserver>
# lit la définition à partir d'un fichier
PROJECTION
TYPE FILE
VALUE "../myfile.prj"
END
</code>
<code mapserver>
# Utilise une définition WKT de l'OGC (des échappements peuvent être nécessaire)
PROJECTION
TYPE OGCWKT
VALUE 'GEOGCS["WGS 84",
DATUM["WGS_1984",
SPHEROID["WGS 84",6378137,298.257223563,
AUTHORITY["EPSG","7030"]],
AUTHORITY["EPSG","6326"]],
PRIMEM["Greenwich",0,
AUTHORITY["EPSG","8901"]],
UNIT["degree",0.01745329251994328,
AUTHORITY["EPSG","9122"]],
AUTHORITY["EPSG","4326"]]'
END
</code>
<code mapserver>
# Utilise une définition WKT d'ESRI (des échappements peuvent être nécessaire)
PROJECTION
TYPE ESRIWKT
VALUE 'GEOGCS["GCS_WGS_1984",
DATUM["D_WGS_1984",
SPHEROID["WGS_1984",6378137,298.257223563]],
PRIMEM["Greenwich",0],
UNIT["Degree",0.017453292519943295]]'
END
</code>
Gestion native de Microsoft SQL Server 2008
- RFC 38
- Développeur : Howard Butler
1 Objectif
Fournir un pilote natif et en lecture seul pour MapServer qui se connecte à un serveur Microsoft SQL Server 2008 (dorénavant appelé SQL server) sous Windows comme un pilote de source de données par PLUGIN.
2 Contexte
I.S. Consulting a fait donation d'un pilote natif modelé sur celui de PostGIS pour gérer les possibilités spatiales des serveurs SQL server 2008. Ce nouveau pilote sera seulement disponible pour les plateformes Windows, et seulement sous forme de pilote de source de données par PLUGIN. Aucune dépendance ne sera ajoutée au code de MapServer pour gérer ce pilote.
3 Détails d'utilisation
Le pilote est une couche PLUGIN, et utilise la syntaxe PLUGIN décrit dans la RFC 8 pour définir les informations de la couche :
<code mapserver>
LAYER
NAME "Routes"
CONNECTIONTYPE PLUGIN
PLUGIN "C:ms4wpluginsmsplugin_mssql2008.dll"
CONNECTION "server=mysqlserver2008.com;uid=dbusername;pwd=dbpassword;database=Roads Database;Integrated Security=false"
DATA "the_geom from roads"
TYPE LINE
STATUS ON
PROJECTION
"init=epsg:4326"
END
CLASS
STYLE
COLOR 0 0 255
WIDTH 8
END
END
END
</code>
Gestion du webservice WCS 1.1.x
- RFC 41
- Développeur : Frank Warmerdam
Aperçu
Il a été proposé d'étendre MapServer pour gérer le protocole WCS 1.1. MapServer gère déjà le protocole WCS 1.0, mais ceux-ci sont significativement différent.
Limitations du protocole WCS 1.1
- Seulement un <Field> peut être associé avec le domaine de couverture lorsqu'il est servit par MapServer.
- Seulement deux types d'Axe seront gérés, un axe "Bands" et un axe "Time".
Usage
WCS 1.1.0 et les versions plus récentes du protocole WCS sont gérés par MapServer 5.2. Pour la majeure partie, la définition du fichier map pour le WCS 1.1.0 est identique à celle du WCS 1.0.0, mais le protocole réel a été substantiellement changé.
4.1 GetCapabilities
La requête ''GetCapabilities'' est identique à celle du WCS 1.0 mais avec une valeur différente pour le paramètre //VERSION// :
SERVICE=WCS&VERSION=1.0.0&REQUEST=GetCapabilities
Le format du document //capabilities// retourné est significativement modifié par rapport à celui du WCS 1.0, et se sert du format OWS 1.0 pour les descriptions du service.
4.2 DescribeCoverage
La requête ''DescribeCoverage'' est identique à celle du WCS 1.0 mais le mot-clé //IDENTIFIER// est utilisé à la place de //COVERAGE// pour nommer la couverture demandée :
SERVICE=WCS&VERSION=1.1.0&REQUEST=DescribeCoverage&IDENTIFIER=spaceimaging
4.3 GetCoverage
Le format pour ''GetCoverage'' a été significativement modifié depuis la version 1.0. Ce qui suit est une liste des paramètres requis de ''GetCoverage'' :
- //VERSION=version// : version demandée ;
- //REQUEST=GetCoverage// : nom demandé ;
- //IDENTIFIER=coverage_name// : nom d'une couverture disponible, comme affiché dans la réponse du ''GetCapabilities'' ;
- //BOUNDINGBOX=minx,miny,maxx,maxy,crs// : coins de la //bounding box// ('le plus bas' 'à gauche', 'le plus haut' 'à droite'), et le //CRS// dans lequel ils sont. Le //CRS// est décrit en utilisant un //URN//, voir plus bas pour plus d'information.
- //FORMAT=output_format// : format de sortie (type mime) d'une produit de grille, comme définie dans la réponse du ''GetCapabilities''.
Si une résolution spatiale alternative est désirée, alors l'ensemble des mot-clé suivant doit être utilisé pour définir l'origine de l'échantillon et la taille des écarts de la grille en sortie à produire. La grille produite sera d'un nombre de pixel et de lignes que peut contenir la //BOUNDINGBOX// démarrant à //GridOrigin//, à la résolution //GridOffsets//.
- //GRIDBASECRS=crs// : la grille de base du //CRS// (//URN//).
- //GRIDCS=crs// : la grille du //CRS// (//URN//).
- //GridType=urn:ogc:def:method:WCS:1.1:2dGridIn2dCrs// : c'est la seule valeur gérée par MapServer.
- //GridOrigin=x_origin,y_origin// : le point d'échantillon pour le pixel en haut à gauche.
- //GridOffsets=xstep,ystep// : La taille des écarts x et y pour l'échantillonnage des grilles (résolution). Les deux sont positifs.
De même, les paramètres optionnels suivant sont disponibles.
//RangeSubset=selection: //Sélectionne un sous ensemble de domaine, et une méthode d'interpolation. Actuellement seulement un sous-ensemble sur les bandes sont permis. En fonction des noms de l'ensemble des domaines, cela peut prendre la forme de //"BandsName[bands[1]]"// pour sélectionner la bande 1, ou //"BandsName:bilinear[bands[1]]"// pour sélectionner la bande 1 avec une interpolation bilinéaire.
Une simple requête ''GetCoverage'' pourrait donc ressembler à ceci :
//RangeSubset=selection: //Sélectionne un sous ensemble de domaine, et une méthode d'interpolation. Actuellement seulement un sous-ensemble sur les bandes sont permis. En fonction des noms de l'ensemble des domaines, cela peut prendre la forme de //"BandsName[bands[1]]"// pour sélectionner la bande 1, ou //"BandsName:bilinear[bands[1]]"// pour sélectionner la bande 1 avec une interpolation bilinéaire.
Une simple requête ''GetCoverage'' pourrait donc ressembler à ceci :
SERVICE=WCS&VERSION=1.1.0&REQUEST=GetCoverage&IDENTIFIER=dem&FORMAT=image/tiff
&BOUNDINGBOX=43,33,44,34,urn:ogc:def:crs:EPSG::4326
Une plus complexe à cela :
SERVICE=WCS&VERSION=1.1.0&REQUEST=GetCoverage&IDENTIFIER=dem&FORMAT=image/tiff
&BOUNDINGBOX=33,43,34,44,urn:ogc:def:crs:EPSG::4326
&GridBaseCRS=urn:ogc:def:crs:EPSG::4326&GridCS=urn:ogc:def:crs:EPSG::4326
&GridType=urn:ogc:def:method:WCS:1.1:2dGridIn2dCrs
&GridOrigin=33,44&GridOffsets=0.01,0.01
&RangeSubset=BandsName:bilinear[bands[1]]
Il doit être noté également que les résultats renvoyés à partir d'une requête ''GetCoverage'' d'un WCS 1.1 sont au format mime multi-part. Typiquement cela consiste d'une première partie avec un document XML référençant l'autre partie du message, et un fichier image pour la deuxième partie. Cependant, pour les formats de sortie qui renvoie des fichiers multiples chacun d'eux sera séparé. Par exemple, cela signifie qu'il est possible de renvoyer un fichier jpeg avec un fichier world, avec un //OUTPUTFORMAT// correctement configuré.
4.4 URN
Dans le protocole WCS 1.1, les systèmes de coordonnées sont référencés par un URN. Quelques URN typiques :
urn:ogc:def:crs:EPSG::4326
urn:ogc:def:crs:EPSG:27700
urn:ogc:def:crs:OGC::CRS84
Les deux premiers sont plus ou moins équivalent à //EPSG:432// et //EPSG:27700// alors que le troisième est un CRS définie par l'OGC (essentiellement du WGS84). Une critique à noter est que le WCS 1.1 suit l'ordre des tuples/axes définie par l'EPSG pour les systèmes de coordonnées géographiques. Cela signifie que les coordonnées rapportées, ou fournit dans //urn:ogc:def:EPSG::4326// (WGS84) sont actuellement pris en charge comme des lat, long pas comme des long,lat. Par exemple la //BOUNDINGBOX// pour une zone en Californie devrait donc ressembler à cela :
BOUNDINGBOX=34,-117,35,-116,urn:ogc:def:crs:EPSG::4326
Et, contrairement aux limites rapportés par la requête ''GetCapabilities'', ''DescribeCoverage'' sera dans cet ordre, comme approprié.
Gestion de la redirection des cookies
- RFC 42
- Développeur : Julien-Samuel Lacroix
Contexte
Cette fonctionnalité permet d'étendre MapServer pour faire suivre les cookies HTTP lors d'une requête OWS.
Une méthode d'authentification dans un environnement de serveur distribué est d'utiliser des cookies HTTP. Les cookies HTTP sont utilisés par les serveurs web pour différencier les utilisateurs et pour maintenir les données liées à l'utilisateur pendant sa navigation, éventuellement à travers plusieurs visites et pour des statistiques. Techniquement, les cookies sont des morceaux arbitraires de données choisies par le serveur web et envoyés au navigateur. Le navigateur les renvois non changés au serveur. L'amélioration de MapServer permet à l'application de renvoyer n'importe quel cookie HTTP ( d'une requête //http// ou //https// pour les méthodes //get// ou //post//) reçu d'un client à n'importe quel serveur ou service auquel MapServer pourrait récupérer des informations.
Cela nécessite que MapServer puisse recevoir et renvoyer des cookies au nouveau service pendant la requête pour les opérations (cascades) tels que (mais non limité à) les requêtes WMS : GetMap, GetFeatureInfo et les requêtes WFS pour GetFeature.
Une méthode d'authentification dans un environnement de serveur distribué est d'utiliser des cookies HTTP. Les cookies HTTP sont utilisés par les serveurs web pour différencier les utilisateurs et pour maintenir les données liées à l'utilisateur pendant sa navigation, éventuellement à travers plusieurs visites et pour des statistiques. Techniquement, les cookies sont des morceaux arbitraires de données choisies par le serveur web et envoyés au navigateur. Le navigateur les renvois non changés au serveur. L'amélioration de MapServer permet à l'application de renvoyer n'importe quel cookie HTTP ( d'une requête //http// ou //https// pour les méthodes //get// ou //post//) reçu d'un client à n'importe quel serveur ou service auquel MapServer pourrait récupérer des informations.
Cela nécessite que MapServer puisse recevoir et renvoyer des cookies au nouveau service pendant la requête pour les opérations (cascades) tels que (mais non limité à) les requêtes WMS : GetMap, GetFeatureInfo et les requêtes WFS pour GetFeature.
Méthodologie d'implémentation
Un nouveau paramètre sera ajouté à l'objet //metadata// (//http_cookie_data//) au niveau du mapfile pour stocker temporairement les données du cookie HTTP. Un autre paramètre (//ows_http_cookie//) sera également ajouté au niveau du mapfile et de la couche pour contrôler l'utilisation du cookie. Ce dernier sera définie soit à //forward//, pour faire suivre le cookie stocké dans la méta-données //http_cookie_data//, ou dans une valeur du cookie codé en dure, pour faire suivre cette valeur codée en dure seulement.
Exemple de //ows_http_cookie// dans METADATA :
<code mapserver>
LAYER
...
METADATA
"ows_http_cookie" "forward" # cela fera suivre le cookie envoyé à MapServer
END
...
</code>
L'utilisateur peut aussi passer directement les valeurs du cookie à la place du cookie passé à MapServer. Pour passer de multiple cookie, utiliser la syntaxe suivante :
<code mapserver>
LAYER
...
METADATA
"ows_http_cookie" "cookie1=my_value; cookie2=myvalue; " # cela fera suivre la valeur de la méta-donnée
END
...
</code>
En utilisant la configuration de METADATA, une application MapScript sera capable de faire suivre le cookie HTTP en définissant la méta-donnée correcte.
Actuellement seul le code WMS et WFS utilisera ceci puisque ils sont les seuls endroits où MapServer réalise une requête à un serveur web externe.
Problèmes d'implémentation
Il a été indiqué pendant la phase de relecture de la RFC qu'envoyer et stocker les données du cookie en utilisant une méta-donnée //http_cookie_data// est une mauvaise utilisation du mécanisme de méta-données de MapServer.
Puisque MapServer actuellement n'a pas de mécanisme pour associer des informations d'un état d'une application dans un objet map, il n'y a actuellement aucun meilleur mécanisme en place pour stocker les données du cookie reçues du client et envoyées au code de rendu qui appel le WMS distant. Dû à l'absence d'une meilleur solution, pour le moment il faut utiliser la méta-données //http_cookie_data// en sachant que ce n'est pas la meilleur solution et que dès qu'il y en aura une meilleur pour stocker et envoyer l'état de l'application dans un objet map alors cette méda-donnée sera obsolète et remplacée par un nouveau mécanisme. Les développeurs d'application MapScript définissant cette méta-donnée //http_cookie_data// doivent être conscient de cela et être préparé à faire évoluer leur application lors d'une future révision de MapServer.
Un autre problème est qu'aucun encodage n'est actuellement réalisé avec la méta-donnée //http_cookie_data//. Les méta-données mal formatés peuvent casser l'en-tête HTTP d'une requête. Curl n'encode pas la valeur du cookie, seul les caractères avec une valeur entre 32 et 126 (caractère ASCII imprimable) sont autorisés.
MapScript
En stockant les données du cookie HTTP dans les méta-données du mapfile MapScript sera capable d'utiliser cette nouvelle fonctionnalité. Voici un exemple d'une utilisation de cookie HTTP par PHP/MapScript :
<code php>
foreach($_COOKIE as $szKey => $szValue)
{
$szHTTPCookies .= "$szKey=$szValue; ";
}
$oMap->setMetadata("http_cookie_data", $szHTTPCookies);
$oMap->setMetadata("ows_http_cookie", "forward");
$oMap->draw();
</code>
Génération des tuiles directe pour l'API de Google Map
- RFC 43
- Développeur : Paul Ramsey
Aperçu
Fournir un accès simple à l'API dans le CGI de mapserver pour permettre l'utilisation de mapServer avec Google Maps et Virtual Earth et faciliter l'interfaçage pour les nouveaux utilisateurs.
Solution technique
L'API de GMaps définie un GTileLayer qui peut être utilisé comme une carte de base ou de superposition. GTileLayer gère un GTileLayerOption, tileUrlTemplate, qui permettent au TileLayer d'accèder à une URL en utilisant un simple motif d'URL qui substitue des coordonnées x/y/z de Google dans une requête :
http://host/tile?x={X}&y={Y}&z={Z}.png
Voyez
http://code.google.com/apis/maps/documentation/reference.html#GTileLayer
Pour MapServer, le motif simple de l'URL sera :
http://host/cgi-bin/mapserv?map=/the.map&layers=foo,bar&mode=tile&tilemode=gmap&tile={X}+{Y}+{Z}
Comme pour l'interface WMS, l'API GMap nécessite que PROJ soit définie, et l'existence d'un paramètre PROJECTION définie pour toutes les couches disponible. Les coordonnées X/Y/Z de Google seront converties en coordonnées //spherical mercator// et introduit dans l'extent.
Le résultat permettra de réaliser une carte Google avec Mapserver aussi facilement que :
Le résultat permettra de réaliser une carte Google avec Mapserver aussi facilement que :
<code javascript>
var url = "http://host/cgi-bin/mapserv?";
url += "map=/the.map&";
url += "layers=parcels&";
url += "mode=tile&";
url += "tilemode=gmap&";
url += "tile={X}+{Y}+{Z}";
var myLayer = new GTileLayer(null,null,null,
{
tileUrlTemplate:url,
isPng:true,
opacity:0.5
}
);
var map = new GMap2(document.getElementById("map"));
map.addOverlay(new GTileLayerOverlay(myLayer));
</code>
Une carte Virtual Earth avec MapServer ressemblera à :
<code javascript>
var url = "http://host/cgi-bin/mapserv?";
url += "map=/the.map&";
url += "layers=parcels&";
url += "mode=tile&";
url += "tilemode=ve&";
url += "tile=%4";
map = new VEMap("map");
map.LoadMap();
var tileSourceSpec = new VETileSourceSpecification( "myLayer", url );
tileSourceSpec.Opacity = 0.3;
map.AddTileLayer(tileSourceSpec, true);
</code>
Une requête avec ''tilemode '' à //gmap// implique les paramètres suivants :
- Le paramètre //tile// sera de la forme : x y zoom.
- Le CRS en sortie sera définie à "spherical mercator" (EPSG:900913).
- Les limites du service sera d'étendue global. Le niveau de "zoom" maximal (0) aura une seule tuile.
- Les niveaux de "zoom" partiront de 0.
- L'axe des "y" des coordonnées des tuiles débuteront du haut vers le bas.
- L'axe des "x" des coordonnées des tuiles débuteront de la gauche vers la droite.
- Les tuiles en sortie auront une taille de 256x256.
- Chaque niveau de zoom sera lié à leur parent et enfant par une puissance de deux.
Une requête avec ''tilemode'' à //ve// implique les paramètres suivants :
- Le paramèter //tile// utilisera le schéma de numérotation des tuiles de VE, par exemple "//0312//". Lisez la page http://msdn.microsoft.com/en-us/library/bb545006.aspx pour plus de détails.
- Le CRS en sortie sera définie à "spherical mercator" (EPSG:900913).
- Les limites du service sera d'étendue global. Le niveau maximal aura 4 tuiles ((0, 1, 2, 3).
- Les tuiles en sortie auront une taille de 256x256.
- Chaque niveau de zoom sera lié à leur parent et enfant par une puissance de deux.
L'API du mode tile de MapServer ne tentera pas explicitement de s'intéresser aux problèmes des étiquettes en méta-tuilage ou en cross-tuilage. Cependant, les étapes suivantes seront prises en compte pour tenter de minimiser ces problèmes :
- les phases futures auront un rendu légèrement plus grande que la tuile et donc couperont les pixels des bords en trop.
Site officiel :
MapServer 
Autres Liens :
Les tests sur le blog de Guillaume Sueur (Mapserver, toujours plus vite ...) 
