[OSM-dev] project idea

[Thomas Meller]

Thank you for your suggestions.

To explain what I think of, let me crosspost this:

--------schnipp----------

I climb rocks.
There might be the need to find a climbing facility for the next weekend.
I specify the difficulty level, the radius, the date and let software create a list of suggestions.

Near where I live, there is a rock inside of a game reserve. That is, you are not allowed to leave the ways from octobre til june. Resulting in 'climbing forbidden' til july.

Other example:
Road, find boundaries:
found :
- Boundary_Europe
- Boundary_Switzerland
- Boundary_Kanton_Solothurn
- Boundary_Communal_Grenchen
- Boundary_city_limit
- Boundary_landuse=residential

Road is highway=primary
Europe adds nothing
Switzerland adds maxspeed=80 kph
Solothurn adds nothing
Grenchen adds nothing
city_limit adds nothing (different in other countries)
landuse adds nothing
Road adds maxspeed=50 kph

Result: maxspeed=50kph
If the road wasn't tagged at all, the result would be maxspeed=80 kph.

--------schnapp----------


The decision how and on which application layer to implement such functions depends on how these should be used. You mentioned off-line use. That makes implementation client-bound and thus platform-dependent, but opens the opportunity for offline use. A question of taste and goal, if you ask me. (wow, I found two tasks instead of one! ;-)

Whether these functions should form part of the OSM API or if they should be implemented as a stand-alone service relying on OSM data is a question I cannot answer. Every implementer should consider consulting the creators of the OSM API to add to usability instead of complexity.
As I wrote: spending some thought on the platform which executes these functions could get vital when/if OSM becomes a widely accepted data collection. The calculations needed are not trivial and demand some computing power on the server's part.

I could imagine a function to get 'effective' tags, specify a filter on what bounding object need to fulfill (ex: admin-level <=3 .OR. landuse=*) and an output format out of a collection of several models, returned as an array. One could be 'tag|value|admin-level', another could be 'tag|value|tag-source', where tag-source can be (explicit|default|regional).
But my ideas may not be mature. I am not capable to foresee every possible use of such functions.

One thing I see ist that a way- or area-type of object can intersect with a boundary. The result may be a number of resulting sub-objects with their own individual set of effective tags. You could divide this task into another set of functions which return an array of sub-objects. This adds the need to handle such sub-objects (a really new set of things to do).

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

I'm going to write down a description on my account's discussion page before I post it on the Student_projetcs page. Corrections in every respect are highly welcome!

Thomas

-------- Original-Nachricht --------
> Datum: Fri, 12 Mar 2010 09:27:27 +0100
> Von: "Peter Körner" <osm-lists at mazdermind.de>
> An: dev at openstreetmap.org
> Betreff: Re: [OSM-dev] project idea

> Graham Jones schrieb:
> > 
> > Thomas,
> > I think this suggestion is essentially to provide a 'default' set of 
> > tags for ways depending on where the way is.
> > If the tag is not explicitly included in the way, the API will return 
> > the default?
> > 
> > I can not help with the technical aspects of this, but it sounds like a 
> > fair suggestion for a project working on extending the API - can someone
> > that knows about the API code comment?
> Please don't put it in the API. The API and the Planet-Dumper and all 
> server-side tools out there just should show what's in the database -- 
> not more, not less.
> 
> For me this sounds like a feature for a client library, that can be 
> plugged in or out. This Plugin for this client lib could (!) use the 
> rules from some server but could also use rules locally stored (eg. when 
> in offline mode on some navigation device)
> 
> Maybe some parts of the JOSM-Code could be used as a basis for this.
> 
> Peter
> 
> _______________________________________________
> dev mailing list
> dev at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/dev

-- 
http://www.openstreetmap.org/?lat=47.172&lon=7.4395&zoom=15&layers=B000FTFTT&mlat=47.16677&mlon=7.43513

GMX DSL: Internet, Telefon und Entertainment für nur 19,99 EUR/mtl.!
http://portal.gmx.net/de/go/dsl02

-- 
http://www.openstreetmap.org/?lat=47.172&lon=7.4395&zoom=15&layers=B000FTFTT&mlat=47.16677&mlon=7.43513

GMX DSL: Internet, Telefon und Entertainment für nur 19,99 EUR/mtl.!
http://portal.gmx.net/de/go/dsl02