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