Hi all, just wanted to update you on this and the mapserver INSPIRE work in
general.
The latest version of the 'Technical Guidance to implement INSPIRE View
Services' has been out for a while. whether its the final doc or not I can't
say, but they have at least focused in on which attributes and
I think that what needs to be passed to mapserver is something like
lang=en_US and that is then used to select the appropriate alias. And if
that does not exist then there are appropriate rules for how to handle
it or error out.
-Steve
this is much better:
ows_title highways # default
Hi Thomas,
I think it would be good it someone summarized this thread in an
enhancement request ticket. Ideally someone that knows what is required
by INSPIRE, which is not me :) Posting the ticket number to the list is
also a good idea so others with interest can add themselves to the CC
Le 2010-10-12 09:36, tellett a écrit :
Hi Stephen, at the moment I'm writing a draft RFC that proposes changes to
make mapserver 'INSPIRE compliant', we're proposing a whole package of
changes (hopefully not too major!!) and I could add this problem to that. Of
course we're creating separate
Hi Steve,
I did not (mean to) say the client does not send the correct language parameter
to the server. The client (browser) is in control and will request the language
needed.
Your e-mail said the client needed to do the actual translation of e.g. layer
names, and that's where I disagreed.
Hi Michael,
thats a realy good idea for the attributes of the geodata. But what about
LAYER
NAME 'my_highway_layer'
TYPE LINE
DATA geom from data where lang='%lang%'
METADATA
ows_title highways # must be i18n
ows_group_title Infrastructure # must be i18n
I'm not sure that there is any reason that this:
could not be coded like:
gml_ID_alias Number # must be i18n
gml_NAME_alias Name # must be i18n
could not be coded like:
gml_ID_alias_en_US Number # must be i18n
gml_NAME_alias_en_US Name # must be i18n
On 10/7/2010 2:30 AM, Bart van den Eijnden wrote:
Hi Steve,
I did not (mean to) say the client does not send the correct language
parameter to the server. The client (browser) is in control and will
request the language needed.
Your e-mail said the client needed to do the actual translation of
Would it be better to make then available for variable substitution?
gml_ID_alias %GML_ID_NO% # must be i18n
gml_NAME_alias %GML_NAME_ALIAS% # must be i18n
Mike
--
Michael Smith
US Army Corps of Engineers
Remote Sensing/GIS Center
Hanover, NH
On 10/7/10 9:14 AM, Stephen
On 10/7/2010 9:24 AM, Smith, Michael ERDC-CRREL-NH wrote:
Would it be better to make then available for variable substitution?
gml_ID_alias %GML_ID_NO% # must be i18n
gml_NAME_alias %GML_NAME_ALIAS% # must be i18n
I think that what needs to be passed to mapserver is something like
I think that what needs to be passed to mapserver is something like
lang=en_US and that is then used to select the appropriate alias. And if
that does not exist then there are appropriate rules for how to handle
it or error out.
-Steve
I'm also not a friend of the idea to have multiple
On 10/6/2010 11:07 AM, teeschke wrote:
Hi Jeff,
Thanks a lot, but I don't mean the support of caracter encoding.
I want to publish the same map in different languages.
I mean the technology to publish the same content in multiple languages.
E.g. an american user would see the layers named
I don't agree with you here Steve.
Also look at the INSPIRE language parameter, it's up to the service (View
Service, WMS) to translate, not the client. Think of layer titles in WMS
GetCapabilities.
The way I've been doing it is to duplicate my datasets behind Mapserver, but
that's not an
On 10/6/2010 12:54 PM, Bart van den Eijnden wrote:
I don't agree with you here Steve.
Also look at the INSPIRE language parameter, it's up to the service
(View Service, WMS) to translate, not the client. Think of layer
titles in WMS GetCapabilities.
The way I've been doing it is to duplicate
Hi Steve,
I have no real ideas towards a solution, like I said I use data duplication
right now :-) . Normally a thesaurus would be used in between, but I don't know
how viable it is to do this on the fly.
Best regards,
Bart
--
Looking for flexible support on OpenLayers or GeoExt? Please
I would do this on the backend. Pass a language variable to your data query
DATA geom from data where lang='%lang%'
LABELITEM %LANG%HIGHWAY
And have one mapfile and just have your translations in PostGis/Oracle/etc.
Mike
--
Michael Smith
US Army Corps of Engineers
Remote Sensing/GIS Center
16 matches
Mail list logo
