I think it makes perfect sense to separate the Topology component into its<br>own Control. Were you able to alter the priority of the Snapping vs. <br>Topology controls?<br><br>-Evan<br><br><div class="gmail_quote">2009/6/4 Björn Harrtell <span dir="ltr">&lt;<a href="mailto:bjorn.harrtell@gmail.com">bjorn.harrtell@gmail.com</a>&gt;</span><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I&#39;ve rewritten the implementation so that topology isn&#39;t calculated on<br>
the fly, which I think might solve the problem discussed below and<br>
also improves performance.<br>
<br>
In doing this I got to think about the initial proposal. A redesign<br>
that popped up in my head is to remove the idea that rules are applied<br>
to a Vector layer and instead add a new Control called Topology that<br>
controls the enforcement and renderIntent-stuff for the supplied layer<br>
(or layer)<br>
<br>
The basic idea with the above is to be able to leave the Vector Layer<br>
completely unmodified (it&#39;s large as it is :) and also put all user<br>
configurable interaction with the functionality in the control instead<br>
of manipulating the rule. Any opinions?<br>
<br>
/Björn<br>
<br>
2009/6/4 Björn Harrtell &lt;<a href="mailto:bjorn.harrtell@gmail.com">bjorn.harrtell@gmail.com</a>&gt;:<br>
<div><div></div><div class="h5">&gt; The issue you describe is probably caused by conflicts between<br>
&gt; snapping and topology enforcement, more specifically both snapping and<br>
&gt; topology enforcement listen on vertexmodified-events and the order of<br>
&gt; this combined logic is significant. I haven&#39;t investigated if I can<br>
&gt; control priority of my event listener, but if that&#39;s possible I think<br>
&gt; it would solve the problems.<br>
&gt;<br>
&gt; On another note, the sandbox and example is now updated with an<br>
&gt; initial implementation of the renderIntent-idea which means that at<br>
&gt; each completed feature modification the state of topology will be<br>
&gt; calculated and polygon that does not satisfy the rule will be set into<br>
&gt; the renderIntent state &quot;error&quot; and will be colored in red.<br>
&gt;<br>
&gt; /Björn<br>
&gt;<br>
&gt; On Wed, Jun 3, 2009 at 00:21, Roald de Wit &lt;<a href="mailto:roald.dewit@lisasoft.com">roald.dewit@lisasoft.com</a>&gt; wrote:<br>
&gt;&gt; Hi Björn,<br>
&gt;&gt;<br>
&gt;&gt; Great initiative! Topology preserving editing functionality would be a very<br>
&gt;&gt; valuably contribution to OL (IMHO).<br>
&gt;&gt; I did notice that when you edit one feature, then uncheck &#39;enforce<br>
&gt;&gt; topology&#39;, edit a bit more (by moving vertices) and then check &#39;enforce<br>
&gt;&gt; topology&#39; again, the enforcing does not work anymore when you move more than<br>
&gt;&gt; the snapping threshold. I know this is work in progress, so you might be<br>
&gt;&gt; aware of it already.<br>
&gt;&gt;<br>
&gt;&gt; I&#39;m sure that more than 1 person (2 now, including me) will be interested in<br>
&gt;&gt; your work!<br>
&gt;&gt;<br>
&gt;&gt; Regards, Roald<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; Björn Harrtell wrote:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Since I got at least one (and hopefully more :) interested person(s)<br>
&gt;&gt;&gt; in the details I&#39;m posting this information about my initial<br>
&gt;&gt;&gt; implementation of the below proposal using using events in this<br>
&gt;&gt;&gt; sandbox:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; <a href="http://dev.openlayers.org/sandbox/bjornharrtell/eventbasedtopology" target="_blank">http://dev.openlayers.org/sandbox/bjornharrtell/eventbasedtopology</a><br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Check out the example at<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; <a href="http://dev.openlayers.org/sandbox/bjornharrtell/eventbasedtopology/examples/topology.html" target="_blank">http://dev.openlayers.org/sandbox/bjornharrtell/eventbasedtopology/examples/topology.html</a><br>

&gt;&gt;&gt; to see the implementation in effect.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; The only change from the initial proposal is that<br>
&gt;&gt;&gt; OpenLayers.Control.ModifyFeature essentially does not have to be<br>
&gt;&gt;&gt; modified, which is made possible by basing the implementation on the<br>
&gt;&gt;&gt; vertexmodified event - though I do have added and are using<br>
&gt;&gt;&gt; delta-movement information to the vertexmodified event-message, which<br>
&gt;&gt;&gt; required small changes in DragFeature and ModifyFeature controls to<br>
&gt;&gt;&gt; fill in this information.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; New classes are:<br>
&gt;&gt;&gt; OpenLayers.Topology<br>
&gt;&gt;&gt; OpenLayers.Topology.Rule<br>
&gt;&gt;&gt; OpenLayers.Topology.Rule.VerticesMustIntersect<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; The implementation is dynamic which means that the topology rule is<br>
&gt;&gt;&gt; evaluated at each change of the geometry which I think should be<br>
&gt;&gt;&gt; optional since this can be costly with more complex geometry and can<br>
&gt;&gt;&gt; cause wierd side-effects when using snapping for instance. I&#39;d like to<br>
&gt;&gt;&gt; add some kind of caching in the future that would require manual or<br>
&gt;&gt;&gt; semi-manual update of the topology state.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; The render intent stuff is not done yet.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Forgive me if I&#39;ve forgot some detail in the above description :)<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; /Björn<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; 2009/4/22 Björn Harrtell &lt;<a href="mailto:bjorn.harrtell@gmail.com">bjorn.harrtell@gmail.com</a>&gt;:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; Hi devs,<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; I want to make an effort to implement a topology restriction in<br>
&gt;&gt;&gt;&gt; OpenLayers (specifically that polygons must share vertices). The ideal<br>
&gt;&gt;&gt;&gt; would be something that is reusable for other topology rules than the<br>
&gt;&gt;&gt;&gt; one I want to implement at first and my intent is to build it so that<br>
&gt;&gt;&gt;&gt; it can be contributed as a patch. I&#39;ve discussed the matter with Tim<br>
&gt;&gt;&gt;&gt; briefly and here is my rough initial design proposal. Any feedback<br>
&gt;&gt;&gt;&gt; will of course be appreciated.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; I wanted to add this to the wiki at Proposal/Topology but seems I<br>
&gt;&gt;&gt;&gt; can&#39;t create new wikipages even when I&#39;m logged in, or I&#39;m missing<br>
&gt;&gt;&gt;&gt; something. So here is it:<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; * Represent topology rules as classes in namespace<br>
&gt;&gt;&gt;&gt; OpenLayers.Topology.Rule with a base class OpenLayers.Topology.Rule (I<br>
&gt;&gt;&gt;&gt; don&#39;t really like using the same identifier as a namespace and class,<br>
&gt;&gt;&gt;&gt; but I think this is the convention in OpenLayers?). The base class<br>
&gt;&gt;&gt;&gt; should provide an interface for checking feature(s) for topology<br>
&gt;&gt;&gt;&gt; errors and optionally set the render intent and return the violating<br>
&gt;&gt;&gt;&gt; features.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; * Add a render intent for indicating topology violation<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; * Add topologyRules property to OpenLayers.Layer.Vector as an optional<br>
&gt;&gt;&gt;&gt; array of topology classes to associate with the layer<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; * Add topologyAutoCheck boolean property to OpenLayers.Layer.Vector to<br>
&gt;&gt;&gt;&gt; indicate if a vector layer automatically should update the topology<br>
&gt;&gt;&gt;&gt; render intent on feature changes (default false)<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; * Add enforceTopology boolean property to<br>
&gt;&gt;&gt;&gt; OpenLayers.Control.ModifyFeature to restrict edits to follow the<br>
&gt;&gt;&gt;&gt; topology rule by either automatically snapping stuff (if possible) or<br>
&gt;&gt;&gt;&gt; disallowing the interaction.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; * The first rule to be implemented is that polygons must share<br>
&gt;&gt;&gt;&gt; vertices, suggested name is<br>
&gt;&gt;&gt;&gt; OpenLayers.Topology.Rules.PolygonsMustShareVertices<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; Motivations:<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; * Topology rules could be constant enums instead of classes, the<br>
&gt;&gt;&gt;&gt; reasons for suggesting classes are to make it more clear that the rule<br>
&gt;&gt;&gt;&gt; should contain as much of the implementation as possible and that one<br>
&gt;&gt;&gt;&gt; might want to make OL-builds containing only the rules that are<br>
&gt;&gt;&gt;&gt; relevant for the use case.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; Uncertainties:<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; * Where to put the logic that restricts editing - I&#39;m not sure if it&#39;s<br>
&gt;&gt;&gt;&gt; possible to separate it without creating a dependency mess between<br>
&gt;&gt;&gt;&gt; ModifyControl and the topology rule.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; With regards,<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; Björn Harrtell<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; _______________________________________________<br>
&gt;&gt;&gt; Dev mailing list<br>
&gt;&gt;&gt; <a href="mailto:Dev@openlayers.org">Dev@openlayers.org</a><br>
&gt;&gt;&gt; <a href="http://openlayers.org/mailman/listinfo/dev" target="_blank">http://openlayers.org/mailman/listinfo/dev</a><br>
&gt;&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;<br>
_______________________________________________<br>
Dev mailing list<br>
<a href="mailto:Dev@openlayers.org">Dev@openlayers.org</a><br>
<a href="http://openlayers.org/mailman/listinfo/dev" target="_blank">http://openlayers.org/mailman/listinfo/dev</a><br>
</div></div></blockquote></div><br>