[OpenLayers-Dev] Topology proposal

Tue Jun 9 08:08:06 EDT 2009

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.lemoine at camptocamp.com> wrote:
> On Saturday, June 6, 2009, Björn Harrtell <bjorn.harrtell at 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.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 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.lemoine at camptocamp.com
> http://www.camptocamp.com
>