Filesystem interface to spatial data


The main idea of the filesystem interface for POLYMAP3 is to provide a way to 'mount' the content of the projects, maps and layers into the regular filesystem. The data is generated on-the-fly by the server, so it does not waste disk space. And it allows for example to work with the spatial data of a layer just like those data are present as real files in the filesystem.

The POLYMAP3 Workbench provides and integrated GIS user interface via the Workbench. To access the data from other applications the OGC web services can be used. However, there are usecases where both is not an option:

  • mobile use, where data are transfered to a mobile device
  • (older) desktop GIS applications that do not support open web services
  • web applications with limited capabilities

For such usecases a simple, extendable, filesystem based access system can help to integrate other applications into the POLYMAP3 data workflow.

Schematic file/folder layout:

        |- map1
            |- layer1
            |    |- layer1.shp
            |    |- layer1.shx
            |    |- layer1.dbf
            |    |
            |    |-
            |- layer2
                 |- ...

The entiry folder structure as well as the several file formats are extendable via the standard plugin extension point: org.polymap.service.fs (@since 3.1). The file content is generated on demand by implementing the IContentFile interface. An example and a good starting point might be the GeoJsonContentProvider. So basically the system can be extended to expose any folder structure and/or file format.

Content formats

In nature filesystems are content agnostic. This is different to OGC services where access technology, filter semantics and content is strictly specified. So, in order to provide something usefull the format of the data is important.

As one of the main goals is to enable desktop GIS applications of any kind to work with the provided data the first choice is the Shapefile format. Although it has a lot of disadvantages, first that it is not an open standard, it is the format that th most programs can work with.

For download services zipped shapefile is a good choice. Also GeoServer provides mimetype SHAPE-ZIP as download via WFS.

For web applications JSON or GeoJSON is easy to parse and to handle.

Filesystem technologies

There are some technologies that should be able to provide a filesystem like interface for spatial data. Possible candidates are:

  • WebDAV
  • Remote filesystems: CIFS, NFS
  • Server protocols: FTP, SSH

Tasks and Status

Status: closed (9 matches)

Ticket Summary Owner Type Priority Component Version
#71 Neues Modul org.polymap.service.fs falko enhancement major org.polymap.service 3.1
#72 Filesystem Infrastructure falko enhancement major org.polymap.service 3.1
#73 ShapefileContentProvider falko enhancement major org.polymap.service 3.1
#74 Verbindung mit Feature-Buffer des Nutzers falko enhancement major org.polymap.service 3.1
#75 Schreib-Operationen für WebDAV falko enhancement major org.polymap.service 3.1
#76 Authentication/Authorization für WebDAV falko enhancement major org.polymap.service 3.1
#77 WebDAV SLDContentProvider falko enhancement major org.polymap.service 3.1
#78 Timestamp in generierten Shapefiles falko enhancement major org.polymap.service 3.1
#127 CSV-Export via WebDAV falko enhancement major org.polymap.service 3.0

Trac Appliance - Powered by TurnKey Linux