Thanks Eric :) Details are important, though I would argue that OpenLayers.TopologyRule is only one char shorter than OpenLayers.Topology.Rule ;)
I've improved the current sandbox code (optimizations and bugfixes) and I'm using registerPriority which does seem to fix the problems when using the splitting control at the same time. Two random thoughts: 1. Does the topology stuff really fit into OpenLayers or should be done as an add-in? Might become alot of code if many rules are done... 2. The current implementation calculates topology state as a cache separate from the basic geometry types. The dynamic nature of javascript might allow "real" topology.. by this I mean that for example a Point-instance could be shared between two different LineString-instances. but I haven't tested this at all and would complicate feature manipulation and communication with a backend via WFS. /Björn On Tue, Jun 9, 2009 at 08:01, Eric Lemoine<eric.lemo...@camptocamp.com> wrote: > On Saturday, June 6, 2009, Björn Harrtell <bjorn.harrt...@gmail.com> wrote: >> Not yet, but I was informed by Tim Schaub about the registerPriority >> method on the Event class > > for some reason I dont know this method is marked "3.0 remove" IIRC. > >> 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. > > This is great work Björn! > > I haven't looked at your code, so I'd just have one unimportant > comment: do you envision other stuff than Rule under the > OpenLayers.Topology namespace? If not I'd rather go with > OpenLayers.TopologyRule to keep namespace depth minimal. What do you > think? > > > >> >> /Björn >> >> On Fri, Jun 5, 2009 at 17:20, Evan James Bowling<evan.bowl...@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.harrt...@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.harrt...@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.de...@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 t > > -- > Eric Lemoine > > Camptocamp France SAS > Savoie Technolac, BP 352 > 73377 Le Bourget du Lac, Cedex > > Tel : 00 33 4 79 44 44 96 > Mail : eric.lemo...@camptocamp.com > http://www.camptocamp.com > _______________________________________________ Dev mailing list Dev@openlayers.org http://openlayers.org/mailman/listinfo/dev
