Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GetLegendGraphic with OPACITY from a WMS service with a colon [nrwn:track] in layer name does not work. #5039

Closed
bosthy opened this issue Nov 20, 2014 · 14 comments

Comments

@bosthy
Copy link

@bosthy bosthy commented Nov 20, 2014

Hi,
We have an issue with using the GetLegendGraphic request with OPACITY in the URL and the colon character (:) in the layer name like: [nrwn:track]

The following url does not work:

http://ows.geobase.ca/wms/geobase_en?TRANSPARENT=TRUE&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetLegendGraphic&EXCEPTIONS=application%2Fvnd.ogc.se_xml&LAYER=nrwn%3Atrack&map.layer[nrwn:track]=OPACITY+100&FORMAT=image/png&SCALE=3466743.3252500976

This url does work:

http://ows.geobase.ca/wms/geobase_en?TRANSPARENT=TRUE&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetLegendGraphic&EXCEPTIONS=application%2Fvnd.ogc.se_xml&LAYER=nrwn%3Atrack&FORMAT=image/png&SCALE=3466743.3252500976

We may have to apply our own fix or cascade the layers in a new mapfile however if this is a valid issue any insight would be greatly appreciated.

Thanks

@sdlime
Copy link
Member

@sdlime sdlime commented Nov 21, 2014

What happens if you use a layer name without the colon? What version of MapServer are you using?

@sdlime
Copy link
Member

@sdlime sdlime commented Nov 21, 2014

Looking at git master the URL token parsing seems to only support simple strings as defined by maplexer.l on line 487. A colon is not part of the allowed character list although dashes and underscores are. You (or we) could tweak that pattern to include colons and I believe that would fix your problem.

Steve

@msmitherdc
Copy link
Contributor

@msmitherdc msmitherdc commented Nov 21, 2014

@sdlime aren't colons in xml tags (like layer names) illegal so tweaking that would break OGC compliance?

@sdlime
Copy link
Member

@sdlime sdlime commented Nov 21, 2014

@msmitherdc this would only change what's allowed in a URL string that is used to modify a layer. It doesn't show up in any output. The colon in the layer name is already allowed. Whether using a colon in a layer name is a good idea or not is beyond the scope of this ticket.

@tomkralidis
Copy link
Member

@tomkralidis tomkralidis commented Nov 21, 2014

FYI layers with colons might trip things up if they are queried via GetFeatureInfo, in which the response uses the layername as part of the XML element output.

@bosthy
Copy link
Author

@bosthy bosthy commented Nov 21, 2014

We are using 6.4.1 sur Ubuntu 14.04 LTS. A layer without colons in it's name works fine.We publish WMS's and also allow users to add there own services to the map. These service come from elsewhere.(No control) However I like @msmitherdc solution that it would only change what's allowed in a URL. I beleve a wfs with colons will not work either.

@sdlime
Copy link
Member

@sdlime sdlime commented Nov 21, 2014

Maybe you can try locally first and see if it solves your issue. --Steve

From: bosthy [mailto:notifications@github.com]
Sent: Friday, November 21, 2014 1:49 PM
To: mapserver/mapserver
Cc: Lime, Steve D (MNIT)
Subject: Re: [mapserver] GetLegendGraphic with OPACITY from a WMS service with a colon [nrwn:track] in layer name does not work. (#5039)

We are using 6.4.1 sur Ubuntu 14.04 LTS. A layer without colons in it's name works fine.We publish WMS's and also allow users to add there own services to the map. These service come from elsewhere.(No control) However I like @msmitherdchttps://github.com/msmitherdc solution that it would only change what's allowed in a URL. I beleve a wfs with colons will not work either.


Reply to this email directly or view it on GitHubhttps://github.com//issues/5039#issuecomment-64027265.

@sdlime
Copy link
Member

@sdlime sdlime commented Nov 26, 2014

What does everyone think? Should I expand the character set just a bit or just leave it to users to make local modifications if necessary? Would like to close this ticket one way or the other.

Steve

@jmckenna
Copy link
Member

@jmckenna jmckenna commented Nov 26, 2014

I personally vote for users doing local modifications to remove special characters from their layer names in their mapfiles.

@bosthy
Copy link
Author

@bosthy bosthy commented Nov 26, 2014

Our client would prefer to expand the character set whithin mapserver. Otherwise they will have to ask the wms provider to accept and remove colons in there layer names or else we will have to cascade every layer in the Geobase from the Canadian Federal Government in our own map file. Does GeoServer allow already colons in the group layer name?

@sdlime
Copy link
Member

@sdlime sdlime commented Nov 26, 2014

I don't know about GeoServer. It's a pretty easy change on our end. The change would help native MapServer calls too. We're not real limiting in layer names in the native case. @bosthy would this have to be in 6.4 or would the 7.0 release be good enough.

I'll prepare a patch...

Steve

@bosthy
Copy link
Author

@bosthy bosthy commented Nov 26, 2014

@sdlime A patch for 6.4 will be greatly appreciated. If I understand correctly it will also be part of the 7.0 release. Thank you very much.

sdlime added a commit that referenced this issue Dec 1, 2014
@sdlime
Copy link
Member

@sdlime sdlime commented Dec 1, 2014

@bosthy, I made the change to master and it works fine. Here's a quick patch against the 6.4 branch:

index 31845c8..1e085be 100644
--- maplexer.l
+++ maplexer.l
@@ -473,7 +473,7 @@ char path[MS_MAXPATHLEN];
wms { MS_LEXER_RETURN_TOKEN(MS_WMS); }
alpha { MS_LEXER_RETURN_TOKEN(MS_GD_ALPHA); }

-<URL_VARIABLE>[[a-z/.][a-z0-9/.-=_ ]] {
+<URL_VARIABLE>[[a-z/:.][a-z0-9/.-=
]_] {
msyytext++;
msyytext[strlen(msyytext)-1] = '\0';
MS_LEXER_STRING_REALLOC(msyystring_buffer, strlen(msyytext),

@sdlime
Copy link
Member

@sdlime sdlime commented Dec 2, 2014

Closing for now... --Steve

@sdlime sdlime closed this Dec 2, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants
You can’t perform that action at this time.