Roadmap for turning Semantic Mediawiki into a full Semantic GIS
Semantic Mediawiki is an amazing web database system. Here is a list of enhancement we would need to make of Semantic Mediawiki an amazing GIS (web, web 2.0, endlessly configurable, history, other wonderful features??) as well.
- Link to PostGIS - Add read/write support for all the PostGIS types of geometry (point, line, polygon, etc..) as new SMW data types. Should there be only one type encompassing all the others (“postgis geometry” like the “geometry” type in PostGIS) or as many types as there is types of geometries (“postgis point”,”postgis line”, etc…)? Should the geometry type be stored a ewkt or as hexewkb in a wiki page? Geometries could also be stored in the MySQL spatial extension.)
- Storage – Geographic information could be stored in three ways:
- One row per page: This is already possible in SMW.
- All the rows of a layer in one page. This is already possible in SMW with the SIO extension (one row = one SIO object).
- Virtual tables - Optionally, all the rows as a virtual object making the link between a layer stored as a table in the database and a wiki page. This is useful to avoid storing, say, 25 million geographic features, as 25 M pages or as 25M SIO in one page. This virtual table object would internally create SMW relations like the SIO object do without actually needing a named template to be added in the page for each row. This would very much ack like a RSS feed reader linking to internal (and eventually or external) data with the difference that it would allow editiong as well. These virtual table objects could be created in a new namespace and feeded through import of shapefiles with the data transfer extension. They could be inserted in a page (to create relations) as a special tag. SMW would then see every row as a set of relation like it does with SIO. Semantic Form should allow editing the rows of those objects and #ask queries should allow querying them. This new type of object is actually independent from the new spatial support. It is just a general mechanism to be able to make relations with virtual (internal or external) objects stored in the Mediawiki data base or as remote data feed. Remote data feed could be edited only through a protocol similar to WFS.
- Coordinate Systems - A special standard semantic content page could store all the coordinate systems necessary to the system being build. There could be a special form where we can drop the .prj or any text representation of a coordinate system (see http://spatialreference.org). Every geometry should have an implicit "Has Coordinate System" property.
- Display – Add display of complex ewkt (or hexewkt) geometries over the Google map of Mediawiki Map. Add the possibility to display all the resulting rows of a #ask query in a single map. How should symbology be managed?
- Import/Export – Import could be done (as a CSV ewkt or hexewkb strings) via the Data Transfer extension. This implies that the users have a way to convert shapefiles geometries into ewkt or hexewkb (PostGIS can easily do that). Data Transfert or a new extension could also support direct import (and conversion to ewkt or hexewkbx) of the OGR format.
- Edition – Add the possibility to edit a complex geometry like it is possible to do in My Google Map.
- Geoprocessing – Unary geoprocessing (implying unary operators acting on a single geometry) would be done as a set of functions (like PostGIS ST_Buffer()) working on the new PostGIS geometry type and usable in #ask template queries. Actual computation would be done internally using the PostGIS SQL API. Binary geoprocessing (implying binary operators acting on two geometries) could be done the same way as it is done in SMW (is it possible? Inference? This is the equivalent of a many to many relation).
That’s it! That’s all we need to transform SMW into a spatial database and the most functional web GIS ever! (Like SMW is the most functional web database ever!). The most fundamentals pieces are "Link to PostGIS", "Coordinate Systems", "Display of complex geometry" and "Edition". "Storage" is already possible in two forms. "Import/export" would already be possible as ewkt or hexewkb produced by other means, "Virtual table" is optional and "Geoprocessing" would be the cherry on the cake!
Still some obscure points:
- how to automatically assign a symbology to a geometry (based on its characteristics) when displaying it on a map. Should just it be the responsibility of the displayer (like the kml query format) or should there be a more general mechanism where symbology are stored as semantic pages and are automatically associated to geometries by some magic... A first attempt should allow modifying the pin image for example. There should be a page for this pin with a color parameter and a way to select the right pin based on some property of the object we want to display. We should then generalize the principle for lines and polygons...
- how to do binary spatial operation (like intersection) on a many to many relationship (one road intersects with many lakes and one lake intersect with many roads). I try to create an example with employes and team (one employe belong to many teams and one team gathers many employe) to see how a query recreating all the teams but attribute only relationship are generally explicit (you assign an employe to a team) whereas spatial relation are implicit (derived from a spatial relationship).
- how to deal with raster data (PostGIS 2.0 will store raster)
Sounds very interesting and should be doable. I got interested in geo-coded data a while ago and tried to build an ad-hoc system to query and display them. I did something much more basic as you describe (not PostGIS) storing geo-coded data sets with several thousand entries on one page as multi-valued properties (although in practice to fetch all the data every time from the SMW database is much too slow so the data are cached as tables in files to be read quicker as long as the cache is valid, which is no problem as my data are more or less static). The display is via an #ask query and the Exhibit query result format either from one data set or from several ones combined. It allows various different types of overlays to be added to the map and the usual data filtering via the exhibit facets/views. However, it's all very customized to deal with the large number of data points and other specific problems with the data sets I use, so all of the extensions are modified. Cheers, Gu
This project can maybe help you https://dev.opensahara.com/projects/2/wiki/IndexingSail It already uses PostGIS to deal with geo semantic and triple store. Regards. ThomasG
