<div dir="ltr">Simone,<div><br></div><div>I agree with your analysis. I think we will have no choice to modify the behavior of the client. Hopefully, Martin can help us address this issue. I think we should report this issue as a CR to enforce the adherence to standards. This is a huge impediment to interoperability as every vendor comes out with their strategy. Given a URL to WFS, it is impossible to implement a client that can accommodate the different profile for each vendor. We are harvesting thousands of WFS on Geoplatform and access them in a unified way is crucial. So the usage of the short name EPSG:xxxx should be banned or need to be enforced to follow the standard. Not sure if this issue has already been addressed by OGC.</div><div><br></div><div>Regards</div><div>Stephane</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 27, 2017 at 12:19 PM, Simone Giannecchini <span dir="ltr"><<a href="mailto:simone.giannecchini@geo-solutions.it" target="_blank">simone.giannecchini@geo-solutions.it</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Ciao All,<br>
reversing axis order for EPSG:4326 requires coding and cannot be done<br>
quickly, since we cannot make this behavior the default as most client<br>
will break.<br>
<br>
Preserving the full URL on the client side seems the lowest hanging<br>
fruit at this stage, since with the full URL you should get<br>
coordinates in the proper order.<br>
<br>
<br>
Regards,<br>
Simone Giannecchini<br>
==<br>
GeoServer Professional Services from the experts!<br>
Visit <a href="http://goo.gl/it488V" rel="noreferrer" target="_blank">http://goo.gl/it488V</a> for more information.<br>
==<br>
Ing. Simone Giannecchini<br>
@simogeo<br>
Founder/Director<br>
<br>
GeoSolutions S.A.S.<br>
Via di Montramito 3/A<br>
55054  Massarosa (LU)<br>
Italy<br>
phone: <a href="tel:%2B39%200584%20962313" value="+390584962313">+39 0584 962313</a><br>
fax:     <a href="tel:%2B39%200584%201660272" value="+3905841660272">+39 0584 1660272</a><br>
mob:   <a href="tel:%2B39%20%20333%208128928" value="+393338128928">+39  333 8128928</a><br>
<br>
<a href="http://www.geo-solutions.it" rel="noreferrer" target="_blank">http://www.geo-solutions.it</a><br>
<a href="http://twitter.com/geosolutions_it" rel="noreferrer" target="_blank">http://twitter.com/<wbr>geosolutions_it</a><br>
<br>
------------------------------<wbr>-------------------------<br>
AVVERTENZE AI SENSI DEL D.Lgs. 196/2003<br>
Le informazioni contenute in questo messaggio di posta elettronica e/o<br>
nel/i file/s allegato/i sono da considerarsi strettamente riservate.<br>
Il loro utilizzo è consentito esclusivamente al destinatario del<br>
messaggio, per le finalità indicate nel messaggio stesso. Qualora<br>
riceviate questo messaggio senza esserne il destinatario, Vi preghiamo<br>
cortesemente di darcene notizia via e-mail e di procedere alla<br>
distruzione del messaggio stesso, cancellandolo dal Vostro sistema.<br>
Conservare il messaggio stesso, divulgarlo anche in parte,<br>
distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità<br>
diverse, costituisce comportamento contrario ai principi dettati dal<br>
D.Lgs. 196/2003.<br>
<br>
The information in this message and/or attachments, is intended solely<br>
for the attention and use of the named addressee(s) and may be<br>
confidential or proprietary in nature or covered by the provisions of<br>
privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New<br>
Data Protection Code).Any use not in accord with its purpose, any<br>
disclosure, reproduction, copying, distribution, or either<br>
dissemination, either whole or partial, is strictly forbidden except<br>
previous formal approval of the named addressee(s). If you are not the<br>
intended recipient, please contact immediately the sender by<br>
telephone, fax or e-mail and delete the information in this message<br>
that has been received in error. The sender does not give any warranty<br>
or accept liability as the content, accuracy or completeness of sent<br>
messages and accepts no responsibility  for changes made after they<br>
were sent or for other risks which arise as a result of e-mail<br>
transmission, viruses, etc.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
On Fri, Oct 27, 2017 at 6:09 PM, Stephane Fellah<br>
<<a href="mailto:stephanef@imagemattersllc.com">stephanef@imagemattersllc.com</a><wbr>> wrote:<br>
> Martin,<br>
><br>
> Yes, definitely we will test it. You plan to deploy 4.0.4 on maven repo will<br>
> work for us.<br>
> Please note that the CRS URL is truncated in the WFSFeatureStore<br>
><br>
><br>
> The code snippet that breaks is in the WFSFeatureStore.java  (line 138)<br>
><br>
> //extract the feature type ------------------------------<wbr>-----------<br>
> CoordinateReferenceSystem crs;<br>
> FeatureType sft;<br>
> try {<br>
>     String defaultCRS = ftt.getDefaultCRS();<br>
>     if(defaultCRS.contains("EPSG")<wbr>){<br>
>         final int last = defaultCRS.lastIndexOf(':');<br>
>         defaultCRS = "EPSG:"+defaultCRS.substring(<wbr>last+1);<br>
>     }<br>
>     crs = CRS.forCode(defaultCRS);<br>
>     if (getLongitudeFirst()) {<br>
>         crs =<br>
> AbstractCRS.castOrCopy(crs).<wbr>forConvention(AxesConvention.<wbr>RIGHT_HANDED);<br>
>     }<br>
>     sft = requestType(typeName);<br>
> }<br>
><br>
><br>
> Simone has redeployed the WFS using the short version "EPSG:4326" to see if<br>
> the problem is solved, However, we ran into another issue with Geoserver.<br>
> The coordinates of lat/long are flipped when the short version is used on<br>
> Geoserver.<br>
> Only the preservation of the full URL will keep the order lat/long. I will<br>
> forward to you the email thread related to this problem.<br>
><br>
><br>
><br>
><br>
> Regards<br>
><br>
><br>
><br>
><br>
> On Fri, Oct 27, 2017 at 11:16 AM, Martin Desruisseaux<br>
> <<a href="mailto:martin.desruisseaux@geomatys.com">martin.desruisseaux@geomatys.<wbr>com</a>> wrote:<br>
>><br>
>> Hello Stephane<br>
>><br>
>> Indeed, the srsName attribute in gml:Envelope is of type anyURI. My<br>
>> interpretation is that the "urn:ogc:def:crs:epsg:…" syntax is more adequate<br>
>> than "EPSG:…" there. I'm not sure why WFSFeatureStore uses the short form;<br>
>> maybe at the time it was written, not all servers understood the URN form.<br>
>><br>
>> I can try modify Geotk 4.0.0 for using the URN form. I think (but I'm not<br>
>> sure) it would be at line 576 of GTtoSE110Transformer. If I try a change,<br>
>> would you have an opportunity to test? What would be the preferred approach?<br>
>><br>
>> You checkout the source code and propose the line to edit.<br>
>> I deploy a 4.0.4-SNAPSHOT version (the changes in 4.0.1 to 4.0.3 should<br>
>> not affects WFS).<br>
>><br>
>> If we get a test to work, I can deploy a 4.0.4 on<br>
>> <a href="http://maven.geotoolkit.org/" rel="noreferrer" target="_blank">http://maven.geotoolkit.org/</a> if useful.<br>
>><br>
>>     Martin<br>
>><br>
>><br>
><br>
><br>
><br>
> --<br>
> Stephane Fellah<br>
> Chief  Knowledge Scientist<br>
> Image Matters LLC<br>
> Office: +<a href="tel:%28703%29%20669%205510" value="+17036695510">(703) 669 5510</a><br>
> Cell: <a href="tel:703%20431%209420" value="+17034319420">703 431 9420</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div style="font-family:arial;font-size:small">Stephane Fellah<br></div><div style="font-family:arial;font-size:small">Chief  Knowledge Scientist</div><div style="font-family:arial;font-size:small">Image Matters LLC</div><div style="font-family:arial;font-size:small">Office: +(703) 669 5510</div><div style="font-family:arial;font-size:small">Cell: 703 431 9420</div></div></div></div></div>
</div>