Hace relativamente poco vi por primera vez este mensaje en gvSIG, al intentar poner en edición una capa vectorial reproyectada al vuelo:
Si uno lo piensa, se da cuenta de que nunca o casi nunca puede tener sentido poner en edición una capa cuyo SRS en origen es diferente al de la vista. La edición es algo parecido a la cirugía. No tiene sentido afinar a mano la posición de los vértices para después reproyectar a otro SRS, cuando sabemos que esta reproyección va a introducir errores casi con toda seguridad. Por otro lado, el implementar la edición y la reproyección simultáneas, aunque pueda parecer sencillo, nos lleva a dificultades inesperadas: ¿qué pasa si se trata de una reproyección con parámetros especiales o con rejilla? ¿sabremos siempre calcular esa reproyección inversa? ¿es posible que la reproyección inversa sea más imprecisa que la reproyección directa original? etc. Al final, estamos dedicando recursos a intentar resolver un problema al cual no deberíamos haber llegado. Como dice el diálogo, lo razonable es reproyectar primero la capa y editarla después, o viceversa.
Edición de capas gigantes
Otro caso quizá no tan claro es el permitir que se ponga en edición una capa con varios cientos de miles de geometrías. Hay dos casos mucho más comunes que el resto: editar un shapefile gigante (que es relativamente factible, salvo casos verdaderamente extremos) o bien editar una capa GeoBD gigante (generalmente PostGIS u Oracle Spatial).
Este segundo caso sí da problemas graves en un número no pequeño de casos, puesto que no es raro tener una base de datos geométrica en la que hay tablas con cientos de miles o incluso millones de registros.
Afortunadamente, el diálogo de creación de capas GeoBD prevé la inserción de restricciones geométricas o alfanuméricas en el momento de añadirlas a nuestra vista, de modo que la capa creada es relativamente ligera en comparación con la tabla enorme en la que se apoya. Esa es, en mi opinión, la vía correcta para editar tablas geométricas gigantes, y hacia ahí hay que procurar reconducir al usuario. Llegado el caso, habría que mostrar al usuario un mensaje que dijera por ejemplo: “No es posible iniciar la edición de esta capa GeoBD porque tiene más de 300.000 registros”. El umbral no permitido podría calcularse en el momento, dependiendo por ejemplo de la potencia del PC, o se le podría preguntar a la capa (es decir, al driver) si en la actual situación (número de registros y vértices, velocidad estimada de la red) se considera capaz de aceptar el modo de edición.
¿Una negativa es siempre mala?
Si permitimos que el usuario use opciones en condiciones que nos llevan a procesos larguísimos o muy complejos, nos arriesgamos a que el comportamiento de la aplicación sea substandard, como diría Steve Jobs, es decir, no usable, de modo que el usuario se frustra porque no se da cuenta de que lo que ha pedido implica una cantidad de cálculos inimaginable, y además hay otras vías mucho más adecuadas para conseguir lo mismo. A partir de ese momento, ese usuario va a difundir la idea de que la aplicación no funciona bien, y si por casualidad tiene un blog con unas cuantas visitas al mes, el daño puede ser tremendo.
En cambio, si denegamos la petición (o al menos informamos de que lo que va a hacer es poco recomendable y le ofrecemos una alternativa explicada en un diálogo informativo), estamos evitando esa situación de la que no saldremos bien parados.
Por decirlo (quizá) exageradamente: en el 98% de los casos, el usuario no necesita editar una capa reproyectada al vuelo ni poner en edición un millón de geometrías, y se le puede y debe reconducir a la opción razonable. En el 1% de los casos, se trata de un usuario curioso que prueba casos extremos para ver cómo se las arregla la aplicación, y sólo en el 1% restante se trata de usuarios que realmente necesitan poner en marcha esos procesos tan exigentes, y además han sido capaces de hacerlo antes con algún otro software. En este último caso, se trata objetivamente de una derrota nuestra, pero casi siempre habrá otro motivo por el cual gvSIG es preferible: su licencia GPL, sus muchas otras funcionalidades, el tamaño de la comunidad, etc.
