I think it makes perfect sense to separate the Topology component into its own Control. Were you able to alter the priority of the Snapping vs. Topology controls?
-Evan 2009/6/4 Björn Harrtell <bjorn.harrt...@gmail.com> > 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 >
_______________________________________________ Dev mailing list Dev@openlayers.org http://openlayers.org/mailman/listinfo/dev
