openlayers editor

Editor de OpenLayers

OpenLayers Editor (OLE) se basa en OpenLayers y proporciona un conjunto de controles para la edición extendida de datos espaciales.

¡Las contribuciones son bienvenidas! Siéntase libre de agregar más controles y extender la funcionalidad actual. Además, el proceso de compilación es actualmente muy básico y podría optimizarse. Las traducciones también serían buenas.

Características

• Herramienta CAD para la alineación de la geometría
• Línea de dibujo, características de punto y polígono
• Geometrías en movimiento y rotación
• Modificación de geometrías
• Eliminar geometrías
• Operaciones de topología utilizando JSTS: búfer, unión, intersección, diferencia
• Barra de herramientas para activar y desactivar controles

Manifestación

Para una demostración, visite https://openlayers-editor.geops.com.

Dependencias

• nodo y npm

Empezando

• Clon este repositorio
• Instalar: yarn install
• Build: yarn build
• Run: yarn start
• Abra su navegador y visite http: // localhost: 8080

Uso

 < link rel =" stylesheet " type =" text/css " href =" https://cdn.jsdelivr.net/npm/ole@latest/style/ole.css " />
< script src =" https://cdn.jsdelivr.net/npm/ole@latest/index.js " > </ script > 

 var editor = new ole . Editor ( map ) ;

var cad = new ole . control . CAD ( {
  source : editLayer . getSource ( )
} ) ;

var draw = new ole . control . Draw ( {
  source : editLayer . getSource ( )
} ) ;

editor . addControls ( [ draw , cad ] ) ;

Versiones y Changelog

Este repositorio utiliza la versión estándar para la versión de versión y la gestión de ChangeLog. Por lo tanto, las actualizaciones deben comprometerse utilizando mensajes de confirmación convencionales:

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

La confirmación contiene los siguientes elementos estructurales, para comunicar la intención a los consumidores de su biblioteca:

1. Corrección: una confirmación del tipo corrige un error en su base de código (esto se correlaciona con el parche en versiones semánticas).
2. hazaña: una confirmación del tipo que ha introducido una nueva característica para la base de código (esto se correlaciona con menor en versiones semánticas).
3. Cambio de ruptura: una confirmación que tiene un cambio de pie:, o agrega un! Después del tipo/alcance, introduce un cambio de API de ruptura (correlacionando con especialización en versiones semánticas). Un cambio de ruptura puede ser parte de los compromisos de cualquier tipo.
4. Tipos que no se corrigen: y hazaña: están permitidos, por ejemplo, @comitlint/config convencional (basado en la convención angular) recomienda construir:, tarea:, CI:, documentos:, estilo:, refactor:, perf:, prueba:, y otros.
5. Piaderos que no sean el cambio: se puede proporcionar y seguir una convención similar al formato de remolque GIT.

Los tipos adicionales no son obligatorios por la especificación Conjuntos convencionales y no tienen ningún efecto implícito en el versiones semánticas (a menos que incluyan un cambio de ruptura). Se puede proporcionar un alcance al tipo de un comité, para proporcionar información contextual adicional y está contenido entre paréntesis, por ejemplo, hazaña (analizador): Agregar capacidad para analizar las matrices.

Que contribuye

Todos los PR son bienvenidos y serán revisados tarde o más tarde. Asegúrese de seguir las especificaciones Convencionales.