Draw feature doesn't respect behavior settings

yeah sorry about that it's my fault, my patch wasn't complete obviously. I'll roll one tonight.

Ok here is a patch.

It remove some depreciated options in the behavior's settings, add an 'allow edit' option, and respect the behavior settings.
Should work fine, if more config options are needed just ask.

new patch that avoid a js crash when there is no input field (if the map is used for display, not input field).
See #1344030: GMap not working.

Hi nod_! Thanks for the patch!

I just applied it to the latest dev version and it seems to work fine for honoring the behaviors settings for drawing features now. But I still can draw multiple features even though I've selected only one in the fields settings of the widget. And I can't find a way to modify/delete features. Clicking on the maps keeps adding new features.

yeah that's still not fixed. The thing is, if you set your field to unlimited, you'll have a different map where you can draw as many features as you want. So we'd better get brandonian here to make him choose how this stuff should work.

It's not hard to do, just need to know if that's what he wants.

Yeah, I didn't realize (or had conveniently forgotten) that when we set Geofield to multiple values, we get multiple maps, which isn't the best UX for this sort of thing. And even though WKT supports geometry and feature collections, I imagine that for most people, limiting an input widget to x number of fields means that you only have x number of simple features (points, lines, and polygons).

nod_, it's my understanding with hacking around with field code that converting a widget to handle multiple values in a custom manner is a non-trivial fix, and I'd really like to get a stable 1.0 out before the end of the year. If you feel that you can do a patch to handle it without breaking lots of stuff, then I'll accept it. Otherwise, I think we should leave the multiple behavior as is and tackle that in 2.0.

I haven't had a chance to look at the patch at #4, but plan to review shortly.

A quick fix is allowing 1 feature for each map, because with all features on the same map for multiple values we kind of loose control over ordering.
A different map for different value may not be the best UI we can have but it makes it very clear what's what.

@Brandonian Most people are already used to using one map for multiple features on a map. OpenLayers CCK and Geocoder input fields for D6 respect that settings and allow one to draw only the number of features specified in the widget settings. For example if there the allowed features is 1 – the second time a user clicks on the map the first fearue is deleted and the new one added. It works the same for multiple fields while preserving the order the features were added.

@node_ Different map for each feature does not seem right – why do we have to store multiple fields with a single WKG geometry when a single field is capable of storing all of them?

Ok we need to be clear or we'll end up not understanding each other. I'll explain my understanding of the issue.

I don't see a widget setting limiting the number of features available, what I see in OL CCK is a limit in the behavior settings of the map configuration. This stuff will go away in D7 (i'm working on it) it's not the place to set a limit.

So we're left with this:

A field setting which is the Maximum number of values users can enter for this field. meaning : 1 value <=> 1 row in the field table. Take a closer look at how the values are saved in the DB, it'll help seeing what i'm talking about next.

An example

you have features to save:

• A linestring representing your trip in india
• A point on the new york airport where you left for india
• Another point in Vienna where the plane made a stop

With all features on the same map (your solution)

All of this is in a GEOMETRYCOLLECTION in 1 row of your field table and the bounding box for it is pretty much a quarter of the world.

With 1 field value <=> 1 map feature (mine, not really but for clarity's sake)

You have 3 rows in your table: LINESTRING, POINT, POINT and the bounding box for each is what you'd expect. And you can reorder: NY first then Vienna and finally India (or the other way around).

Brandonian's whish for 2.x

1 field value <=> 1 map feature (same as "mine"), with only one map. Here the ordering is something to think about. The UI will need some tweaking to know what goes where.

Now using the field values

if you're looking for which field value has geo-stuff in Italy for example, you'll make a quick and dirty condition on the bounding box of your field values, GEOMETRYCOLLECTION will match even if there is nothing in Europe.

In the end

We need one more option in the widget configuration this time : 'Allow complex geometry' which will enable people to draw as many features as they want for one field, it'll all go in a GEOMETRYCOLLECTION; or possibly a JS-only solution for cases like :

• delta 0 : simple geomerty,
• delta 1: simple geometry,
• delta 2 : complex geometry.

And i believe we covered all our use-cases. Do we agree on this or not ?

Hi. OL CCK field for D6 uses the field settings "Number of values" for the number of features that can be drawn on a single map. I'd be happy to create a short video to demonstrate that if it's needed.

You can place multiple features on a single map and limit the number of features from the settings of the field. And if somebody needs to create 3 or more types of features with the ability to sort them then create separate CCK fields for that reason. But that works only if the number of those fields is know, which is not the case with your example.

I agree with you that it's too comlpex to be just 1 field value <=> 1 map feature.

It seems like that the "Number of values" for the field itself is not the place to configure the number of features (like OL CCK does in D6). The geofield widget should allow configuration of both number of instances for the widget and number of features for a single map.

If one needs to create 3 maps in specific order like your example – that would be possible.
If one needs to mark 3 locations on a single map – it would also be possible.

I guess that functionality is too complex for the 1.x timeframe and a 1 field value <=> 1 map feature would be fast and good enough for a start.

here is the patch limiting a map to 1 feature. We're left with the second behavior described in #10
patch on top of #4 :)

Thanks for the patches, nod_. Everything looks good, patch is committed.

Umm, we might need to add a warning somewhere. as-is the patch will remove all but one features on the map, meaning that people with multiple features on one map will lose their data upon edit. We could add the behavior after drawing the features and they will be removed if you try to add another feature on the map (might be possible to show an confirm of some sort before that).

I don't think we can keep it that way, there is some serious data-loss waiting to happen. We might even need to provide an upgrade path to transform a geometrycollection to a bunch of simple geometry values.

Good call. I think better verbage in the help text below the map would suffice for the documentation, and I definitely agree with the upgrade path.

The original intent of this issue is solved. Continued discussion for the upgrade path is happening over at #1408442: Upgrade path from geometrycollection to simple geometry shape.