User talk:Tmeller

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.

Licensing :(

Hello! And thanks for your upload - but some extra info is necessary.

Are you author of images https://wiki.openstreetmap.org/wiki/File:Barrier_tightcorner.JPG https://wiki.openstreetmap.org/wiki/File:Smoothness_veryhorrible.JPG  ?

Or is it copied from some other place (which one?)?

Would you agree to open licensing of this image, allowing its use by anyone (similarly to your OSM edits)?

Would you be OK with https://wiki.openstreetmap.org/wiki/Template:CC0 (it allows use without attribution or any other requirement) ?

Or do you prefer to require attribution and some other things using https://wiki.openstreetmap.org/wiki/Template:CC-BY-SA-4.0 ?

Mateusz Konieczny (talk) 17:36, 30 October 2021 (UTC)

This also applies to https://wiki.openstreetmap.org/wiki/File:Barrier_unnamed.JPG Mateusz Konieczny (talk) 18:33, 2 December 2021 (UTC)

Thomas Meller 13:36, 5 March 2022 (UTC)

I added a copyright notice to the remaining image. I am not very active any more.

Can you consider using https://wiki.openstreetmap.org/wiki/Template:CC0 or https://wiki.openstreetmap.org/wiki/Template:CC-BY-SA-4.0 license? GNU GPL is quite unusual and problematic for images (was used for https://wiki.openstreetmap.org/wiki/File:Smoothness_veryhorrible.JPG )

And https://wiki.openstreetmap.org/wiki/File:Barrier_unnamed.JPG https://wiki.openstreetmap.org/wiki/File:Barrier_drehkreuz.JPG are without license at all Mateusz Konieczny (talk) 09:41, 8 March 2022 (UTC)