tbonfort
commented
12 years ago Author: dmorissette Date: 2003/09/26 - 15:06
Assefa, can you please add this to your list for when you'll work on WMS.Closed tbonfort closed 12 years ago
tbonfort
commented
12 years ago Author: dmorissette Date: 2003/09/26 - 15:06
Assefa, can you please add this to your list for when you'll work on WMS.Author: dmorissette Date: 2003/10/15 - 15:21
Here is some relevant information from the WMS 1.1.0 spec:
DTD:
====
<!-- A Map Server may use zero or more MetadataURL elements to offer detailed,
standardized metadata about the data underneath a particular layer. The type
attribute indicates the standard to which the metadata complies. Two types
are defined at present: 'TC211' = ISO TC211 19115; 'FGDC' = FGDC CSDGM. The
format element indicates how the metadata is structured. -->
<!ELEMENT MetadataURL (Format, OnlineResource) >
<!ATTLIST MetadataURL
type ( TC211 | FGDC ) #REQUIRED>
EXAMPLE:
========
<!-- Metadata specific to this particular layer. The same FGDC metadata
is offered in two formats. -->
<MetadataURL type="FGDC">
<Format>text/plain</Format>
<OnlineResource xmlns:xlink="http://www.w3.org/1999/xlink"
xlink:type="simple"
xlink:href="http://www.university.edu/metadata/roads.txt" />
</MetadataURL>
<MetadataURL type="FGDC">
<Format>text/xml</Format>
<OnlineResource xmlns:xlink="http://www.w3.org/1999/xlink"
xlink:type="simple"
xlink:href="http://www.university.edu/metadata/roads.xml" />
</MetadataURL>
Author: dmorissette Date: 2003/10/15 - 15:42
Tom.Kralidis@CCRS.NRCan.gc.ca wrote:
> I am surely for this enhancement!! I also suggest DataURL to be added.
>
Author: dmorissette Date: 2003/10/15 - 15:46
See also bug 459 about MetadataURL which is also missing in the map context
implementation. The fix for both bugs should use the same MapServer metadata
entries.Author: tomkralidis Date: 2004/02/17 - 14:09
Note that this should also apply for the OGC:WFS. Perhaps a layer metadata
element "ows_metadata_url" which tackles OGC:WMS, OGC:WMS, OGC:WMC? Or is this
available in another manner within the CVS dist?
..TomAuthor: dmorissette Date: 2004/02/17 - 16:29
I think that in the context of this bug, we should continue to use
wms_metadataurl_href and wms_metadataurl_format for consistency with the rest of
the WMS and WMC stuff.
However, we've had discussions about trying to use ows_* metadata names to
reduce redundancy in the mapfiles. I have summarized our discussions on this in
bug 568
Author: bartvde@osgis.nl Date: 2004/04/19 - 18:34
I was just reading the 4.2 release notes and I am a bit confused now about the
status of this bug:
Replace wms_style_%s_legendurl, wms_logourl, wms_descriptionurl, wms_dataurl
and wms_metadataurl metadata by four new metadata by metadata replaced. The
new metadata are called legendurl_width, legendurl_height, legendurl_format,
legendurl_href, logourl_width, etc...
Old dependancy to the metadata with four value in it , space separated, are
not kept.
Does this mean the metadataurl_href works now?Author: dmorissette Date: 2004/04/21 - 17:28
At the moment the metadataurl_href is supported only in the map context (bug
459), but not in the WMS getcapabilities yet (the current bug). We'll have to
make sure this is added in 4.3/4.4.Author: tomkralidis Date: 2004/07/04 - 00:25
Any update on this issue? I believe Assefa was working on these in the last
couple of weeks (DataURL also).Author: dmorissette Date: 2004/07/13 - 06:43
We've had another question on the list asking to explain the meaning of the
entry in the HISTORY.TXT that was quoted by Bart above in comment #7... here is
a copy of the explanation:
-----------
First of all, you can't implement legendurl_href in WMS Capabilites yet, the
comment above applies only to WMS context, the support of LegendURL in the WMS
capabilities is still an open issue, see
http://mapserver.gis.umn.edu/bugs/show_bug.cgi?id=438
IIRC, what the comment above tries to say is that the following metadata were
used before by the WMS context code, and that each of them used to expect a
different number of parameters delimited by spaces:
wms_style_%s_legendurl
wms_logourl
wms_descriptionurl
wms_dataurl
wms_metadataurl
This was a mess since some of the above included 4 space-delimited values
(width, height, format, url) and some included only 2 (only format and url since
width/height don't make sense for DataUrl for instance), so each of the above
was replaced by a set of 4 metadata entries instead.
e.g.
wms_style_%s_legendurl has been replaced with:
wms_style_%s_legendurl_width
wms_style_%s_legendurl_height
wms_style_%s_legendurl_format
wms_style_%s_legendurl_href
wms_logourl has been replaced with:
wms_logourl_width
wms_logourl_height
wms_logourl_format
wms_logourl_href
... and so on for each of the 5 old metadata values above that were split into 4
values the same way. Author: dmorissette Date: 2004/07/19 - 22:37
*** Bug 721 has been marked as a duplicate of this bug. ***Author: dmorissette Date: 2004/07/19 - 23:13
-------- Original Message --------
Subject: [Mapserver-dev] mapwms.c and mapwfs.c hacks for LegendURL, MetadataURL,
and DataURL
Date: Mon, 19 Jul 2004 15:31:04 -0400
From: Kralidis,Tom [Burlington] <Tom.Kralidis@ec.gc.ca>
To: <mapserver-dev@lists.gis.umn.edu>
Hi,
Thought I'd post/share this:
My organization has requirements for the following in OGC Capabilities
documents:
- LegendURL (WMS 1.1.0+, encoded as StyleURL in 1.0.0)
- MetadataURL (WMS 1.1.0+ WFS 1.0.0)
- DataURL (WMS [all versions])
..so I made a hack in the following files to enable this as per below:
mapwms.c: line 591
/* HACK BEGIN */
msOWSPrintEncodeMetadata(stdout, &(lp->metadata), NULL,
"wms_metadataurl_href", OWS_NOERR,
" <MetadataURL
type=\"FGDC\">\n\t\t<Format>text/html</Format>\n\t\t<OnlineResource
xmlns:xlink=\"http://www.w3.org/1999/xlink\" xlink
:href=\"%s\"/>\n\t</MetadataURL>\n", NULL);
msOWSPrintEncodeMetadata(stdout, &(lp->metadata), NULL,
"wms_dataurl_href", OWS_NOERR,
"
<DataURL>\n\t\t<Format>text/html</Format>\n\t\t<OnlineResource
xmlns:xlink=\"http://www.w3.org/1999/xlink\" xlink:href=\"%s\"/>\n\t
</DataURL>\n", NULL);
printf(" <Style>\n");
printf(" <Name>default</Name>\n");
printf(" <Title>Default</Title>\n");
printf(" <LegendURL width=\"20\" height=\"10\">\n");
printf(" <Format>image/png</Format>\n");
printf(" <OnlineResource
xmlns:xlink=\"http://www.w3.org/1999/xlink\"
xlink:href=\"%sversion=1.1.1&service=WMS&request=GetLegendGraphi
c&layer=%s&format=image/png\"/>\n", msOWSGetOnlineResource(map,
"wms_onlineresource", NULL), lp->name);
printf(" </LegendURL>\n");
printf(" </Style>\n");
/* HACK END */
mapwfs.c: line 379
/* HACK BEGIN */
msOWSPrintEncodeMetadata(stdout, &(lp->metadata), NULL,
"wms_metadataurl_href", OWS_NOERR,
" <MetadataURL type=\"FGDC\"
format=\"XML\">%s</MetadataURL>\n", NULL);
/* HACK END */
As this is a hack, there's most certainly a better way to do this, as
the following info is not integrated/supported:
- wms_legendurl_width and wms_legendurl_height not used/integrated.
There should be a test to test for these in mapfile, if not there, go
with default (20x10?). I didn't know how to fit more than one mapfile
parameter as an argument in msOWSPrintEncodeMetadata -- is there a way?
- wms_dataurl_format and wms_metadataurl_format not used/integrated. I
didn't know how to fit more than one mapfile parameter as an argument in
msOWSPrintEncodeMetadata -- is there a way?
..TomAuthor: dmorissette Date: 2004/07/19 - 23:15
My reply to Tom on the list:
Kralidis,Tom [Burlington] wrote:
>
> - wms_legendurl_width and wms_legendurl_height not used/integrated.
> There should be a test to test for these in mapfile, if not there, go
> with default (20x10?).
Um... I don't like returning a hardcoded default (e.g. 20x10) that is not going
to be accurate 99% of the time anyway. False information is worse than no
information in my opinion. Perhaps in this case we could just return nothing
(ie. no LegendURL element) and produce a <!--WARNING:...--> in the capabilities
output saying that width/height are required and were missing, and therefore the
LegendURL could not be included. Same thing when format is missing with the
other URL types
> I didn't know how to fit more than one mapfile
> parameter as an argument in msOWSPrintEncodeMetadata -- is there a way?
>
No, there is no way. Perhaps in this specific case we should implement a
msOWSPrintURLType() that would be re-used for LegendURL, LogoURL, MetadataURL, etc.
Author: tomkralidis Date: 2004/07/20 - 05:34
Agreed, a msOWSPrintURLType function would be useful. We also implemented
something like this as a complexType in the OGC:WMC spec, so the approach makes
sense. This can also apply globally as OGC URL type XML defs are uniform for
the most part.
For LegendURL, width and height are required else it breaks the OGC:WMS 1.1.1
DTD. So we need a default (or calculated) width/height. Ideas?
For MetadataURL and DataURL, Format is required else it breaks the schema. So
we need a default format. Ideas?
Also, as LegendURL exists as StyleURL in OGC:WMS pre 1.1.0, we need to encode
this as such for OGC:WMS pre 1.1.0 (i.e. 1.0.0).
Also, as GetLegendGraphic is not supported pre OGC:WMS 1.1.1, but
LegendURL/StyleURL does, we need to encode a native MapServer CGI mode=legend
call in this element.
So now we need to layout msOWSPrintURLType() function.Author: dmorissette Date: 2004/09/02 - 22:21
*** Bug 844 has been marked as a duplicate of this bug. ***Author: tomkralidis Date: 2004/10/06 - 18:41
Anyway we can fit this in? Suggest:
mapwms.c GetCapabilities support of:
wms_metadataurl_format
wms_metadataurl_href
wms_dataurl_format
wms_dataurl_href
Really only a couple of lines of code. I can send an updated hack if desired.
PS -- of course, this will have to support the generic ows_* metadata names,
which is being worked on in bug 568
As for LegendURL, see bug 262Author: dmorissette Date: 2004/10/06 - 21:49
Tom, and all, we need a unified solution for all *URL types in all OWS services
and not a bunch of hacks here and there. (i.e. we cannot apply the patches that
you proposed in bugs 438, 262 and 936 directly, that would just create a mess)
I think the clean solution is as I wrote at the end of comment#13 above:
> Perhaps in this specific case we should implement a
> msOWSPrintURLType() that would be re-used for LegendURL, LogoURL, MetadataURL,
> etc.
Author: dmorissette Date: 2004/10/19 - 18:00
Reassigned to Julien to fix this at the same time as bug 936Author: jlacroix Date: 2004/10/25 - 19:50
By including msOWSPrintURLType() function (bug 944), MetadataURL and DataURL
have been added to WMS. This will be available in 4.4. The metadata are:
wms_metadataurl_type
wms_metadataurl_format
wms_metadataurl_href
and
wms_dataurl_format
wms_dataurl_href
Since this was the main prupose of this bug I will mark as FIXED.
Reporter: kafka@email.cz Date: 2003/09/25 - 15:01