[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [udig-users] WMS and no access to XSDs for schema validation
|
Hi Frank,
Am 05.10.2020 um 21:20 schrieb Frank Gasdorf:
welcome to the users-list and thanks for your post!
thanks for the quick answer!
Have I understood you correctly, the added WMS Server/Layer has not been
added to the Map/Catalog due to this validation error? Maybe this error
is just logged but ignored at the end.
After closing the "Add layer" wizard the WMS server is added to the
catalog view. If I click on this new entry new entry in the catalog view
the following error message appears in red in status bar:
(this is the original message in german)
"Keine Verbindung zum WMS. Möglicher Grund: Error downloading
http://schemas.opengis.net/sld/1.1.0/sld_capabilities.xsd"
(Translation: "No connection to WMS. Possible cause: Error downloading
http://schemas.opengis.net/sld/1.1.0/sld_capabilities.xsd)
I found a similar report on Stackoverflow
(https://stackoverflow.com/questions/29073622/geotools-wms-module-error).
This seems like a solution of the problem to me. I already asked the
admin of the WMS server if it's possible for him to change the server
config to add only URLs to local XSD files in the schema location
attribute of the GetCapabilities response.
Then I found a GeoTools - FAQ entry :
https://docs.geotools.org/latest/userguide/faq.html#q-i-am-in-a-restricted-environment-how-to-configure-schemalocator
I also found this FAQ entry the last days during my research for a
solution. In this FAQ the GeoTools developers basically say that they
used the mentioned approach to force XML parsers to use copies of schema
files included in GeoTools jars instead of downloading the schema each time.
This made me think that GeoTools also does not download the XSDs usually
needed for WMS or WFS. And the link to the GeoTools architecture in my
previous post seemed to confirm this. There they say
"To support the XML module in GeoTools we have bundled up several XML
schemas in JAR form (to prevent needing to download them from the
Internet each time they are needed). " And then they list the JARs like
gt-xsd-wms and net-opengis.ows. My conclusion was that GeoTools by
default uses local XSDs.
But in my case it seems that at least one XSD is not contained in the
mentioned GeoTools JARs. Perhaps it's really a GeoTools problem.
I'm trying to perform a test with the latest uDig 2.2.0 RC1 to see if
this problem still exists with the newer GeoTools 22.1.
Would you please create an issue at github
(https://github.com/locationtech/udig-platform/issues) so we can dig
into uDig and find a way to solve it. I guess it needs more investigation..
I will create the issue as soon as possible.
Many thanks in advance
No problem. I'm glad to help.
Thanks,
Riccardo
--
Frank
Am Mo., 5. Okt. 2020 um 15:48 Uhr schrieb Riccardo Foschia
<riccardo.foschia@xxxxxxxxxxxxx <mailto:riccardo.foschia@xxxxxxxxxxxxx>>:
Hello udig-users,
this is probably more a GeoTools problem but it happens with uDig, so I
ask this list first:
I'm running uDig 2.0.0 on a machine without internet access.
Unfortunately I cannot add a WMS layer to a uDig map from a WMS server
in the same LAN as the machine running uDig. In the status bar uDig
complains it cannot connect to the WMS because of
"Error downloading
http://schemas.opengis.net/sld/1.1.0/sld_capabilities.xsd"
I'm suspecting that uDig or better GeoTools tries to access some of the
URLs to the XSD referenced in the XML file returned by the
GetCapabilities request to the local WMS. For your information: these
are the first lines of the GetCapablities response:
<?xml version='1.0' encoding="UTF-8" standalone="no" ?>
<WMS_Capabilities version="1.3.0" xmlns="http://www.opengis.net/wms"
xmlns:sld="http://www.opengis.net/sld"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:ms="http://mapserver.gis.umn.edu/mapserver"
xsi:schemaLocation="http://www.opengis.net/wms
http://schemas.opengis.net/wms/1.3.0/capabilities_1_3_0.xsd
http://www.opengis.net/sld
http://schemas.opengis.net/sld/1.1.0/sld_capabilities.xsd
http://mapserver.gis.umn.edu/mapserver">
I did some research and it seems to me that GeoTools should by default
not access the internet when parsing GetCapabilities responses if some
JARs (gt-xsd-*.jar and net.opengis.*.jar) are distributed with an
application, see chapter "GeoToolsExtensions / XML" here
https://docs.geotools.org/latest/userguide/welcome/architecture.html
I checked that the GeoTools JARs mentioned in the above document are
distributed with uDig 2.0.0. They are also listed in bundle
classpath of
org.locationtech.udig.libs plugin.
It would be OK for me, if no validation at all would happen for the
used
WMS. So my question is:
Is there a way to configure uDig that no schema validation happens for
responses to WMS requests?
Any hints are really appreciated.
Thanks in advance,
Riccardo
--
META-LEVEL Software AG
Lyonerring 1
66121 Saarbrücken
Deutschland
Tel: +49 - 681 / 99687-0
Fax: +49 - 681 / 99687-99
Mail: info@xxxxxxxxxxxxx <mailto:info@xxxxxxxxxxxxx>
Web: www.meta-level.de <http://www.meta-level.de>
Rechtsform: Aktiengesellschaft
Sitz: Saarbrücken
HR B Nr. 13 380 Amtsgericht Saarbrücken
USt-IdNr. DE 1 38 166667
Vorstände: Dipl.-Inform. Peter Badt und Dipl.-Inform. Peter Raber
Vorsitzender des Aufsichtsrats: Reinhard Kuhn
_______________________________________________
udig-users mailing list
udig-users@xxxxxxxxxxx <mailto:udig-users@xxxxxxxxxxx>
To unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/udig-users
_______________________________________________
udig-users mailing list
udig-users@xxxxxxxxxxx
To unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/udig-users
--
META-LEVEL Software AG
Lyonerring 1
66121 Saarbrücken
Deutschland
Tel: +49 - 681 / 99687-0
Fax: +49 - 681 / 99687-99
Mail: info@xxxxxxxxxxxxx
Web: www.meta-level.de
Rechtsform: Aktiengesellschaft
Sitz: Saarbrücken
HR B Nr. 13 380 Amtsgericht Saarbrücken
USt-IdNr. DE 1 38 166667
Vorstände: Dipl.-Inform. Peter Badt und Dipl.-Inform. Peter Raber
Vorsitzender des Aufsichtsrats: Reinhard Kuhn