• create an alternames column
• Make a list of cities with erroneous name and:
  • put the original name in the alternates column
  • change the name of the city
  • change the name of the country (if needed)
  • generate new url_name

•  Search should ignore accents
•  Improve contributors query

I. e., if the line is a BRT, a Metro, a light rail/tram, etc...

• This should be in the Line model
• It should matc line-widths

It should trigger the change event every time a number is pressed (not only after an ENTER key)

For example:

• section_backups
• station_backups

These tables show store a copy of the features that are going to be modified or deleted

@LucasLechat_twitter (Gitter) said: "Shouldn't station creation be counted on contributor's profile, and ranking. Not that I'm cursing for point or anything, but to see how much we contributed, not only by lines creations."

Two possibilities:

• Replace cache helpers with updated_at propagation.
  Today there are certain helpers that calculate the last updated_at depending on the situation.
  We have to change it so any time a feature, a system or a line is updated, the city's updated_at column gets updated. This way we are going to save a lot time removing real-time calcs.

• Drop memcached and use cloudfront.
  My doubts are: Is invalidation time short-enough? How much money-expensive would be?

• There should be a default system, with no name. This system has to be shown in the right panel of the general view as the current "Lines" list.
• Each system has a NewLineItem component, with a system_id prop set to the system id.
• Lines should be draggable from one system to another

Check if buildstart_year or opening_year is < start_year, and if it is, update it

This should include:

• Top contributors this month
• Top contributors ever

Perhaps the query should be something like this:

CreatedFeature.left_join(:sections,
                         :created_features__feature_id => :sections__id,
                         :created_features__feature_class => 'Section')
              .select_group(:user_id).select_append{sum(:length).as(sum)}
              .order(Sequel.desc(:sum)).all.reject{|e| !e[:sum]}

• The color and and all line-specific data should be store in the Line model
• The general style things should be hardcoded (for now)
• See if style js class has to be removed

Related to #34

At least, there should be an option to import features from OSM.

• add two new fields osm_id and osm_tags
• we could use the overpas api wrapper
• the area should match a the viewport or a circle with a certain radius from the city coords
• osm tags should be a with select list or input
• the osm data should be loaded in the editor mode, and not saved (it would require further editing from the user)
• lines
  • a button and a tag option should load the relations names as lines in a new system. Except if a line with the osm_id overlaps (that line won't be created again)
• features
  • a button and a tag option should load the nodes or routes as sections or stations, elements with osm_id that collide won't be added
  • if the line with the corresponding name (matching the relations name) should be automatically set

Steps

•  Push script
• Change name Santiago de Chile to Santiago
• Run migrations
•  Add country for Buenos Aires and Santiago
•  Run script

•  USA cities (see http://www.infoplease.com/ipa/A0001796.html)

•  cities list
•  sources

When editing a line, when we click on the color bor, a color edition panel pops up. I can click on the color gradient, or on the preset colors at the bottom. But if I try to change the hexa code or the RGB, the panel closes.

See this: http://stackoverflow.com/a/6511606

This happens when there are many features modified

What type of data "citylines" need to show info, for example from Costa Rica?

I have a GTFS file with data from Costa Rican Urban Train, is it useful?

Once a feature is removed (but changes not saved), no features can be selected ( a bug is triggered)

Where we can see:

• The first name of the user
• What cities he contributed to
• The total length (km) of features created/removed
• The total number of stations created/removed

• combination should be a relationship between 2 stations (table with station a and station b)
• it should be drawn whenever both stations are operative (unless we add a operative_from and operative_to fields, I'm not sure about that)
• If a combination involves more than 2 stations, it has to be drawn by pairs
• They can be added from a list that displays close stations