Skip to content
Octo × Repository PT Request an assessment

Octo for the MapGuide repository

Every published layer is an XML file. Who decides what goes live is you.

In MapGuide Open Source 4.0, data sources, layers, maps and viewers are XML documents in the Library:// repository, read and written by 24 mapagent API operations. Octo inventories the repository, finds broken references and old schemas, generates layers in batch from a spreadsheet, validates against the XSDs before sending and prepares the package with a backup first. Publishing to production, credentials and published data stay with the administrator and the technical lead.

Request an assessment See what it does
A terminal lists the Library repository tree with sources, layers and a map; Octo, in the center, connects each layer to a slice of a fictitious municipal map with zoning, a river and parcels, and to an .mgp package with a manifest and an XSD validation badge $ ENUMERATERESOURCES DEPTH=-1 Library://Municipio/ Dados/ Urbanismo.FeatureSource Ambiente.FeatureSource Camadas/ Zoneamento.LayerDefinition Lotes.LayerDefinition APP.LayerDefinition Risco.LayerDefinition 2.4.0 Mapas/ Municipal.MapDefinition Portal.WebLayout MUNICIPAL.MAPDEFINITION · 3.0.0 package.mgp Library/… + manifest resources + folders XSD checked · backup first xmllint --schema LayerDefinition-4.0.0.xsd Risco.LayerDefinition_CONTENT.xml validates OCTO × REPOSITORY MGOS 4.0 · LIBRARY:// R-03
Illustration: repository, map assembled from the layers and validated package; fictitious data.
MapGuide Open Source4.0released Oct 12, 2025, LGPL 2.1 license
XSD schemas in the 4.0 branch78only one new resource schema: LayerDefinition 4.0.0
Resource operations in mapagent24from ENUMERATERESOURCES to APPLYRESOURCEPACKAGE
Sources12listed at the end of the page
01

What Octo does with the resource repository.

Six possible deliverables, drawn from the assessment. All of them start with a read and a local copy, all validate against the server version's schemas, and all go to review by whoever administers the server.

Library:// inventory

Lists every resource with ENUMERATERESOURCES and DEPTH=-1, downloads each XML with GETRESOURCECONTENT and records type, schema version, owner and date. Read-only.

Deliverable: spreadsheet by resource and a dated copy of the XML

Dependency graph

Builds layout → map → layer → source → symbol and cross-checks with ENUMERATERESOURCEREFERENCES. Points out broken references, resources nothing points to and schemas below the newest.

Deliverable: list of open items for the administrator

Batch layers from a template

A spreadsheet with source, class, filter, label, scale and colors becomes standardized 4.0.0 LayerDefinition resources and a MapDefinition with the groups, with no clicks in the editor.

Deliverable: generated resources + a package reviewable by diff

Validation before sending

Well-formedness, the rule the server applies (root matches type, schema name) and full validation with xmllint --schema, because the server checks very little and the version label is a "TODO" in the code.

Deliverable: report per file, a gate before the package

Package with a backup first

Builds the .mgp (Library/ tree + manifest), first downloads whatever will be overwritten and checks afterward through canonical XML and TESTCONNECTION.

Deliverable: package, rollback copy and check

Password outside the XML

Replaces the password stored in the sources with %MG_USERNAME% and %MG_PASSWORD%; the credential goes separately, in MG_USER_CREDENTIALS, written by whoever holds the password.

Deliverable: clean sources for packaging and version control
02

Eight arms, one checked repository.

The same Octo cycle, applied to the resource repository. Each arm has a narrow role; the people publish to production, hold the credentials and are accountable for the data.

  1. Discovery

    Maps what already exists

    Server version, complete Library listing, schema version of every resource and the dependency graph.

  2. Data

    Pins down what each source reads

    FDO provider, schema and class of each source, substitution tags and attached resource data.

  3. Security

    Handles access and passwords

    Read-only user for the inventory; passwords out of the XML and the command line; folders with personal data flagged (LGPD).

  4. Architecture

    Chooses the path

    SETRESOURCE resource by resource or an atomic package; template-based generation; MaestroAPI when the edit is structural.

  5. Development

    Writes the script

    Generators and validators with a log and the source of every syntax noted in the file.

  6. Review

    Checks by content

    Local XSD, canonical XML matching the package, TESTCONNECTION and the map rendered in staging. "The server accepted it" is not a check.

  7. Release

    Prepares the package

    Delivers the package and the rollback copy. Applying it to production is done with a person's approval.

  8. Documentation

    Records what holds on your server

    Inventory, open items, version of each schema, package applied, who approved it and how to roll back.

Octo works with read access in production; it writes only to staging, in a support role. It does not decide what goes to production, hold database credentials, delete resources on its own or answer for published data.

03

Each task, its own path.

The criteria Octo uses to choose, with the code and reference for the installed version.

TaskPathNote
List the whole LibraryENUMERATERESOURCES, DEPTH=-1Library repository only
Download a resource's XMLGETRESOURCECONTENTSave before any change
Find who uses a sourceENUMERATERESOURCEREFERENCESExternal applications can use it without showing up
Generate layers in batchXML template + CSVLayerDefinition 4.0.0, the only new resource version in 4.0
Validate before sendingxmllint --noout --schemaThe server checks the root and schema name
Write a resourceSETRESOURCE, multipart POSTCONTENT and HEADER as files
Move many resources.mgp + APPLYRESOURCEPACKAGEAtomic; Library only; does not keep the previous version
Take the password out of the XML%MG_USERNAME%/%MG_PASSWORD% + MG_USER_CREDENTIALSCredential written on each server
Test the written sourceTESTCONNECTIONFeature service
Export a package from the serverMgServerAdmin::MakePackageWrites to PackagesPath
04

From clicks in the editor to a versioned repository.

Three steps. Each one only makes sense after the previous one has shown results on your team.

A proposal, not a promise

1 Today

Inventory and open items

Octo shows what is in the repository and what is broken, without writing anything.

  • Spreadsheet by resource, with schema version
  • Dependency graph
  • List of broken references and orphans
Benefit: know the size of the problem before migrating
2 Next

Batch generation and validation

New layers come from a spreadsheet and a template, validated against the XSD, in a reviewable package.

  • Standardized style by design
  • Validation report per file
  • Passwords out of the XML
Benefit: the team reviews one diff, not every layer
3 Later

Promotion with a record

Staging and production receive the same package, with a backup first, approval and a check.

  • Resources under version control
  • Who approved each package
  • Rollback ready
Benefit: publishing with a before, an after and proof
05

Confirmed in a source.

Every point below has a source published by OSGeo (project page, official mailing lists, downloads area), by the official repository or by Autodesk. The examples are scripts, not executions. The sources are in the next section.

3

points with a published source, each with its reference shown alongside.

ConfirmedMapGuide Open Source 4.0
Final release announced on Oct 12, 2025 on the OSGeo lists, after RC1 on Sep 10, 2025. OSGeo community project, LGPL 2.1.Source: lists.osgeo.org, mapguide-users; osgeo.org
ConfirmedOne new resource schema
78 XSDs in the 4.0 branch versus 71 in 3.1; of the seven new ones, only LayerDefinition-4.0.0 is a resource schema, with the optional IncludeBoundsForSelectedFeatures element (RFC 178, r9644, Feb 5, 2020).Source: svn.osgeo.org, MgDev/Common/Schema
ConfirmedShallow validation on the server
On write, the server checks that the schema name contains the root and that the root is the resource type; above that rule, the code says "TODO: Enforce versioning in future release".Source: ResourceDefinitionManager.cpp and ResourceContentManager.cpp, 4.0 branch
06

What Octo does and what stays with you.

Octo prepares everything, but it does not sign. The document of record stays with whoever is accountable for it.

Octo prepares

Gathers, calculates, organizes and generates the documents: scripts, inventories, reports and maps.

Deliverable: material ready to check

Your team checks

The licensed professional checks what Octo delivered before signing. If something doesn't add up, it goes back to Octo with the correction.

Step: review by the signer

The signer

Octo does not sign. Designs, technical reports, ART/RRT, accountability reports and any official document are still signed by the licensed professional of the company or agency: here, the technical lead for the map or system.

Signature: technical lead for the map or system
07

Sources.

Code from the official MapGuide SVN, OSGeo mailing lists and the MapGuide Maestro and mapguide-rest repositories used in the assessment, consulted on Oct 31, 2026.

Your MapGuide repository, inventoried and checked.

The assessment starts with a Library inventory and a dependency graph, read-only. You get the list of what is broken, what is outdated and the questions only your team can answer, and you decide with it in hand.

Request an assessment