Ticket #1547 (new feature)

Opened 5 years ago

Last modified 3 years ago

Format.GML: introduce option to postpone parsing of the geometries

Reported by: bartvde Owned by: tschaub
Priority: minor Milestone: 2.13 Release
Component: Format.GML Version: 2.6
Keywords: Cc:
State: Needs More Work

Description

This is not the most common use-case, but it is one IMHO. Imagine you want to use Format.GML to fill an attribute table. Now the parsing of geometries can be quite consuming, and you might want to postpone the parsing until it is really necessary, e.g. when the user presses the highlight feature button in the toolbar above the grid. Currently there is no way to do this.

My proposal would be to introduce a property for this, and to cache the DOMElement on the feature so it can be easily parsed later on when necessary.

Attachments

ticket1547.patch Download (3.2 KB) - added by bartvde 5 years ago.
fixed a bug in the patch

Change History

Changed 5 years ago by bartvde

  • keywords needs discussion added

I've attached a proposed patch. Things which need discussion:

1) is it okay to add properties to OpenLayers.Feature.Vector which are not advertized in that class? I want to cache the geometryNode, and I named the property feature.geometryNode. But I don't know if this is allowed without specifying it in Vector.js.

2) maybe it's necessary to create another APIProperty called cacheGeometryNode? Now by default I cache the node when parseGeometry is false, but maybe this is not flexible enough and we need an extra property to control the caching?

An example usage is:

            var gmlParser = new OpenLayers.Format.GML();
            var feature = row.get('feature');
            if (!feature.geometry) {
                var type = feature.geometryNode.type;
                var parser = gmlParser.parseGeometry[type.toLowerCase()];
                if(parser) {
                    var geometry = parser.apply(gmlParser,
                        [feature.geometryNode.node]);
                    feature.geometry = geometry;
                    this.layer.addFeatures(feature);
                }
            } else {
                this.layer.addFeatures(feature);
            }

Changed 5 years ago by bartvde

  • keywords needs discussion removed
  • state set to Needs Discussion

Changed 5 years ago by bartvde

  • milestone set to 2.7 Release

Changed 5 years ago by crschmidt

The answer to the former is 'Yes, that's fine', the answer to the latter is, in my mind, 'no, we don't need that.'

Changed 5 years ago by euzuro

  • state changed from Needs Discussion to Needs More Work
  • milestone changed from 2.7 Release to 2.8 Release

Changed 5 years ago by bartvde

fixed a bug in the patch

Changed 4 years ago by crschmidt

Has had work since 2.7; someone want to comment on the current state?

Changed 4 years ago by crschmidt

  • milestone changed from 2.8 Release to 2.9 Release

So, chatting on this with Tim, we discussed that the right thing to do here is probably:

  • Cause OpenLayers geometry access to be through an accessor method, like Geometry.getGeometry()
  • If geometry parsing is delayed, stash an XML node or some such on the object
  • Allow getGeometry to create the geometry ondemand

I'm not entirely sure how we'd implement the latter; perhaps a bound callback that could be passed the geometry to create it?

In any case, I'm not in a position to reiew this, and I think Tim wuld rather a different implementation; with that in mind, I'm kicking this out of 2.8 for further discussion. Bart, if you start/restart a thread on the mailing list about it, we can discuss implementation there; I'll even participate :)

Changed 3 years ago by bartvde

  • milestone changed from 2.9 Release to 2.10 Release
Note: See TracTickets for help on using tickets.