This design makes sense to me. Regarding the strategy: are you thinking of a projection strategy that will listen on beforefeaturesadded and, if the layer proj isn't the same as the map proj, will reproject the features before they're added to the layer? Such a strategy would be useful when the data isn't read through a format.
Eric 2008/11/11, Tim Schaub <[EMAIL PROTECTED]>: > Hey- > > Picking up on the thread that Bart just referenced: > http://www.mail-archive.com/dev@openlayers.org/msg02523.html > > I agree, we should keep track of projection at the geometry level. > > There are plenty of times that you have a geometry without a feature or > a layer, and you want to maintain the srs info for that geometry. > > I've always thought this change would come with 3.0. But it probably > makes sense to start working it in to see how things go. > > Seems to me like we need a setter and getter. So the following would work: > > polygon.setProjection(foo); > polygon.components[0].components[0].getProjection(); // foo > > And it makes sense to me to push the work on to the setter (setting the > same on all components), making access less work. > > I think it also makes sense to me that the layer does not set the > geometry projection. We assume that geometry projection is properly set > before a feature is added to a layer. This pushes the setting or > transforming closer to the parsing (where it makes sense that you'd know > the projection). > > In some cases, a format would do the transform (assuming > internal/externalProjection are set). In other cases, a strategy could > do the transform (since it knows the map projection and the layer > projection - where the layer projection should be set to match the source). > > I'm sure there's lots more to talk about. This is what a sprint is good > for. Without that, it probably makes sense to get some code going and > see where it takes us. To this end, I've created a new sandbox [1]. I > won't have any time for a bit to work on it, but I'll be happy to comment. > > Tim > > [1] http://svn.openlayers.org/sandbox/projection > > > -- > Tim Schaub > OpenGeo - http://opengeo.org > Expert service straight from the developers. > _______________________________________________ > Dev mailing list > Dev@openlayers.org > http://openlayers.org/mailman/listinfo/dev > _______________________________________________ Dev mailing list Dev@openlayers.org http://openlayers.org/mailman/listinfo/dev
