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
