Mostrando entradas con la etiqueta xml. Mostrar todas las entradas
Mostrando entradas con la etiqueta xml. Mostrar todas las entradas

lunes, 23 de noviembre de 2020

Estilos QGIS para representar medidas de líneas (o polígonos).

Vamos hoy con otro poco de QGIS. En este caso queremos mostraros cómo representar las medidas de una línea o polígono mediante simbología de estilos para tener una salida gráfica atractiva y sencilla. Como una imagen vale más que mil palabras, dentro portada:
Lo primero que necesitamos es añadir los estilos que vamos a utilizar posteriormente en líneas y polígonos, y que son archivos XML con el código necesario para que automáticamente apliquen una simbología predefinida a los vectores. Para las líneas vamos a utilizar el estilo Measure Line disponible en el repositorio de estilos de QGIS.
Descargamos el archivo XML y lo añadimos a QGIS desde el Administrador de estilos:
Hacemos lo propio con el estilo para los polígonos. En nuestro caso hemos utilizado el estilo de Faunalia llamado Distance Measurement Styles, que podemos encontrar desde el repositorio del plugin QGIS Resource Sharing.
Como casi todo en QGIS hay diferentes opciones para un resultado similar, así que podéis utilizar el estilo que más os guste de los disponibles (u obviamente elaborarlo vosotros mismos).

El siguiente paso es crear un par de nuevas capas shapefile, una de líneas y otra de polígonos, a fin de poder probar nuestros estilos. Lo hacemos en un sistema de coordenadas proyectada en metros como unidad de medida. Usamos también como fondo la ortofoto PNOA para visualizar aquello que queremos medir.
Dibujamos después un par de líneas de ejemplo que nos servirán para la prueba (click derecho termina línea):
Seguimos el mismo proceso para crear la capa de polígonos y tras dibujar el polígono que usaremos de prueba ya tenemos el lienzo terminado con ambos elementos en sus capas (un par de líneas y un polígono).

El último paso es aplicar los estilos que hemos añadido a QGIS al comienzo del artículo a su capa correspondiente. Vemos el ejemplo con la capa de líneas:
Os enseñaría el paso con las medidas del polígono pero no ha habido manera, y después de muchos intentos con muchas proyecciones diferentes siempre me lo etiquetaba con medidas de 0 metros o similares... No entiendo porqué y me quedo con la sensación de que me ha funcionado cuando le ha dado la gana (como en la primera imagen de este artículo... ¿?¿?). Me rindo. Si alguno sabéis la clave para que funcione siempre...

Una última utilidad. Si queremos tener un campo con las medida de cada una de nuestras líneas en la tabla de atributos simplemente usaremos el comando $length en la calculadora de campos (en el ejemplo con dos decimales).
Para la superficie y perímetro de los polígonos podéis usar los algoritmos $area y $perimeter respectivamente.
Finalmente reseñar que los estilos son totalmente modificables en su simbología (colores, anchuras, distancias, etc...) y agradecer a sus creadores el ponerlos al alcance de los que nos queda muy grande programarlos. Saludos.


lunes, 6 de noviembre de 2017

De SASPlanet a MOBAC: mapas offline.

Hay que ver lo que aprende uno casi sin querer y trasteando... Hasta hoy mismo yo pensaba que MOBAC sólo abría mapas online provenientes de servidores de mapas, de semejante manera a como hace también SASPlanet. Gracias a un comentario por los foros acerca del mapa TopoEH he descubierto la manera de cargar en MOBAC archivos de mapas offline para luego poder exportarlos a cualquiera de los variados formatos que permite el programa (algo que debe llevar bastante tiempo inventado y yo sin enterarme). En el fondo no deja de ser un proceso variante y similar del que ya explicamos cuando hablamos de cómo aprovechar la caché de imágenes de SASPlanet en MOBAC, sólo que esta vez cargando un archivo único en lugar de un directorio con todas las pequeñas imágenes.
De esta forma podemos unir una vez más estos dos magníficos programas y aprovechar indistintamente las diferentes fuentes de mapas que tengamos en cada uno de ellos, combinando las posibilidades de mejor manera. Un ejemplo claro que se me ocurre: si tengo una cartografía configurada en SASPlanet que NO tengo en MOBAC (y yo tengo muchas de esas), podemos elaborar desde el primero el mapa offline para luego abrirlo en el segundo y poder exportarlo, por ejemplo, al formato RMAP de TwoNav en el que SASPlanet no puede exportar. Cierto es también que si tenemos la fuente en SASPlanet debería poder configurarse igualmente para verse en MOBAC, pero yo no he dedicado mucho tiempo a las mapsources de MOBAC y si más a las de SASPlanet, por lo que este sistema me viene de maravilla. Ahora me queda la terrible duda de si en SASPlanet podrán configurarse de alguna forma los parámetros del mapa para poder hacer algo parecido y engañar al programa para cargar un archivo offline... Qué sinvivir...

De momento, vamos con el proceso detallado:

1.- Crear desde SASPlanet un mapa RMaps (SQLite 3).
No se si MOBAC será capaz de cargar otros formatos, pero lo que es indudable es que con este formato SQLite la cosa funciona. Así pues creamos el mapa en SASPlanet de la forma habitual y lo exportamos en el mencionado formato; en nuestro ejemplo, y dado que SASPlanet permite exportar al archivo también las capas superpuestas, hemos elegido la orto PNOA con la capa base del IGN para ortofoto. Una pequeña área sobre la ciudad de Huesca a los zooms 16, 17 y 18.
Captura de SASPlanet mostrando los mapas activos en el área elegida y la ventana de exportación preparada para crear nuestro archivo .sqlitedb.
Ya tenemos nuestro mapa Huesca_orto.sqlitedb al que enlazo para descarga por si queréis seguir el ejercicio desde este punto (6,7 megas). Voy a pegarlo en la propia carpeta de fuentes de MOBAC de mi PC, que en este caso es C:\Program Files\MOBAC\mapsources (si tuvierais muchos o grandes mapas de este tipo podéis considerar hacer un directorio para ellos y así tenerlos agrupados).

2.- Crear el archivo XML para MOBAC mapsources.
Ahora debemos crear el pequeño archivo de texto en formato XML que hace de fuente de mapa llamando al archivo SQLite. En el mismo bloc de notas de Windows creamos un nuevo documento con el siguiente contenido:
En amarillo nombre con el que el mapa se nos va a mostrar en la lista de mapas de MOBAC. En verde la ruta completa a la ubicación del archivo SQLite imagen del mapa.
En rojo nombre identificativo con el que hemos guardado el XML.
Guardamos el documento y LO RENOMBRAMOS CAMBIANDO LA EXTENSIÓN .TXT POR .XML. Lo colocamos en la carpeta mapsources de MOBAC que es donde están las fuentes de mapa por defecto del programa. Este archivo Huesca_orto.xml también os lo enlazo para descarga por si queréis usarlo para esta práctica.
Ahora, con los dos archivos juntos en la carpeta mapsources de MOBAC, sólo nos resta arrancar el programa y comprobar que todo ha ido bien:
El mapa se muestra correctamente en nuestra lista de mapas y representa a la perfección
los tres niveles de zoom disponibles con los que fue creado en SASPlanet (15, 16 y 17 en la escala de MOBAC).
A partir de aquí ya podemos exportar desde MOBAC a alguno de los múltiples formatos que nos permite el programa, siguiendo el proceso básico que ya explicamos en su día y podéis recordar en el vídeo de nuestro canal YouTube.

Esto es todo. Un útil apaño para aquellos casos en que se nos resista la configuración de un servicio WMS en MOBAC pero en cambio lo tengamos bien añadido en SASPlanet y necesitemos exportarlo a un formato en el que SASPlanet no trabaje (RMAP para TwoNav/Compe, SQLITEDB para Orux con varias cartografías). Jugando de esta forma con ambos softwares son pocas las posibilidades que quedan fuera de nuestro alcance. Saludos!!

lunes, 14 de noviembre de 2016

Cartografía catastral.

La cartografía catastral quizá sea una de las informaciones más demandadas y útiles para el conjunto de usuarios. La Dirección General del Catastro ha implementado por ello un nuevo portal, ajustado a las normas europeas INSPIRE de estructura y acceso a la información geográfica. Este nuevo portal lo encontramos en la dirección http://www.catastro.minhap.gob.es/webinspire/index.html, y es todo un ejemplo de sencillez y eficacia en sus contenidos.
Se establecen tres conjuntos de datos para la información: parcela catastral, direcciones y edificios. Las especificaciones, definiciones o estructura de cada conjunto se nos ofrecen en un estupendo documento PDF en el mismo portal, así como los archivos de metadatos correspondientes.
El portal recoge también las tres diferentes maneras de acceder a la información:

1.- Servicio de visualización WMS.
Mucho hemos hablado ya en el blog de estos servicios WMS y su enorme difusión y ventajas, así pues no insistiremos hoy más sobre ello. De nuevo un EXCELENTE documento PDF explicativo del servicio, del que destacamos por ejemplo su cobertura del 95% del territorio, su escala general de 1:1000 para zonas urbanas y 1:5000 para zonas rústicas, o que la información presente en el WMS está continuamente actualizada. La URL de acceso es:
Ejemplo del servicio WMS, con los tres conjuntos de datos activos, abierto en Global Mapper.
2.- Servicio de descarga WFS.
También hemos hablado en varias ocasiones en el blog de estos servicios WFS que, además de permitir la visualización, ofrecen la descarga vectorial de la misma. El portal estructura y nos informa perfectamente del servicio correspondiente a cada conjunto de datos (parcelas, direcciones, edificios).
Recomendamos de nuevo la lectura de los excelentes PDF correspondientes, en los que descubriremos, por ejemplo, que el servicio WFS tiene importantes limitaciones por alcance y número de elementos. Así pues deberemos acotar antes la zona de interés lo suficiente para que el servicio no nos devuelva error en nuestra petición. Para parcela catastral el límite es 1 km² y 5000 elementos. Para direcciones y edificios 4 kms² y 5000 elementos.
En cuanto a su manejo, depende del programa. Global Mapper los descarga directamente en un archivo GML que luego tenemos que abrir, mientras que QGIS carga los datos en memoria y en pantalla y después ya podemos guardarlos en el formato deseado.

3.- Servicio de descarga ATOM.
Mucho más novedoso y agradable para mi ha sido descubrir este servicio, que permite la descarga de datos completa por municipios desde el mismo navegador de Internet y se actualiza dos veces al año. La información se proporciona mediante archivos vectoriales GML directamente desde la base de datos del catastro.
De nuevo recomendamos la lectura de los documentos PDF para descubrir, por ejemplo, que no todos los navegadores soportan adecuadamente este servicio. Google Chrome por ejemplo no representa bien las tablas y he tenido que recurrir a Firefox. Introducimos la URL correspondiente en el navegador (en este caso la de parcelas), y accedemos al listado provincial, con reseña de los municipios incluidos. Al final de cada provincia se encuentra el enlace para acceder a los municipios:
Pinchamos en él y se nos abre la página con el listado municipal, debajo de cada cual tenemos enlace para descarga.
No tenemos más que pinchar en el municipio deseado y se nos descarga un archivo comprimido ZIP con todos los elementos, y cuya estructura, para el caso del conjunto de datos parcelas, es:



- archivo XML de metadatos. Es simplemente información técnica del servicio, sin datos catastrales.
- archivos GML correspondientes a los dos grupos dentro del conjunto parcelas: zona catastral (o polígono) y parcela catastral propiamente dicha.





Abrimos los archivos GML en algún programa capaz de visualizarlos. De los que utilizo habitualmente nos pueden servir Global Mapper, QGIS o gvSIG.
Municipio completo cargado en Global Mapper.
Es ahora cuando, combinando la potencia de estos softwares SIG con los datos ofrecidos por Catastro, podemos realizar variedad de análisis y clasificaciones de la información. Para muestra un ejemplo:
Boca de Huérgano (León). Capa de parcelas catastrales etiquetadas por número y capa de edificios categorizada por uso.
 Todo ello sobre fondo de ortofoto PNOA.
Incluso, desde las mismas herramientas de información de nuestro software SIG, podemos acceder directamente a través de enlace a la web del Catastro, con una simplicidad y comodidad muy destacables.

Sin duda, un portal este del Catastro indispensable en la función de facilitar el acceso de ciudadanos e instituciones a la información geográfica de interés general. Nuestra más sincera enhorabuena.

martes, 28 de junio de 2016

Mapas de Navarra en OruxMaps.

Hace pocos días hablábamos en este artículo de cómo el Gobierno de Navarra había liberado miles de datos geográficos a través de un servicio FTP. Entre los datos disponibles se encuentra un extenso repertorio de mapas para smartphones, tanto online (requieren conexión a internet) como offline (para llevar en el propio teléfono sin necesidad de conexión). 
En este articulo vamos a ver la forma de llevar dichos mapas en nuestro dispositivo Android a través del software de navegación OruxMaps. Todo ello se puede hacer desde el mismo teléfono y en muy pocos minutos. Solamente necesitamos:
  • un cliente FTP capaz de acceder al servicio. Desde el propio navegador de internet puede accederse al FTP pero recomendamos un software específico pues el navegador habitualmente abrirá los archivos complicando mucho la función de copiar o descargar los mismos. Usaremos el muy conocido gestor de archivos ES File Explorer.
  • OruxMaps instalado, obviamente.
  • Conexión a Internet, también obvio y cuanto mas rápida mejor si se trata de archivos grandes.

Vamos a ello:
1.- Abrimos ES File Explorer. Entre sus herramientas, dentro de la sección Red, cuenta con un cliente FTP, por lo que accedemos a él y añadimos una nueva conexión a servidor según esta secuencia:

Rellenamos ahora los parámetros necesarios tal como se ve en la imagen.
Los parámetros más importantes son la dirección FTP (la del servidor de Navarra es ftp.cartografia.navarra.es), el puerto de conexión el 21 (por defecto); marcamos Anónimo como tipo de conexión ya que el servicio es abierto y no requiere usuario ni contraseña, y por último le damos un nombre identificativo en Mostrar como. Pulsamos OK y nos aparece la nueva carpeta FTP denominada Navarra. Dentro de ella el directorio completo del servidor, con la carpeta de la categoría 7_Mapas_para_smartphones que nos interesa en este caso.
2.- Copiamos nuestros mapas desde el FTP a la carpeta mapfiles de OruxMaps. Una vez llegamos al mapa de nuestro interés a través de las carpetas del FTP, seleccionamos el archivo y lo movemos o copiamos a la carpeta contenedora de mapas de Orux (por defecto oruxmaps/mapfiles). Por ejemplo primero los mapas online.
Dentro de la carpeta con ruta mapas para smarthphones/online/Oruxmaps se encuentra el archivo wms_services.xml. Este es el archivo xml con las fuentes de los mapas de Navarra. Tras seleccionarlo y mediante las funciones Mover A o Copiar A buscamos la carpeta mapfiles dentro del directorio oruxmaps. Aceptamos y nos sale el aviso de que ya existe un archivo con dicho nombre.
En el directorio mapfiles de Oruxmaps existe por defecto un archivo denominado wms_services.xml. Dicho archivo no es en realidad ningún mapa, sino una especie de plantilla de la estructura que un archivo xml debe tener para que Orux sea capaz de leer los servicios online wms. Por ello podemos sobreescribir el archivo, o si queréis conservarlo no tenemos más que salvarlo en otro lugar del teléfono antes de ejecutar el copia/pega. En cualquier caso para que Oruxmaps lo reconozca nuestro archivo xml de mapas de Navarra debe mantener su nombre: wms_services.xml.

Hacemos la misma operación con uno de los mapas offline que el FTP de Navarra nos proporciona. Se encuentran en la ruta mapas para smartphone/offline/Fondos Raster. Son mapas en formato rmap de un tamaño considerable (entre 750 megas y 1,5 gigas), por lo que moverlos llevará más tiempo y espacio en el teléfono. Si para el archivo xml de mapas online no es necesaria una buena conexión pues ocupa pocos kb, para estos archivos se hace imprescindible trabajar bajo conexión wifi. Por cierto, estos mapas rmap multicapa son perfectamente compatibles con CompeGPS.

3.- Comprobar que OruxMaps lee sin problemas los archivos transferidos. Momento de comprobar que todo ha ido bien; siempre es recomendable pulsar el icono de las dos flechas para que la lista de mapas se actualice.

1.- Transferencia de un mapa offline rmap a la carpeta mapfiles de Orux. 2.- Carpeta mapfiles de Orux conteniendo los dos mapas utilizados de ejemplo en este artículo. 3.- Desde dentro de Orux mapa orto 2010.rmap perfectamente reconocido en la lista de mapas offline. 4.- Desde dentro de Orux lote de mapas online de Navarra perfectamente reconocidos como conexiones wms.
Y esto es todo, en unos minutos y sin necesidad de PC ni de nada accesorio al propio teléfono móvil, tenemos disponibles en OruxMaps los mapas que el Gobierno de Navarra nos facilita a través de su FTP pública.

jueves, 3 de abril de 2014

SASPlanet: crear fuentes WMS.

SASPlanet es un magnífico software para la visualización y creación de mapas, pero su funcionamiento depende totalmente de servidores wms que le surten de contenido. Por eso es importante poder configurar las fuentes wms que nos interesen, y aprovechando su filosofía opensource, aquí va mi explicación de la forma en que modifico las carpetas .zmp de SASPlanet para añadir nuevas fuentes de mapas wms. Mi proceso es muy artesanal y fruto de la observación y cotejo de los archivos de texto necesarios; ni maldita idea que tengo de programación ni de nada que se le parezca, pero a base de prueba-error (más bien prueba-error-error-error) al final he conseguido más o menos un esquema que parece funcionar en bastantes casos. Cuantos más conozcamos algún proceso de elaboración que funcione, más mapas podemos tener disponibles en beneficio de todos.

Las carpetas .zmp contenedoras tienen tres archivos básicos: una pequeña imagen, un archivo GetUrlScript.txt y un archivo params.txt.

- El archivo de imagen corresponde con el pequeño logotipo que se muestra junto al nombre del mapa en la lista de mapas desplegable. Parece ser que su resolución máxima debe ser 24x24 pixels y debe estar en formato .bmp (a mi alguno me ha funcionado a resolución 90x60, pero tampoco es algo fundamental pues en el menú no hay sitio para más). En cuanto a su nombre también parece que "24" es el nombre por defecto (he probado con otros como "topo10" y la imagen deja de verse).
- El archivo GetUrlScript.txt ni tocarlo. No se muy bien ni para qué vale ni lo que hace; yo siempre he usado el mismo en todas las carpetas y parece que funciona, así que copiarlo, pegarlo y a callar ;-p
- El verdadero meollo está en el archivo params.txt. En él se contienen todos los parámetros a modificar. Pongo captura de su contenido estándar con las cosas a modificar seleccionadas y explico cada una de ellas. IMPORTANTE: el texto seleccionado es EXACTAMENTE el texto a sustituir. Quiero decir que una simple coma, o punto o caracter de más o de menos puede hacer que el archivo no funcione.

- pnum: digamos que es un número ordinario de mapa, como un orden en la lista de todos los mapas que tengamos. Ni siquiera se si habría conflicto si tuviera un número ya asignado a otro txt de otro mapa... Simplemente me limito a poner el siguiente número del último mapa que he creado. Puede dejarse en blanco.
- GUID: número único e intransferible que identifica a ese mapa. Aquí si he comprobado que si se repite al arrancar SASPlanet nos canta que tales mapas X e Y tienen el mismo número GUID y no los muestra. Resulta que hay webs que generan directamente estos códigos GUID, así que yo uso esta (http://www.guidgen.com/) y le doy a generar nuevo GUID cada vez que creo una nueva fuente. Copiamos el GUID generado y lo pegamos en su espacio entre los corchetes.
- name: es el nombre que el mapa tendrá en nuestro menú desplegable de mapas y por el que lo identificaremos; se pone el mismo en las tres líneas, pues no son mas que el nombre del mapa en cada uno de los tres idiomas del programa (ruso, inglés y ucraniano).
- ParentSubMenu: nombre del menú superior que contiene varios mapas; digamos que CATALUNYA es la carpeta y TOPO 10k uno de los archivos que contiene. Si queremos que el archivo de mapa quede suelto sin estar contenido en un submenú simplemente dejamos estas tres líneas en blanco.
- asLayer: define si el archivo va a ser un mapa o una capa. Si queremos que esté en la lista de mapas ponemos 0; si queremos que esté en la lista de capas (Layers) ponemos un 1. Depende de las características del mapa nos interesará más que sea mapa o capa a superponer.
- DefURLBase: esta es la dirección url principal del servicio wms del que vamos a descargar los datos. La mayoría de los proveedores de mapas la facilitan de forma pública y notoria.
- STYLES: la capa que queramos descargar desde el servidor puede estar hecha con varios de estos styles; normalmente es el estilo por defecto (default) pero hay que mirar bien por si tiene un estilo personalizado poner aquí lo que corresponda.
- image: el formato de imagen en el que el servidor proporciona los datos. Jpeg, gif y png son los más extendidos (png es el más extendido por la calidad/tamaño y la posibilidad de soportar transparencias). También es importante comprobar si el servidor ofrece descarga en el formato que esté puesto en esta línea.
- LAYERS: fundamental que aquí figure el nombre de la capa a descargar literal, tal cual lo veamos en las líneas xml del servidor. En teoría separando varios nombres de capa con comas (Ej: 8,12,15) el servidor wms debía descargarnos en una las que le pongamos; pero si son mapas del mismo tipo opaco y misma superficie la primera capa puede tapar el resto y aparentar que no funciona. Es muy útil por ejemplo para meter en una capa tres que suelen venir separadas en los servidores: ríos, curvas de nivel y carreteras. Pero también reconozco que no me ha funcionado siempre.
- NameInCache: nombre que queremos darle a la carpeta de caché donde van a descargarse los mosaicos correspondientes a este mapa.
- ContentType: relacionado con el tipo de archivo (image) y formato (png) con que sirve los datos el servidor. Podría tenerse que cambiar, por ejemplo por text/html o cualquier otra cosa si los datos a descargar son así, pero no puedo asegurar nada.

Una vez explicados los parámetros a tener en cuanta vamos a buscar una dirección WMS y elaborar un nuevo archivo params.txt sobre la plantilla. Un sitio clásico que ofrece multitud de servicios wms es el Geoportal IDEE (Infraestructura de Datos Espaciales de España), pero hay multitud de sitios nacionales, autonómicos y hasta locales donde conseguir direcciones de servicios Web Map Service. En su directorio de servicios vamos buscando por autonómicos/catalunya... hasta que entre la inmensa lista de direcciones encontramos una que nos puede interesar:
Pinchando sobre ella (es también la dirección que tendremos que copiar y pegar en el campo DefURLBase) se nos abre el archivo xml conteniendo la programación del servidor en el famoso lenguaje xml (Google Chrome si abre ventana directamente, supongo que otros exploradores también) y que tiene este aspecto:
En este a menudo inmenso texto es donde tendremos que ir escudriñando la información que nos interese, y que con cierta práctica localizaremos cada vez más rápido una vez nos habituemos a la estructura de este tipo de archivos. Por ejemplo a poco del comienzo encontramos las líneas donde se nos dice los formatos de imagen soportados por el servicio para la obtención del mapa::
<GetMap>

<Format>image/gif</Format>

<Format>image/png</Format>

<Format>image/jp2;subtype="gmljp2"</Format>

<Format>image/bmp</Format>

<Format>image/jpeg</Format>

<Format>image/tiff</Format>

Pero, yendo al grano, buscamos si el servidor dispone del mapa topográfico de Catalunya a escala 1:5000. Así que bajamos y bajamos por todas sus líneas descartando otros mapas hasta que encontramos esto (os selecciono en el texto los parámetros que podríamos necesitar):
En nuestro archivo params.txt pondremos la primera selección (mtc5m) en el campo LAYERS y poco más tenemos que cambiar en este caso (ya puesta la DefUrlBase por supuesto). No hay ninguna referencia a Style de capa (a veces si la hay), así que la dejamos en default. He destacado el formato image/gif para que os fijéis, pero en este caso al principio del xml se nos decía que el png también está soportado así que podemos probar a dejarlo (si no funciona se prueba a poner "gif" donde corresponde). La línea roja la he puesto para que veáis que a partir de ella ya empieza otra capa de otro mapa (el topo 25k en este caso) O sea que nuestro params.txt quedaría así:
En amarillo los campos obligatorios; en naranja aquellos que podéis darle el nombre que más os guste.
Con nuestro archivo params.txt salvado lo metemos en una carpeta junto con el archivo GetUrlScript.txt y la imagen que hará de icono identificativo (una bandera, un escudo,... lo que queráis; de hecho ni siquiera es necesario que esté esta imagen, sólo es para que haga bonito). A la carpeta le damos un nombre identificativo (por ejemplo Topo5k) y le ponemos la extensión .zmp. La carpeta tiene que estar dentro de la carpeta Maps del programa (yo las pongo dentro de la carpeta "user.maps" para saber siempre cuales son los mapas creados por mi). Dentro de user.maps podéis organizar las carpetas como mejor os venga, pues eso no afecta a la disposición en el menú para nada (lo que manda son los campos name y ParentSubMenu del archivo).
Os recomiendo muy mucho borrar el archivo Maps.ini (en la carpeta Maps) y el contenido de la carpeta cache cada vez que se añade una nueva carpeta de fuentes; así el programa arranca de cero creando un nuevo maps.ini con la nueva fuente y los mosaicos de la cache existente no ocultan el nuevo mapa creado llevando a confusión de si el mapa está correcto.
Arrancamos SASPlanet para comprobar y aquí tenéis el resultado:

No quiero enrollarme más aunque me deje cosillas en el tintero (por ejemplo añadir una Leyenda a la info del mapa que en algunos casos es imprescindible para interpretarlo), pero bastante ladrillo de artículo me ha salido ya. Espero no haberos liado demasiado, no he sabido hacerlo más claro y conciso. Si te has leído todo es que estás peor que yo, jajaja...
Cualquier cosa me dejáis comentario y a ver si entre todos lo solucionamos o mejoramos el sistema.