Toolserver:GeoShape

Wikimedia's GeoShape or whatever you call it is an attempt to display ways and areas of the Openstreetmap Database in Wikipedia to illustrate articles. In contrary to GeoHack, wich does this for points given in Wikipedia, GeoShape takes the data entirely from OSM, using the [wikipedia]-tag of objects.

Frontend Examples

 * 1) Bezirk Neubau in OpenStreetBrowser

Similar projects and tools
similar projects: see List of projects that highlight OSM ways

tools: see Comparasion between osm2pgsql and osmosis for GeoShape

Ways to get there

 * use an OSM Database, extract the objects (ways, areas, points, relations) with wikipedia tag, hand on the relations's tags to their primitives (ways, areas, points), order them by wikipedia tag, display them

The rest of the chapter is a first try, still theoretically, starting with links.. The project
 * 1) other OpenStreetMap projects on toolserver, outdated doku: http://meta.wikimedia.org/wiki/OpenStreetMap
 * 2) Fossgis2011-WP-GEO 2011 Plans on the subject
 * uses a PostGreSql database with PostGIS and hstore
 * osm2pgsql
 * Tirex with Mapnik-Backend
 * probably OpenLayers

Layout
Osm2pgsql or Osmosis database is used and updated automatically with built in procedures. Data cannot be restricted to objects with wikipedia tag, because tagged relations can have untagged objects as members. New table can be: wiki_members lang            character(10)  pk    de        namespace lemma           character(255) pk    Bern      lemma member_type     character(1)   pk    N         NODE WAY or RELATION member_id       bigint         pk  action           character(1)         NULL      NULL or R (Rebuild namespaced lemma (classification))

update procedures todo..
Rebuilds the wiki_members table from scratch, that is, from the nodes, ways and relations tables of Osm2pgsql or Osmosis. Function (still missing) findwiki filters those tables to find tags like wikipedia:en=>Girard or wikipedia=>en:Girard or  wikipedia=>http://en.wikipedia.org/wiki/Ren%C3%A9_Girard#Religi.C3.B6ses_Denken  or wikipedia=>de:Girard, wikipedia:es=>Giño. DROP wiki_members; INSERT INTO wiki_members SELECT f.wikiLang, f.wikiLemma, 'N', n.member_id FROM nodes n, select findwiki(tags) AS f Is done along with updating data source tables (from Osm2pgsql). In Osm2pgsql, updating is happening 'undetected' without a workaround. The following workaround adds pgSql event handler hooks to change in altered tables:
 * rebuild
 * update prepare

trigger nodes on UPDATE BEFORE or DELETE: ALTER wiki_members SET action='R' SELECT f.wikiLang, f.wikiLemma, 'N', n.member_id FROM nodes n, select findwiki(n.tags) AS f WHERE n.member_id=ALTERED.id trigger nodes on UPDATE AFTER or NEW: IF tags(..) IF EXISTS .. ALTER action='R' FROM wiki_members .. ELSE INSERT INTO wiki_members ..

In Osmosis this can be done by the osmosisUpdate stored procedure.

Starts after updating data source tables is finished, that is, nodes, ways and relations tables of Osm2pgsql or Osmosis are up to date and the. FOR EACH lang, lemma FROM wiki_members WHERE action='R': rebuild rows update kml files
 * update postprocess

Step 2, cache in kml files
Make klm files to display the extracted ways or areas, to cache them (or store them in the database?). This can be done with PostGis functions.

Step 3, test link to wikipedia
Via WikiMiniAtlas, GeoHack, etc. using OpenLayers most probably.

Step 4, Rendering?
Or simplification of big relations.

Step 5, interwikilinks
Merge de:Donau with en:Danube.

Step 6, nested Relations
Processing of trees is a graph problem, and processing this kind of relation tree is a directed graph problem. The data is a subset of the relation_members table (the relation to relation part) which is an edge list or adjacency_list. The thing to do is to eliminate cycles and build the relation tree.
 * 1) see Osmwiki Super-Relation/Implementation