Not yet, but I was informed by Tim Schaub about the registerPriority method on the Event class. I suspect that snapping needs the priority though, but that's a bit of a guess right now.
I made an effort towards the Control-implementation in sandbox which I'm reasonably happy with and the code now tries to follow the coding standards of OL, so I guess the only thing missing now from the implementation is testcases. That might take a while for me so I'll probably create an initial patch for review and discussion against post 2.8 trunk when 2.8 is released. /Björn On Fri, Jun 5, 2009 at 17:20, Evan James Bowling<evan.bowl...@gmail.com> wrote: > 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
