> > David brought up an additional problem, which is that if the new shapefile > has a substantially different schema, it can break styles that are > associated with that layer. > > "substantial" is vague and misleading here. The changes are easily > described and could be automatically detected with a bit of effort. > Style-breaking changes include - > * removing attributes > * changing the type of an existing attribute >
Thanks for these details, David. > If we want, we could even scan known styles and only flag as an error > changes to attributes that are actually used. > What do you think is the best way to go about setting the roadmap for this sort of thing? > What's the solution to this bug? > > I think that if the way that best short-term solution is to add whatever > error handling is needed for the broken styles to fail gracefully, and let > the user clean up after broken styles as needed. > > -0.5 > > I don't think that letting GeoNode users unwittingly break *other users' > maps* is a great way to go. imo, we should defer the layer replacement > feature until after the 1.0 release so we have time to implement some > complementary features to take off some of the rough edges. > I disagree with this for two reasons. First, whenever a map depends on a layer, that is going to involve a dependency on a resource managed by another person. There is no way that we are going to be able to prevent GeoNode users from inadvertently break other users' maps (users can upload consistent but otherwise bogus data sets; they can delete their layers, etc.) I think the only way we can "solve" this problem is by implementing a much richer system of dependency management than anyone's anticipated so far (but which could be a cool roadmap item.) Second, I think that replacing a layer is very important functionality for this round. The use case "I have an updated version of this layer; I would like to make sure people (and maps) have access to the most recent data" seems like one that would come up a lot if GeoNode were used by an institution with active GIS work. If we don't provide the 'Replace this data' feature, then the only other option available to the users is to delete the old map and upload a new one. I think this is a clumsy workflow to impose on people. Additionally, it makes it much harder to reuse styling work, because new styles are currently associated with layers. Consider: I upload the data haiti_roads. Then I spend several hours developing a complex style. Then i get an updated version of the data with the same schema. If I can replace the data in-place, then no problem. If I have to delete and reupload the layer, then I have to recreate the style because we don't currently support style uploading. Even if we did add that to the scope at the last minute, that would mean that this replacing data workflow would involve the additional steps of download an SLD and reuploading it. So, I'm +1 on the layer replacement feature being in 1.0 As for how to deal with the ugliness in the short term, I think it would be adequate to do the following: * Make it so that an informative error message is published in the layer's tiles when it is requested with an invalid style. * Putting a big text warning above the form used for layer replacement telling people that they should not replace a layer with one with a different schema or else their styles may fail. I think it would be great to handle this stuff better in a later milestone. -- Sebastian Benthall OpenGeo - http://opengeo.org
