Contributors functionalities wishlist

From OpenStreetMap Wiki
Jump to navigation Jump to search

The goal of this page is to build a community driven short list of most wanted functionalities by contributors to help them in their day to day mapping work.

It is based on the API_v0.7 page (part of contents comes from it) and aims at beeing the second phase of it by splitting the list into Lower priority functionalities and higher prioritiy wishes (this page) but unlike API_v0.7 it doesn't limits to API 0.7 or core OSM infrastructure but still focus on contributors functionalities (could they be external tools or operated on the OSM servers)

Bare in mind that this is not an easy task as many ideas could just be utopic to develop, duplicate, wanted by some and not by others, and so on. (The bug and suggestion tracking system of the rails-port has several suggestions/bugs still hanging around or closed and not done, and most developpers won't risk spending time reading all of that to order it by priority/feasability/interest/usefullness). So our goal here, is to try something, some method to reach a short list of max 15 "prefered ideas" (10 would be great) just like Top_Ten_Tasks but gathered by the contributors (this is in no way a replacement to the previous) to discover what they miss the most in their day to day work of mapping. That is why people willing to suggest ideas for the wishlist with (long) OSM experience, some (and even more than some) technical knowledge are prefered, but still, every one is welcome to suggest a wish but be prepared that your wish might be move to the Lower priority list, and if that happen don't think it will be destroyed or lost forever !

Note that by no way, even if we manage to reach a nice 10 item list, will there be any assurance that someone will actually do the work. This will still depend on people stepping up and doing work. This list will be however useful to get a more comprehensive view of what are the most important improvements to OpenStreetMap.

Goal being set, the question now is how do we avoid chaos on one hand :400 wishes neven listened to, and dictatorship on the other : One or two self proclamed god (like me) telling what is good or not ? Frankly, I am far far from knowing what the best solution/tool/place is, the best I can do is to say : we have to try, and here is my proposed way of trying it here (please discuss it on talk page for improvement)

Rules

  • Everyone is permitted to add a wish at the bottom of a category while checking that :
  • Is not already there
  • Is noy in the Lower priority list
  • And make it is clear to understand, not too technically oriented, not too long, not already existing and is geared toward mappers

(examples of not wished wishes - examples wishes ok)

  • Please add you name and date with ~~~~ after it
  • If you don't want people to start voting on it, but still would like feedbacks and visibility before that, just express in some way that people shouldn't vote on it. (To avoid chaos, such a wish should be moved elsewhere if here for 15 days without inputs)
  • Every wish has a scoring system of popularity
  • Everyone can add or remove 1 point to every wish by specifying +1 or -1 (with your name and an optional explanation) after a wish. The higher the score, the higher the popularity of the wish should be on long term
  • please don't add too long comments for ease of read, if you want to answer to someone's comment with long reflexion, or start discussing a wish, please continue discussion on it's own page (create it if it doesn't exists in a form like [[Contributors functionalities wishlist/wish title]])
  • Clean-up/shortening list system
  • Once a whish has at least a vote, no one (even creator) should change it's meaning (typo/link/explanation ok). (If you want to change it, write a new one)
  • Everyone can move a wish to the Lower priority list if :
  • The wish has less than 3 votes 15 days after it's creation (1 month for the first big list of origin)
  • The wish stayed at a score of -4 or less for more than 15 days

Notes : You can of course +1 every wishes because you like all of them or ignore those you don't like, but remember that we are trying to reach a short list, 50 wishes on this page will just be useless to developpers A wish on the low priority is not lost forever, you can +1 for them, and bring them back when their score is over -4

  • Ordering wishes for easier readability for those who want to find most popular wishes
  • Everyone can move up or down a wish (and all it's votes) to create a score ordered wish list (don't overdo it for one or two places or the wiki history will be a mess)

Access to history

Monitoring

Users should be able to monitor a boundary box or a set of elements and be alerted when somebody edits them. This way edits gets verified by local mappers faster and there will be less vandalism.

+1 from me! --Lulu-Ann 16:09, 16 December 2009 (UTC)
+1 and allow us to subscribe to them with RSS --Skippern 18:49, 17 December 2009 (UTC)
+1 --Neic 01:27, 3 July 2010 (UTC)
+1 --Don-vip 14:51, 17 April 2011 (BST)
+1 Would have been great if there was something similar to http://wiki.openstreetmap.org/wiki/Special:Watchlist to see if ways/nodes that I subscribes to has changed. --Magol 10:05, 30 January 2012 (UTC)
+1 RSS and email alerts would be great. The more filters the better (based on user name, tags, delete/modify) sletuffe 14:45, 18 October 2012 (BST)

This is already implemented with WhoDidIt, but making this more visible to the mappers might be beneficial. --Sanderd17 16:00, 18 October 2012 (BST)

This one osm-watch comes really really close to this wish. It rather new, but with really few additions it would even be better. sletuffe 19:11, 25 October 2012 (BST)

New History tab/sidebar (see here) powered by OWL should take care of this issue. Paweł Paprota 20:13, 21 January 2013 (UTC)

Better querying of changesets

If you click the history tab on the main page you get a huge list of changesets with a boundary box that intersects your area. This causes all the planet size changesets made by bots and careless humans to appear in every query even if nothing was changed in the requested area. The changesets query should only return the changesets which edited the requested area. 03:11, 18 October 2012 (BST)

+1--Robotnic 14:43, 3 March 2010 (UTC)

  • I second that. That's one of the first problems I noticed as a newcomer, and it's still a major pain. Tongro 11:00, 15 May 2010 (UTC)
  • Good idea, but I would like to add a detail: Even if there is something changed inside the bounding box, it should be possible to get the subset of the changeset intersecting with the bounding box. The sketch mentioned above deals with the issue to get notice about a changeset that did NOT affect the requested area. It does not solve the change reports like "the changeset affected your area; have fun to find the single node inside within the 200k other elements". So: Give me the changes of changeset X inside bbox B, please. --Jongleur 17:51, 11 October 2010 (BST)

-1 : Not really a "must have" IMHO, a monitoring tool, see up there would be better sletuffe 14:45, 18 October 2012 (BST)

  • +1 --Magol 11:54, 24 October 2012 (BST)

Undelete/undo/Return to object version X at core level

A proper undelete would be nice, so it would be possible to retain the old history of the object. If the undelete was implemented as undo, it would also work on visible objects, reverting them to the previous version without having to explicitly specify all the tags etc. of the old version. 03:11, 18 October 2012 (BST)

+1 This is definitively needed since the API 0.6 changes happened during redaction process. These changes basically killed the two (unmaintained) JOSM plugins that provided this functionality. A native undo/revert mechanism provided by the API would not be affected by any future API change. --Don-vip 22:27, 3 October 2012 (BST)
+1 sletuffe 14:45, 18 October 2012 (BST)
+1 When reverting a way, option should also be given to revert all the nodes. It is actually difficult to recuperate one by one the nodes deleted. pierzen 22:47, 23 October 2012 (BST)
+1 --StephaneP 17:49, 24 October 2012 (BST)
+1 any easy way to restore accidentally or deliberately deleted items (whilst preserving their history) is good IMO. Drnoble 20:19, 26 October 2012 (BST)

Keep History at split of an element

It's often the case, that a way is split up into two or more parts to be able to apply different values e.g. for maxspeed or surface to the different parts - or even to add parts of the whole way to a relation only. Currently that's implemented in the following way:

  • delete the nodes of one part out of the way
  • create a new way object containing these nodes
  • upload that

The problem with that algorithm is, that the new way starts with version 1; the history of the other way is not connected to this one any more.

The issue gets obvious at present inside the license discussion regarding "which ways are changed by ODBL/CC-BY-SA/PD only" etc; and there might be other issues as well; e.g. the source tag, mentioning the source of data has to be deleted, when a new changeset applies other sources to the object; but it should be possible to find every object anytime changed with a particular source. To achieve that, a unbroken history would be a good thing.--Jongleur 08:44, 16 November 2010 (UTC)

-1 Looks complex to me, and low priority sletuffe 14:45, 18 October 2012 (BST)
+1 for keeping a referal to the history, but this would be something the editors can already do. Like they used to put the "created_by" tag on every object, they could now apply a "created_from" tag, which contains the id (and version number) of the original way. So you can query the history of that way. It wouldn't need a lot of work. The same could work with merging, by putting a merged_from tag on it. Those tags can be deleted again in the next history version. As they only count for one point in history. --Sanderd17 16:06, 18 October 2012 (BST)
+1 I see similarities with Braches in the Revision control System (like CVS). It should be handled and presented in a similar manner.--Magol 11:58, 24 October 2012 (BST)

Improve history requests

Getting, at editor side, every operations that happen to an object and all tags (or at least comment) of the changesets envolved so that we can have an idea of which contributor did what, why and when.

please discuss+improve before voting, if that is of interest. sletuffe 03:42, 18 October 2012 (BST)

Prevent "Big" changesets

"Big" Changesets usually mean that an armchair mapper is trying to change the world to match their understanding of it. Preventing these from being submitted would force said armchair mapper to break down their changes geographically, making it easier for mappers submitting changes based on the outside world to know when a changeset affects anything that they've added.

An alternative (if this seems a bit drastic) might be preventing changesets larger than a certain size by new users (however "new" is defined). Users should "earn" the right to make progressively larger damage.

Changesets affecting one geographically large OSM item (e.g. a large relation) would still be allowed. - SomeoneElse 17:36, 11 March 2011 (UTC)

What is "big" here? Is it affected area or number of objects? Either way, such limitation would make large-scale fixups and cleanups harder to make and harder to revert (if an error is found after data is modified) if they have to be split into smaller changesets. Limiting only new users may be useful though (more for "number of objects" case, e.g. moving a large portion of data to an unaligned satellite image). - AMDmi3 23:56, 27 June 2012 (BST) 03:11, 18 October 2012 (BST)

-1 I fail to see the real problem ? Of course, a large mixture of edit types is not really good, but it's better to contact users cases by cases sletuffe 14:45, 18 October 2012 (BST)

Changed ways/nodes highlighted on the map

I wish that you can see on a map exactly which nodes/ways that have changed in a changesets.

  • New nodes/ways = green
  • Edited nodes/ways = yellow
  • Removed nodes/ways = red

As it is, you will only see a list of changed nodes/ways in the history of a changesets, and it is difficult to understand the context.

I also wish that you can see all the changes that have occurred in the selected region between two changesets (just like you in Wikipedia can make a comparison between two changesets in an article). I would welcome comments before voting --Magol 09:09, 25 October 2012 (BST)

This one really looks like a duplicate of Contributors_functionalities_wishlist#Map_generation_of_data_at_one_point_in_time, maybe we should merge them ? sletuffe 10:27, 25 October 2012 (BST)
You are right. That suggestion and my suggestion has absolutely parts in common. The best is probably to merge them, but the rules say you can not change on a proposal that someone has already voted on :-(
--Magol 16:37, 26 October 2012 (BST)

New History tab does exactly that. See http://owl.apis.dev.openstreetmap.org/. In the future maybe the changeset details page also will be powered by this software. Paweł Paprota 20:16, 21 January 2013 (UTC)

Areas

Multipolygon bbox [DONE]

Allow for border relations to be used as bbox when downloading an area. This will allow one to download only a certain municipal instead of making several (often overlaping) downloads to cover the same area. 03:11, 18 October 2012 (BST)

+1 from me! --Lulu-Ann 16:14, 16 December 2009 (UTC)
+1 from me! --Bahnpirat 14:57, 17 March 2010 (UTC)
+0 Polygons from relations still have trouble and will so for a long time. See above at areas. I would suggest rather a map call to download from a polygon with explicitly stated coordinates.
+1 Maybe as a external service sletuffe 21:21, 21 October 2012 (BST)
+1 could be an external service pierzen 20:21, 23 October 2012 (BST)
+1 StephaneP 17:49, 24 October 2012 (BST)

With Overpass API 0.7, you can now download by explicit polygon or from an OSM based area. The languge guide contains an example. -- Roland

I'd say this solves the case. Nice feature ! sletuffe 22:41, 8 November 2012 (UTC)

Areas are too often broken

Any areas in the database are prone to breakage. Simple closed way less often than relation, but both can exist in the database and are an hard work for mappers to detect the breakage and repair the breakage. Wouldn't it be possible to forbide broken areas in the first place when a user uploads a broken area ? sletuffe 03:37, 18 October 2012 (BST)

+1 but have no ideas how to do that ! sletuffe 14:45, 18 October 2012 (BST)
-1 broken areas can sometimes be "under construction". I'm thinking mainly of boundaries in this case, where a partial boundary is also useful information. As such, forbidding seems too severe, giving a clear notification might be better (ad I believe JOSM already does this).--Sanderd17 16:11, 18 October 2012 (BST)

Various

OpenStreetBugs integration [DONE]

It has been discussed many times before and every time the outcome of the discussion was that there should be no dependency on an external web service that is not under OSM's control. So the solution would be to integrate OSB functionality into the OSM website and API. 03:11, 18 October 2012 (BST)

I think that OSM would benefit greatly from a prominent "report a problem/bug" link on the homepage to lower the barrier of entrance for new users.

This is a political decision rather than a technical one. Moving the OSB servers to the foundation's server rack does not require any chanes to the API. --Ivansanchez 10:41, 2 February 2010 (UTC)
Uhm...you believe it is a political decision but I believe it is a technical one. We've got to decide on all those proposed features for API 0.7 (that's the political part) but I really meant this to be integrated into the API (just as I said before). I don't believe a single server will be physically moved in this process. Code reuse from the current OSB maybe. But I thought about proper integration with anonymous and authenticated bug reports etc... --LarsF 15:20, 2 February 2010 (UTC)

Search for GPX-Tracks

We need the ability to search for GPX-Tracks which fulfil some criteria as supplied by name, description and tags. 03:11, 18 October 2012 (BST)

The should also include tracks intersection certain areas or within a certain distance of a requested position.
This shall also include searching for tracks with a certain age (newer than the construction)

Better handling of sourcing ('source' tag)

We know that source of data and source date is a fundamental information when we use external sources (like aerial imagery) and not only local surveyed contributions. This information will be more and more important once OSM has reached a certain level of completion. We cannot avoid that but external sources may be outdated and it will then be important in the future to display quickly the existing contributions sources and dates, not only the date of the edits but also the dates of the sources like public data or aerial imagery. Otherwise we cannot avoid that arm chair contributors override older contributions surveyed locally or that recent aerial images or public data are better than very old survey.
Current solution is to put the tag source in the changeset or in each element, completely optional. Putting the source on the changeset is not perfect since a changeset can group different sources. Putting the source in all new elements is painful in editors and it will take a lot of resources.
03:11, 18 October 2012 (BST)

+1, I think this is something where editors should be improved : be able to automatically set changeset tags (AFAIK JOSM propose allready a lot about that) sletuffe 14:45, 18 October 2012 (BST)
+1, Actually sourcing each element is fastidious --PanierAvide 10:54, 24 October 2012 (BST)

Tag Search as a Top Level Feature

Xapi provides a very powerful search facet that would offer great benefits as part of the main API: node or tag search. There are many interesting operations to perform on "all water fountains in this bounding box", for example. Tag search should allow a much larger bounding box compared to any other operation, or perhaps support a limit/offset feature (return the first 1000 drinking fountains... the next 1000... etc)). 03:11, 18 October 2012 (BST)

What's wrong with getting data from XAPI or Overpass API? They allow for almost arbitrary bounding boxes, and are orders of magnitudes faster than the main API could be for tag searches. -- Roland
-1 As Roland said, this allready exists with XAPI/Overpass API sletuffe 14:45, 18 October 2012 (BST)

GPX tracks calls to get per time period tracks

There are lots of GPX tracks in the OSM database and calls exists to call them by BBOX, but some of those tracks are very old and could have been recorder after changes on the road (new roundabout/exit/road). A way to call tracks in a given time period for a given bbox would help to filter out no more up to date tracks. sletuffe 17:07, 24 October 2012 (BST)

+1 sletuffe 17:19, 24 October 2012 (BST)
+1 StephaneP 17:50, 24 October 2012 (BST)
+1 JB 6 December 2012 (BST)

Editing the map

Layers

Support for layers so that editors only receive certain types of data to limit work load on clients and server.

Just allow the API to filter stuff, like OSMXAPI does. And keep in mind that a node may be shared between, say, a road and a fence... so if one of these features is not included in the downloaded data, it should be marked in some way, to let the editor know. --Ivansanchez 10:41, 2 February 2010 (UTC)
I know it will be a PITA to store, but in theory a database query can return a list of objects that a node are members of, that way the editor can know if a node have other bindings than what is in the memory. On the other hand, it can make the memory load if the editor almost as big as if all the information was there, so that the workload part for the software (client side and server side) might not be altered. For the user on the other hand, when editing in areas with a high level of data, it can be a benefit to filter some parts of the data out. --Skippern 21:53, 4 March 2010 (UTC)
Since the data is stored differently on the server than on the XML files commonly used by editors, an aditional XML value can be added to show wether an object have unseen bindings when layering are used. i.e. a node can have <binding way="id#1,id#2" relation="id#3"/> telling the editor that if this node is edited, ways #1 and #2 and relation #3 should be consulted before uploading. --Skippern 21:18, 25 February 2012 (UTC)

03:11, 18 October 2012 (BST)

+1 However XAPI or Overpass API can allready do, most of this request. (Maybe some related parent/child problems to handle of building not overlaping moved roads, but that's tricky) sletuffe 14:45, 18 October 2012 (BST)

Anonymous edits

A lot of users just wants to edit a smal part of the map and not have to register. Why not do like wikipedia and allow anonymous edits up to a limit. The ip address will be stored and after x amount of changes to objects the ip address will be banned and the user will have to register to contribute more. This is an alternative to openstreetbugs and may not be needed if openstreetbugs is more visible to the public. 03:11, 18 October 2012 (BST)

Disabling Anonymous edits was a thought-out decision in 2007. The discussion from that time should explain the reasons. Alv 18:08, 28 February 2010 (UTC)
This is not the same type of anonymous edits. I im sugesting to allow users to edit the map with limited access or to upload tracks without the hustle of creating an account. Just like wikipedia. Gnonthgol 18:30, 28 February 2010 (UTC)
Anonymous Editors should be able to edit their own view of the world. If somebody adds a building he will have this building on his map until he deletes the browsercookie.

If the user want to contribute to OSM he should be able to sign up after editing. If the user finaly has an account he can send for example his collected gpx files to OSM. The API needs no change for that.

JOSM sort of have it implemented already (the user can edit as much as he like, but only upload after he have registered). Maybe Potlatch should have a similar approach? Let people edit as much as they like, maybe even save it as an OSM-diff file, but only apply the changes after registering? (Obviously not API related) --Skippern 02:09, 22 March 2010 (UTC)
-1 Having users with real email seams better as best default pratice, however, in some rare case, someone in charge could set up a "group account" for multiple contributors's simple edits. sletuffe 14:45, 18 October 2012 (BST)
+1 Anonymous users could have the power to suggest edits. A registered user could review the edit and the edit would be that user's responsibility from then on and from then on be rendered. To prevent the need for API changes, the edits could be signed to a special account and all edits of said user won't appear until approved. - Svavar Kjarrval 03:48, 24 October 2012 (BST)

Lock regions

I'd love that the API 0.7 could lock (small) regions if i am editing them. If another user want to modify then he can't if it is locked. However just a region of a maximum of 1 square kilometer should be locked by a user and a maximum of one lock should exist with a maximum duration of 1 hour. Optionally a lock could be just a warning, that somebody else is editing the area already. To prevent vandalism, local chapter/group of experienced local mappers would say that e.g. motorways are finished in given area. No one would be allowed to change/add new motorways. To change this lock, the same group would remove this lock. This would prevent unexperienced mappers from biggest mistakes, trolls from drawing names with motorways and marketing experts from creating cities from pubs.

Lock would include

  • area (multipolygon)
  • element types that are finished
  • maybe only geometry is locked and new tags are possilbe (eg. other language names)

examples:

  • a country and place=city
  • region and highway=motorway|trunk
  • country and region boundaries
  • region and coast boundaries

03:11, 18 October 2012 (BST)

-1 against OSM's philosophy, adn I fear that it would be too hard to know who to ask to correct real mistake. Maybe only in edit wars scenarios (like the "locked page" on wikipedia) but I wait fot the problem to appear. sletuffe 14:45, 18 October 2012 (BST)

remove the atomicity requirement from the POST /api/0.6/changeset/#id/upload call

When an upload to the API is interrupted, the database ends up having orphan nodes and half way done operations, it would be better not to have anything at all (and restart upload) sletuffe 03:32, 18 October 2012 (BST)

+1 sletuffe 14:45, 18 October 2012 (BST)
+1 a big big +1 StephaneP 17:51, 24 October 2012 (BST)
+1, this solution or another after an interrupted upload JB 11:57, 15 November 2012 (BST)
this is technically not correct, a single changeset upload via the API endpoint is atomic on database level. Mmd (talk) 17:16, 11 December 2020 (UTC)

Backgound map with the most possible objects

When I am editing with JOSM my main way of retrieving data is to browse around the places I know with the integrated slippy map, and searching for strange elements, strange names, and any type of odditiy I can see in order to correct or improve them. Before Osmarender was shut down, this was my main choice for a map because it shows much more things than the main (mapnik based) map. I'd like to use again a map (up to date) and crowded with details, no matter if that isn't pretty, geared toward contributors, and not consumers. I'm perfectly find (well, I don't care in fact) that the mapnik base map is a "nice show case" or good to have on one's website, but I miss one hugly map with all (or most of) approved features of the wiki. sletuffe 14:58, 18 October 2012 (BST)

+1 sletuffe 14:58, 18 October 2012 (BST)
+1 pierzen 00:49, 24 October 2012 (BST)
+1 RM87 16:00, 24 October 2012 (GMT)

Map generation of data at one point in time

Datas are removed from the database, but it is hard to get an idea of what was removed on a certain area. A new layer, with all deleted data from date D to now (or date D') would be nice to get a view of what was there, but was removed. Monitoring the deletion is another option suggested here but it is harder to get things of the past with such a suggestion, and a map is sometimes better for an overview. sletuffe 17:14, 24 October 2012 (BST)

+1 StephaneP 17:53, 24 October 2012 (BST)
+1 pierzen 22:54, 13 November 2012 (UTC)

Still improve sorting in route relations

Route relation elements can be sorted with the A–Z button in JOSM relation editor. However, route split, dual parallel ways are not always well understood and sorted, leading to a route presented as several "broken parts" when it still is a regular one. An example may be a bus route, old version, with a single relation for both directions, passing a roundabout with oneway-split access to the roundabout. No sorting can currently take into account the split way–roundabout–split way without "breaking" the route continuity. Also happening with foot routes – JB 6 December 2012

Data model semantics

remove /relation/id/full call

The ability to download a relation and all its members lets many mappers create otherwise useless relations ("all park benches in Munich") just so they can download their pet dataset more easily. This has to stop - let's drop the /relation/id/full call. --Frederik Ramm 22:59, 12 October 2010 (BST)

+1. It is generally a good idea to drop expensive but less useful API calls. -- Roland
-1 This call is really usefull for relations, and the fact that people create bad relation to make this call usefull to them doesn't mean this call is bad. (It means we should listen to them and ask what they want to do and provide alternatives) Beside, people would then turn to other API and the problem won't be solved. However, if the question is about a too intensive call for servers, why not move it to somewhere else. sletuffe 14:50, 18 October 2012 (BST)
-1 when I'm editing a cycle route, or a boundary, it is not possible to download the area where the route passes (it's just too big). It's a lot easier to download all members via the relation, then search where the exact problem is, and download a small area around the exact problem to fix it. --Sanderd17 16:19, 18 October 2012 (BST)
-1, definitively necessary when working on broken routes or boundaries – JB 6 December 2012 (BST)

180th meridian

Perhaps allowing for nodes to have a longitude a bit greater then 180 to allow ways to connect properly and do some magic in the getters to make them appear on the 0 longitude. 03:11, 18 October 2012 (BST)

+1 So that the date-line, and borders that crosses the 180 can be correctly handled by the API, routing, and rendering without fancy workaround. Allow queries to seamlessly pass 180, i.e. with bbox values >180 --Skippern 18:52, 17 December 2009 (UTC)
-1 This bears the risk of duplicate data. In particular, then you have additional workarounds in the API and other workarounds necessary in the tools (what of somebody connects two existing features with longitude close to -180.0 and 180.0 respectively over the 180th meridian?) and unclear semantics. -- Roland
-1 I think a lot of software is based on the fact that those values are between -180 and 180. So changing this might cause extra trouble instead of solving it. --Sanderd17 16:21, 18 October 2012 (BST)

Disallow Empty Relations

There are tons of relations without any members in the database. Most of them seem to have been created by accident. Those that have been added intentionally are perilously close to falling under [Relations are not categories] and there would be not much lost, if they disappear. So, the API should refuse to accept empty relations. Lonvia 18:05, 20 July 2011 (BST)

Even if empty relations may be accidents most times now, they can also be used to more proper express things such as e.g. highway=service + service=driveway, which really means highway-->service-->driveway. Each tag is independent and there is nothing in the API to specify which tags belong to each other. This also leads to things like key:subkey:subsubkey=value or the use of ";" where a tree style key/tag-structure would be better to represent such things. I hope that this issue would be resolved in API 0.7, as for now empty relations are the only way to construct such trees to avoid the use of ";" in values (e.g. for cuisine=*). --Fabi2 00:46, 25 July 2011 (BST)

03:11, 18 October 2012 (BST)

-1 I don't think empty relation are that often, creating the list of long standing empty relation would be better to check them, and, optionaly delete them. sletuffe 14:50, 18 October 2012 (BST)

/Ways are just simple relations

Why not remove ways as a primitive and implement them as a subset of relations? This can be done transparent of the user by having a sort of hidden this_relation_is_really_a_way=yes and serving out just those tagged with it when user queries for ways. Hm... This wouldn't even require an api change, but still... --Gorm 15:05, 7 June 2010 (UTC)

this_relation_is_really_a_way would imply: 1) only nodes may appear as members, and 2) members (nodes) do not have a "role". So although you may think of ways as a special subclass of relations (or they may be just that in a mathematical sense), they form such a strongly restricted subclass that it is wiser to implement them separately, which also avoids some overhead. -- Oli-Wan 07:48, 6 November 2010 (UTC)

03:11, 18 October 2012 (BST)

-1. Relations and ways have very different semantics. The geometry of a relation is just the accumulated geometry of its members: a relation belongs to a bounding box if it has a member that belongs to this bounding box. A way can belong to a bounding box without having a node inside it: one of its segments can intersect the bounding box. Relations may be mutually included to each other and/or distributed over very large areas, ways not.
And from a technical point of view, also no: You have to sort out by hand what you now get granted. This will break every unmaintained tool and divert several man months during transition as well as for future tools (they have to handle the error case of a way having roles) for no extra functionality. -- Roland
-1 I don't see much benefit. Eventualy, for areas, in the current state of model, why not have only relations. But still, I miss the goal of this wish here. sletuffe 14:50, 18 October 2012 (BST)
+1 This might be a way to avoid the problem with "micro-splitted-ways" mentioned above. A common Way might look like this (also tagged as regular ways):
Proposed_osm_way_of_storing_it

--rayquaza 01:15, 30 October 2012 (UTC)

Categories

Just a crazy idea while reading #Disallow Empty Relations and #remove /relation/id/full call: What about a new datatype "Category"? If it's unwanted to (ab)use Relations as Categorys but users want them, we may give them some sort of simplyfied relation called "Category", which contains an unsorted (might be sorted by editing- or viewing-tools) list of element a name, maybe one or two other tags and may be part of an other category or relation. Sorry for my bad english. --rayquaza 01:15, 30 October 2012 (UTC)

Public transport timetables

When it comes to integrate a online map in a website in Switzerland, most prefers map.search.ch because of the nice bus/tram stops and railway stations with integrated live timetable. In fact, while pointing on the symbol tram / bus stop, railway station / halt or boat station, a windows open with up to 5 lines of public transports with the two next departure times in each direction. There are also two links (travel to here and travel from here). f.ex. this small town http://map.search.ch/maennedorf This would be a nice and competitive feature for OSM. For example with a tag "timetable=Country" and uic-name or uic-ref Country name would made the link to the API of this country's online timetable. --Männedorf 08:12, 21 January 2013 (UTC)

See Also

Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Contributors_functionalities_wishlist&oldid=2071365"