Here is a summary of #1343610: Draw feature doesn't respect behavior settings about the way data is saved and where do we go from there.

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 (old way)

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

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, with only one map. Here the ordering is something to think about. The UI will need some tweaking to know what goes where.

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.

So we need to decide if an upgrade path is possible, how and document it.

CommentFileSizeAuthor
#3 1408442-collectionoptions.patch2.98 KBBrandonian

Comments

nod_’s picture

nod_
Primary language French
Location Lille
commented
Issue summary: View changes

remove noise

phayes’s picture

phayes commented

I would even support making this a configuration on the widget settings.

Brandonian’s picture

Brandonian commented

Thanks for making a separate issue for this, @nod_. This is one of things that I wanted to take a crack at during my planeflight tomorrow. (Yah travel time!).

The way I originally saw the issue, we were shooting for just having an upgrade path to the 1 map <=> 1 map feature that was committed earlier. Reading this and @phayes' comments, though, it might not be too difficult to do an either/or solution. I'd still like to get the simple geometries in one map solution at some point, but it's going to take some serious consideration on the UX level.

Brandonian’s picture

Brandonian commented
Status: Active » Needs review
StatusFileSize
new 1408442-collectionoptions.patch2.98 KB

Attached is my first stab at fixing the issue. In this version, I've set up a widget-level setting (data_storage) which determines whether or not maps can hold complex data types or not. Because having the complex data type is default in my implementation, there isn't an upgrade path, but there is a note on the widget discussing potential data loss.

I don't think this patch is ideal, but it's something to rally around/discuss. I'm concerned that we're sidestepping making an important UX decision by offering multiple ways for widgets to behave. While I'm all about giving site admins options, I also don't want to make config overly complex with decisions that we could just as easily make ourselves that work for the vast majority of cases.

That being said, I'm also anxious to get a release out so that we can do some serious coding/refactoring in, so I'm cool with this being a stopgap for 1.0 if we can't come up with anything better.

Brandonian’s picture

Brandonian commented

Oh, and I think I found a typo in the js as well. Forgot to take that out before patching...

Brandonian’s picture

Brandonian commented
Status: Needs review » Fixed

Talked to @nod_ on IRC, he informally RTBC'ed the patch. Applied and committed.

http://drupalcode.org/project/geofield.git/commit/86fdea9

nod_’s picture

nod_
Primary language French
Location Lille
commented

sweet, working fine indeed :)

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Anonymous’s picture

(not verified) commented
Issue summary: View changes

better naming