Talk:Strategic working group/Suggestion review

This is an exercise by the Strategic working group to compile suggestions/comments made by the OSM community as to the future direction of the project.

We are looking to collate suggestions about OSM future strategy (e.g. "OSM should grow the mapper base", "OSM should make special efforts to reach out to the developing world", "OSM should develop osm.org into a consumer-facing map site to rival Google Maps"). We're not looking for operational suggestions (e.g. "OSM should rewrite the editor in HTML5" :) ). We're also not yet making any judgments about the suggestions: just collating them.

How to add your suggestions

• Click 'Edit' and type your suggestions below. Please sign your suggestions with your username. You can do this by typing four tildes (~) in a row.
• Please do not comment on others' suggestions yet. That's not the point of this exercise.
• Make sure your comments are restricted to OSM future strategy, not operational suggestions.

Suggestions

• Make it easier for people who come to osm.org to use the maps and data in simple mashups/data displays, e.g. share a map with a route of a walk they're going on with friends or produce a map showing all the cycle parking in their area for a meeting. Some tools exist but they're hard to find and often confusing. The word "postgresql" should never come up in conversations about these simple tasks :-) This would help motivate mappers by giving them something truly valuable in return for their contributions. TomChance 19:13, 29 November 2011 (UTC)

• Enable non-technical communities to contribute without learning Potlatch / OSM data / etc. Wheelmap and ToiletMap.org are excellent examples of helping people to contribute without needing to identify themselves as mappers or OSM contributors. There are endless community networks who would be interested in this, but not in becoming OSM contributors. TomChance 19:13, 29 November 2011 (UTC)

What does this mean? Should OSMF host lots of different websites for specific usage, i.e. hosting for wheelchairmap, fountainmap, bicycle map? Or do mean some kind of way to handle loads of anonymous submited data Erik Johansson 09:08, 30 November 2011 (UTC)

I tried to avoid writing up the "operational" means to achieve this, but briefly it could include maintaining toolkits to make it easy for people to create these maps (i.e. without expecting them to hack OpenLayers code and set-up postgregis tables) and thinking through the consequences of the anonymous data, how to manage relationships with potentially large external membership organisations, etc. TomChance 10:44, 2 December 2011 (UTC)

• Under "Encouraging the OSM community" we already list "actively working for a more harmonious community"; I would like to note that one aspect of this is establishing an efficient, no-nonsense way (i.e. not Wikipedia style) to deal with edit wars, disputes, and vandalism. This could be an extended Data Working Group, or tools to empower the community to police itself, or a combination of both. It might also tie in with the "Local Chapters" issue. --Frederik Ramm 19:51, 29 November 2011 (UTC)

• OSMF must be like Kickstarter. OSMF must encourage everyone to propose a project on "Do-ocracy" principles. Many community members are good programmers but do not want to be burdened with fund raising and administration. As long as it meets a few basic requirements, it gets the go ahead. For example :
  • It must be a global project, not something that belongs in a chapter
  • All software must be open source
  • Before starting, donors must pledge enough money so that it is not dependent on OSMF funding
  • Before any hardware is purchased, a small scale demonstration must exist
  • No forking i.e. must not be detrimental to the license change process -- Nic 20:34, 29 November 2011 (UTC)

• I noticed that outside the "western" world many people have never used traditional paper maps, often because the only maps readily available are not in their language and only produced for the tourist market. However, GPS navigation devices are quite popular. So I suggest to
  • offer easy ways to get printable maps in local languages, either for city sized areas and including a street name index or country+ sized areas.
  • offer map files for navigation devices (with a choice of labeling in the local language(s) of the covered areas or english labels) at the project website. -- Lyx 21:21, 29 November 2011 (UTC)
• Please tighten tagging rules, there are so so many objects with nothing more than created_by and source tags and nothing more also objects with "epic novel" notes & comments. Sparrowhawk 02:57, 30 November 2011 (UTC)
• Under "Providing resources for existing mappers": It will also be important not to lose highly-motivated mappers with a lot of contributions, particularly in areas that are already very well-mapped and seem not to offer many possibilities for extensions at first sight. We'll have to hold more appeal for them to map even more details of their preferred area, e.g. any kind of 3D information. For this, the appropriate tools will have to be developed (or are already under development). -- Bvbmatze 07:38, 30 November 2011 (UTC)
• I second Tom Chance's suggestion. OSM should provide easy interfaces for all Internet users. OSM is th eonly way to have the walking trails and cycling routes across borders. That should be made accessible to all. --Hugo H 07:50, 30 November 2011 (UTC)
• Under the heading "Encouraging the development of the map" I would like to see a campaign to encourage mappers to fill the holes in the map. The biggest drawback from the map user's point of view (in my case bicycle tourist) is the fact that map coverage is to uneven. We need to undertake a concerted effort to have at least all relevant roads on the map. OSM mappers seem to insert incredibly detailed information on the map, but in very restricted areas only, but at the same time there are areas where there are barely the main roads. Volker 09:13, 30 November 2011 (UTC)
• On the question of if OSM should be more like Google Maps, then it would be nice, but my feeling is that currently the resources are not available to do a good job. Whatever the decision, the homepage should reflect the type of service OSM offers. Currently OSM does not offer a "Google Maps" type service, but the main OSM.org page sure looks like Google Maps. IMO, it creates a set of expectations that OSM does not deliver. Andrew 14:09, 4 December 2011 (UTC)

• Support universal converging rules/tagging/everything, discourage any local standards for features that are not inherently local. For example hiking trails created by a local organization can have local mapping to tags, but the final tags should be universal in every country. Classification of roads can be local in a sense that offical class M, D, R, A... can have locally specific corresponding tag in OSM, but the tags used should be the same. Generally one should not be able to recognise what part of the world is on the map if the names are ommited. Reason: Divergent loacal specifics can, in the long term, make it impossible to create universally applicable tools. --LM 1 22:19, 7 December 2011 (UTC)

• Support default tags and values for areas especially for highway=* within administrative boundaries. Each highway would have default topspeed based on the position and type. If eg. the legislation changed, this would be fixed by one change. Only exceptions (traffic signs) would be tagged directly on the roads. The system should support inheritence (all lower levels would inherit default tags from the immediately higher level, unless explicitly changed there - in effect the most specific available info would be used). Reason: This would make it easy to have consistently tagged large areas wihout thousands of tags replicating the same information. Note that for navigation it is useful to have even the default speedlimit displayd while driving, especially in a foreign country when one is not sure about the default limit is or class of the road. --LM 1 13:38, 8 December 2011 (UTC)

• Better quality and coverage info for so called "professional' user communities. If you come to OSM from the public sector for example it is difficult to understand what the data may be fit for. Potentially the public sector could be a source of very map savvy contributors StevenFeldman 12 December 2011

• Should OSM shift balance of focus from contributor centric (i.e the mappers or community) towards users and potential users. I am not suggesting that we ignore contributors just make more effort to understand the needs of users. StevenFeldman 12 December 2011

• Introduce some easy way to render some limitid area based on custom rules. Something that would allow an advanced user to render a few custom tiles within one hour after deciding to do so. (generally I find it quite easy to contribute to the map, but very difficult to actually use it) --LM 1 18:52, 12 December 2011 (UTC)

Become the world leader for curating and working with Geo-Data by creating an open and integrated Geo-Data-Pipeline.

Today's OSM consists of many sub-projects and sub-communities. This is both its strength in its ability to address even niche applications and its current weakness in that it leads to duplicated work and weak to non-existing tooling support. My vision for the future of OSM is an integrated pipeline of OSM where projects and communities can hook up at the appropriate level for their focus. This would reduce the friction for everyone while maximising reuse of other's work. Creating more transparency and open-ness leads to improved feedback between the input and output side (what data is required? what data is available?).

This approach builds upon the already fabulous projects and pieces that exist in the OSM universe, but calls for new levels of integration, cooperation and value-add within and across those participants.

• Pipeline Inputs: Collecting and presenting these in a standardised fashion allows downstreams to pick and choose the appropriate data-sets. This information can be used both when creating new vector content by tracing as well as introspecting the data when assessing the map's quality.
  • Raster-Images
  • Governmental/Commercial/Community data sets
  • other specialized sources
• Pipeline stages:
  • Vectorization: transform rastered data into vectorised and tagged data sets. This can be supported by crowd-sourcing, automation and toolink like HOT's task manager.
  • Data-Translation and Data-Integration: integrate multiple datasets into a common data pool. With the advent of Open Government Data, highly detailed raster and vector data sets become available which can form the basis of very accurate maps. These datasets need to be integrated into the information flow of the pipeline. This work must be lifted from the current manual processes into the realm of rule-based automation. Local communities input is required for transformation maintenance, quality management and general data management.
  • Dataset Provisioning: The integrated data must be made available in a rich and coherent way. This integration also provides an important viewport into the usage of the data, leading to feedback into the earlier stages.
    • Querying: XAPI already provides a powerful way to query into the data.
    • Streaming: Taking a page out of the current stream processing research, and building upon the minutely planet updates this step houses a set of filters and processors which enable OSM to provide downstream data consumers with the specific data and updates they are interested in, while sharing the complex and data intensive part of the infrastructure.
  • Dataset Rendering: Not all data consumers are interested in vector data, thus an important part of the infrastructure remains the the creation and serving of tiles. This can build upon the filtered and pre-processed data from earlier steps, leading to a reduction in processing requirements. Reduced processing requirements and improved data-management can be re-invested into providing faceted base-layers for different use-cases (car, bicycle, public transport, openwheelmap, openseamap) which all profit from an integration and reduction of duplicated efforts in coding and maintainance.
  • End-user products: Building upon the whole pipeline and using data from all stages, the new end-user products can provide a richer and more accurate picture of the reality.

A few examples to show the power of this model:

• Routing: Building upon the Provision stage, a routing project can request a data-feed only containing the relevant set of ways. Publicising this filter serves as a focus-point for raising awareness which data is required for proper routing. This creates a feedback-loop to facilitate data-provider/data-user communication.
• Data-Cleaning: In the translation/integration step, data cleaning can be implemented without "throwing away" data. This provides a framework for implementing some of the capabilities requested above:
  • replace arbitrary source=* tags with data provenance markers allowing downstreams to correlate to input data/quality.
  • replace arbitrary is_in=* tags with data sourced from a common "administrative boundaries" data set.
  • enhance highway declarations with default per-country data sourced from the local communities.
  • mapping local conventions to global standards.
• local mash-ups: Building on openlayers and the filtered and/or rendered data-sets, easy and powerful new ways to integrate maps (tiles), POIs (data-sets) and local data can be enabled.

--David & Christine Schmitt 10:38, 13 December 2011 (UTC)