Skip to main content
Glama
alexrobl
by alexrobl

export_map_image

Render and export map images from vector GIS files—displayed inline and saved to disk—with customizable symbology, labels, legends, and extra layers.

Instructions

Genera una imagen del mapa con basemap Esri World Light Gray Canvas mostrada INLINE en el chat y guardada en disco en alta resolución. Devuelve además un reporte textual de la simbología realmente aplicada a cada capa: VERIFICARLO antes de afirmar que un color/estilo fue cambiado.

Args: path: Ruta al archivo o directorio espacial. layer: Nombre de la capa (None = primera capa). limit: Máximo de features (default 5000). color_by: Campo para colorear por categoría con colores automáticos. Alternativa simple a style. where: Filtro SQL OGR. Si se aplica, la extensión del mapa se ajusta (zoom) a las features filtradas; las capas extra quedan como contexto recortado sin ampliar la vista. bbox: Extensión [xmin, ymin, xmax, ymax]. style: Estilo avanzado: Categorizado: {"type": "categorized", "field": "Tipo", "categories": {"A": "#e74c3c", "B": "#2ecc71"}} Graduado: {"type": "graduated", "field": "Tiempo", "ramp": "RdYlGn_r", "breaks": 5} breaks = int (clases iguales) o lista de cortes explícitos. Rampas útiles: RdYlGn_r, YlOrRd, Blues, viridis, plasma. "field" en style tiene precedencia sobre color_by. output_path: Ruta completa de salida incluyendo extensión. .png = PNG lossless · .jpg = JPEG · .pdf = PDF vectorial · .svg = SVG. Si None guarda "{capa}_map.jpg" junto al archivo fuente. legend: Mostrar leyenda (default True). dpi: Resolución en DPI para disco (default 150). La imagen inline del chat siempre usa 72 DPI para mantener el tamaño manejable. Con dpi > 150 los tiles del basemap se piden a mayor zoom para mantener la nitidez (descarga más tiles: más lento). figsize: Tamaño [ancho, alto] en pulgadas, ej. [14, 8.5] para A4 horizontal. Default [10, 6]. scalebar: Mostrar barra de escala en esquina inferior izquierda (default True). north_arrow: Mostrar flecha de norte en esquina superior izquierda (default True). credits: Texto de créditos en pie de mapa, ej. "Fuente: INEGI 2024 | Elaborado con GeoAnalisis MCP". label_by: Campo para etiquetar cada feature de la capa PRINCIPAL (anclaje dentro de la parte visible de la geometría). Para etiquetar capas extra, usar la clave 'label_by' dentro de cada entrada de extra_layers. El reporte de salida SIEMPRE indica cuántas etiquetas se renderizaron y cuántas se omitieron (y por qué). label_collision: "auto" (default) descarta etiquetas que se solapan o cuyo polígono ocupa <0.02% de la vista; "none" desactiva ambos filtros y renderiza TODAS las etiquetas visibles aunque se amontonen. Usar "none" cuando el usuario pida ver todas. extra_layers: Capas adicionales a superponer sobre el basemap, en orden ascendente (primera entrada = capa más baja). Cada capa aparece en la leyenda. IMPORTANTE: pasar SIEMPRE 'color' explícito y distinto por capa (matiz diferente); el gris default es solo para puro contexto. Cada entrada es un dict con: path (str, requerido), layer (str), limit (int, default 10000), where (str; filtro SQL OGR aplicado a ESA capa, ej. "INTERVALO <= 10"), color_by (str; campo de ESA capa para colorear por categorías — un solo archivo con clases, sin dividirlo en varios), style (dict; simbología avanzada de ESA capa, mismo formato que el style de la capa principal: type "categorized" con categories, o "graduated" con field/ramp/breaks. La leyenda muestra cada clase prefijada con el nombre de la capa), color (str; ej. "#e74c3c". Default "#888" gris. Ignorado si se pasa color_by o style), alpha (float; default 0.9 líneas, 0.7 resto), linewidth (float; default 1.5 líneas, 0.5 resto), linestyle (str, default "-"; "--" discontinua, ":" punteada), edgecolor (str, default "none"), markersize (float, default 4), label (str; nombre en leyenda, default nombre de capa/archivo), label_by (str; campo de ESA capa para etiquetar sus features — colocación inteligente compartida con la capa principal: las etiquetas de la principal tienen prioridad), zorder (int; opcional, para dibujar sobre la capa principal), crs (str; ej. "EPSG:9377". Solo si el archivo NO define CRS: se asume ese. Si define uno, se respeta el del archivo). Cualquier otra clave se ignora y se reporta en el texto de salida. source_crs: CRS a asumir para la capa principal SOLO si el archivo no define uno (ej. "EPSG:3116"). Sin esto, una capa sin CRS con bounds lon/lat se asume EPSG:4326; con bounds proyectados se rechaza indicando cómo corregir. Todas las capas se reproyectan automáticamente a Web Mercator para el render. basemap: URL de un basemap alternativo al default Esri World Light Gray Canvas. Acepta la raíz de un servicio ArcGIS MapServer con cache de tiles en Web Mercator (ej. "https://host/arcgis/rest/services/ Nombre/MapServer": se valida el cache y se usa la plantilla /tile/{z}/{y}/{x}, con atribución del copyrightText) o una plantilla XYZ con tokens, ej. "https://tile.host/{z}/{x}/{y}.png". Si los tiles fallan al descargar se usa Esri World Light Gray Canvas como fallback y se reporta en el texto de salida. markersize: Tamaño del marcador para capas de puntos, en pt² (semántica matplotlib; ej. 100 ≈ círculo de 3.5 mm). Default None = automático según número de puntos y ancho del lienzo, con halo blanco para resaltar sobre el basemap.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dpiNo
bboxNo
pathYes
layerNo
limitNo
styleNo
whereNo
legendNo
basemapNo
creditsNo
figsizeNo
color_byNo
label_byNo
scalebarNo
markersizeNo
source_crsNo
north_arrowNo
output_pathNo
extra_layersNo
label_collisionNoauto

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.2.10
    • addedInput schema / properties / label_collision
      Added value: +{
      +  "default": "auto",
      +  "title": "Label Collision",
      +  "type": "string"
      +}
  2. Addedv0.2.9

TDQS

A4.2/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden and does so extensively. It discloses inline DPI vs. disk DPI behavior, basemap fallback, automatic reprojection to Web Mercator, precedence of style over color_by, label collision handling, and that unknown extra_layers keys are ignored and reported. It even warns the agent to verify the symbology report before claiming a style changed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Although long, the description is necessary given 20 undocumented parameters. It is organized as a clear intro followed by a per-argument list where each line earns its place. Examples are compact and the structure is scannable for an agent.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is complete for a complex tool with 20 parameters and no annotations. It covers output behavior, defaults, fallbacks, failure handling, and parameter interactions. Since an output schema exists, the description need not restate return structures.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must fully compensate, and it does. Every parameter includes defaults, formats, concrete examples, edge cases, and interactions, such as extra_layers ordering, source_crs fallback logic, and style dict structure. This goes far beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action ('Genera una imagen del mapa'), names the default basemap, and clarifies that the image is shown inline and saved to disk at high resolution, with a symbology report returned. It is clear and specific, but it does not explicitly contrast itself with sibling tools like render_map or export_map_cartographic, so it lacks explicit sibling differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives no explicit guidance about when to choose this tool over alternatives such as render_map or export_map_cartographic. It documents parameters thoroughly but does not state usage context, exclusions, or conditions under which a sibling would be more appropriate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.