[Fwd: Re: Re: [mapserver-dev] [Fwd: [Mapserver-inspire] SoC ProjectMidterm]]

[Stephan Meißl]

Hi devs,

I'm forwarding Stefan's mail below about the update of the INSPIRE RFC.

cu
Stephan


-------- Forwarded Message --------
> From: Stefan Leopold <stefan.leopold at reflex.at>
> To: stephan at meissl.name
> Subject: Re: Re: [mapserver-dev] [Fwd: [Mapserver-inspire] SoC
> ProjectMidterm]
> Date: Fri, 19 Aug 2011 15:01:01 +0200
> 
> hello stephan
> 
> i commited changes based on last feedback, merged latest trunk changes
> to sandbox and updated rfc
> (in particular list of modified functions/additional language
> parameter)
> 
> can you please repost to the mailing list
> 
> thx&cu
> stefan
> 
> Stephan Meißl <stephan at meissl.name> schreibt:
> 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
> 
> 
> 
> 
>