Menu
▾
▴
gwt-openlayers-devl — Developer list. Fairly active.
You can subscribe to this list here.
| 2009 |
Jan
|
Feb
(3) |
Mar
(51) |
Apr
(8) |
May
(8) |
Jun
|
Jul
(3) |
Aug
(8) |
Sep
(6) |
Oct
(1) |
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2010 |
Jan
(1) |
Feb
(21) |
Mar
(13) |
Apr
(8) |
May
(4) |
Jun
(3) |
Jul
(2) |
Aug
(11) |
Sep
(10) |
Oct
(1) |
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
(6) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(4) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Edwin C. <com...@gm...> - 2010-03-15 14:04:58
|
Hi Poul, I checked and it seems it are not the options where it goes wrong in the BasicWFS example. When I post the WFS query generated by the wfsExample layer with Poster (a Firefox add-on) then I get back a WFS FeatureCollection, but when the WFS query goes through the gwtOpenLayersProxy I get an error message: <ows:Exception exceptionCode="MissingParameterValue" locator="request"> <ows:ExceptionText>Could not determine geoserver request from http request POST /geoserver/wfs HTTP/1.1 (...) </ows:ExceptionText> Sth seems go wrong with proxying the request. Do you use the gwtOpenLayersProxy, the OL Python proxy, or some other proxy? Are all the options you specify necessary? It seems that you are passing the default geometryName and srsName, only a non-default WFS version. The schema location is optional and in the OL example the schema location is not used. Maybe only specifying the non-default WFS version is enough for you. Greetings, Edwin On 15 March 2010 14:17, paweluz <pa...@tl...> wrote: > Let me now if it helps :) > I am curies do you also get an error while using WFS and VECTOR layer like this: > > uncaught exception: [Exception... "Component returned failure code: 0xc1f30001 (NS_ERROR_NOT_INITIALIZED) [nsIXMLHttpRequest.send]" nsresult: "0xc1f30001 (NS_ERROR_NOT_INITIALIZED)" location: "JS frame :: http://openlayers.org/api/2.8/OpenLayers.js :: anonymous :: line 1081" data: no] > > or is this only in my case... > > Please let me know... > Poul > > > > Dnia 15 marca 2010 13:47 Edwin Commandeur <com...@gm...> napisał(a): > >> Hi Poul, >> >> Thanks! I had come to the point where I could see the WFS request >> being made, but got an error message from geoserver that I needed to >> look into to get the BasicWFS working. I will look at your changes and >> addn additional setters to WFSProtocol. >> >> Greetings, >> Edwin >> >> >> On 15 March 2010 13:03, paweluz <pa...@tl...> wrote: >> > Hi Edwin! >> > >> > I have seen your newest changes on GWT in >> > >> > http://gwt-openlayers.hg.sourceforge.net/hgweb/gwt-openlayers/gwt-openlayers/rev/17787e046d5e >> > >> > I have to say it does not work form me. I have to add some additional information to finally see the vector layer on the map... >> > >> > My Vector Layer definition looks like this: >> > >> > private void createVectorLayer(){ >> > WFSProtocolOptions wfsProtocolOptions = new WFSProtocolOptions(); >> > wfsProtocolOptions.setUrl("http://localhost:8080/geoserver/wfs"); >> > wfsProtocolOptions.setFeatureType("tasmania_roads"); >> > wfsProtocolOptions.setFeatureNameSpace("http://www.openplans.org/topp"); >> > >> > wfsProtocolOptions.getJSObject().setProperty("srsName", "EPSG:4326"); >> > wfsProtocolOptions.getJSObject().setProperty("version", "1.1.0"); >> > wfsProtocolOptions.getJSObject().setProperty("geometryName", "the_geom"); >> > wfsProtocolOptions.getJSObject().setProperty("schema", "http://localhost:8080/geoserver/wfs/DescribeFeatureType?version=1.1.0&typename=topp:tasmania_roads"); >> > >> > WFSProtocol wfsProtocol = new WFSProtocol(wfsProtocolOptions); >> > String url = wfsProtocol.getUrl(); >> > url.length(); >> > VectorOptions vectorOptions = new VectorOptions(); >> > vectorOptions.getJSObject().setProperty("protocol", wfsProtocol.getJSObject()); >> > vectorOptions.setProtocol(wfsProtocol); >> > vectorOptions.setStrategies(new Strategy[]{new BBoxStrategy()}); >> > vectorLayer = new Vector("My Vector Layer", vectorOptions); >> > }} >> > >> > I do not know if you can see your Vector layer. If not try my approach... Hope I helped... >> > >> > Cheers and thanks for developing GWT-OL :) >> > Poul, >> > >> > >> > |
|
From: Edwin C. <com...@gm...> - 2010-03-15 12:47:49
|
Hi Poul, Thanks! I had come to the point where I could see the WFS request being made, but got an error message from geoserver that I needed to look into to get the BasicWFS working. I will look at your changes and addn additional setters to WFSProtocol. Greetings, Edwin On 15 March 2010 13:03, paweluz <pa...@tl...> wrote: > Hi Edwin! > > I have seen your newest changes on GWT in > > http://gwt-openlayers.hg.sourceforge.net/hgweb/gwt-openlayers/gwt-openlayers/rev/17787e046d5e > > I have to say it does not work form me. I have to add some additional information to finally see the vector layer on the map... > > My Vector Layer definition looks like this: > > private void createVectorLayer(){ > WFSProtocolOptions wfsProtocolOptions = new WFSProtocolOptions(); > wfsProtocolOptions.setUrl("http://localhost:8080/geoserver/wfs"); > wfsProtocolOptions.setFeatureType("tasmania_roads"); > wfsProtocolOptions.setFeatureNameSpace("http://www.openplans.org/topp"); > > wfsProtocolOptions.getJSObject().setProperty("srsName", "EPSG:4326"); > wfsProtocolOptions.getJSObject().setProperty("version", "1.1.0"); > wfsProtocolOptions.getJSObject().setProperty("geometryName", "the_geom"); > wfsProtocolOptions.getJSObject().setProperty("schema", "http://localhost:8080/geoserver/wfs/DescribeFeatureType?version=1.1.0&typename=topp:tasmania_roads"); > > WFSProtocol wfsProtocol = new WFSProtocol(wfsProtocolOptions); > String url = wfsProtocol.getUrl(); > url.length(); > VectorOptions vectorOptions = new VectorOptions(); > vectorOptions.getJSObject().setProperty("protocol", wfsProtocol.getJSObject()); > vectorOptions.setProtocol(wfsProtocol); > vectorOptions.setStrategies(new Strategy[]{new BBoxStrategy()}); > vectorLayer = new Vector("My Vector Layer", vectorOptions); > }} > > I do not know if you can see your Vector layer. If not try my approach... Hope I helped... > > Cheers and thanks for developing GWT-OL :) > Poul, > > |
|
From: Edwin C. <com...@gm...> - 2010-03-10 20:14:28
|
Hi Mikael,
The gwt_openlayers_util.relay.createPolygon function is used to work
around the issue that some OpenLayers functions/constructors check
whether an argument is truly a javascript array using instanceof (var
a = []; a instanceof Array). There are some other relay functions as
well, see below.
Unfortunately, an Array created using GWT, even if created using JSNI,
does not pass this instanceof test (a javascript construct).
If you create an array with JSNI then GWT somehow makes an Object out
of it. Possibly in order to emulate Java client side.
JavaScriptObject javascriptObject = JavaScriptObject.createArray();
where the createArray method is implemented as a JSNI function going
sth like this:
public static native JavaScriptObject createArray()/*-{
return [];
}-*/;
You will find the relay utility functions in 'util.js', which is
distributed with GWT-OL
src/main/java/org/gwtopenmaps/openlayers/public/js/gwt-openlayers/util.js
Greetings,
Edwin
On 10 March 2010 15:32, Mikael Couzic <mik...@cl...> wrote:
> Hi all,
>
>
> I was creating a MultiPolygon class in the geometry package, and to get some
> inspiration I was looking at the Polygon and PolygonImpl classes. In the
> PolygonImpl.create(rings) method, I expected to see something like :
> create(JSObject rings)/*-{
> return new wnd.OpenLayers.Geometry.Polygon(rings);
> }-*/;
>
> However, here's what I found :
> create(JSObject rings)/*-{
> return new $wnd.gwt_openlayers_util.relay.createPolygon(rings);
> }-*/;
>
> My problem is that I have absolutely no idea how this works, and I don't
> know where and what to look for. I'm still going to try and wrap the
> MultiPolygon, but I suspect I'm not going to succed until I resolve this
> mystery.
>
> Do you guys have any advice ?
>
>
> --
> Mikael Couzic
> Pôle Business Intelligence
> Groupe Cliris
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Gwt-openlayers-devl mailing list
> Gwt...@li...
> https://lists.sourceforge.net/lists/listinfo/gwt-openlayers-devl
>
>
|
|
From: Mikael C. <mik...@cl...> - 2010-03-10 16:07:53
|
Nevermind, I found it
2010/3/10 Mikael Couzic <mik...@cl...>
> Hi all,
>
>
> I was creating a MultiPolygon class in the geometry package, and to get
> some inspiration I was looking at the Polygon and PolygonImpl classes. In
> the PolygonImpl.create(rings) method, I expected to see something like :
> create(JSObject rings)/*-{
> return new wnd.OpenLayers.Geometry.Polygon(rings);
> }-*/;
>
> However, here's what I found :
> create(JSObject rings)/*-{
> return new $wnd.gwt_openlayers_util.relay.createPolygon(rings);
> }-*/;
>
> My problem is that I have absolutely no idea how this works, and I don't
> know where and what to look for. I'm still going to try and wrap the
> MultiPolygon, but I suspect I'm not going to succed until I resolve this
> mystery.
>
> Do you guys have any advice ?
>
>
> --
> Mikael Couzic
> Pôle Business Intelligence
> Groupe Cliris
>
--
Mikael Couzic
Pôle Business Intelligence
Groupe Cliris
|
|
From: Mikael C. <mik...@cl...> - 2010-03-10 14:55:04
|
Hi all,
I was creating a MultiPolygon class in the geometry package, and to get some
inspiration I was looking at the Polygon and PolygonImpl classes. In the
PolygonImpl.create(rings) method, I expected to see something like :
create(JSObject rings)/*-{
return new wnd.OpenLayers.Geometry.Polygon(rings);
}-*/;
However, here's what I found :
create(JSObject rings)/*-{
return new $wnd.gwt_openlayers_util.relay.createPolygon(rings);
}-*/;
My problem is that I have absolutely no idea how this works, and I don't
know where and what to look for. I'm still going to try and wrap the
MultiPolygon, but I suspect I'm not going to succed until I resolve this
mystery.
Do you guys have any advice ?
--
Mikael Couzic
Pôle Business Intelligence
Groupe Cliris
|
|
From: Edwin C. <com...@gm...> - 2010-03-02 21:00:22
|
Hi Dave, I will be off radar for a while, since my wife gave birth to a wonderful daugther two days ago. http://www.headspingames.com/bente/familieportret.jpg I thought redraw was a property of HttpRequestLayer and it's subclasses. It was on Layer before for convenience (I thought) and maybe we should put it there. Sounds ok. Greetings, Edwin On 1 March 2010 23:46, Dave Koberstein <da...@ko...> wrote: > Hi Edwin, > > I haven't pushed this commit out yet as I'd like to check with you first. > > Layer.redraw is supported on all layers so I added a redraw method in class > Layer. Also, this method has a return boolean of redrawn so adding that to > LayerImpl required changing the return type of HTTPRequestLayer.redrawn from > void to boolean. If anyone is using this it could create a problem with the > signature change. > > Most of the layer subclasses don't support an argument of force. So I > implemented the Layer.redraw with no argument and then passed through true > to LayerImpl.redraw so that we wouldn't need to change or add a method to > LayerImpl. > > Does that sound ok? > > Davek > |
|
From: Dave K. <da...@ko...> - 2010-02-25 21:27:26
|
I see. As long as we are consistent, sounds reasonable. From a java perspective it might be more intuitive to put the getters in the options - with the setters. I presume the life of the options object would be as long as the parent object since it is passed in via the constructor. In either case, the most important thing is to do it consistently. On 2/25/2010 12:49 PM, Edwin Commandeur wrote: > Hi Dave, > > Sorry about the confusion. The setGeometryName should definitively be > on WFSProtocolOptions, just as setUrl, setFeatureType, > setFeaturePrefix, and setFeatureNS. Those seem to be all: > > http://dev.openlayers.org/releases/OpenLayers-2.8/doc/apidocs/files/OpenLayers/Protocol/WFS/v1-js.html > > My point was just that the properties of the Options are copied to the > Object taking the options, so that Object taking the properties should > have the getters. The Options are just a way to pass a lot of > arguments in one go at construction that's why they only have setters. > > Greetings, > Edwin > > > On 24 February 2010 19:41, Dave Koberstein<da...@ko...> wrote: > >> Hi Edwin, >> >> Let's separate the getter comment I made from where the setter should go. >> Perhaps a getter isn't appropriate. >> >> In terms of the setGeometryName being in WFSProtocolOptions, that's the same >> place that featureType, featureNS, etc are. So I believe that >> setGeometryName belongs there. I don't think this was your point but if it >> was please let me know why you don't believe geometryName goes there. >> >> In terms of a getter, I guess my thinking is simply that every setter should >> have a getter. What if you want to know what the current geometryName is? >> You should be able to call getGeometryName. Wouldn't the getter go in the >> same class as the setter? >> >> Davek >> >> On 2/24/2010 8:19 AM, Edwin Commandeur wrote: >> >>> Hi Dave, >>> >>> Why have a getGeometryName on the Options object? The Options objects >>> typically only have setters, since they are a configuration mechanism. >>> By passing the options (or config) objects to a constructor (or static >>> factory method) the properties are transferred to the object taking >>> the options. That object's properties may be relevant within the >>> application. >>> >>> Greetings, >>> Edwin >>> >>> On 24 February 2010 16:59, Dave Koberstein<da...@ko...> wrote: >>> >>> >>>> Hmmm... No, I think it should be in options. I may have mistyped. >>>> >>>> On 2/24/2010 12:49 AM, Edwin Commandeur wrote: >>>> >>>> Hi Dave, >>>> >>>> Just to get this correct: the getGeometryName should be a method on >>>> WFSProtocol, and not on WFSProtocolOptions, isn't it? >>>> >>>> I haven't used the GetFeature. Currently, I am not on any GWT >>>> projects, so I work on GWT-OL out of pure interest and to keep >>>> up-to-date with developments in GWT. >>>> >>>> Greetings, >>>> Edwin >>>> >>>> >>>> On 23 February 2010 22:51, Dave Koberstein<da...@ko...> wrote: >>>> >>>> >>>> Oh definitely - please do. Would you mind adding a getter for >>>> geometryName? >>>> That will save on hg conflicts. >>>> >>>> I don't know if you plan to use the GetFeature control. Are you using >>>> geoserver? I wonder if you've come across this annoyance. If you make a >>>> layer group in geoserver of two vector layers, it does not let you make >>>> WFS >>>> feature requests on that layer group. You have to request from the >>>> individual layers. If makes sense if the vector layers are different >>>> types >>>> of data classes. But if they are the same, it would be nice if it didn't >>>> impose that limitation. >>>> >>>> The constructor approach for WFSProtocol supports this (doesn't matter >>>> which >>>> layer your use in the constructor) however now the browser code needs to >>>> know what layers the layer group is made of. I hate constants and >>>> configuration values. :) >>>> >>>> Davek >>>> >>>> On 2/23/2010 1:36 PM, Edwin Commandeur wrote: >>>> >>>> Hi Dave, >>>> >>>> Thanks for your explanation. >>>> >>>> The constructor approach is fine! Smart indeed to use to fromWMSLayer >>>> to save coding. >>>> >>>> If you're okay with that I will expand the WFSProtocolOptions with >>>> more setters (setURL, setFeatureType, setFeatureNS etc). >>>> >>>> Greetings, >>>> Edwin >>>> >>>> On 23 February 2010 22:09, Dave Koberstein<da...@ko...> wrote: >>>> >>>> >>>> Hi Edwin, >>>> >>>> I totally relied on openlayers Protocol.WFS.fromWMSLayer constructor. >>>> It's >>>> a convenience method where if your GetFeature control is attached to a >>>> WMS >>>> layer and WFS exists at the same service as WMS, then it just builds up a >>>> protocol for you automatically. It maps very nicely into the typical >>>> geosever implementation and saves a ton of coding. >>>> >>>> I did the implementation right in the constructor since a separate method >>>> of >>>> the somewhat-obscure name seemed less useful. There's a WFSProtocol >>>> constructor (the second one) that takes a WMS layer as well as an options >>>> object. That calls a WFSProtocolImpl.create that takes the Layer.WMS >>>> object >>>> and the options object and does the construction with the javascript >>>> fromWMSLayer. >>>> >>>> I know this deviates from your approach of 1-1 mapping. My thinking was >>>> to >>>> use Java's polymorphism on the constructor to make it simpler to >>>> understand >>>> - pass in your layer at construction time. >>>> >>>> Anyway back to why only setGeometryName. fromWMSLayer uses some default >>>> geometry name (not from the layer) that doesn't match with geoserver (or >>>> maybe our team's use of geoserver - I'm not sure). After construction >>>> any >>>> of the protocol parameters can be overridden and I needed this one. I >>>> didn't go through and add all the others as I wasn't in a position to >>>> confirm any of it worked. Now that I look at it, I should have added the >>>> getter. I'll plan to do that. >>>> >>>> If you'd prefer the more 1-1 approach we can adjust it. If you don't >>>> mind >>>> I'd like to keep this constructor implementation, though. Also I can add >>>> more setters and getters WFSProtocolOptions with the caveat that I may >>>> not >>>> be able to thoroughly test. >>>> >>>> Davek >>>> >>>> On 2/23/2010 12:42 PM, Edwin Commandeur wrote: >>>> >>>> Hi Dave, >>>> >>>> When looking at the WFSProtocolOptions I was expecting to see methods >>>> for setting a Url etc, but it only had a method to setGeometryName >>>> method. >>>> >>>> Am I missing something? Is this an old version of WFSProtocolOptions, >>>> or do you set properties on the options object via JSObject? >>>> >>>> Greetings, >>>> Edwin >>>> >>>> >>>> >> >> |
|
From: Edwin C. <com...@gm...> - 2010-02-25 20:57:37
|
Hi Dave, Sorry about the confusion. The setGeometryName should definitively be on WFSProtocolOptions, just as setUrl, setFeatureType, setFeaturePrefix, and setFeatureNS. Those seem to be all: http://dev.openlayers.org/releases/OpenLayers-2.8/doc/apidocs/files/OpenLayers/Protocol/WFS/v1-js.html My point was just that the properties of the Options are copied to the Object taking the options, so that Object taking the properties should have the getters. The Options are just a way to pass a lot of arguments in one go at construction that's why they only have setters. Greetings, Edwin On 24 February 2010 19:41, Dave Koberstein <da...@ko...> wrote: > Hi Edwin, > > Let's separate the getter comment I made from where the setter should go. > Perhaps a getter isn't appropriate. > > In terms of the setGeometryName being in WFSProtocolOptions, that's the same > place that featureType, featureNS, etc are. So I believe that > setGeometryName belongs there. I don't think this was your point but if it > was please let me know why you don't believe geometryName goes there. > > In terms of a getter, I guess my thinking is simply that every setter should > have a getter. What if you want to know what the current geometryName is? > You should be able to call getGeometryName. Wouldn't the getter go in the > same class as the setter? > > Davek > > On 2/24/2010 8:19 AM, Edwin Commandeur wrote: >> >> Hi Dave, >> >> Why have a getGeometryName on the Options object? The Options objects >> typically only have setters, since they are a configuration mechanism. >> By passing the options (or config) objects to a constructor (or static >> factory method) the properties are transferred to the object taking >> the options. That object's properties may be relevant within the >> application. >> >> Greetings, >> Edwin >> >> On 24 February 2010 16:59, Dave Koberstein<da...@ko...> wrote: >> >>> >>> Hmmm... No, I think it should be in options. I may have mistyped. >>> >>> On 2/24/2010 12:49 AM, Edwin Commandeur wrote: >>> >>> Hi Dave, >>> >>> Just to get this correct: the getGeometryName should be a method on >>> WFSProtocol, and not on WFSProtocolOptions, isn't it? >>> >>> I haven't used the GetFeature. Currently, I am not on any GWT >>> projects, so I work on GWT-OL out of pure interest and to keep >>> up-to-date with developments in GWT. >>> >>> Greetings, >>> Edwin >>> >>> >>> On 23 February 2010 22:51, Dave Koberstein<da...@ko...> wrote: >>> >>> >>> Oh definitely - please do. Would you mind adding a getter for >>> geometryName? >>> That will save on hg conflicts. >>> >>> I don't know if you plan to use the GetFeature control. Are you using >>> geoserver? I wonder if you've come across this annoyance. If you make a >>> layer group in geoserver of two vector layers, it does not let you make >>> WFS >>> feature requests on that layer group. You have to request from the >>> individual layers. If makes sense if the vector layers are different >>> types >>> of data classes. But if they are the same, it would be nice if it didn't >>> impose that limitation. >>> >>> The constructor approach for WFSProtocol supports this (doesn't matter >>> which >>> layer your use in the constructor) however now the browser code needs to >>> know what layers the layer group is made of. I hate constants and >>> configuration values. :) >>> >>> Davek >>> >>> On 2/23/2010 1:36 PM, Edwin Commandeur wrote: >>> >>> Hi Dave, >>> >>> Thanks for your explanation. >>> >>> The constructor approach is fine! Smart indeed to use to fromWMSLayer >>> to save coding. >>> >>> If you're okay with that I will expand the WFSProtocolOptions with >>> more setters (setURL, setFeatureType, setFeatureNS etc). >>> >>> Greetings, >>> Edwin >>> >>> On 23 February 2010 22:09, Dave Koberstein<da...@ko...> wrote: >>> >>> >>> Hi Edwin, >>> >>> I totally relied on openlayers Protocol.WFS.fromWMSLayer constructor. >>> It's >>> a convenience method where if your GetFeature control is attached to a >>> WMS >>> layer and WFS exists at the same service as WMS, then it just builds up a >>> protocol for you automatically. It maps very nicely into the typical >>> geosever implementation and saves a ton of coding. >>> >>> I did the implementation right in the constructor since a separate method >>> of >>> the somewhat-obscure name seemed less useful. There's a WFSProtocol >>> constructor (the second one) that takes a WMS layer as well as an options >>> object. That calls a WFSProtocolImpl.create that takes the Layer.WMS >>> object >>> and the options object and does the construction with the javascript >>> fromWMSLayer. >>> >>> I know this deviates from your approach of 1-1 mapping. My thinking was >>> to >>> use Java's polymorphism on the constructor to make it simpler to >>> understand >>> - pass in your layer at construction time. >>> >>> Anyway back to why only setGeometryName. fromWMSLayer uses some default >>> geometry name (not from the layer) that doesn't match with geoserver (or >>> maybe our team's use of geoserver - I'm not sure). After construction >>> any >>> of the protocol parameters can be overridden and I needed this one. I >>> didn't go through and add all the others as I wasn't in a position to >>> confirm any of it worked. Now that I look at it, I should have added the >>> getter. I'll plan to do that. >>> >>> If you'd prefer the more 1-1 approach we can adjust it. If you don't >>> mind >>> I'd like to keep this constructor implementation, though. Also I can add >>> more setters and getters WFSProtocolOptions with the caveat that I may >>> not >>> be able to thoroughly test. >>> >>> Davek >>> >>> On 2/23/2010 12:42 PM, Edwin Commandeur wrote: >>> >>> Hi Dave, >>> >>> When looking at the WFSProtocolOptions I was expecting to see methods >>> for setting a Url etc, but it only had a method to setGeometryName >>> method. >>> >>> Am I missing something? Is this an old version of WFSProtocolOptions, >>> or do you set properties on the options object via JSObject? >>> >>> Greetings, >>> Edwin >>> >>> > > |
|
From: Edwin C. <com...@gm...> - 2010-02-24 16:20:00
|
Hi Dave, Why have a getGeometryName on the Options object? The Options objects typically only have setters, since they are a configuration mechanism. By passing the options (or config) objects to a constructor (or static factory method) the properties are transferred to the object taking the options. That object's properties may be relevant within the application. Greetings, Edwin On 24 February 2010 16:59, Dave Koberstein <da...@ko...> wrote: > Hmmm... No, I think it should be in options. I may have mistyped. > > On 2/24/2010 12:49 AM, Edwin Commandeur wrote: > > Hi Dave, > > Just to get this correct: the getGeometryName should be a method on > WFSProtocol, and not on WFSProtocolOptions, isn't it? > > I haven't used the GetFeature. Currently, I am not on any GWT > projects, so I work on GWT-OL out of pure interest and to keep > up-to-date with developments in GWT. > > Greetings, > Edwin > > > On 23 February 2010 22:51, Dave Koberstein <da...@ko...> wrote: > > > Oh definitely - please do. Would you mind adding a getter for geometryName? > That will save on hg conflicts. > > I don't know if you plan to use the GetFeature control. Are you using > geoserver? I wonder if you've come across this annoyance. If you make a > layer group in geoserver of two vector layers, it does not let you make WFS > feature requests on that layer group. You have to request from the > individual layers. If makes sense if the vector layers are different types > of data classes. But if they are the same, it would be nice if it didn't > impose that limitation. > > The constructor approach for WFSProtocol supports this (doesn't matter which > layer your use in the constructor) however now the browser code needs to > know what layers the layer group is made of. I hate constants and > configuration values. :) > > Davek > > On 2/23/2010 1:36 PM, Edwin Commandeur wrote: > > Hi Dave, > > Thanks for your explanation. > > The constructor approach is fine! Smart indeed to use to fromWMSLayer > to save coding. > > If you're okay with that I will expand the WFSProtocolOptions with > more setters (setURL, setFeatureType, setFeatureNS etc). > > Greetings, > Edwin > > On 23 February 2010 22:09, Dave Koberstein <da...@ko...> wrote: > > > Hi Edwin, > > I totally relied on openlayers Protocol.WFS.fromWMSLayer constructor. It's > a convenience method where if your GetFeature control is attached to a WMS > layer and WFS exists at the same service as WMS, then it just builds up a > protocol for you automatically. It maps very nicely into the typical > geosever implementation and saves a ton of coding. > > I did the implementation right in the constructor since a separate method of > the somewhat-obscure name seemed less useful. There's a WFSProtocol > constructor (the second one) that takes a WMS layer as well as an options > object. That calls a WFSProtocolImpl.create that takes the Layer.WMS object > and the options object and does the construction with the javascript > fromWMSLayer. > > I know this deviates from your approach of 1-1 mapping. My thinking was to > use Java's polymorphism on the constructor to make it simpler to understand > - pass in your layer at construction time. > > Anyway back to why only setGeometryName. fromWMSLayer uses some default > geometry name (not from the layer) that doesn't match with geoserver (or > maybe our team's use of geoserver - I'm not sure). After construction any > of the protocol parameters can be overridden and I needed this one. I > didn't go through and add all the others as I wasn't in a position to > confirm any of it worked. Now that I look at it, I should have added the > getter. I'll plan to do that. > > If you'd prefer the more 1-1 approach we can adjust it. If you don't mind > I'd like to keep this constructor implementation, though. Also I can add > more setters and getters WFSProtocolOptions with the caveat that I may not > be able to thoroughly test. > > Davek > > On 2/23/2010 12:42 PM, Edwin Commandeur wrote: > > Hi Dave, > > When looking at the WFSProtocolOptions I was expecting to see methods > for setting a Url etc, but it only had a method to setGeometryName > method. > > Am I missing something? Is this an old version of WFSProtocolOptions, > or do you set properties on the options object via JSObject? > > Greetings, > Edwin > > > -- > ________________________________ > Dave Koberstein > Experienced head of open source technologies, > VP of Product Line Management, Customer Engineering Services > email: > phone: > da...@ko... > +1-650-575-3853 > > > -- > ________________________________ > Dave Koberstein > Experienced head of open source technologies, > VP of Product Line Management, Customer Engineering Services > email: > phone: > da...@ko... > +1-650-575-3853 > > > -- > ________________________________ > Dave Koberstein > Experienced head of open source technologies, > VP of Product Line Management, Customer Engineering Services > email: > phone: > da...@ko... > +1-650-575-3853 |
|
From: Edwin C. <com...@gm...> - 2010-02-24 08:49:51
|
Hi Dave, Just to get this correct: the getGeometryName should be a method on WFSProtocol, and not on WFSProtocolOptions, isn't it? I haven't used the GetFeature. Currently, I am not on any GWT projects, so I work on GWT-OL out of pure interest and to keep up-to-date with developments in GWT. Greetings, Edwin On 23 February 2010 22:51, Dave Koberstein <da...@ko...> wrote: > Oh definitely - please do. Would you mind adding a getter for geometryName? > That will save on hg conflicts. > > I don't know if you plan to use the GetFeature control. Are you using > geoserver? I wonder if you've come across this annoyance. If you make a > layer group in geoserver of two vector layers, it does not let you make WFS > feature requests on that layer group. You have to request from the > individual layers. If makes sense if the vector layers are different types > of data classes. But if they are the same, it would be nice if it didn't > impose that limitation. > > The constructor approach for WFSProtocol supports this (doesn't matter which > layer your use in the constructor) however now the browser code needs to > know what layers the layer group is made of. I hate constants and > configuration values. :) > > Davek > > On 2/23/2010 1:36 PM, Edwin Commandeur wrote: > > Hi Dave, > > Thanks for your explanation. > > The constructor approach is fine! Smart indeed to use to fromWMSLayer > to save coding. > > If you're okay with that I will expand the WFSProtocolOptions with > more setters (setURL, setFeatureType, setFeatureNS etc). > > Greetings, > Edwin > > On 23 February 2010 22:09, Dave Koberstein <da...@ko...> wrote: > > > Hi Edwin, > > I totally relied on openlayers Protocol.WFS.fromWMSLayer constructor. It's > a convenience method where if your GetFeature control is attached to a WMS > layer and WFS exists at the same service as WMS, then it just builds up a > protocol for you automatically. It maps very nicely into the typical > geosever implementation and saves a ton of coding. > > I did the implementation right in the constructor since a separate method of > the somewhat-obscure name seemed less useful. There's a WFSProtocol > constructor (the second one) that takes a WMS layer as well as an options > object. That calls a WFSProtocolImpl.create that takes the Layer.WMS object > and the options object and does the construction with the javascript > fromWMSLayer. > > I know this deviates from your approach of 1-1 mapping. My thinking was to > use Java's polymorphism on the constructor to make it simpler to understand > - pass in your layer at construction time. > > Anyway back to why only setGeometryName. fromWMSLayer uses some default > geometry name (not from the layer) that doesn't match with geoserver (or > maybe our team's use of geoserver - I'm not sure). After construction any > of the protocol parameters can be overridden and I needed this one. I > didn't go through and add all the others as I wasn't in a position to > confirm any of it worked. Now that I look at it, I should have added the > getter. I'll plan to do that. > > If you'd prefer the more 1-1 approach we can adjust it. If you don't mind > I'd like to keep this constructor implementation, though. Also I can add > more setters and getters WFSProtocolOptions with the caveat that I may not > be able to thoroughly test. > > Davek > > On 2/23/2010 12:42 PM, Edwin Commandeur wrote: > > Hi Dave, > > When looking at the WFSProtocolOptions I was expecting to see methods > for setting a Url etc, but it only had a method to setGeometryName > method. > > Am I missing something? Is this an old version of WFSProtocolOptions, > or do you set properties on the options object via JSObject? > > Greetings, > Edwin > > > -- > ________________________________ > Dave Koberstein > Experienced head of open source technologies, > VP of Product Line Management, Customer Engineering Services > email: > phone: > da...@ko... > +1-650-575-3853 > > > -- > ________________________________ > Dave Koberstein > Experienced head of open source technologies, > VP of Product Line Management, Customer Engineering Services > email: > phone: > da...@ko... > +1-650-575-3853 |
|
From: Edwin C. <com...@gm...> - 2010-02-23 21:36:44
|
Hi Dave, Thanks for your explanation. The constructor approach is fine! Smart indeed to use to fromWMSLayer to save coding. If you're okay with that I will expand the WFSProtocolOptions with more setters (setURL, setFeatureType, setFeatureNS etc). Greetings, Edwin On 23 February 2010 22:09, Dave Koberstein <da...@ko...> wrote: > Hi Edwin, > > I totally relied on openlayers Protocol.WFS.fromWMSLayer constructor. It's > a convenience method where if your GetFeature control is attached to a WMS > layer and WFS exists at the same service as WMS, then it just builds up a > protocol for you automatically. It maps very nicely into the typical > geosever implementation and saves a ton of coding. > > I did the implementation right in the constructor since a separate method of > the somewhat-obscure name seemed less useful. There's a WFSProtocol > constructor (the second one) that takes a WMS layer as well as an options > object. That calls a WFSProtocolImpl.create that takes the Layer.WMS object > and the options object and does the construction with the javascript > fromWMSLayer. > > I know this deviates from your approach of 1-1 mapping. My thinking was to > use Java's polymorphism on the constructor to make it simpler to understand > - pass in your layer at construction time. > > Anyway back to why only setGeometryName. fromWMSLayer uses some default > geometry name (not from the layer) that doesn't match with geoserver (or > maybe our team's use of geoserver - I'm not sure). After construction any > of the protocol parameters can be overridden and I needed this one. I > didn't go through and add all the others as I wasn't in a position to > confirm any of it worked. Now that I look at it, I should have added the > getter. I'll plan to do that. > > If you'd prefer the more 1-1 approach we can adjust it. If you don't mind > I'd like to keep this constructor implementation, though. Also I can add > more setters and getters WFSProtocolOptions with the caveat that I may not > be able to thoroughly test. > > Davek > > On 2/23/2010 12:42 PM, Edwin Commandeur wrote: > > Hi Dave, > > When looking at the WFSProtocolOptions I was expecting to see methods > for setting a Url etc, but it only had a method to setGeometryName > method. > > Am I missing something? Is this an old version of WFSProtocolOptions, > or do you set properties on the options object via JSObject? > > Greetings, > Edwin > > > -- > ________________________________ > Dave Koberstein > Experienced head of open source technologies, > VP of Product Line Management, Customer Engineering Services > email: > phone: > da...@ko... > +1-650-575-3853 |
|
From: Edwin C. <com...@gm...> - 2010-02-23 20:42:23
|
Hi Dave, When looking at the WFSProtocolOptions I was expecting to see methods for setting a Url etc, but it only had a method to setGeometryName method. Am I missing something? Is this an old version of WFSProtocolOptions, or do you set properties on the options object via JSObject? Greetings, Edwin |
|
From: Edwin C. <com...@gm...> - 2010-02-21 13:06:25
|
Hi Andrew, On of the strongholds of GWT is the IDE support. The showcase has been setup as Google Eclipse project, since that is easy to get running within the Eclipse IDE as long as you have the official Google Eclipse plugin (which will most probably be up-to-date with GWT versions). The GWT-OL is just a jar-red GWT module, so that is easy to compile and package with Maven. The showcase is a webapp and the Google Eclipse default folder structure does not follow the Maven defaults. The showcase should be packaged as a war not a jar. However, I think you would always want to run the showcase in an IDE, in order to be able look at the code and to be able to debug it. I would agree that it would be nice to use Maven for both building the GWT-OL jar and the showcase, and to be independent of the IDE for running the showcase (most IDEs have good Maven support). It is a bit of a pain indeed that you now have to copy the the GWT-OL jar to the showcase. Though an Ant task could easily do that after a package and that Ant task could be called from Maven. Also, it is probably possible to use Maven only for the dependency management for the showcase. Then the default Maven goal for the GWT-OL module should be install. I haven't looked at the gwt-maven project for a while, but in the past it used to be a bit of a pain to get Maven and GWT play together if you want to launch the project and debug it in the IDE. At least, not as easy as using the Google Eclipse plugin. For example look at: http://www.screaming-penguin.com/node/7353. It is not difficult, but automatic copying of the GWT-OL jar or using Maven only for dependency management and subsequently running the project with Google Eclipse seems easier to me. What you can always do is make the poms, and copy the showcase stuff over to a new folder, for example 'samples' or 'explorer' that is setup with Maven in mind and if that works out fine, then we can drop the original showcase. One other thing that has not been fixed yet in the Maven poms is how to run the testcases. The GWT stuff is Ant oriented, so it was easy to setup an Ant test target, but it would be good to fix this in Maven as well. Greetings, Edwin On 19 February 2010 00:05, Andrew Hughes <ahh...@gm...> wrote: > Hi Guys, > I wanted to add something to the showcase (based on some new additions). But > this was a little bit odd because... > 1. The showcase is not a maven project. > 2. If it was, then the showcase/openlayers and not grouped maven project > (modules) so I can't (easily) have the showcase depend on the latest > snapshot > and then you can get into the fact that the showcase really should be on the > same compile/test/release lifecycle e.t.c. > To fix this would require the following: > gwt-openlayers/pom.xml (artifactId=parent, packaging=pom) > gwt-openlayers/gwt-openlayers/pom.xml > (artifactId=gwt-openlayers, packaging=jar) > gwt-openlayers/showcase/pom.xml (artifactId=showcase, packaging=jar). > otherwise, I can't (easily) do a showcase example of recent changes, I can't > release them with the gwt-openlayers release and I can't sync the two > dependencies in the release phase. > Thoughts? :) > --AH > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Gwt-openlayers-users mailing list > Gwt...@li... > https://lists.sourceforge.net/lists/listinfo/gwt-openlayers-users > > |
|
From: Edwin C. <com...@gm...> - 2010-02-17 13:08:25
|
Hi Andrew,
The Util class does indeed contain some handy functions that would be
nice to wrap. The Util class should never be instantiated and should
only have static methods in my opinion so both a Util and UtilImpl are
not strictly necessary, but having both may give more flexibility and
clarity than only a Util with static JSNI methods in it.
If we mirror OL then Util is in the
org.gwtopenmaps.client.openlayers.* namespace and not in
org.gwtopenmaps.client.openlayers.util.*
Example of usage:
Util.extend(x:JSObjectWrapper, y:JSObjectWrapper)
in Util:
public static JSObjectWrapper extend(JSObjectWrapper destination,
JSObjectWrapper source){
JSObject obj = UtilImpl.extend(destination.getJSObject(),
source.getJSObject());
return destination.setJSObject(obj);
}
In UtilImpl
public static JSObject extend(JSObject destination, JSObject source)/*-{
return $wnd.OpenLayers.Util.extend(destination, source);
}-*/;
The example you give is immediately an example for which plain JSNI
seems the most appropriate, because you need to create a function that
can be pretty broad. You could off course do sth similar as in
setFormatOutput of MousePositionOptions, but plain JSNI is more
straightfoward:
public static void onImageLoadErrorDisplayNone()/*-{
$wnd.Openlayers.Util.onImageLoadError = function()
{this.style.display ="none";}
}-*/;
Such a function could off course be added as a convenience to GWT-OL
on the Util object.
Greetings,
Edwin
On 17 February 2010 07:18, Andrew Hughes <ahh...@gm...> wrote:
> Hi Guys,
> There is a (handy) OpenLayer's class that doesn't appear to be wrapped
> 'OpenLayers/Util.js': http://trac.openlayers.org/browser/tags/openlayers/release-2.8/lib/OpenLayers/Util.js
> I'd like to wrapping this with: org.gwtopenmaps.openlayers.client.Util.java
> and org.gwtopenmaps.openlayers.client.UtilImp.java
> There's a slight naming overlap with
> the org.gwtopenmaps.openlayers.client.util package. But is a minor issue.
> Anyone like to chip in on this one? Trac ticket e.t.c. I need this so I can
> fix those annoying pink tiles for missing map images.
> Like this.. OpenLayers.Util.onImageLoadError = function() {
> this.style.display="none";}
> This appears to be a singleton (same for us) and I'm not sure if this should
> 'extends OpenLayersObjectWrapper'. Some advice would be great.
> Cheers :)
> --AH
> ------------------------------------------------------------------------------
> SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
> Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
> http://p.sf.net/sfu/solaris-dev2dev
> _______________________________________________
> Gwt-openlayers-users mailing list
> Gwt...@li...
> https://lists.sourceforge.net/lists/listinfo/gwt-openlayers-users
>
>
|
|
From: Edwin C. <com...@gm...> - 2010-02-12 17:28:06
|
Hi Nishant, The GWT-OpenLayers library is wrapped using JSNI (http://code.google.com/webtoolkit/doc/latest/DevGuideCodingBasicsJSNI.html), but it uses JSObject, which decorates JavascriptObject with some convenience methods, so less JSNI code is needed. The approach that was taken was to use composite wrapper classes, so everything in GWT-OpenLayers is a JSObjectWrapper that keeps on to the JSObject it wraps. If there is JSNI code this is put in a separate Impl file. Overlay types are not used for multiple reasons: - a cleaner API can be achieved with JSObjectWrapper, as methods on JSObject are not automatically on the object extending JSObjectWrapper - Overlay types have to have a default constructor - Overlay types cannot be used for creating JavaScript objects from scratch (read: OpenLayers configuration objects) When no arrays of objects are returned or have to go into a method, than wrapping is straightforward. The code is online browsable. Simple examples are perhaps the base types such as Pixel: http://gwt-openlayers.hg.sourceforge.net/hgweb/gwt-openlayers/gwt-openlayers/file/ Let me know if that is what you were looking for... If you want to contribute to GWT-OL it will not be problematic to grant you access to do that. I try to keep the entry bar low for that. Greeting, Edwin On 12 February 2010 14:21, nishant verma <nis...@gm...> wrote: > Hi Edwin, > > Thanks for your reply. I have one question. Lets say we start > using GWT-OpenLayers in our application, but later find that there is some > functionality of OpenLayers which is not provided by GWT-Openlayers, then > how can we wrap those required functionalities into java code. Can you give > us a simple example of how this is done currently. May be we could ourselves > expand GWT-Openlayers library according to our requirements and thereby also > be able to contribute to your project. > > Regards, > Nishant > > On Wed, Feb 10, 2010 at 9:09 PM, Edwin Commandeur > <com...@gm...> wrote: >> >> Hi Nishant, >> >> GWT-OpenLayers is a wrapper library for the OpenLayers Javascript >> library, so GWT projects can use OpenLayers functionality without >> having to implement the JSNI wrapper code themselves. >> >> In an ideal world it would be a plain GWT port of OpenLayers, but for >> now it leverages the momentum of OpenLayers. >> >> Add 1) There is currently no overview of which functionality is >> wrapped by GWT-OL exactly. However, most of the stuff for working with >> OGC WMS/WFS webservices and vector layers has been wrapped. Recently >> also the vector feature manipulations controls (modify, drag, rotate >> features) have been wrapped and the WFS protocol has been implemented. >> The GWT-OL codebase has evolved mainly on the basis of the needs of >> the developers. There has been some work on third-party layers >> (Google, ArcGiS), but I cannot tell you the status of the support for >> these layers, as I do not have showcase examples for them yet and have >> not used them myself. >> >> Add 2) First of all GWT-OL wraps OpenLayers, so bugs in OpenLayers are >> also in GWT-OL. There are no pressing bugs that I can think of in >> GWT-OL specifically. The most pressing things are extending the >> showcase with more examples and providing more documentation to users >> of the API. My current focus is adding a simple open proxy >> implementation, which should make it easy to use WFS protocol and make >> a showcase example for that. >> There is off course more functionality of OpenLayers that I'd like to >> see wrapped, but the infrastructure for wrapping OpenLayers is good in >> place. >> >> Add 3) MapFish is a solution with client and server side components. >> The client side components are build on top of OpenLayers and recently >> GeoExt, which itself uses OpenLayers for the map component and Ext-JS >> for the GUI components. GeoExt in turn is building stuff to interface >> with the MapFish print service. GeoExt and MapFish provide stuff for >> building GIS applications that is not in OpenLayers, but tie you into >> Ext-JS for the GUI. >> The only true comparison you can make is GWT-OpenLayers with >> OpenLayers. If you're doing everything in JavaScript then you should >> be using OpenLayers and if you are also using Ext-JS then have a look >> at GeoExt and MapFish. However, if you are developing with GWT, which >> itself gives you a lof of benefits over developing in Javascript (see >> for example: http://www.keylimetie.com/Blog/2009/3/11/why-choose-gwt/), >> then you cannot simply use OpenLayers, but need GWT-OpenLayers. >> >> Ad 4) There is no roadmap past the one for version 0.5 >> (https://sourceforge.net/apps/trac/gwt-openlayers/roadmap), but the >> ultimate goals are: >> - to wrap all OpenLayers offers >> - provide tight GWT integration (using GWT widgets in popups etc) >> >> In tandem to those goals it would be nice if a plain GWT web mapping >> library gets of the ground. That would preferably be when Vector >> Graphics hit GWT to implement Vector Layers. There is already a >> GWTCanvas in incubator: >> http://code.google.com/p/google-web-toolkit-incubator/wiki/GWTCanvas >> and there are other iniatives like: >> http://code.google.com/p/gwt-canvas/ >> http://code.google.com/p/gwt-g2d/ >> http://vaadin.com/web/hene/wiki/-/wiki/Main/GWT+Graphics >> >> Greetings, >> Edwin >> >> On 10 February 2010 14:15, nishant verma <nis...@gm...> wrote: >> > Hi >> > >> > I am currently a developer in OpenXdata project >> > http://www.openxdata.org/. OpenXdata is an open-source, enterprise, >> > end-to-end software solution for any type of forms based data collection >> > and >> > management using mobile devices and web forms. >> > >> > We are now looking for developing a web-based GIS >> > application >> > for OpenXdata. We were searching for various open-source GIS web >> > frameworks, >> > when we came across your project at >> > http://sourceforge.net/projects/gwt-openlayers/. We have also looked at >> > OpenLayers, MapFish etc. But on sourceforge, we couldn't find answers to >> > some questions we have. In this context, on behalf of OpenXdata, I would >> > like to ask you a few questions: >> > >> > 1) What all functionalities of OpenLayers does GWT-OpenLayers support? >> > On >> > this link >> > >> > http://geoserver.org/display/GEOSDOC/Google+Web+Toolkit+(GWT),+OpenLayers+and+GeoServer, >> > we could find a mention of some of the functionalities, but seems like >> > this >> > is an old documentation and refers to GWT-OpenLayers 0.1. >> > >> > 2) What are the most pressing bugs that GWT-OpenLayers is facing? >> > >> > 3) What are the key benefits when compared to other frameworks like >> > MapFish? >> > >> > 4) What is the road map for this project? Does it strive to provide all >> > the >> > functionality of OpenLayers in future versions? >> > >> > I will be grateful to get a reply. Please feel free to ask any >> > questions. >> > >> > Regards, >> > Nishant >> > > > |
|
From: Edwin C. <com...@gm...> - 2010-02-12 01:11:23
|
Hi all, I wanted to remove the WFS classes, but did not do so in order to support users that have already built stuff around that. I will put in the docs that the preferred way to add a WFS layer is via WFSProtocol. Greetings, Edwin |
|
From: Edwin C. <com...@gm...> - 2010-02-12 00:55:31
|
Hi Andrew, Thanks contributing! I have adding narrowTo functions to all Layer objects, which I will have to explain in the user reference. I also just added a narrowToXYZ function. The reason is that Map.getLayer returns a Layer object and sometimes you want to turn that Layer object into a specific Layer object so you can call that specific layer's methods on it. In JavaScript it just returns an object on which you can call any method you like, but in Java that will not work :)... Greetings, Edwin On 12 February 2010 01:04, Andrew Hughes <ahh...@gm...> wrote: > XYZ is Done :) > http://gwt-openlayers.hg.sourceforge.net/hgweb/gwt-openlayers/gwt-openlayers/rev/40f1d318cd4e > https://sourceforge.net/apps/trac/gwt-openlayers/ticket/39 > Thanks for helping me get started :) > > On Wed, Feb 10, 2010 at 7:30 PM, Edwin Commandeur > <com...@gm...> wrote: >> >> Hi Andrew, >> >> I already had an idea the XYZ doc's mixed XYZ and OSM. >> >> The correlation between OL en GWT-OL is important, but XYZ extends >> Grid, so it seems a particular kind of Grid. Renaming it to XYZGrid >> would be acceptable to my mind, but there's also a lot to say for a >> one-on-one correspondence. >> >> I do think GWT-OL can divert from OL if it makes things clearer. >> Examples are Vector and VectorFeature that are both called Vector in >> OL, because in JS you cannot import packages, so you always have the >> full name or eventually I would like to move the stuff in Style to a >> class called Symbology (which has already been suggested in OL). >> >> Regarding documentation I think we do good to refer to the original >> doc in javascript, but I think referring to the actual URL of specific >> version of OL is a bit to brittle. Also, it can't do any harm to give >> additional clarifications, as not all things in OpenLayers are >> described that clearly to the API user and sometimes there is >> redundancy in OL or there are legacy functions which you want to make >> users of the API aware of. >> >> I totally agree on you that it would be nice if GWT-OL would be pure >> GWT! In fact, in time I think we should start a pure GWT >> implementation just as the OpenScales folks did for Flex >> (http://openscales.org/). However, at present I do not structurally >> have time to pull that of the ground. There is a Belgian company who >> is implementing a map component in GWT (http://majas.dfc.be/), but >> they are basing it on SmartGWT, which is itself a javascript wrapper. >> >> If you have a smart idea for a translator infrastructure, then please >> post it to the developers mailing list to discuss it. >> >> Greetings, >> Edwin >> >> On 10 February 2010 01:23, Andrew Hughes <ahh...@gm...> wrote: >> > Hi Again, >> > The doc's are wrong for the XYZ constructor, it is XYZ and not OSM :) >> > I think correlation between openlayers and gwt-openlayers is important >> > so >> > I'd personally prefer to stick to XYZ. It made it into the 2.8 release >> > so >> > it's pretty safe to assume this was named for a sensible reason (even if >> > we >> > don't know what that is) :) The Z probably refer's to scale/resolution >> > or >> > the 'height' of the grid/matrix axis. >> > Similarly, since gwt-openlayers is implemented in JS then we should >> > probably >> > use the native documentation: >> > >> > http://dev.openlayers.org/releases/OpenLayers-2.8/doc/apidocs/files/OpenLayers/Map-js.html#OpenLayers.Map.updateSize >> > I'll open a ticket, and hopefully commit some code in the next day or so >> > :) >> > Mercurial, sourceforge & gwt-openlayers are new to me. GWT and >> > OpenLayers >> > are not :) >> > >> > Andrew >> > p.s. I wish this was pure GWT. So much can be done with data/widget's >> > over >> > RPC it's a pitty we have to push/translate all the objects to >> > "openlayers" >> > object's over RPC. Is there some form of Generic architecture we could >> > add >> > to the classes so that a translator can be assigned to a wrapped class? >> > This >> > is a tough one. >> > >> > On Tue, Feb 9, 2010 at 7:38 PM, Edwin Commandeur >> > <com...@gm...> wrote: >> >> >> >> Hi Andrew, >> >> >> >> It is indeed unproblematic to wrap updateSize, but then I think we >> >> should describe it's use clearer than it is currently described in the >> >> OpenLayers API. I will add the method to Map and document that it's >> >> for specific kinds of divs. Any suggestions for JavaDoc are welcome. >> >> >> >> Great if you would like to research the XYZ layer a bit and add a Trac >> >> ticket about it. The name XYZ layer is a horrible choice of name IMHO. >> >> It should at least have been called XYZGrid and maybe we can give it >> >> that name in GWT-OL. I do not fully understand the Z -bit, but that is >> >> probably my lack of knowledge about this type of layer. >> >> >> >> Greetings, >> >> Edwin >> >> >> >> On 8 February 2010 23:49, Andrew Hughes <ahh...@gm...> wrote: >> >> > Hi There, >> >> > update() >> >> > ------------ >> >> > The problem is specifically related to Google BaseLayer's in >> >> > OpenLayers >> >> > v2.8. >> >> > When the div size is changed at runtime you need to call it to sync >> >> > the >> >> > google div's (afaik). Looks like OpenLayers v3.0 has fixed this. >> >> > However, if >> >> > the method is there I don't see any harm in wrapping it. >> >> > Layer.XYZ >> >> > ---------------- >> >> > My use case is that we have a client who is 110% esri. So, esri >> >> > Cached >> >> > Maps, >> >> > REST services e.t.c. I've got to get some of these wrapped if we are >> >> > going >> >> > to use OpenLayers. I wasn't aware of the inheritence/relationship of >> >> > XYZ, >> >> > OSM, TMS e.t.c. Regardless of this I will submit this to trac, do >> >> > some >> >> > RnD >> >> > of the openlayers src and introduce this to openlayers-gwt. I will >> >> > also >> >> > have >> >> > a look at OpenLayers 3.0 to see if there are any considerations to >> >> > make >> >> > now. >> >> > >> >> > Cheers :) >> >> > >> >> > On Tue, Feb 9, 2010 at 6:44 AM, Edwin Commandeur >> >> > <com...@gm...> wrote: >> >> >> >> >> >> Hi Andrew, >> >> >> >> >> >> I wonder when the updateSize method should be called. As far as I >> >> >> know >> >> >> it should work to let the OpenLayers div be 100% by 100% of the >> >> >> parent >> >> >> div, since the size of the div is requested from the div when it is >> >> >> needed. It seems that the updateSize method is a work-around for >> >> >> when >> >> >> you set a fixed width and height, while in reality the map is not >> >> >> fixed, but the parent div can be expanded and the div containing the >> >> >> map should resize to its parent. However, maybe I am missing out on >> >> >> something there. >> >> >> >> >> >> If you have a good use case for the XYZ class then please add it to >> >> >> Trac. You can create tickets without having to log in. It seems the >> >> >> XYZ class is a low-level thing intended for use in specific >> >> >> OpenLayers >> >> >> classes, such as the OSM layer. I see that it wrongly states above >> >> >> the >> >> >> XYZ constructor that it is the OSM layer constructor. We should >> >> >> possible wrap both the XYZ and the OSM layer, with the OSM layer >> >> >> extending XYZ. >> >> >> >> >> >> For OpenStreetMap things are a bit unclear to me, because there is >> >> >> also the TMS layer, which is wrapped by GWT-OL by someone who used >> >> >> OpenStreetMap. I am not sure which layer is more up to date XYZ/OSM >> >> >> or >> >> >> TMS. It seems that one of them is obsolete. The 'osm-layer.html' >> >> >> example in OpenLayers 2.8 includes OSM data by means of a WMS. The >> >> >> 'tms.html' does have a TMS layer, but is not what I expected to see. >> >> >> Andrew, if you know more about this, please let me know. >> >> >> >> >> >> Greetings, >> >> >> Edwin >> >> >> >> >> >> On 8 February 2010 05:54, Andrew Hughes <ahh...@gm...> wrote: >> >> >> > Hi Guys, >> >> >> > I have a few things I would like to add/wrap. >> >> >> > Map.updateSize() >> >> >> > >> >> >> > >> >> >> > >> >> >> > http://dev.openlayers.org/releases/OpenLayers-2.8/doc/apidocs/files/OpenLayers/Map-js.html#OpenLayers.Map.updateSize >> >> >> > Layer.XYZ >> >> >> > >> >> >> > >> >> >> > >> >> >> > http://dev.openlayers.org/releases/OpenLayers-2.8/doc/apidocs/files/OpenLayers/Layer/XYZ-js.html >> >> >> > >> >> >> > How would you like me to proceed? Do we raise issues or what first >> >> >> > e.t.c??? >> >> >> > Cheers. >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> >> > ------------------------------------------------------------------------------ >> >> >> > The Planet: dedicated and managed hosting, cloud storage, >> >> >> > colocation >> >> >> > Stay online with enterprise data centers and the best network in >> >> >> > the >> >> >> > business >> >> >> > Choose flexible plans and management services without long-term >> >> >> > contracts >> >> >> > Personal 24x7 support from experience hosting pros just a phone >> >> >> > call >> >> >> > away. >> >> >> > http://p.sf.net/sfu/theplanet-com >> >> >> > _______________________________________________ >> >> >> > Gwt-openlayers-users mailing list >> >> >> > Gwt...@li... >> >> >> > https://lists.sourceforge.net/lists/listinfo/gwt-openlayers-users >> >> >> > >> >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > ------------------------------------------------------------------------------ >> >> > The Planet: dedicated and managed hosting, cloud storage, colocation >> >> > Stay online with enterprise data centers and the best network in the >> >> > business >> >> > Choose flexible plans and management services without long-term >> >> > contracts >> >> > Personal 24x7 support from experience hosting pros just a phone call >> >> > away. >> >> > http://p.sf.net/sfu/theplanet-com >> >> > _______________________________________________ >> >> > Gwt-openlayers-users mailing list >> >> > Gwt...@li... >> >> > https://lists.sourceforge.net/lists/listinfo/gwt-openlayers-users >> >> > >> >> > >> > >> > > > |
|
From: Edwin C. <com...@gm...> - 2010-02-12 00:46:52
|
hi all,
I moved the redraw function from Layer to HTTPRequestLayer. Are there
any objections to that?
The redraw function is a function of HTTPRequestLayer and subclasses
in OpenLayers.
I guess it got moved to Layer for convenience, but when you have Layer
and want to call redraw you should actually first check if it is a
Layer on which redraw can be called.
For example:
WMS wmsLayer;
String layerClassName =
Layer.narrowToOpenLayersObjectWrapper(layer).getClassName();
if(layerClassName.equals(Layer.WMS_CLASS_NAME)){
wmsLayer = WMS.narrowToWMS(Layer.getJSObject());
}
When you know it's a WMS layer then you can also simply do:
WMS wmsLayer = WMS.narrowToWMS(layer.getJSObject());
I will have to describe that on the users wiki...
Greetings,
Edwin
|
|
From: Edwin C. <com...@gm...> - 2010-02-10 15:39:40
|
Hi Nishant, GWT-OpenLayers is a wrapper library for the OpenLayers Javascript library, so GWT projects can use OpenLayers functionality without having to implement the JSNI wrapper code themselves. In an ideal world it would be a plain GWT port of OpenLayers, but for now it leverages the momentum of OpenLayers. Add 1) There is currently no overview of which functionality is wrapped by GWT-OL exactly. However, most of the stuff for working with OGC WMS/WFS webservices and vector layers has been wrapped. Recently also the vector feature manipulations controls (modify, drag, rotate features) have been wrapped and the WFS protocol has been implemented. The GWT-OL codebase has evolved mainly on the basis of the needs of the developers. There has been some work on third-party layers (Google, ArcGiS), but I cannot tell you the status of the support for these layers, as I do not have showcase examples for them yet and have not used them myself. Add 2) First of all GWT-OL wraps OpenLayers, so bugs in OpenLayers are also in GWT-OL. There are no pressing bugs that I can think of in GWT-OL specifically. The most pressing things are extending the showcase with more examples and providing more documentation to users of the API. My current focus is adding a simple open proxy implementation, which should make it easy to use WFS protocol and make a showcase example for that. There is off course more functionality of OpenLayers that I'd like to see wrapped, but the infrastructure for wrapping OpenLayers is good in place. Add 3) MapFish is a solution with client and server side components. The client side components are build on top of OpenLayers and recently GeoExt, which itself uses OpenLayers for the map component and Ext-JS for the GUI components. GeoExt in turn is building stuff to interface with the MapFish print service. GeoExt and MapFish provide stuff for building GIS applications that is not in OpenLayers, but tie you into Ext-JS for the GUI. The only true comparison you can make is GWT-OpenLayers with OpenLayers. If you're doing everything in JavaScript then you should be using OpenLayers and if you are also using Ext-JS then have a look at GeoExt and MapFish. However, if you are developing with GWT, which itself gives you a lof of benefits over developing in Javascript (see for example: http://www.keylimetie.com/Blog/2009/3/11/why-choose-gwt/), then you cannot simply use OpenLayers, but need GWT-OpenLayers. Ad 4) There is no roadmap past the one for version 0.5 (https://sourceforge.net/apps/trac/gwt-openlayers/roadmap), but the ultimate goals are: - to wrap all OpenLayers offers - provide tight GWT integration (using GWT widgets in popups etc) In tandem to those goals it would be nice if a plain GWT web mapping library gets of the ground. That would preferably be when Vector Graphics hit GWT to implement Vector Layers. There is already a GWTCanvas in incubator: http://code.google.com/p/google-web-toolkit-incubator/wiki/GWTCanvas and there are other iniatives like: http://code.google.com/p/gwt-canvas/ http://code.google.com/p/gwt-g2d/ http://vaadin.com/web/hene/wiki/-/wiki/Main/GWT+Graphics Greetings, Edwin On 10 February 2010 14:15, nishant verma <nis...@gm...> wrote: > Hi > > I am currently a developer in OpenXdata project > http://www.openxdata.org/. OpenXdata is an open-source, enterprise, > end-to-end software solution for any type of forms based data collection and > management using mobile devices and web forms. > > We are now looking for developing a web-based GIS application > for OpenXdata. We were searching for various open-source GIS web frameworks, > when we came across your project at > http://sourceforge.net/projects/gwt-openlayers/. We have also looked at > OpenLayers, MapFish etc. But on sourceforge, we couldn't find answers to > some questions we have. In this context, on behalf of OpenXdata, I would > like to ask you a few questions: > > 1) What all functionalities of OpenLayers does GWT-OpenLayers support? On > this link > http://geoserver.org/display/GEOSDOC/Google+Web+Toolkit+(GWT),+OpenLayers+and+GeoServer, > we could find a mention of some of the functionalities, but seems like this > is an old documentation and refers to GWT-OpenLayers 0.1. > > 2) What are the most pressing bugs that GWT-OpenLayers is facing? > > 3) What are the key benefits when compared to other frameworks like MapFish? > > 4) What is the road map for this project? Does it strive to provide all the > functionality of OpenLayers in future versions? > > I will be grateful to get a reply. Please feel free to ask any questions. > > Regards, > Nishant > |
|
From: Edwin C. <com...@gm...> - 2010-02-10 09:00:15
|
Hi Andrew, I already had an idea the XYZ doc's mixed XYZ and OSM. The correlation between OL en GWT-OL is important, but XYZ extends Grid, so it seems a particular kind of Grid. Renaming it to XYZGrid would be acceptable to my mind, but there's also a lot to say for a one-on-one correspondence. I do think GWT-OL can divert from OL if it makes things clearer. Examples are Vector and VectorFeature that are both called Vector in OL, because in JS you cannot import packages, so you always have the full name or eventually I would like to move the stuff in Style to a class called Symbology (which has already been suggested in OL). Regarding documentation I think we do good to refer to the original doc in javascript, but I think referring to the actual URL of specific version of OL is a bit to brittle. Also, it can't do any harm to give additional clarifications, as not all things in OpenLayers are described that clearly to the API user and sometimes there is redundancy in OL or there are legacy functions which you want to make users of the API aware of. I totally agree on you that it would be nice if GWT-OL would be pure GWT! In fact, in time I think we should start a pure GWT implementation just as the OpenScales folks did for Flex (http://openscales.org/). However, at present I do not structurally have time to pull that of the ground. There is a Belgian company who is implementing a map component in GWT (http://majas.dfc.be/), but they are basing it on SmartGWT, which is itself a javascript wrapper. If you have a smart idea for a translator infrastructure, then please post it to the developers mailing list to discuss it. Greetings, Edwin On 10 February 2010 01:23, Andrew Hughes <ahh...@gm...> wrote: > Hi Again, > The doc's are wrong for the XYZ constructor, it is XYZ and not OSM :) > I think correlation between openlayers and gwt-openlayers is important so > I'd personally prefer to stick to XYZ. It made it into the 2.8 release so > it's pretty safe to assume this was named for a sensible reason (even if we > don't know what that is) :) The Z probably refer's to scale/resolution or > the 'height' of the grid/matrix axis. > Similarly, since gwt-openlayers is implemented in JS then we should probably > use the native documentation: > http://dev.openlayers.org/releases/OpenLayers-2.8/doc/apidocs/files/OpenLayers/Map-js.html#OpenLayers.Map.updateSize > I'll open a ticket, and hopefully commit some code in the next day or so :) > Mercurial, sourceforge & gwt-openlayers are new to me. GWT and OpenLayers > are not :) > > Andrew > p.s. I wish this was pure GWT. So much can be done with data/widget's over > RPC it's a pitty we have to push/translate all the objects to "openlayers" > object's over RPC. Is there some form of Generic architecture we could add > to the classes so that a translator can be assigned to a wrapped class? This > is a tough one. > > On Tue, Feb 9, 2010 at 7:38 PM, Edwin Commandeur > <com...@gm...> wrote: >> >> Hi Andrew, >> >> It is indeed unproblematic to wrap updateSize, but then I think we >> should describe it's use clearer than it is currently described in the >> OpenLayers API. I will add the method to Map and document that it's >> for specific kinds of divs. Any suggestions for JavaDoc are welcome. >> >> Great if you would like to research the XYZ layer a bit and add a Trac >> ticket about it. The name XYZ layer is a horrible choice of name IMHO. >> It should at least have been called XYZGrid and maybe we can give it >> that name in GWT-OL. I do not fully understand the Z -bit, but that is >> probably my lack of knowledge about this type of layer. >> >> Greetings, >> Edwin >> >> On 8 February 2010 23:49, Andrew Hughes <ahh...@gm...> wrote: >> > Hi There, >> > update() >> > ------------ >> > The problem is specifically related to Google BaseLayer's in OpenLayers >> > v2.8. >> > When the div size is changed at runtime you need to call it to sync the >> > google div's (afaik). Looks like OpenLayers v3.0 has fixed this. >> > However, if >> > the method is there I don't see any harm in wrapping it. >> > Layer.XYZ >> > ---------------- >> > My use case is that we have a client who is 110% esri. So, esri Cached >> > Maps, >> > REST services e.t.c. I've got to get some of these wrapped if we are >> > going >> > to use OpenLayers. I wasn't aware of the inheritence/relationship of >> > XYZ, >> > OSM, TMS e.t.c. Regardless of this I will submit this to trac, do some >> > RnD >> > of the openlayers src and introduce this to openlayers-gwt. I will also >> > have >> > a look at OpenLayers 3.0 to see if there are any considerations to make >> > now. >> > >> > Cheers :) >> > >> > On Tue, Feb 9, 2010 at 6:44 AM, Edwin Commandeur >> > <com...@gm...> wrote: >> >> >> >> Hi Andrew, >> >> >> >> I wonder when the updateSize method should be called. As far as I know >> >> it should work to let the OpenLayers div be 100% by 100% of the parent >> >> div, since the size of the div is requested from the div when it is >> >> needed. It seems that the updateSize method is a work-around for when >> >> you set a fixed width and height, while in reality the map is not >> >> fixed, but the parent div can be expanded and the div containing the >> >> map should resize to its parent. However, maybe I am missing out on >> >> something there. >> >> >> >> If you have a good use case for the XYZ class then please add it to >> >> Trac. You can create tickets without having to log in. It seems the >> >> XYZ class is a low-level thing intended for use in specific OpenLayers >> >> classes, such as the OSM layer. I see that it wrongly states above the >> >> XYZ constructor that it is the OSM layer constructor. We should >> >> possible wrap both the XYZ and the OSM layer, with the OSM layer >> >> extending XYZ. >> >> >> >> For OpenStreetMap things are a bit unclear to me, because there is >> >> also the TMS layer, which is wrapped by GWT-OL by someone who used >> >> OpenStreetMap. I am not sure which layer is more up to date XYZ/OSM or >> >> TMS. It seems that one of them is obsolete. The 'osm-layer.html' >> >> example in OpenLayers 2.8 includes OSM data by means of a WMS. The >> >> 'tms.html' does have a TMS layer, but is not what I expected to see. >> >> Andrew, if you know more about this, please let me know. >> >> >> >> Greetings, >> >> Edwin >> >> >> >> On 8 February 2010 05:54, Andrew Hughes <ahh...@gm...> wrote: >> >> > Hi Guys, >> >> > I have a few things I would like to add/wrap. >> >> > Map.updateSize() >> >> > >> >> > >> >> > http://dev.openlayers.org/releases/OpenLayers-2.8/doc/apidocs/files/OpenLayers/Map-js.html#OpenLayers.Map.updateSize >> >> > Layer.XYZ >> >> > >> >> > >> >> > http://dev.openlayers.org/releases/OpenLayers-2.8/doc/apidocs/files/OpenLayers/Layer/XYZ-js.html >> >> > >> >> > How would you like me to proceed? Do we raise issues or what first >> >> > e.t.c??? >> >> > Cheers. >> >> > >> >> > >> >> > >> >> > ------------------------------------------------------------------------------ >> >> > The Planet: dedicated and managed hosting, cloud storage, colocation >> >> > Stay online with enterprise data centers and the best network in the >> >> > business >> >> > Choose flexible plans and management services without long-term >> >> > contracts >> >> > Personal 24x7 support from experience hosting pros just a phone call >> >> > away. >> >> > http://p.sf.net/sfu/theplanet-com >> >> > _______________________________________________ >> >> > Gwt-openlayers-users mailing list >> >> > Gwt...@li... >> >> > https://lists.sourceforge.net/lists/listinfo/gwt-openlayers-users >> >> > >> >> > >> > >> > >> > >> > ------------------------------------------------------------------------------ >> > The Planet: dedicated and managed hosting, cloud storage, colocation >> > Stay online with enterprise data centers and the best network in the >> > business >> > Choose flexible plans and management services without long-term >> > contracts >> > Personal 24x7 support from experience hosting pros just a phone call >> > away. >> > http://p.sf.net/sfu/theplanet-com >> > _______________________________________________ >> > Gwt-openlayers-users mailing list >> > Gwt...@li... >> > https://lists.sourceforge.net/lists/listinfo/gwt-openlayers-users >> > >> > > > |
|
From: Edwin C. <com...@gm...> - 2010-02-10 08:37:34
|
Hi Andrew, It seems your doing stuff no one is working on yet, so I added you as a developer (guessing your username would be ahhughes :-)..). Mercurial can be a bit different if you are not used to distributed version control tools. For a little bit more information on how to get going, please take a look at: https://sourceforge.net/apps/trac/gwt-openlayers/wiki/Developer_reference If you have any additions, I also gave you rights (like all developers) to edit the gwt-openlayers Trac wiki. Greetings, Edwin On 10 February 2010 01:38, Andrew Hughes <ahh...@gm...> wrote: > Hi Guys, > SF.net say's I need to contact you in order to join the GWT-OpenLayers > project. I also need commit access to check my work back in. > Not sure how this works, but I have used my OpenID to join SF (should be > linked to this email address). > Cheeeeeeeeeeeeers :) |
|
From: Edwin C. <com...@gm...> - 2010-02-05 10:16:20
|
Hi Bob,
I wrongly presumed that Dave added code for the WFS Layer, but it was
for the WFSProtocol. I found out when making a start on adding a WFS
example.
It seems to me then that the WFS implementation is yours. Would you
feel comfortable adding that to the codebase? If so, then I will add
you as a developer. Alternatively, you can send me the files and I
will make sure they make it into the codebase promptly.
Coming monday I hope to have a bit of time to see what needs to be
done to get a new GWT-OL release out shortly and it would be nice if
the WFS stuff can be in it.
Greetings,
Edwin
On 5 February 2010 01:14, Edwin Commandeur <com...@gm...> wrote:
> Hi Bob,
>
> That's great that you have already have some proxy code. Would you
> mind if I merge that into GWT-OL? It looks just fine for our purposes.
>
> I would really have to dive into the WFS stuff to see what's going on.
>
> I will make it high priority to add a WFS example, so I can try to
> reproduce what's going on. Sorry that I cannot help you on a shorter
> notice.
>
> Greetings,
> Edwin
>
> On 4 February 2010 19:33, Robert Light <rob...@ve...> wrote:
>> To proxy, I just used the servlet (see attached) which worked just fine for
>> me.
>>
>> - Bob
>>
>> Edwin Commandeur wrote:
>>
>> Hi Robert,
>>
>> The WFS functionality is a recent contribution by Dave, maybe he
>> recognizes the problem easily. I still need to get working on a Java
>> port of the Open Proxy that is necessary for the WFS functionality and
>> that is included in the OpenLayers examples.
>>
>> How are you running your code? Is the Python Open Proxy implementation up?
>>
>> The dev list is not publicly visible as far as I am aware, but I have
>> cc'd this reply to the devl list.
>>
>> Greetings,
>> Edwin
>>
>>
>> On 4 February 2010 16:54, Robert Light <rob...@ve...> wrote:
>>
>>
>> Edwin,
>>
>> I think I've found a bug either in openlayers or in gwt-openlayers code.
>>
>> if I create a WFS layer:
>> WFSParams wfsParams = new WFSParams();
>> wfsParams.setTypename("topp:states");
>> WFSOptions wfsLayerOptions = new WFSOptions();
>> wfsLayerOptions.setTransitionEffect(TransitionEffect.RESIZE);
>> wfsLayerOptions.setExtractAttributes(true);
>>
>> WFS wfsLayer = new WFS(
>> "states",
>> "http://192.168.1.167:8080/geoserver/wfs",
>> wfsParams,
>> wfsLayerOptions);
>>
>> and then I want to get selection events so I do:
>>
>> wfsLayer.addVectorFeatureSelectedListener( new
>> VectorFeatureSelectedListener() {
>>
>> public void onFeatureSelected(FeatureSelectedEvent
>> eventObject) {
>> JSONObject map = new
>> JSONObject(eventObject.getVectorFeature().getJSObject().getProperty("attributes"));
>> System.out.println("Feature.id =
>> "+eventObject.getVectorFeature().getId());
>> for( String key : map.keySet()) {
>> System.out.println(key+"="+map.get(key));
>> }
>> }
>> });
>>
>> This does not work... my VectorFeatureSelectListener never get's called.
>>
>> To make this work, I had to add the following:
>> SelectFeatureOptions selectFeatureOptions = new
>> SelectFeatureOptions();
>> selectFeatureOptions.onSelect( new
>> SelectFeature.SelectFeatureListener() {
>>
>> public void onFeatureSelected(VectorFeature vectorFeature) {
>> JSONObject map = new
>> JSONObject(vectorFeature.getJSObject().getProperty("attributes"));
>> for( String key : map.keySet()) {
>> System.out.println(key+"="+map.get(key));
>> }
>> }
>> });
>>
>> SelectFeature selfeature = new SelectFeature(wfsLayer,
>> selectFeatureOptions);
>> map.getMap().addControl(selfeature);
>> selfeature.activate();
>>
>>
>> And now BOTH my VectureFeatureSelectListener AND my SelectFeatureListener
>> get called when I select a feature.
>>
>> To put another wrinkle in the puzzle....instead of adding the SelectFeature
>> Control as above, I do just the following:
>>
>> SelectFeature selfeature = new SelectFeature(wfsLayer);
>> map.getMap().addControl(selfeature);
>> selfeature.activate();
>>
>> My VectorFeatureSelectListener does NOT get called.
>>
>> Any ideas? Is there a developer's list I should post this query to?
>>
>> Note, I'm working off the latest set of sources that I downloaded via
>> mercurial.
>>
>> many thanks.
>>
>> - Bob Light
>>
>>
>>
>>
>>
>
|
|
From: Edwin C. <com...@gm...> - 2010-02-05 10:14:46
|
ESRI also has a proxy.jsp for download: http://resources.esri.com/help/9.3/arcgisserver/apis/javascript/gmaps/help/google_start.htm#topics/ags_proxy.html Amazing that al these people use a jsp for the proxying. Possible, because it does not have to be configured in web.xml like a servlet. To my mind a servlet would seem more logical. Any thoughts anyone? Greetings, Edwin On 5 February 2010 10:36, Edwin Commandeur <com...@gm...> wrote: > Hi Robert, > > Great you found that piece of proxy code. I will put the code in and > try to find out who I should attribute or I will include a ref to: > http://trac.openlayers.org/browser/sandbox/august/openlayers/2.8%2B/lib/OpenLayers/Util/openlayers-proxy.jsp > > That is the code which I would like to take as a starting point. > > The code is very useful and we can slash out the couple of jsp only > lines and start adding functionality so you can add a white list of > servers as in the Python proxy (even though in practice I think there > are more use cases for connecting to arbitrary WFS servers). > > Greetings, > Edwin > > On 5 February 2010 07:31, Robert Light <rob...@ve...> wrote: >> The proxy code originally came from the openlayers jsp proxy example. I >> can't be sure...but here is clearly where most of the code started from: >> >> http://trac.openlayers.org/changeset/8099/sandbox?format=diff&new=8099 >> >> - Bob >> >> Edwin Commandeur wrote: >> >> Hi Bob, >> >> I wrongly presumed that Dave added code for the WFS Layer, but it was >> for the WFSProtocol. I found out when making a start on adding a WFS >> example. >> >> It seems to me then that the WFS implementation is yours. Would you >> feel comfortable adding that to the codebase? If so, then I will add >> you as a developer. Alternatively, you can send me the files and I >> will make sure they make it into the codebase promptly. >> >> Coming monday I hope to have a bit of time to see what needs to be >> done to get a new GWT-OL release out shortly and it would be nice if >> the WFS stuff can be in it. >> >> Greetings, >> Edwin >> >> >> On 5 February 2010 01:14, Edwin Commandeur <com...@gm...> >> wrote: >> >> >> Hi Bob, >> >> That's great that you have already have some proxy code. Would you >> mind if I merge that into GWT-OL? It looks just fine for our purposes. >> >> I would really have to dive into the WFS stuff to see what's going on. >> >> I will make it high priority to add a WFS example, so I can try to >> reproduce what's going on. Sorry that I cannot help you on a shorter >> notice. >> >> Greetings, >> Edwin >> >> On 4 February 2010 19:33, Robert Light <rob...@ve...> wrote: >> >> >> To proxy, I just used the servlet (see attached) which worked just fine for >> me. >> >> - Bob >> >> Edwin Commandeur wrote: >> >> Hi Robert, >> >> The WFS functionality is a recent contribution by Dave, maybe he >> recognizes the problem easily. I still need to get working on a Java >> port of the Open Proxy that is necessary for the WFS functionality and >> that is included in the OpenLayers examples. >> >> How are you running your code? Is the Python Open Proxy implementation up? >> >> The dev list is not publicly visible as far as I am aware, but I have >> cc'd this reply to the devl list. >> >> Greetings, >> Edwin >> >> >> On 4 February 2010 16:54, Robert Light <rob...@ve...> wrote: >> >> >> Edwin, >> >> I think I've found a bug either in openlayers or in gwt-openlayers code. >> >> if I create a WFS layer: >> WFSParams wfsParams = new WFSParams(); >> wfsParams.setTypename("topp:states"); >> WFSOptions wfsLayerOptions = new WFSOptions(); >> wfsLayerOptions.setTransitionEffect(TransitionEffect.RESIZE); >> wfsLayerOptions.setExtractAttributes(true); >> >> WFS wfsLayer = new WFS( >> "states", >> "http://192.168.1.167:8080/geoserver/wfs", >> wfsParams, >> wfsLayerOptions); >> >> and then I want to get selection events so I do: >> >> wfsLayer.addVectorFeatureSelectedListener( new >> VectorFeatureSelectedListener() { >> >> public void onFeatureSelected(FeatureSelectedEvent >> eventObject) { >> JSONObject map = new >> JSONObject(eventObject.getVectorFeature().getJSObject().getProperty("attributes")); >> System.out.println("Feature.id = >> "+eventObject.getVectorFeature().getId()); >> for( String key : map.keySet()) { >> System.out.println(key+"="+map.get(key)); >> } >> } >> }); >> >> This does not work... my VectorFeatureSelectListener never get's called. >> >> To make this work, I had to add the following: >> SelectFeatureOptions selectFeatureOptions = new >> SelectFeatureOptions(); >> selectFeatureOptions.onSelect( new >> SelectFeature.SelectFeatureListener() { >> >> public void onFeatureSelected(VectorFeature vectorFeature) { >> JSONObject map = new >> JSONObject(vectorFeature.getJSObject().getProperty("attributes")); >> for( String key : map.keySet()) { >> System.out.println(key+"="+map.get(key)); >> } >> } >> }); >> >> SelectFeature selfeature = new SelectFeature(wfsLayer, >> selectFeatureOptions); >> map.getMap().addControl(selfeature); >> selfeature.activate(); >> >> >> And now BOTH my VectureFeatureSelectListener AND my SelectFeatureListener >> get called when I select a feature. >> >> To put another wrinkle in the puzzle....instead of adding the SelectFeature >> Control as above, I do just the following: >> >> SelectFeature selfeature = new SelectFeature(wfsLayer); >> map.getMap().addControl(selfeature); >> selfeature.activate(); >> >> My VectorFeatureSelectListener does NOT get called. >> >> Any ideas? Is there a developer's list I should post this query to? >> >> Note, I'm working off the latest set of sources that I downloaded via >> mercurial. >> >> many thanks. >> >> - Bob Light >> >> >> >> >> >> >> >> > |
|
From: Edwin C. <com...@gm...> - 2010-02-05 09:45:02
|
Hi Robert, Great you found that piece of proxy code. I will put the code in and try to find out who I should attribute or I will include a ref to: http://trac.openlayers.org/browser/sandbox/august/openlayers/2.8%2B/lib/OpenLayers/Util/openlayers-proxy.jsp That is the code which I would like to take as a starting point. The code is very useful and we can slash out the couple of jsp only lines and start adding functionality so you can add a white list of servers as in the Python proxy (even though in practice I think there are more use cases for connecting to arbitrary WFS servers). Greetings, Edwin On 5 February 2010 07:31, Robert Light <rob...@ve...> wrote: > The proxy code originally came from the openlayers jsp proxy example. I > can't be sure...but here is clearly where most of the code started from: > > http://trac.openlayers.org/changeset/8099/sandbox?format=diff&new=8099 > > - Bob > > Edwin Commandeur wrote: > > Hi Bob, > > I wrongly presumed that Dave added code for the WFS Layer, but it was > for the WFSProtocol. I found out when making a start on adding a WFS > example. > > It seems to me then that the WFS implementation is yours. Would you > feel comfortable adding that to the codebase? If so, then I will add > you as a developer. Alternatively, you can send me the files and I > will make sure they make it into the codebase promptly. > > Coming monday I hope to have a bit of time to see what needs to be > done to get a new GWT-OL release out shortly and it would be nice if > the WFS stuff can be in it. > > Greetings, > Edwin > > > On 5 February 2010 01:14, Edwin Commandeur <com...@gm...> > wrote: > > > Hi Bob, > > That's great that you have already have some proxy code. Would you > mind if I merge that into GWT-OL? It looks just fine for our purposes. > > I would really have to dive into the WFS stuff to see what's going on. > > I will make it high priority to add a WFS example, so I can try to > reproduce what's going on. Sorry that I cannot help you on a shorter > notice. > > Greetings, > Edwin > > On 4 February 2010 19:33, Robert Light <rob...@ve...> wrote: > > > To proxy, I just used the servlet (see attached) which worked just fine for > me. > > - Bob > > Edwin Commandeur wrote: > > Hi Robert, > > The WFS functionality is a recent contribution by Dave, maybe he > recognizes the problem easily. I still need to get working on a Java > port of the Open Proxy that is necessary for the WFS functionality and > that is included in the OpenLayers examples. > > How are you running your code? Is the Python Open Proxy implementation up? > > The dev list is not publicly visible as far as I am aware, but I have > cc'd this reply to the devl list. > > Greetings, > Edwin > > > On 4 February 2010 16:54, Robert Light <rob...@ve...> wrote: > > > Edwin, > > I think I've found a bug either in openlayers or in gwt-openlayers code. > > if I create a WFS layer: > WFSParams wfsParams = new WFSParams(); > wfsParams.setTypename("topp:states"); > WFSOptions wfsLayerOptions = new WFSOptions(); > wfsLayerOptions.setTransitionEffect(TransitionEffect.RESIZE); > wfsLayerOptions.setExtractAttributes(true); > > WFS wfsLayer = new WFS( > "states", > "http://192.168.1.167:8080/geoserver/wfs", > wfsParams, > wfsLayerOptions); > > and then I want to get selection events so I do: > > wfsLayer.addVectorFeatureSelectedListener( new > VectorFeatureSelectedListener() { > > public void onFeatureSelected(FeatureSelectedEvent > eventObject) { > JSONObject map = new > JSONObject(eventObject.getVectorFeature().getJSObject().getProperty("attributes")); > System.out.println("Feature.id = > "+eventObject.getVectorFeature().getId()); > for( String key : map.keySet()) { > System.out.println(key+"="+map.get(key)); > } > } > }); > > This does not work... my VectorFeatureSelectListener never get's called. > > To make this work, I had to add the following: > SelectFeatureOptions selectFeatureOptions = new > SelectFeatureOptions(); > selectFeatureOptions.onSelect( new > SelectFeature.SelectFeatureListener() { > > public void onFeatureSelected(VectorFeature vectorFeature) { > JSONObject map = new > JSONObject(vectorFeature.getJSObject().getProperty("attributes")); > for( String key : map.keySet()) { > System.out.println(key+"="+map.get(key)); > } > } > }); > > SelectFeature selfeature = new SelectFeature(wfsLayer, > selectFeatureOptions); > map.getMap().addControl(selfeature); > selfeature.activate(); > > > And now BOTH my VectureFeatureSelectListener AND my SelectFeatureListener > get called when I select a feature. > > To put another wrinkle in the puzzle....instead of adding the SelectFeature > Control as above, I do just the following: > > SelectFeature selfeature = new SelectFeature(wfsLayer); > map.getMap().addControl(selfeature); > selfeature.activate(); > > My VectorFeatureSelectListener does NOT get called. > > Any ideas? Is there a developer's list I should post this query to? > > Note, I'm working off the latest set of sources that I downloaded via > mercurial. > > many thanks. > > - Bob Light > > > > > > > > |
|
From: Edwin C. <com...@gm...> - 2010-02-05 09:21:35
|
Hi Bob and Dave and GWT-OL devls, For all on the gwt-openlayers-devl list: IF NO ONE OBJECTS I WILL REMOVE THE WFS LAYER CLASSES FROM THE CODEBASE, AND CREATE A WFSPROTOCOL EXAMPLE, WHICH DOCUMENTS WHY WFS SHOULD BE DONE THAT WAY. (see below) First of all, great that it' s working now. Dave, thanks for your clever analysis of the problem. WFS indeed extends the Vector class. This was done, because in OpenLayers the WFS class inherits both from the Markers Layer and from the Vector Layer, but it seemed to me to have more Vector Layer qualities than Marker Layer qualities and since multiple inheritance is not possible in Java I let WFS extend VectorFeature. See the OL UML diagram about this: http://trac.openlayers.org/attachment/wiki/UML/ClassDiagram_OL2.7RC2-20080916.pdf Notice that according to the way it is organized in OpenLayers the WFS class indeed inherits the event "featureselected" from the Vector Layer. This is the same event the SelectFeature control will register itself for, as you pass it the Vector Layer. All of the OpenLayers WFS examples on dev seem to use the WFSProtocol (http://openlayers.org/dev/examples/ and filter on WFS), also the wfs-states example, which uses a WFS layer in the examples bundled with 2.8. The WFSProtocol should cover everything that you want to do with WFS. I am now on the track that we should deliberately not implement the WFS layer at all, especially since the dev example don't seem to use it also and an OpenLayers committer I know confided to me that the WFS layer is indeed a legacy construct that is superseded by WFSProtocol. Added bonus: It makes the libary leaner if we can omit WFS layer and use WFSProtocol. The issue you are describing with the SelectFeature Control listener versus the Vector Layer listener could also occur with a plain Vector layer it seems, as there are apparently two ways to add a "featureselected" listener. I did indeed add some classes for WFS, but hadn't come round to really wrapping the WFS stuff. Sorry, about the confusion around that. Bob, in the example code you send I saw you created a WFSParam object and a WFSOptions object, which are just empty stubs in the current Hg repo. So that's why I assumed you filled in the WFS stubs (even though it has my name above it). Sorry for putting you on the wrong track by including the WFS stubs. Greetings, Edwin On 5 February 2010 07:38, Robert Light <rob...@ve...> wrote: > Dave, > > Thanks for the analysis...this seems to explain the behavior I was seeing > from my side. I ultimately did as you suggested and created the WFS layer > with the SelectFeature control... with the SelectFeatureOptions setup > properly. > > Things are good now ...but clearly I managed to step into a tarpit which was > sort of "mystical" on why it behaved the way it did. > > We too will be having a huge number of features and will shift to using a > WMS server to paint the tiles and download it to the client... this makes it > easy to pass selection events back to the server and have the server figure > out what got clicked. > > - Bob > > Dave Koberstein wrote: > > Hi Guys, > > Sorry for the slow response. > > I haven't actually used WFS layer. In our case we have tons of features. > So I use a WMS layer to get an image of the features. Then I recently > implemented Control.GetFeature to request via WFSProtocol the features the > server returns in a bbox as described by the WMS layer. Upon callback one > can do as they wish, include adding VectorFeature()'s to a Vector Layer > (which I've done). I'm currently using markers and popups but maybe I > should look at a vector layer and vectorfeature. > > I think there may be a combination that shouldn't be allowed in the > gwt-openlayers. It looks like VectorFeatureSelected ultimately is looking > for a 'featureselected' event in OpenLayers. Layer/Vector.js will generate > that but Layer/WFS.js will not (looking at the openlayers source). > > I see that SelectFeature also can generate 'featureselected'. So apparently > when you have the SelectFeature control setup you then get 'featureselected' > events and you've got two listeners for that event. > > I think what you really want is WFS layer and SelectFeature control on that > layer. When your page loads the WFS layer gets loaded with features that > you can then select. > > VectorFeature seems only associated with vector layers. Perhaps our WFS > class shouldn't extend the Vector class like it does now. It's allowing > combinations that can't happen. > > Anyway, that's all I can come up with by looking at the code. > > Davek > > > > > On 2/4/2010 9:54 AM, Edwin Commandeur wrote: > > Hi Robert, > > The WFS functionality is a recent contribution by Dave, maybe he > recognizes the problem easily. I still need to get working on a Java > port of the Open Proxy that is necessary for the WFS functionality and > that is included in the OpenLayers examples. > > How are you running your code? Is the Python Open Proxy implementation up? > > The dev list is not publicly visible as far as I am aware, but I have > cc'd this reply to the devl list. > > Greetings, > Edwin > > > On 4 February 2010 16:54, Robert Light<rob...@ve...> wrote: > > > Edwin, > > I think I've found a bug either in openlayers or in gwt-openlayers code. > > if I create a WFS layer: > WFSParams wfsParams = new WFSParams(); > wfsParams.setTypename("topp:states"); > WFSOptions wfsLayerOptions = new WFSOptions(); > wfsLayerOptions.setTransitionEffect(TransitionEffect.RESIZE); > wfsLayerOptions.setExtractAttributes(true); > > WFS wfsLayer = new WFS( > "states", > "http://192.168.1.167:8080/geoserver/wfs", > wfsParams, > wfsLayerOptions); > > and then I want to get selection events so I do: > > wfsLayer.addVectorFeatureSelectedListener( new > VectorFeatureSelectedListener() { > > public void onFeatureSelected(FeatureSelectedEvent > eventObject) { > JSONObject map = new > JSONObject(eventObject.getVectorFeature().getJSObject().getProperty("attributes")); > System.out.println("Feature.id = > "+eventObject.getVectorFeature().getId()); > for( String key : map.keySet()) { > System.out.println(key+"="+map.get(key)); > } > } > }); > > This does not work... my VectorFeatureSelectListener never get's called. > > To make this work, I had to add the following: > SelectFeatureOptions selectFeatureOptions = new > SelectFeatureOptions(); > selectFeatureOptions.onSelect( new > SelectFeature.SelectFeatureListener() { > > public void onFeatureSelected(VectorFeature vectorFeature) > { > JSONObject map = new > JSONObject(vectorFeature.getJSObject().getProperty("attributes")); > for( String key : map.keySet()) { > System.out.println(key+"="+map.get(key)); > } > } > }); > > SelectFeature selfeature = new SelectFeature(wfsLayer, > selectFeatureOptions); > map.getMap().addControl(selfeature); > selfeature.activate(); > > > And now BOTH my VectureFeatureSelectListener AND my SelectFeatureListener > get called when I select a feature. > > To put another wrinkle in the puzzle....instead of adding the SelectFeature > Control as above, I do just the following: > > SelectFeature selfeature = new SelectFeature(wfsLayer); > map.getMap().addControl(selfeature); > selfeature.activate(); > > My VectorFeatureSelectListener does NOT get called. > > Any ideas? Is there a developer's list I should post this query to? > > Note, I'm working off the latest set of sources that I downloaded via > mercurial. > > many thanks. > > - Bob Light > > > > |
8 messages has been excluded from this view by a project administrator.
