User talk:Tmeller

From OpenStreetMap Wiki
Jump to: navigation, search

surface_unification

folgendes Schema vorgeschlagen:

complexity:<use>=*
<use>=[skates|handicapped|sportscar|pedestrian|citybike|citycar|mtb|4x4|enduro]
values=[easy|intermediate|challenging|difficult|tough|impossible]

Ich verwende es in meinen surroundings. Fuehlt Euch dazu eingeladen, das Schema zu verwenden.


Suggested the following scheme:

complexity:<use>=*
<use>==[skates|handicapped|sportscar|pedestrian|citybike|citycar|mtb|4x4|enduro]
values=[easy|intermediate|challenging|difficult|tough|impossible]
ex:
highway=track
tracktype=grade3
complexity:mtb=easy
complexity:sportscar=intermediate
complexity:skates=impossible
complexity:citybike=easy
wheelchair=no

I use this scheme in my surroundings, especially in the forests around where I'm living. Feel free to use it.

seasonal availability

Suggesting this scheme:

access=private
seasonal_on:access=month
month_on=11-04
seasonal_off:access=month_off
month_off=06-09
seasonal:access=weekdays
weekdays=01,07

means:

private access between november and april, including, and on every sunday and saturday
open access between june and september, including

status: incomplete, data model not error-free


access:seasonal=private
seasonal:weekdays=active
weekdays:month=01,07
month=11-04

means:

access is private on sunday and saturday from november to april, including

status: seems complete, does not support every constellation

Student Projects

This is a draft of a description of a project which may be of interest to be implemented. Up to now, the text and goal definition are not mature. Once they are, post this text to the Student_projects page:

Thomas, can you include it in the GSoC projects list too once you have finalised it please (http://wiki.openstreetmap.org/wiki/GSoC_Project_Ideas_2010)? Thanks, Graham - Grahamjones 20:45, 13 March 2010 (UTC).

Description:

To find the start of how the ideas evolved, see the original idea's post and where the stone started rolling.

draft_1
Many regions in the world, be it a country, county, town, or other type of categorisation, often have properties specific to the region in question. Using boundary objects, one could translate these properties to a styling for the object on the displayed map, much like CSS attributes are used to style objects in a DOM structure.

draft_2
Usually, most objects in OpenStreetMap can be adequately characterised by default properties attached to the type of object in consideration. However, many regions in the world, be it a country, county, town, or other type of categorisation, often have properties that are peculiar to the region in question.

Thus, it seems best to characterise objects through a mixture of default and specific tags, based on a hierarchy of geographical boundaries. For most cases, the default attribute tags would suffice, but where present, explicit tags would override these. The tagged properties on the boundary objects would translate into a tagging style on the objects inside, much like CSS attributes are used to style objects in a DOM structure.


Tasks:
  • tagging of such boundary objects
  • data representation in the OSM technical environment to serve queries for such objects
  • technical infrastructure needed to support queries for such objects (->performance)
  • API functions to support such queries
  • definition of use-cases to be used as introduction and as a pilot-project to test such a function's versatility


hints and help:

Every implementer should consider consulting the creators of the OSM API to add to usability instead of complexity.


thoughts:

Offline use makes implementation client-bound and thus platform-dependent. A question of taste and goal. An online implementation can be maintained easier and adds less complexity while still supplying a default infrastructure for this task. Spending some thought on the platform which executes these functions could get vital. The calculations needed are not trivial and demand some computing power on the server's part. Whether transforming the resulting data as a batch job or better on request should be considered.

Objects intersecting with boundaries may be divided into sub-objects to be handled individually. There is currently no support for such data.

The project can get really demanding and needs to be truncated somewhere.

Care must be taken in deciding, in case of conflicting tags, which value gets precedence. A policy to handle such cases could be of help, bound to objects containing other boundaries and defining the precedence and the depth or object-type on which it's validity ends.