[OpenLayers-Dev] [OpenLayers-Trac] [OpenLayers] #1273: Support reprojection of vector layers

Christopher Schmidt crschmidt at metacarta.com
Mon Jan 21 08:41:22 EST 2008


For context, see http://trac.openlayers.org/ticket/1273

>> r5828 changes the behavior of Layer.GeoRSS by not loading the data when
>> the layer is added to the map any more. This breaks the
>> point-track-markers.html example (#1287). It might break other
>> applications as well.
>> 
>> I do not see the benefit of this change. I would not consider loading
>> the data when adding the layer to the map as a waste, because the amount
>> of data to load is the same for every extent (unlike e.g. Layer.WFS). Or
>> am I missing something here?
>
>  If I add 100 GeoRSS layers to a map, but keep them all turned off, they
>  will all be loaed 'immediately' -- even though the data is not yet used.
>  This has been brought up several times seperately, though I had not yet
>  opened a ticket or addressed it.
> 
>  This patch changes the Layer.GeoRSS behavior to match the Layer.GML
>  behavior, which also waits until it is visible or moved to request data
>  from the server.
> 
>  Even though the data is always valid for the whole extent, that oes not
>  mean it is neccesary to load even when it is turned off.
>  If I add 100 GeoRSS layers to a map, but keep them all turned off, they
>  will all be loaed 'immediately' -- even though the data is not yet used.
>  This has been brought up several times seperately, though I had not yet
>  opened a ticket or addressed it.
> 
>  This patch changes the Layer.GeoRSS behavior to match the Layer.GML
>  behavior, which also waits until it is visible or moved to request data
>  from the server.
> 
>  Even though the data is always valid for the whole extent, that oes not
>  mean it is neccesary to load even when it is turned off.
> 
>  The actual reason for this is described in the comments above: "In the
>  process of doing this, there is a minor refactor for the Text and GeoRSS
>  layers, so that they are not loaded at startup, but instead the first time
>  they are moved: this is so the projection information is available at the
>  time the format class is created."

Now, as to my opinion, rather than the facts: I believe that this is a
minor API break. However, I don't think that this is an API break which
we should be against making, because the current behavior has negative
effects for the above stated reasons, and because the issue is small and
easy to document. (As you can see, I've already added it to
http://trac.openlayers.org/wiki/Release/2.6/Notes .) 

However, I'm also amenable to an option-based approach: instead of
always delaying the load, I would be open to only delaying the load in
the case where a projection is defined or a 'delayLoad' flag is set to
true. I'm willing to do the work to add these options if people decide
that's the right way to go.

I probably should have made it more obvious that I was making this
change and let it percolate for longer; I was looking forward to getting
this change in because it's a significant step in being able to use data
from OpenStreetMap in OpenLayers maps, so I let my excitement get the
better of me. I'm perfectly willing to do refactoring to make this work
better, so long as there is *some* mechanism I can document where the
Format will automatically reproject, even if it's an extra options that
you have to enable.

Feedback is welcome.

Regards,
-- 
Christopher Schmidt
MetaCarta



More information about the Dev mailing list