Toolserver:GeoShape

Wikimedia's GeoShape as I just called it, following the Query-to-Map-idea, will be a tool to display Wikipedia tags of the Openstreetmap Database. It should illustrate Wikipedia articles.

Frontend Examples

 * 1) Bürkliplatz-Shape for Bürkliplatz article (static)
 * 2) Mariahilf in OpenStreetBrowser
 * 3) Fossgis2011-WP-GEO Plans of the subject

Thomas' bicycle-map
uses Vector rendering of toolserver
 * 1) http://osm.t-i.ch/bicycle/map/

PostGIS Terminal
Similar in display and db but not storing shapes in db. uses EOSMDBOne / Osm2pgsql, PGSql, Openlayers. Programming in JavaScript, PHP see unten
 * 1) http://labs.geometa.info/postgisterminal/

OSM Inspector
by Geofabrik Tools, background not public

OpenStreetBrowser 2.0
by Stephan P.
 * 1) http://www.sotm-eu.org/slides/29_StephanPlepelits_OpenStreetBrowser2.pdf
 * 2) Mariahilf in OSB  (rel_ Nummer in url ist osm kompatibel)
 * 3) GNU Affero General Public License (AGPLv3) Source

data from original .osm is processed by osmosis (--write-pgsql-dump to $ROOT_PATH/data/) to get the dump which can be loaded into osmosis-db (pgsql_simple_load.sql), the style-xml files(?) are created and with the dumps? rendered to get tiles (probably) and site-specific categorydata.
 * usesPostgreSQL 9.0 + PostGIS 1.5,
 * osmosis (pgsql_simple_schema) for analyse and osm2pgsql for rendering [DOCU file]
 * Mapnik 0.7.1/mod_tile/renderd, Cascadenik (not Tirex)
 * OpenLayers 2.9
 * Osmosis 1.5.1 for updating database + stored procedure OsmosisUpdate

lonvia

 * 1) http://dev.lonvia.de/trac/wiki/OsgendeFramework
 * 2) http://dev.lonvia.de/trac/browser/README which is in the GNU GENERAL PUBLIC LICENSE V.3 Source filesystem

uses Osgende Python-framework In Osgende each derived table is implemented by one class. If you know the Django web frame work then you are familiar with the concept. By convention, each class should implement three functions: construct (to create a new table), create (to create data from scratch), update (to bring data up to date). Osgende provides base classes for common cases, like collecting nodes with a certain tagging or creating polygons.
 * Osmosis, PGSql, PostGIS, Mapnik, OpenLayers. Osmosis Data in Snapshot Schema, own derivate tables may have been (once?) in Simple Schema but look like snapshot after all (no highway column and thelike).
 * Powerful postprocessing for Small derivative tables using ..full programming language

Osgende uses psycopg, Python bindings for osmosis and Shapely, Python bindings for the geos library

GeoShape on Ptolemy

 * 1) http://toolserver.org/~kolossos/openlayers/kml-on-ol.php?lang=de&uselang=de&zoom=15&lat=51.05811&lon=13.74135
 * 2) http://a.www.toolserver.org/tiles/osm/4/3/3.png
 * 3) Ungarischer style: http://toolserver.org/~osm/locale/hu.html
 * 4) doku: https://wiki.toolserver.org/view/OpenStreetMap
 * 5) DOKU outdated mentioning Ptolemy: http://meta.wikimedia.org/wiki/OpenStreetMap

An OSM Multi-maintainer project. Toolserver Ptolemy has a Solaris OS (?).

data goes over a front-end proxy (a.www.toolserver.org, b.www.toolserver.org..)
 * uses a PGSql db with PostGIS and hstore
 * osm2pgsql to fill up the db
 * Tirex with Mapnik-Backend
 * finally OpenLayers

others
Imposm kann auch Daten in die Datenbank schaufeln, hab ich aber keine Erfahrung mit. Osm2postgresql ebenso. http://wiki.openstreetmap.org/wiki/Osm2postgresql
 * 1) http://forum.openstreetmap.org/viewtopic.php?id=12182
 * 2) http://www.mail-archive.com/talk-de@openstreetmap.org/msg85284.html

Osmosis
Data can be in in PostGIS Snapshot Schema (pg_snapsnot schema), or "simple" (which is obsolet according to wambacher). options (Snapshot Schema ):
 * 1) http://wiki.openstreetmap.org/wiki/Osmosis
 * 2) http://wiki.openstreetmap.org/wiki/Osmosis/PostGIS_Setup (Table layout at the bottom)
 * 3) Public domain trunk/core/src (mirror)
 * 4) Public domain trunk/package/script (mirror), Simple and snapshot comparasion


 * pgsnapshot_schema_0.6.sql - Builds the minimal schema.
 * pgsnapshot_schema_0.6_action.sql - Adds the optional "action" table which allows derivative tables to be kept up to date when diffs are applied.
 * pgsnapshot_schema_0.6_bbox.sql - Adds the optional bbox column to the way table.
 * pgsnapshot_schema_0.6_linestring.sql - Adds the optional linestring column to the way table.

osmosis tables: Polygons must eventually be created, but there might be tools.
 * actions
 * geometry_colums
 * nodes
 * relation_members
 * relations
 * schema_info
 * spatial_ref_sys
 * users
 * way_nodes
 * ways

The contents of actions-table of simple schema or the action-column XXlonvia specific can be used to update derivative tables, for example by customising the osmosisUpdate stored procedure. http://www.mail-archive.com/dev@openstreetmap.org/msg04645.html , http://gis.638310.n2.nabble.com/Osmosis-questions-about-applying-changesets-td5811546.html: action column is:
 * changemanagement for derivate tables
 * "A" - Add
 * "M" - Modify
 * "D" - Delete

Osm2pgsql
Osm2pgsql is filtering the information usually for Mapnik rendering and also creates tables to easily do that. Osm2pgsql tables:
 * planet_osm_point
 * planet_osm_line
 * planet_osm_polygon
 * planet_osm_roads (auch in planet_osm_line)

and intermediate tables
 * planet_osm_nodes
 * planet_osm_ways
 * planet_osm_rels

Osm2pgsql adds additional ways for relations with negative relation id and relation tags. Relations that have just point are not supported.(Enforcement-Relationen)
 * Relationen:

default.style filters according to tag/patterns. 
 * Eingangsfilter

If the line is very long then it gets split every 100km. 
 * Split

Updateable, but just for the built-in tables, not for derivate tables, originally. I just found temporary pending column in planet_osm_rels table (virtually undocumented).
 * changemanagement for derivate tables

Openstreetmap-Server inklusive einer osm2pgsql Datenbank mit hstore Spalte in einer Linux-Umgebung einrichten und nachher mit Tirex (wie Ptolemy und auch OSM Dev-Server): 
 * Setup

Comparasion osm2pgsql and osmosis
Both of them can do incremental updates. Both Support for hstore (not stated: the war).
 * Osmosis does no processing thats useful for rendering, that is, it has no polygons.
 * On the other side it has more details, eg. also invalid keys or rarely-used keys, (I expect) and the structure is preserved, eg. from super-relations.
 * osm2pgsql's planet_osm_roads table is just for rendering
 * osm2pgsql's changemanagement for derivate tables would probably need a workaround

Sql Examples
on cool PostGIS Terminal

Tables there, von EOSMDBOne, done with Osm2pgsql: osm_point, osm_line, osm_polygon, osm_nodes, osm_ways, osm_rels, osm_poi, osm_poi_v, osm_all, osm_all_v, geography_columns, geometry_columns, spatial_ref_sys

SELECT ST_AsText(way) AS geom, tags->'wikipedia' AS label FROM osm_line WHERE exist(tags,'wikipedia') LIMIT 1

SELECT ST_AsText(way) AS geom, tags->'wikipedia' AS label FROM osm_line WHERE exist(tags,'wikipedia') AND tags->'wikipedia' LIKE 'de:Bü%' LIMIT 1

SELECT ST_AsText(ST_Collect(way)) AS geom, tags->'wikipedia' AS label FROM osm_line WHERE exist(tags,'wikipedia') GROUP BY tags->'wikipedia' LIMIT 5

tbc.