Le 24/04/2013 12:51, Rahkonen Jukka a écrit : > edgar soldin wrote: >> On 24.04.2013 11:41, Alexis "Agemen" wrote: >> >>> hi, >>> >>> The query string can basically be kept by doing a more accurate test. >>> For instance by searching for it in the input URL. If it is there, we >>> can then check for a final & and then go on. I've done that thanks to >>> Jukka comment on this, and it seems to be working. (most of the work >>> as been made on the OrbisGIS side, no change in the WMS client unless >>> the said test). >> what exactly is your rationale to add the "?". how does it make anything >> more robust? what do you need the questioonmark for, if there is no query >> string? > There is always a query string in WMS but it is normally not shown for users. > Clients tend to take the base URL and complete it silently with well-known > KVP parameters. OpenJUMP starts the discussion with WMS server as > http://base_url[?or&]SERVICE=WMS&REQUEST=GetCapabilities > If there is ? or & after the base_url depens on the base URL itself. If it > already contain ? the ending character must be &
Makes sense, indeed. If you prefer, I can move my test in an upper layer so that I don't have to change the client's code for that. The test is already written, it shouldn't be too hard :-) My rationale is the following : the input URL comes from the user, and the user makes mistakes. Particularly, supposing I understand what the client does, it seems that it will concatenate the WMS query string to the URL without checking the input URL. So it will fail. To avoid that (at least in some cases, I don't know the http URL restrictions very well...), I search for ? and & in the URL to be sure that it end by the expected one. In OrbisGIS, it's up to the user to give the URL. As we're not speaking about people that know HTTP well, most of them will forget the ending ? or &. This URL is given directly to the client, and if the ? or & is missing at the end, requests will fail. But as said, I can change things in OrbisGIS, just before making calls to the WMS client. Even if the behaviour is kept as is in the client, I think it may be documented, particularly if this part of openJUMP is taken to become a dedicated library. As explained earlier, being able to contribute directly to this library would be a real gain for us, and that would probably be easier if it was extracted of the whole openJUMP code base. >>> Considering the work made by Michaël, the axis order problem seems to >>> be less painful... I've made some tests and it seems to be working. >>> That's >> as long as the crs list is up to date and not faulty somewhere. nobody can >> guarantee that. a proper solution would need a periodically updated EPSG >> database. > I believe Michaël followed my hint and copied the list from Mapserver > sources or generated an own list from EPSG database. Yes, of course, there will always be a doubt about the reliability of such a feature. As well as there will always be a doubt about the reliability of projection library. From my point of view, projection management is definitely rocket science >>> said, we will probably stick with the highest version rather than >>> defaulting to 1.1.1. Version 1.3.0 is the current standard for WMS. >> did you read the link i sent around? >> http://dmorissette.blogspot.de/2012/12/dont-upgrade-to-wms-130-unless- >> you.html > Alexis may decide what he wants to do. We can help him and emphasize that > because of the axis order thing WMS 1.3.0 is not painless and version 1.1.1 > is more reliable. This is especially true is one starts to use WMS with > advanced SLD files which contain spatial filters because the axis order of > coordinates must be handled correctly also in the GML that is used inside > SLD. But if there is a button for selecting a desired version then it will > be OK. I did read it because I really lack perspective about the WMS specifications and about the differences between the versions. It has been really helpful, so, thanks again for having it linked here. >>> I really prefer the idea to let the user force the requested version. >>> Moreover, there is no guarantee WMS 1.1.1 is implemented on the >>> requested server. >> that's why you'd probe and choose the next best option, according to your >> list and probe again > Chapter 6.1.4 describes what was the meaning of OGC. > >>> That means that if the version is not explicitly stated in the >>> getCapabilities request (i.e. not explicitly given by the >>> user/caller), the client will try to connect to a WMS 1.3.0 *only* >>> server with the 1.1.1 protocol. I don't know how this could work. >> it obviously wont ;) > If the document above is followed it will work: > 2b) If the client request is for a version lower than any of those known to > the server, then the server shall send the lowest version it knows. > > "Hi WMS, I would prefer to use 1.1.1 - Sorry, I can only 1.3.0 - Well, let > 's try with 1.3.0 then" I totally misunderstood this part of the norm :-) For me it has two meanings : I must review what I made in the client, and I must check that the WMS Server I'm working with behaves properly :-D >>> I >>> think it's safer to query the server before. >> totally, but if you occur a server supporting both 1.3 and 1.1 , 1.1 is the >> better >> way to go as explained in the link above. > There is nothing that is better in WMS 1.3.0 but the whole version is only > about the principle of the meaning of X and Y. Next thing to happen is to > create an OGC-JSON for the same reason > http://lists.geojson.org/pipermail/geojson-geojson.org/2013-April/000706.html > > -Jukka Rahkonen- > I'll read this one too. As a side note : thanks for all these inputs. They are really valuable to me. Michaël said he was new to WMS - I'm probably even newer. All your advices and help are really nice and I really appreciate them. Thanks to you, I may be able to avoid mistakes other already made, and that's great. Regards, Alexis. ------------------------------------------------------------------------------ Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
