[OpenLayers-Dev] Topology proposal

[Evan James Bowling]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/openlayers-dev/attachments/20090605/a8e44930/attachment.html