Skip to main content
Glama
alexrobl
by alexrobl

export_map_image

Generate a high-resolution map image from vector spatial data with customizable basemaps, styling, labels, and legends. Save as PNG, JPG, PDF, or SVG.

Instructions

Genera una imagen del mapa con basemap CartoDB Positron 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 en su centroide. 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), color (str; ej. "#e74c3c". Default "#888" gris), 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), 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 CartoDB Positron. 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 CartoDB Positron 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

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior4/5

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

With no annotations, the description carries full burden and discloses many behaviors: inline vs disk DPI differences, basemap fallback, CRS handling, style precedence, and warnings about extra layers. It does not explicitly state it is read-only or describe file creation side effects, but given the tool's nature, this is acceptable.

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

Conciseness4/5

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

The description is verbose but well-structured with a clear high-level overview followed by an 'Args:' section. Each parameter gets a focused explanation. Some lines (e.g., basemap) could be slightly more concise, but overall it is front-loaded and organized.

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?

Given 19 parameters, no annotations, and an existing output schema, the description covers all parameters with appropriate detail. It mentions the return of a textual report, and the output schema presumably documents the return format, so the description is complete for agent use.

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%, yet the description documents every parameter with type, default, examples, and nuanced details (e.g., style format, basemap URLs, extra layer attributes). This fully compensates for the missing schema descriptions, adding significant value.

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

Purpose5/5

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

The description clearly states the tool generates a CartoDB Positron basemap image inline and saves a high-res copy to disk, plus returns a text report of applied symbology. This distinguishes it from siblings like 'render_map' (likely just inline) and 'export_map_cartographic' (cartographic export) by emphasizing both inline display and disk saving with symbolic report.

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 provides no explicit guidance on when to use this tool versus its siblings (e.g., render_map, export_map_cartographic). It does not mention when not to use or suggest alternatives, leaving the agent to infer from parameter details.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/alexrobl/geoanalisis-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server