[OpenLayers-Dev] Topology proposal

[Björn Harrtell]

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
>>
>
>