Improving OpenStreetMap

From OpenStreetMap Wiki
Jump to: navigation, search


Despite its prominence in some communities and relatively large user-base, the OpenStreetMap Rails Port has seen very little development and has a small developer base relative to similar open-source projects. This means that some designs that were thought to be temporary have lasted through the years and been accepted as 'the design', and much of the effort that is spent on the project is fixing bugs rather than making core improvements or adding features. This page attempts to be an overview of high-level issues from a technical and practical perspective, and potential actions.

Also, given the developer-heavy makeup of OSM, it is currently easier to propose and get effort behind new features than to improve core functionality. This needs to change, because the problems with OSM will not be fixed by adding more things. While it would be nice to switch to Leaflet, for instance, or add sparkcharts everywhere, the situation as it stands is that OpenStreetMap has serious problems and a small number of developer braindollars, and they should be spent carefully.

Please edit this page. If you have something that's purely discussion, post it on the accompanying Discussion page, but feel free to outline other things we should focus on, in a similar form to how this page is laid out, and your next actions at the bottom. Ideally we can make this page a collective focus for where to put our time, to improve OpenStreetMap and its surrounding architecture.

See Also

OpenStreetMap is not good looking

See Rails port/UI

The homepage is raw and functional, but looks dated in comparison to most sites of the same scale, and has not scaled well with content & functionality additions. This matters on a few levels:

  • New contributors are not inclined to trust a site that looks unmaintained or hackish
  • When OSM is compared to other sites like Google Map Maker, superficial elements can outweight the more 'properly' important issues of accessibility

Status

Front Page Design is an example of existing ideas for designs, and there's Minor UI Fixups for smaller problems. Due to the next issue (People Don't Contribute to the Rails Port), designs are very often mockups - not code

Technical Issues

  • Designers who want to contribute may be stymied by the difficulty of setting up the Rails port. See that section for details. This problem is even more pronounced on **inner pages**: to redesign a changesets page, you need a real database of OSM data, which is absurdly painful to get.
  • OpenLayers is very limited in terms of styling
  • The home page supports three 'views': RTL, LTR, and compact, for mobile devices. This increases the amount of work required for small changes.

Practical Issues

  • There's an existing effort for a larger-scale redesign, and camps are split on whether to 'redesign' or to 'improve the site'

People Don't Contribute to the Rails Port

Problems with the Rails Port are well-known, but few people contribute code.

Status

Technical Issues

  • Ruby on Rails may be too high a bar for contributors - would more people contribute if the source was in PHP? Mainly, setting up the Rails port is difficult with the number of dependencies and the environment.
    • Rails is a very well structured framework that makes it much easier for a new developer to quickly understand the application.
      • You have to know Ruby first, which looks a bit like Python and may be doable. To understand the source and the whole thing, you also have to understand the "well structured framework" in addition first. I thought not about contributing, but have done a little bit programming in C, PHP and a liitle bit Perl/Python (which are all nearly the same) in the past and only had a short interested look on the source of the rails port. And all I finally found out after around two hours was that the ruby on rails framework is some kind of high level template fremework which seems to split the web templates date from the functions of the code. So someone have to unterstand which template belongs to which code and that requires knowledge about the Rails api. This means it is very hard to leran ruby by just look on the code and understand how it all works --Fabi2 02:41, 26 February 2012 (UTC)
  • Documentation is incredibly light, and the usual open-source standards of the day - like having a LICENSE file, tracking bugs on GitHub, and such, are not adopted yet.
    • Tickets are in Trac, code is in Github. Github is new, but consolidation and guidance to resources is key.
  • There are too many mirrors of the Rails Port - even the core maintainers aren't always clear on where contributions should go.
    • The core maintainers are perfectly clear actually. The should sent as pull requests to openstreetmap/openstreetmap-website on github or by email to the rails-dev list. If you find anywhere that says anything then it is out of date and should be fixed. TomH 00:21, 26 February 2012 (UTC)
    • Fixed Rails Port and Rails port/Development, this can be considered done. Tmcw
  • Criteria for acceptance of patches are unclear.
    • Well I think it is hard to right an a-priori list of what is or is not acceptable. Any patch will be considered and if the consensus is that it improves the site and is of appropriate quality from a technical point of view then it should be accepted. TomH 00:21, 26 February 2012 (UTC)

You have to be one of us to know how this is different from Google Map Maker

This is a problem: why do people contribute to Google Map Maker, and not here? Do they properly understand the difference? The homepage fails to explain this, and it should be a top priority.

Technical Issues

  • The homepage has very little space to communicate, and this is a multi-layered issue that requires some very strong and good wording
  • The current 'get your data' pages are really poorly designed and explained, with the Planet site being slightly better: but still not explaining anything properly for truly new users.

The OSM online editing interface could be easier to use

See Next Editor

Potlatch can do everything an editor needs, but can be intimidating on first load - the Map Maker & MapZen interfaces show that it's possible to focus on tasks like POI editing or 'street editing mode' that are more easily made user-friendly. (rewritten)

  • I'd really love to see RichardF's reaction if you tried to tell him Potlatch was trying to be a web version of JOSM... It's so far from the truth as to just be completely ridiculous. TomH 00:21, 26 February 2012 (UTC)

Technical Issues

  • Potlatch is written in Flex, an environment both hated on by free-software folks, and by people who hate setting up programming environments (everyone)
  • A better editor would be written in Javascript, but the XML-heavy API will be hard to support from pure JS.
    • We're perfectly happy to accept patches to support alternate input/output formats (eg JSON) for the API. In fact there is already code for cgimap aimed at delivering this which Matt has promised to merge. TomH 00:21, 26 February 2012 (UTC)
    • Yes - Jeff Warren's fork has stronger JSON APIs and needs tests & to be brought up to date. Tmcw

Next Actions

tmcw

  1. Fix OSM home page to the point of being decent-looking. Not a huge redesign, just slight changes to make it look 'decent'
  2. Redesign log-in page, fix 'first run' experience
  3. Fix vs. Map Maker communication difference
  4. Push on making contributing to the Rails Port accessible: documentation, fixing up a dev environment
  5. Write a subset-Potlatch editor compatible with new browsers and the iPad that focuses on buildings, fixing roads, and POIs, and nothing else.
  6. Work towards deprecating the OpenStreetMap SVN repository, which is a graveyard for open-source projects.
  • This has nothing to do with the web site. As far as I'm concerned it is already deprecated, and with the exception of the JOSM plugin mob I try and disuade people from using it for anythign new. TomH 00:21, 26 February 2012 (UTC)
  • This looks to be deprecated, but there are many references from Mapnik and other pages - it looks like SVN is still the official place for the osm.xml file? Tmcw 01:51, 26 February 2012 (UTC)
  • Yes the mapnik styles are still in svn - a major complication there is that main author of the style is not a programmer and uses Windows so getting him used to a different VCS is tricky (doubly for git which has issues with Windows). TomH 12:46, 26 February 2012 (UTC)
    • Perhaps you've not tried Git in Windows recently (or ever). Git Extensions and TortoiseGit make using Git a breeze. Years ago there were significant problems with Git on Windows, but I haven't had any (I have to work on both Windows and Linux using Git). -- Joshdoe 15:15, 27 February 2012 (UTC)
  • SVN is still the main place for many important parts of OSM (e.g. osm2pgsql, Mapnik styles, Tirex, mod_tile/renderd, huge amounts of utilities that are actively developed). Everyone is free to use the VCS they prefer for their work. --Frederik Ramm 14:31, 26 February 2012 (UTC)
  1. Document developing changes to the Rails Port's styles - including how to test RTL styles.

Andrew Turner

  1. Rails db:seed for creating a test set of data in a developer environment
  2. Documentation on Rails architecture
  3. Consolidated user profile page

Travis Pinney created a simple vagrant installer for OSM rails development. The rails port was not that difficult to setup once dependencies are met.