Hi again !

Some news from our side... I've integrated the work from Michael : it is 
far better than what I made ;-). I decided to work fast and to improve 
axis order management later. It's been made, and the code looks nice, so 
I basically replaced what I had before with that. It has been funny to 
see that you've introduced methods I created too, with the same name and 
goal ^_^ The changes you've made in the API make it really clear and 
easy to use : thanks for that too :-)

I've changed some things related to the default wms version we find : I 
really prefer to keep the highest one if nothing is given from the user. 
I've made some changes in WMService so that it can work. I've tried to 
retrieve the getCapabilities document only once for performance purpose. 
I've split the initialize method in three, consequently. Another minor 
change is that I add a "?" at the end of the input URL in order to be 
more resistant to user input :-)

I've not removed all the references to AWT/Swing yet. I may do it, 
according to the answer to the following question : Would it be possible 
to isolate the WMS client from openJUMP in a dedicated library ? I think 
it's working quite well and other people maybe interested in it. 
Moreover, it would ease the potential work from people like me that 
probably won't code directly in openJUMP but who would contribute more 
easily in a separated library.

I still have to change some things in our UI so that the user may force 
the WMS version. Shouldn't be too hard ^_^

Thanks for the good work, again. You may find my work on 
https://github.com/agueganno/orbisgis by selecting the fix-wms-driver 
branch. The last commit on this branch is the interesting one.

Regards,

Alexis.

Le 20/04/2013 23:03, Rahkonen Jukka a écrit :
> Hi,
>
> The WMS version negotiation is described by the OGC and you can read it for 
> example from here 
> http://cite.opengeospatial.org/OGCTestData/wms/1.1.1/spec/wms1.1.1.html#basic_elements.version.negotiation
>
> You did the right thing by doing GetCapabilities without &VERSION=x.x.x. 
> Please be kind for your users and give them a possibility to override the 
> automatically detected highest version and select some other version manually.
>
> -Jukka Rahkonen-
>
>
>   Alexis "Agemen" wrote:
>
>> Hi everybody !
>> I'm Alexis Guéganno and currently am part of the OrbisGIS development
> team. First message on this list, I hope I'll do the things right.
>
>> We've been stuck recently in OrbisGIS with our WMS client
> implementation. It was made of legacy code that was pretty
> unefficient... So we've searched for a solution. As one of my teammates
> knew the openJUMP code base, having been a contributor here, he advised
> me to have a look in the openJUMP client. After some readings in it, I
> decided to give it a try and had to solve the following issues :
>
>> - extract the code from openJUMP and put it in the OrbisGIS code base
>> - Add support for WMS 1.3.0
>> - Fix OrbisGIS to use the library from openJUMP.
>> I made the first operation in two steps. I first put the code directly
> in ours... and then realize that it was not practical for me or for
> other developers. I decided to put it in a dedicated maven project so
> that it can be used with more ease. It has been quite easy has the code
> is already well isolated in openJUMP and as you don't have exotic
> dependencies on it.
>
>> The second and third steps have been a bit more difficult. I've had some
> problems with bounding box and crs management that I've tried to solve.
> Fortunately, as WMS 1.1.1 is already ready, I've been able to use it to
> build the WMS 1.3.0 support. It seems to be working with most servers
> now. The ones I'm having problems with seem to be buggy, so the problems
> I have seem not to come from the client...
>
>> A huge modification I've made is linked to the recognition of the server
> version. It had to be asked explicitly by the caller until now, but I
> did not find a way to check the uppest supported version from the
> server... What I do is that I perform a
>
>> ?SERVICE=WMS&REQUEST=GetCapabilities
>> request, that shall give me some capabilities document, and I try to
> recognize the version from it. The client assumed the server to be 1.0.0
>
>> I've tried not to change the code base much. In some places, however,
> I've sometimes removed comments or done some other minor
> modifications... I've removed some call to swing/awt APIs as I didn't
> want to face AWT exceptions while performing batch processing.
>
>> The API is still the same, though. I've added a method in MapLayer to
> retrieve the BoundingBox associated to a given SRS/CRS, if any, but I
> think that's all. And WMS 1.3.0, but I already said that :-p
>
>> There are still some things to do. 1.3.0 support is not perfect, as we
> don't process completely the GetMap part of the GetCapabilities answer.
> Consequently, if the HTTP GET URI in the GetMap part of the answer is
> not the same one that is used to make the GetMap query, we may face
> unexpected behaivour.... Moreover, when processing XML documents, we do
> not take the XML namespace definition in account so some tags and
> attributes won't be recognized in some cases...
>
>> You can find the code I've written on Github. It' has been merged today
> in OrbisGIS master on https://github.com/irstv/orbisgis
> You'll find the code I've changed under the "wms-client" maven
> subproject. It should be quite easy to port back in openJUMP, I would be
> really happy if this could happen. I've decided not to change package
> names so that my work stays compatible with what you've made in openJUMP.
>
>>    If you think I've made mistakes that must be solved before merging,
> let me know here, I'll try to do them as soon as possible (hopefully
> some day in the next 12 monthes, so :-p)
>
>> And as a conclusion : thanks for the original code. I found it clear and
> easy to read and understand, I hope it didn't loose any clarity because
> of me.
>
> Best wishes,
>
> Alexis Guéganno
>
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Precog is a next-generation analytics platform capable of advanced
> analytics on semi-structured data. The platform includes APIs for building
> apps and a phenomenal toolset for data science. Developers can use
> our toolset for easy data analysis & visualization. Get a free account!
> http://www2.precog.com/precogplatform/slashdotnewsletter
> _______________________________________________
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
> ------------------------------------------------------------------------------
> Precog is a next-generation analytics platform capable of advanced
> analytics on semi-structured data. The platform includes APIs for building
> apps and a phenomenal toolset for data science. Developers can use
> our toolset for easy data analysis & visualization. Get a free account!
> http://www2.precog.com/precogplatform/slashdotnewsletter
> _______________________________________________
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel


------------------------------------------------------------------------------
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
_______________________________________________
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Reply via email to