I've rewritten the implementation so that topology isn't calculated on the fly, which I think might solve the problem discussed below and also improves performance.
In doing this I got to think about the initial proposal. A redesign that popped up in my head is to remove the idea that rules are applied to a Vector layer and instead add a new Control called Topology that controls the enforcement and renderIntent-stuff for the supplied layer (or layer) The basic idea with the above is to be able to leave the Vector Layer completely unmodified (it's large as it is :) and also put all user configurable interaction with the functionality in the control instead of manipulating the rule. Any opinions? /Björn 2009/6/4 Björn Harrtell <bjorn.harrt...@gmail.com>: > The issue you describe is probably caused by conflicts between > snapping and topology enforcement, more specifically both snapping and > topology enforcement listen on vertexmodified-events and the order of > this combined logic is significant. I haven't investigated if I can > control priority of my event listener, but if that's possible I think > it would solve the problems. > > On another note, the sandbox and example is now updated with an > initial implementation of the renderIntent-idea which means that at > each completed feature modification the state of topology will be > calculated and polygon that does not satisfy the rule will be set into > the renderIntent state "error" and will be colored in red. > > /Björn > > On Wed, Jun 3, 2009 at 00:21, Roald de Wit <roald.de...@lisasoft.com> wrote: >> Hi Björn, >> >> Great initiative! Topology preserving editing functionality would be a very >> valuably contribution to OL (IMHO). >> I did notice that when you edit one feature, then uncheck 'enforce >> topology', edit a bit more (by moving vertices) and then check 'enforce >> topology' again, the enforcing does not work anymore when you move more than >> the snapping threshold. I know this is work in progress, so you might be >> aware of it already. >> >> I'm sure that more than 1 person (2 now, including me) will be interested in >> your work! >> >> Regards, Roald >> >> >> Björn Harrtell wrote: >>> >>> Since I got at least one (and hopefully more :) interested person(s) >>> in the details I'm posting this information about my initial >>> implementation of the below proposal using using events in this >>> sandbox: >>> >>> http://dev.openlayers.org/sandbox/bjornharrtell/eventbasedtopology >>> >>> Check out the example at >>> >>> http://dev.openlayers.org/sandbox/bjornharrtell/eventbasedtopology/examples/topology.html >>> to see the implementation in effect. >>> >>> The only change from the initial proposal is that >>> OpenLayers.Control.ModifyFeature essentially does not have to be >>> modified, which is made possible by basing the implementation on the >>> vertexmodified event - though I do have added and are using >>> delta-movement information to the vertexmodified event-message, which >>> required small changes in DragFeature and ModifyFeature controls to >>> fill in this information. >>> >>> New classes are: >>> OpenLayers.Topology >>> OpenLayers.Topology.Rule >>> OpenLayers.Topology.Rule.VerticesMustIntersect >>> >>> The implementation is dynamic which means that the topology rule is >>> evaluated at each change of the geometry which I think should be >>> optional since this can be costly with more complex geometry and can >>> cause wierd side-effects when using snapping for instance. I'd like to >>> add some kind of caching in the future that would require manual or >>> semi-manual update of the topology state. >>> >>> The render intent stuff is not done yet. >>> >>> Forgive me if I've forgot some detail in the above description :) >>> >>> /Björn >>> >>> 2009/4/22 Björn Harrtell <bjorn.harrt...@gmail.com>: >>> >>>> >>>> Hi devs, >>>> >>>> I want to make an effort to implement a topology restriction in >>>> OpenLayers (specifically that polygons must share vertices). The ideal >>>> would be something that is reusable for other topology rules than the >>>> one I want to implement at first and my intent is to build it so that >>>> it can be contributed as a patch. I've discussed the matter with Tim >>>> briefly and here is my rough initial design proposal. Any feedback >>>> will of course be appreciated. >>>> >>>> I wanted to add this to the wiki at Proposal/Topology but seems I >>>> can't create new wikipages even when I'm logged in, or I'm missing >>>> something. So here is it: >>>> >>>> * Represent topology rules as classes in namespace >>>> OpenLayers.Topology.Rule with a base class OpenLayers.Topology.Rule (I >>>> don't really like using the same identifier as a namespace and class, >>>> but I think this is the convention in OpenLayers?). The base class >>>> should provide an interface for checking feature(s) for topology >>>> errors and optionally set the render intent and return the violating >>>> features. >>>> >>>> * Add a render intent for indicating topology violation >>>> >>>> * Add topologyRules property to OpenLayers.Layer.Vector as an optional >>>> array of topology classes to associate with the layer >>>> >>>> * Add topologyAutoCheck boolean property to OpenLayers.Layer.Vector to >>>> indicate if a vector layer automatically should update the topology >>>> render intent on feature changes (default false) >>>> >>>> * Add enforceTopology boolean property to >>>> OpenLayers.Control.ModifyFeature to restrict edits to follow the >>>> topology rule by either automatically snapping stuff (if possible) or >>>> disallowing the interaction. >>>> >>>> * The first rule to be implemented is that polygons must share >>>> vertices, suggested name is >>>> OpenLayers.Topology.Rules.PolygonsMustShareVertices >>>> >>>> Motivations: >>>> >>>> * Topology rules could be constant enums instead of classes, the >>>> reasons for suggesting classes are to make it more clear that the rule >>>> should contain as much of the implementation as possible and that one >>>> might want to make OL-builds containing only the rules that are >>>> relevant for the use case. >>>> >>>> Uncertainties: >>>> >>>> * Where to put the logic that restricts editing - I'm not sure if it's >>>> possible to separate it without creating a dependency mess between >>>> ModifyControl and the topology rule. >>>> >>>> With regards, >>>> >>>> Björn Harrtell >>>> >>>> >>> >>> _______________________________________________ >>> Dev mailing list >>> Dev@openlayers.org >>> http://openlayers.org/mailman/listinfo/dev >>> >> >> > _______________________________________________ Dev mailing list Dev@openlayers.org http://openlayers.org/mailman/listinfo/dev
