[OpenLayers-Dev] Topology proposal

[Björn Harrtell]

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.harrtell at 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.dewit at 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.harrtell at 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 at openlayers.org
>>> http://openlayers.org/mailman/listinfo/dev
>>>
>>
>>
>