[OpenLayers-Dev] Topology proposal

[Roald de Wit]

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
>