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" <[email protected]> > An: [email protected] > 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 > [email protected] > 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 _______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/dev
