5 votos

¿Debe cambiar de ArcMap a QGIS?

Antecedentes: Nuestro grupo tiene plena ESRI licencias y aplicaciones construidas con ArcDesktop.

Estamos invertido en el arco de la geodatabase en sí mismo y no va a cambiar ese nivel.

Hay una propuesta para cambiar de ARCO aplicaciones para QGIS y QT con el uso de la geodatabase de ESRI.

Hay un empuje para:

Ser una plataforma agnóstica: Problemas cuando windows (lado del cliente) se mueve OS.

La verdadera separación entre el software de niveles - Este argumento no es fuerte para el caso, ya que esto puede lograrse de muchas maneras. Mejores prácticas de programación, políticas, etc.

El abandono de la dependencia de Microsoft: - en la actualidad el código está escrito en su mayoría en VB y C++. Hay algo de python, pero no mucho.

El fondo de idiomas aquí es python y C++.

Pregunta: Hay un beneficio para hacer este cambio? No creo que la licencia va a cambiar, pero nos puede dar un código fuente para todas las plataformas.


Gracias a todos por los comentarios. El empuje para que el cambio no es debido a que el backend, pero para la interfaz de cliente y los costos de licencia. Sus respuestas me han ayudado a hacer las preguntas correctas.

11voto

mapBaker Puntos 5348

No es fácil cambiar a QGIS si te has decidido a permanecer invertido en el Arco de la Geodatabase. Yo diría que no hay que cambiar. Vas a tener más problemas con la mezcla de las tecnologías que valdría la pena.

La Geodatabase de ESRI es una base de datos destinado a trabajar con el de la plataforma de ESRI. Aunque no es un 'plugin' para QGIS para utilizar una geodatabase de archivos, no es (como se sugirió anteriormente) ninguna de las funciones de edición dentro de QGIS, y veo muchos errores reportados en este foro relacionados con QGIS y la Geodatabase de Archivos. (Además, vea la nota en la parte inferior de esta respuesta en simplemente moviendo los flujos de trabajo de código abierto...)

Para nosotros, estamos cambiando a una base de datos espaciales de flujo de trabajo, en lugar de una geodatabase de flujo de trabajo. Esto significa que el movimiento de datos en Microsoft SQL Espacial por lo que podemos utilizar el SQL espacial de las capacidades de una base de datos espaciales. Este flujo de trabajo se basa en PostGIS y un sistema de la empresa donde espacial de los datos es tratado como cualquier otro tipo de datos (frente a un modelo en el que los datos espaciales es el principal tipo de datos, y nada, es sólo un "atributo").

Sin embargo, a pesar de que estamos siendo capaces de utilizar el poder de la base de datos espaciales, que nos puede llevar a los resultados de las consultas, personalizada tablas espaciales construido en vistas de SQL que contiene los datos espaciales, etc., en ArcMap para la visualización y la otra de geoprocesamiento y análisis, así como la publicación de estas tablas para ArcGIS Server.

¿Por qué no podemos mover con el open source? Nuestro sistema de información del estudiante se basa en Microsoft SQL Server. El cambio a un total de código abierto pila cortar los lazos con este sistema (por ejemplo: PostgreSQL no tiene un MSSQL contenedor, y no quiero tirar de millones de registros en Postgresql sobre una base regular cuando el propietario de la pila funciona muy bien para lo que tenemos). Si yo tuviera a mi manera, el sistema completo que residen en el open source, a partir de la base de datos para el escritorio 'SIG' cliente, el servidor de mapas, que en la parte delantera. No quiero usar el Folleto de la API de ArcGIS server, porque no tiene tareas de consulta!

Hay un montón de hablar de la fusión de la fuente abierta y los modelos de propiedad, pero no estoy para eso. Como he dicho en este foro antes, el solo hecho de cambiar los flujos de trabajo de ArcGIS para el software de código abierto no da toda la potencia de la open source geospatial flujo de trabajo de un sistema como PostGIS ofrece...

6voto

Hameno Puntos 129

Beneficios para la conmutación:

  1. No hay costo de la licencia por usuario!
  2. Puede integrarse con otras aplicaciones de código abierto. (por ejemplo, GeoServer, MapServer, PostGIS, etc..)
  3. El Plug-in de idioma construido en C++/python (pyQGIS)
  4. No se como buggy

La desventaja para el cambio:

  1. La curva de aprendizaje para los usuarios y desarrolladores
  2. No se puede editar el Archivo GDB de datos, tendrá que cambiar a Postgresql/PostGIS o SQLite DB
  3. La migración de secuencias de comandos de arcpy a pyQGIS

3voto

rg255 Puntos 111

Las dos razones principales (de los muchos) para hacer esto son:

  1. Costo

Licencia de Software de costos. QGIS proporcionará costo mucho más bajo precio de compra del software, pero usted tendrá que peso, esto junto con el personal de los costes de formación (¿la necesidad de formar a todo el mundo?), los costos de apoyo (en la actualidad ESRI ofrece soporte de software como parte de su licencia), los costos de programación (¿tienes hundreda de secuencias de comandos que se necesitan para ser reescrita?) y otra más difícil a medida de software libre de los costos. Sólo porque las licencias son gratis no significa que los costos son siempre más bajos.

  1. La personalización y la Propiedad

Software libre generales permite la modificación más que comercial de la OET de productos SIG tales como ArcGIS. Si la propiedad del código y la modificación de los derechos son importantes (y a veces el código de transparencia, aunque en realidad muchas de software libre son peores que los de ESRI en este), luego de conmutación puede ser más atractivo.

Si usted es una gran empresa que me gustaría recomendar un total de necesidades y análisis de costos.

Como el Rebelde unidos, me pregunto por qué tendría que permanecer con la geodatabase de ESRI. Seguramente el cambio a un software libre espacial DB sería la forma de proceder en caso de que usted transición.

i-Ciencias.com

I-Ciencias es una comunidad de estudiantes y amantes de la ciencia en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros usuarios, hacer tus propias preguntas o resolver las de los demás.

Powered by:

X