Hi Jody,
An answer to all your questions ( I think ).
On 22/05/14 02:39, Jody Garnett wrote:
1) version negotiation how?
Okay, so I have been looking at this GML3 issue, and I found where it
happens is in the method getDefaultOutputFormat in AbstractWFSStrategy.
What this method does is look at the client formats and server formats
and takes the first match.
The client formats are defined in the class
GmlGetFeatureResponseParserFactory in the gt-data module. They are:
"text/xml; subtype=gml/3.1.1",//
"text/xml;subtype=gml/3.1.1",//
"text/xml; subtype=gml/3.1.1/profiles/gmlsf/0",//
"text/xml;subtype=gml/3.1.1/profiles/gmlsf/0",//
"application/gml+xml; subtype=gml/3.1.1",//
"application/gml+xml;subtype=gml/3.1.1",//
"application/gml+xml;
subtype=gml/3.1.1/profiles/gmlsf/0",//
"application/gml+xml;subtype=gml/3.1.1/profiles/gmlsf/0",//
"GML3", //
"GML3L0", //
"text/xml", // oddly, GeoServer returns plain
'text/xml' instead of the propper
// subtype when resultType=hits. Guess
we should make this something
// the specific strategy can hanlde?
"text/gml; subtype=gml/3.1.1",// the incorrectly
advertised GeoServer format
"GML2",//
"text/xml; subtype=gml/2.1.2"//
Then the server formats are taken from the parsed getcapabilities document.
For the geoserver WFS 1.0 server this is:
GML3, GML2, CSV, JSON, SHAPE-ZIP, KML
So... since GML3 is *first* in the list, that is the chosen format.
Question is: is this wrong? If Geoserver puts it in that order in its
wfs 1.0 getcapabilities document, doesn't it make sense to pick it
first? If the server didn't support GML3 it wouldn't occur.
2) Replacement for WFSSchema.NAMESPACE
public static URI NAMESPACE = makeURI("http://www.opengis.net/wfs";);
Is there is good place to reference this value? I don't want to have
to create it in multiple locations?
What about WFS.NAMESPACE in the xsd-wfs module? It is a string though.
3) GetBounds / CRS not working -> getInfo problem?
I have found that all my problems disappeared as soon as I filled in the
*namespace* parameter when creating the store.
a) CRS and bounds were received properly;
b) Map was rendered successfully;
c) Features were editable and transactions were sent to server successfully.
So I found the bug is not in wfs-ng getInfo but in uDig.
More specifically: you can find the bug on line 79 of the class
WFSGeoResourceInfo in the module org.locationtech.udig.catalog.wfs. The
namespace is here used without a null check. Because of that, the whole
method crashes (which is actually a constructor) and therefore *none* of
the metadata of the resource is being received. According to the
geotools API I see no reason why the namespace can't be null. udig
shouldn't crash on that... so in my opinion it is udig that needs to
change and not wfs-ng! Correct me if I'm wrong...
4) Visual representation of parameters names, formatting sources, ...
Will be sorted.
Kind Regards
Niels
------------------------------------------------------------------------------
The best possible search technologies are now affordable for all companies.
Download your FREE open source Enterprise Search Engine today!
Our experts will assist you in its installation for $59/mo, no commitment.
Test it for FREE on our Cloud platform anytime!
http://pubads.g.doubleclick.net/gampad/clk?id=145328191&iu=/4140/ostg.clktrk
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
