[OpenLayers-Dev] Topology proposal

Fri Jun 5 20:21:29 EDT 2009

Not yet, but I was informed by Tim Schaub about the registerPriority
method on the Event class. I suspect that snapping needs the priority
though, but that's a bit of a guess right now.

I made an effort towards the Control-implementation in sandbox which
I'm reasonably happy with and the code now tries to follow the coding
standards of OL, so I guess the only thing missing now from the
implementation is testcases. That might take a while for me so I'll
probably create an initial patch for review and discussion against
post 2.8 trunk when 2.8 is released.

/Björn

On Fri, Jun 5, 2009 at 17:20, Evan James Bowling<evan.bowling at gmail.com> wrote:
> I think it makes perfect sense to separate the Topology component into its
> own Control. Were you able to alter the priority of the Snapping vs.
> Topology controls?
>
> -Evan
>
> 2009/6/4 Björn Harrtell <bjorn.harrtell at gmail.com>
>>
>> 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
>> >>>
>> >>
>> >>
>> >
>> _______________________________________________
>> Dev mailing list
>> Dev at openlayers.org
>> http://openlayers.org/mailman/listinfo/dev
>
>