Hi mandsch, Christoph and Michael :-),
i 've tested some mapserver WFS with the 2.6 branch.
I have to say that the gazetter module works very fine now.
I only got some troubles with the new jquery tablesorter module.
My error was caused by a misconfiguration with the output position numbers
which you can define in mod_wfs_edit.php.
If you don't set the columns to a correct order(without a gap),
the tablesorter module will not display any dataset that the WFS delivered.
Very cool feature,
now i can change over most of my WFS's to mapserver!! :-)
cheers marc
Michael Schulz schrieb:
Hi Christoph,
yes, I also agree, that this is a more generic approach and I'd be
willing to integrate that into 2.6 branch. Although I'd be happy to
have someone with strong-WFS background check this approach.
Cheers, Michael
2009/7/29 Christoph Baudson <[email protected]>:
Michael Schulz schrieb:
Hi Michael, ;-)
another approach would be to search with xpath for
"gml:featureMember", and then feed the firstChild, which is always the
featuretype to the featuretype parser ... sth. like that:
$gmlFeatureMembers = $gmlDoc->xpath("//gml:featureMember");
if (count($gmlFeatureMembers) > 0) {
foreach ($gmlFeatureMembers as $gmlFeatureMember) {
$gmlfeatureMember_dom =
dom_import_simplexml($gmlFeatureMember);
$feature = new Feature();
$this->parseFeature($gmlfeatureMember_dom->firstChild,
$feature, $wfsConf);
if (isset($feature->geometry)) {
$gml->featureCollection->addFeature($feature);
}
}
}
This looks like a more generic approach...are you willing to integrate this
into the 2.6 branch?
But I guess we should consult mschulz first ;-)
Thanks for your help
Christoph
Actually, I wondered why e.g. QGIS had no problems to load a UMN
WFS... so that's the reason.
Cheers, mandsch
2009/7/28 Michael Schulz <[email protected]>:
Hi Devs,
after some detours and especially after some valuable hints from
Christoph on irc I came to this workaround, for the described problem,
when using UMN as WFS-Server and getting no results from WFS-Gazatteer
requests, because there is an obscure namespace problem with UMN-WFS
(it breaks down to: umn gives a featuretype name in the getcaps
without ns, this is stored in the mapbender db, when parsing
getfeature request, that stored value is used to go through the
getfeature result xml, that unfortunately now uses a namespace "ms:",
so mapbender code won't find any features).
My workaround is to ignore namespaces when searching for the result
features, by using the xpath function local-name(). This can be
applied in class_gml_factory around line 20, instead of:
$gmlFeatureMembers = $gmlDoc->xpath("//" . $featureType->name);
you could write:
$admin = new administration();
$gmlFeatureMembers = $gmlDoc->xpath("//*[local-name()='".
$admin->sepNameSpace($featureType->name)."']" );
This ignores the namespace, but certainly leaves the xml untouched.
I've tested it with UMN and Geoserver. If someone wants to give it a
try, I'll be happy for any feedback.
Cheers, Michael
2009/7/14 Michael Schulz <[email protected]>:
Hi,
I have a strange problem when using umn mapserver as a wfs-server for
a gazetteer search. The problem is that the featuretype is announced
in get getCaps as
<Name>meinFeatureType</Name>.
When actually searching and issueing the getfeature request, the
result is returned with featuremembers with the default ms namespace:
<gml:featureMember><ms:meinFeatureType
fid="meinFeatureType.007">...</gml:featureMember>.
The problem is now that in the gml classes, the returned gml is
accessed with the xpath function searching for the featuretype name as
recieved from the getCapabilities response and since this name has no
namespace it won't find the featuremembers...
Is this a mapserver wfs misconfiguration on my side (i tried with
wms_namespace_prefix ...) or a mapserver wfs bug or a mapbender bug?
When using geoserver the featuretype namespace is also returned in the
getcapabilities response.
Thanks for your hints ... Michael
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Aufwind durch Wissen!
Qualifizierte Open Source Schulungen bei der
http://www.foss-akademie.de/
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-----------------------------------------------------------
Michael Schulz
[email protected]
in medias res
Gesellschaft für Informationstechnologie mbH
+++ Bitte beachten Sie unsere neue Adresse und Durchwahl +++
Schwimmbadstraße 2
D-79100 Freiburg i. Br.
Tel: +49 (0)761 705798-102
Tel: +49 (0)761 705798-0
Fax: +49 (0)761 705798-09
+++ Bitte beachten Sie unsere neue Adresse und Durchwahl +++
http://www.webgis.de / http://www.zopecms.de
--------------------------------------------------------------
Geschäftsführer: Stefan Giese, Dr. Christof Lindenbeck
Eingetragen im Handelsregister HRB 5930 beim Amtsgericht Freiburg
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Aufwind durch Wissen!
Qualifizierte Open Source Schulungen bei der
http://www.foss-akademie.de/
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-----------------------------------------------------------
Michael Schulz
[email protected]
in medias res
Gesellschaft für Informationstechnologie mbH
+++ Bitte beachten Sie unsere neue Adresse und Durchwahl +++
Schwimmbadstraße 2
D-79100 Freiburg i. Br.
Tel: +49 (0)761 705798-102
Tel: +49 (0)761 705798-0
Fax: +49 (0)761 705798-09
+++ Bitte beachten Sie unsere neue Adresse und Durchwahl +++
http://www.webgis.de / http://www.zopecms.de
--------------------------------------------------------------
Geschäftsführer: Stefan Giese, Dr. Christof Lindenbeck
Eingetragen im Handelsregister HRB 5930 beim Amtsgericht Freiburg
--
----------------------------------
Aufwind durch Wissen!
Qualifizierte OpenSource-Schulungen
bei der www.foss-academy.eu
----------------------------------
_______________________________________
W h e r e G r o u p GmbH & Co. KG
Siemensstraße 8
53121 Bonn
Germany
Christoph Baudson
Anwendungsentwickler
Fon: +49 (0)228 / 90 90 38 - 15
Fax: +49 (0)228 / 90 90 38 - 11
[email protected]
www.wheregroup.com
Amtsgericht Bonn, HRA 6788
_______________________________________
Komplementärin:
WhereGroup Verwaltungs GmbH
vertreten durch:
Olaf Knopp, Peter Stamm
_______________________________________
_______________________________________________
Mapbender_dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/mapbender_dev
_______________________________________________
Mapbender_dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/mapbender_dev
