Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [udig-devel] WMS-C hackery - review please? 
I've added a few additional modifications:
* some comments
* fixed up another port = -1 generated url that was missed (I updated it to use your fancy new function) 

Emily


Jody Garnett wrote:

Hi Emily:

I noticed I was unable to commit after sending that email; my commit
has gone through now.


Question - can we display them but not allow people to add them to the map?
 Sort of like services that we can't connect to.  This would allow people to
know they are there but there is some issue with them.
If not, then I guess you can hide them; it might confuse people though.  I
know I would get a little confused if I looked at the getCapabilities
document and saw it and then didn't see it in udig.


I think we can do something; maybe display them grayed out if they do
not have a "info"? The thing is we *try* and display data with no info
 usually (by assuming generic 2d and in many cases we can get away
with it).

I think the best thing is to support the google projection.


For the readCapabilities document I don't see any reason why we can't just
use service.  I think when we first wrote it I assumed that you had to strip
off all the arguments, but it seems that is an incorrect assumption.


Okay that makes sense; I did patch the code (and isolate the
processing of the URL to a single function). When you get a chance to
update you may wish to remove this ...

In the normal WMS code I do process the function; adding in
Request=GetCapabilities; Service=WMS and version if needed. I think we
need to do the same here - including adding tiled=true.  However we
also need to maintain the query parameters that were there already -
map server indicates what map file it is using that way. And geoserver
is looking to do similar things with profiles and maps in the future.


In terms of the buildBaseTileRequestFunction - I think if we just return
service.toString() we'll get duplicate 'request=' parameters and confuse the
wmsc?


Correct - but we should be using the WMS GetMap request it provided
for us (which may not have anything to do with the capabilities end
point).


- decided to hold onto the couldNoTConnect exception and rethrow
rather than parse each time

Where are you doing this?  I suspect it is fine; however I'm wondering what
happens if you have a poor internet connection and you have intermittent
connections.  I seem to recall trying to connect with one tile and getting
and error and trying again with a second tile and getting that tile.  Maybe
I don't understand what you are saying here.


Now that the code is committed I think you can review this part. My
problem ended up being that it would connect once; fail; then connect
again during the dispose method (in order to try and get members to
dispose!) and in general was very slow to fail.


- Service.dispose() was tripping up and calling members() in order to
dispose each member; if we were unable to connect - this call made the
WMSC code try and connect again!

Ok this doesn't sound good; I assume you fixed it?


I did; the fix is in the IService super class.

Jody
_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel

Back to the top