Some questions about WFS-T

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Some questions about WFS-T

aaime-2
Hi,
today I was trying Openlayers trunk, WFS-T and Geoserver; well, guess
what, I have some questions :-)
* there is no example I can see that allows to edit the attributes of
   a geometry, or edit an existing geometry. The WFS-T one seems to be
   dealing with just adding geometry. Missing functionality, or missing
   example?
* in the wfs-t example, once I select a tool, I cannot deactivate it
   anymore. I can commit transactions all right, but the editing tool
   remains active.
Oh, that was with firefox. If I use IE7 instead, I cannot even commit
the transaction, getting an error instead, whose rough translation to
english is "line 50, column 9, property or method not supported by the
object, code 0, URL: http://localhost:8080/geoserver/ol/gs-test/wfs-t.html".
Oh the wfs-t.html example is just the standard wfs-t page that's using
locahost:8080/geoserver instead of the online one.

Another thing I noticed, this time in the wfs-states.html sample, is
that while the states layer is loading, firefox is frozen, and
performing a CPU intensive task (I guess it's GML parsing).
The same goes with IE7, with the aggravation that IE suggests killing
the script that's blocking it (with a popup).

Cheers
Andrea
_______________________________________________
Dev mailing list
[hidden email]
http://openlayers.org/mailman/listinfo/dev
Reply | Threaded
Open this post in threaded view
|

Re: Some questions about WFS-T

Christopher Schmidt-2
On Mon, Apr 02, 2007 at 08:11:07PM +0200, Andrea Aime wrote:
> Hi,
> today I was trying Openlayers trunk, WFS-T and Geoserver; well, guess
> what, I have some questions :-)
> * there is no example I can see that allows to edit the attributes of
>    a geometry, or edit an existing geometry. The WFS-T one seems to be
>    dealing with just adding geometry. Missing functionality, or missing
>    example?

Editing attributes of a feature (features combine attributes, geometry,
and style) doesn't have a UI, but is available programmatically:
attributes are available via the 'attributes' property of the feature,
and are (hopefully) properly saved.

Editing geometry is not available in this release.

> * in the wfs-t example, once I select a tool, I cannot deactivate it
>    anymore. I can commit transactions all right, but the editing tool
>    remains active.

This looks like a recently introduced bug -- I know it worked at one
point ;) I'll poke at this a bit.

> Oh, that was with firefox. If I use IE7 instead, I cannot even commit
> the transaction, getting an error instead, whose rough translation to
> english is "line 50, column 9, property or method not supported by the
> object, code 0, URL: http://localhost:8080/geoserver/ol/gs-test/wfs-t.html".
> Oh the wfs-t.html example is just the standard wfs-t page that's using
> locahost:8080/geoserver instead of the online one.

"Internet Explorer does not have a built in XML Serializer, so it can
not save WFS-T payloads to a server via the 'commit' method on a WFS
layer." -- http://trac.openlayers.org/wiki/Release/2.4/Notes

http://trac.openlayers.org/ticket/535 is tracking for this, though it
appears this is actually more complex, since IE doesn't have support for
a number of methods used by the WFS format writer.

> Another thing I noticed, this time in the wfs-states.html sample, is
> that while the states layer is loading, firefox is frozen, and
> performing a CPU intensive task (I guess it's GML parsing).
> The same goes with IE7, with the aggravation that IE suggests killing
> the script that's blocking it (with a popup).

Yes. GML parsing is slow.

Regards,
--
Christopher Schmidt
MetaCarta
_______________________________________________
Dev mailing list
[hidden email]
http://openlayers.org/mailman/listinfo/dev
Reply | Threaded
Open this post in threaded view
|

Re: Some questions about WFS-T

aaime-2
Christopher Schmidt ha scritto:

>> Another thing I noticed, this time in the wfs-states.html sample, is
>> that while the states layer is loading, firefox is frozen, and
>> performing a CPU intensive task (I guess it's GML parsing).
>> The same goes with IE7, with the aggravation that IE suggests killing
>> the script that's blocking it (with a popup).
>
> Yes. GML parsing is slow.

I'm under the impression that you're requesting all the properties
from a WFS layer, while using only the geometric one (the first you
find I guess, since there may be many) to depict the layer.
It would be better to just load what you need, and then eventually
load the full feature on demand. On a layer with a crazy number
of properties like states (more than 100 if I remember properly)
it should help.

Cheers
Andrea
_______________________________________________
Dev mailing list
[hidden email]
http://openlayers.org/mailman/listinfo/dev
Reply | Threaded
Open this post in threaded view
|

Re: Some questions about WFS-T

Christopher Schmidt-2
On Mon, Apr 02, 2007 at 10:00:34PM +0200, Andrea Aime wrote:

> Christopher Schmidt ha scritto:
>
> >>Another thing I noticed, this time in the wfs-states.html sample, is
> >>that while the states layer is loading, firefox is frozen, and
> >>performing a CPU intensive task (I guess it's GML parsing).
> >>The same goes with IE7, with the aggravation that IE suggests killing
> >>the script that's blocking it (with a popup).
> >
> >Yes. GML parsing is slow.
>
> I'm under the impression that you're requesting all the properties
> from a WFS layer, while using only the geometric one (the first you
> find I guess, since there may be many) to depict the layer.
> It would be better to just load what you need, and then eventually
> load the full feature on demand. On a layer with a crazy number
> of properties like states (more than 100 if I remember properly)
> it should help.

Nope. The states example doesn't load any attributes. The data may be
there: it's not parsed by default -- only if you turn on the
extractAttributes option on the layer.

Parsing the coordinate string is usually the worst of it, but there's
also a pathological bad behavior with large polygons (in the thousands
of coordinates range), though I'm not sure if that is triggered here.

Regards,
--
Christopher Schmidt
MetaCarta
_______________________________________________
Dev mailing list
[hidden email]
http://openlayers.org/mailman/listinfo/dev