[mapserver-dev] [Fwd: [Mapserver-inspire] SoC Project Midterm]

[Stephan Meißl]

Hi Steve,

thanks for the feedback!

I'm not sure if Stefan's response made it to the mailing list (see
below).

cu
Stephan


On Thu, 2011-08-18 at 17:58 +0200, Stefan Leopold wrote: 
> hello
> 
> thx for your feedback
> put comments inline
> 
> >In section 3 is "wms_inspire_languagesubstitution" really necessary
> or
> >could that be inferred by the presence of "wms_inspire_languages". (I
> >like the approach of language specific extensions.)
> 
> good point, not sure but don't think that the additional language
> parameter in the onlineresource is problematic
> e.g. <OnlineResource
> xlink:href="http://path/to/onlineresource...?language=ger&version=1.3.0&service=WMS&request=GetLegendGraphic&sld_version=1.1.0&layer=TN.RailTransportNetwork.RailwayLink&format=image/png&STYLE=inspire_common:DEFAULT" xmlns:xlink="http://www.w3.org/1999/xlink" xlink:type="simple"/>
> 
> so it avoids an additional configuration step if we always infer it ->
> will change that
> 
> >In section 3, using run-time subs implies modification of mapfile.c
> or
> >would this be done elsewhere? Would wms_inspire_languages serve as a
> >validation (e.g. supplied value would have to be in that list, no
> >regex)?
> 
> here we are just using already existing mapserver features and didn't
> implement anything new
> -> currently it is necessary to use language substitution  the
> following way (for each layer!)
> 
> LAYER
> NAME TN.AirTransportNetwork.AirLink
> DATA "road_%language%"
> METADATA
>  "language_validation_pattern" "eng|ger"
>   ...
> 
> will change that so that the validation_pattern is automatically
> derived from "wms_inspire_languages" "eng,ger" 
> 
> btw: with an invalid value (eg ...&language=abc) provided, do you
> think it is worth to implement a fallback mechanism with the default
> language, using road_eng instead of road_%language% (=no runtime
> substitution applied)?
>  
> >In section 6, specifically which API functions would take a language
> parameter?
> 
> will update the rfc with all modified/new api functions and also
> repost it here
> 
> br
> stefan
> 
> 
> > From: Steve Lime <sdlime at gmail.com>
> > To: Stephan Meißl <stephan at meissl.name>
> > Cc: mapserver-dev <mapserver-dev at lists.osgeo.org>
> > Subject: Re: [mapserver-dev] [Fwd: [Mapserver-inspire] SoC Project
> > Midterm]
> > Date: Mon, 15 Aug 2011 23:29:08 -0500
> > 
> > Hi guys: Thanks for the well written RFC. The implementation looks
> > pretty straight forward- a tedious implementation I bet. Tedious
> > configuration too although I don't have any ideas to shorten
> > configuration beyond adding service specific blocks to mapfile
> parsing
> > to shorten metadata keys.
> > 
> > Anyway, only a couple of basic comments from me:
> > 
> > In section 3 is "wms_inspire_languagesubstitution" really necessary
> or
> > could that be inferred by the presence of "wms_inspire_languages".
> (I
> > like the approach of language specific extensions.)
> > 
> > In section 3, using run-time subs implies modification of mapfile.c
> or
> > would this be done elsewhere? Would wms_inspire_languages serve as a
> > validation (e.g. supplied value would have to be in that list, no
> > regex)?
> > 
> > In section 6, specifically which API functions would take a language
> parameter?
> > 
> > Testing looks quite extensive... Great! It would be helpful to get
> > some comment from some of the more OGC competent -devs and/or users
> > out there. I'd be ok with moving forward on a vote since there's
> time
> > to work out kinks before the next release.
> > 
> > Steve