Currently, this option is ignored.

In addition to annotating maps using shapes, add the ability to annotate maps with text.

There are some instances where NeatlineFeatures saves WKT using weird projections, converts lat/long values to very small values, close to zero. Seems to be trying to convert annotations to another projection.

Points are confusing because each maintains its size, no matter what the zoom level.

Since Features can have multiple map widgets (unlike Neatline), the Delete, Drag, Scale, and Rotate buttons need to have unique IDs.

Currently the WTK string is displayed in the coverage element; change this to be a map of the current coverage extant.

This borks symlinks.

On a new form, the coverage field should look like the default Omeka form with a checkbox that says, "Use Map".

When "Use Map" is selected, the map would appear below the current box. It would have the OpenLayers map with editing controls and a way to view the raw codes.

The actual Omeka coverage field would be the raw codes field, which would be automatically updated from changes made on the text field and the map field.

The raw coverage field would then contain:

• a NL Features [magic number](http://en.wikipedia.org/wiki/Magic_number_(programming%29);
• the map's viewport;
• feature data as WKT;
• text data.

We're throwing a lot of stuff in the coverage field. It seems like having a separate table for it might make more sense.

Users should be able to remove any changes they've made since the page was loaded. Add a "reset" button to the feature map to implement this.

If the map is positioned too far west, say around longitude/X coordinate -12459847 (Salt Lake City), the position will overflow to -9999999.99999 (near Peoria). The values are stored properly for the features.

This may not be fixable.

Also, cursor should be a pointer on hover.

Each coverage field would get its own layer in OpenLayers.

Currently, NeatlineFeatures only recognizes WKT using EPSG:3857 (the official designation for EPSG:900913) being directly entered into the raw text box. In the future, we should support at least KML and maybe GML.

This brings up the issue of what projection this uses, so we'll need to figure out some way to prompt the user for the projection.

Currently, there's a visible field for free-text, the map, and a hidden field that contains the free text plus several other fields (WKT, zoom setting, and center). As we add more fields (e.g., base layer for #29), this is going to get harder and harder to maintain.

Instead, there should be an array of hidden fields, one for each field, and they should be stored in the neatline_features table, which currently only stores the is_map setting.

Use GML instead of WKT for serializing coverage

Allow the user to set and save the viewport of the coverage field.

From zerocrates on #omeka:

changing the base layer seems to mess things up in some way I can't totally accurately describe

sometimes it kills the red on my selected feature, sometimes i can't then select anything else after i change the layer, sometimes i can't unselect what i already had selected

things seem to work fine if i've never selected anything from the time i load the page to the time i change the layer

but if i've selected something, then unselected it, then change the layer, it gets auto-reselected and can't be unselected

or something like that

Create an itemShow method for displaying items with just NeatlineMaps and NeatlineFeatures.

Fix issue with changing projections with zoom levels

Merge in davidmcclure's changes to https://github.com/scholarslab/Neatline/blob/master/views/shared/javascripts/neatline_map.js

Allow the user to set the color of features when they're entered or being edited.

David's already added these (and other features that this issue also covers), so part of this will be copying his implementation over. I'll also need to change the internal data format to GML, and use a namespace to encode the view and this information.

In the public item show view, the map control defaults to a box selection tool that lets you drag out an area on the map. When I hit the page, thought, I wanted to be able to pan the map, not select features.

It could be useful to add a simple control that would let you toggle back and forth. I suspect, though, that in most cases people will want / expect to be able to pan, since that's the default pattern in Google Maps, etc.

Right now, configuration is handled by this process:

• If window.Neatline exists, it's used;
• Otherwise, the default option handling for widgets is used (passed into initializer and then defaults).

The global options need to be used integrated into the standard configuration processing, so that precedence becomes:

1. Defaults defined in the widget definition;
2. window.Neatline; and finally,
3. options passed into the initializer.

This should really be a method on the simpletab widget.

Replace the RSS button with add image

Look at jquery issue with adding multiple coverages

There's an option for the toolbar class (options.markup.toolbar_class); however, it's also hardcoded at https://github.com/scholarslab/NeatlineFeatures/blob/develop/views/shared/javascripts/nlfeatures.js#L463

When editing features, sometimes you have to click off of the currently selected feature before you can select another one. This is unintuitive and needs to be fixed.

Click/mousedown should be bound onto the whole tab area, not just the label text. At first, I was clicking on the tab (but not on the text), and thought it was broken.

NeatlineFeatures currently only has an edit widget for editing coverage for an item, but no show widget to display that coverage in a map as well.

Having a show widget would allow us to filter the coverage field on the items/show view, to display a map of the coverage instead of the WKT values.

Right now, the viewport is determined by the features on the map. So if there's only one point, the extent is too close to see where you are or anything on the map.

This could be handled by having a minimum zoom level for the initial extent.

This could also be fixed by implementing #20.

This will just use the local File API, where it's available, and use the file's contents to populate the raw text area. So it will support whatever data formats entering data into the raw textarea will support (see #13).

What about clobbering existing data?

Also, like entering text directly into the raw textarea, we'll need to prompt for the projection.

http://maps.stamen.com/#watercolor/12/37.7706/-122.3782

Add button to add a simple text annotation on the feature item

In FF/Chrome/Safari, clicking on any of the Delete/Drag/Scale/Rotate buttons has the result of submitting the master item edit/create form, which then bounces the user out to the admin/items/show route for the item.

For the push-pin icon, include licensing information in

• README
• LICENSE
• a license file in the images directory containing the image.

http://www.wpzoom.com/wpzoom/new-freebie-wpzoom-developer-icon-set-154-free-icons/

This one's intermittent and can be hard to reproduce. Keep trying.

Just using show and hide is a little too abrupt.

Look at what David did on Neatline.

This is to prevent clashes between the versions used with scholarslab/Neatline. Some files may also need to be renamed.