The current drawfeatures behaviour always generate a GEOMETRYCOLLECTION type of WKT, and can only be configured
to specify which tools to make available for drawing (point, path, polygon).

There should be a way to also tell if the user should be only allowed to write a _single_ point/path/polygon, or, more
generically, it could take a single value for the feature type from the set:

geometrycollection (current behaviour)
point
multipoint
linestring
multilinestring
polygon
multipolygon

And eventually another value to limit the set of tools available, in the (unlikely?) case you want to a collection
containing POINTs and LINESTRINGs but no POLYGONs, or similar.

Allowing such configuration would make it possible to have an improved widget for the GEO field.
See http://drupal.org/node/804878

Comments

tmcw’s picture

tmcw commented

First off this description needs to be clearer, it's hard to grep from here.

Are the goals that:

  1. When users can only create a single element, that element should not be wrapped in a collection? (not sure of the benefit here, but okay)
  2. How is it that we'll eventually have a value to limit the tools available when we already have one?

    3. I won't mark this as by design, but it essentially is - the code belongs in the OpenLayers JS library, and then it will be supported in this library. If you can take the reins on this task and get it done, then absolutely it'd be an accepted patch, but for the time being, the implementation of EditingToolbar and DrawFeatures on the OpenLayers side is, rightfully I would say, non-strict about the underlying data and, unfortunately, not very flexible.

strk’s picture

strk commented

"When users can only create a single element, that element should not be wrapped in a collection? (not sure of the benefit here, but okay)"

For single-element the interface should behave differently.
For example, for single-point, every click should move the point rather than add a new one.
For linestring and polygons that'd likely be harder to do.

You may be right it needs to be implemented in OpenLayers core first.
Surely not the POINT behaviour though as I saw it working with DOL-1.x and GEO-1.x-alpha5

The tool limiting idea was in case we do allow to define strict type, in which case there's no strict
type expressing "points and lines but no polygons". There _is_ that expressivity in current code, but
not the "limit to single value" one.

tmcw’s picture

tmcw commented

Oh, you mean limiting CCK features - there's a ticket for that #721924: CCK does not limit features. I assumed that you were talking more about datatypes, in which you'd prefer to have point instead of array(point) when there's a single point allowed.

strk’s picture

strk commented

I'm not sure it is the same thing.
Theoretically it's two different things:

1) Allow multiple values (could be multiple collections or multiple multipoints) - requires separate table
2) Allow different types for a single value (point,multipoint,line,multiline,poly,multipoly,collection) - a single db field is enough

strk’s picture

strk commented

See, my current problem is with the GEO field module.
That module doesn't properly support GEOMETRYCOLLECTION types, nor MULTIPOINT/MULTILINE/MULTIPOLYGON.
So, I'm kind of stuck with simple types.

I'm looking at the patch provided by Brandonian (OpenLayers V2 Support) and trying to improve it.
As long as I type the POINT(x y) WKT manually, the widget is able to read it (with my feature array patch) but
everytime you edit, you get a GEOMETRYCOLLECTION.

The original patch by Brandonian naively removed the GEOMETRYCOLLECTION() wrapper, but didn't limit
the number of points you could draw, which resulted in bogus WKT, like:

POINT(0 0),POINT(1 1)

Instead, what I'd like to do is instruct the drawfeatures behavior that only a POINT geometry (not a GEOMETRYCOLLECTION)
is allowed, and expect the drawing UI to take the corresponding action. For extension, I might want to ask for a LINESTRING
instead, or for a MULTILINESTRING.

I'll see if I can come up with a patch for this.

zzolo’s picture

zzolo commented

I am not sure if the problem is really this module.

As this module stands, it is storing WKT data as a GEOMETRYCOLLECTION and sticking with that. Overall, we don't even want to be storing data with this module, so, to make this anymore complicated would really be out of the scope of this module (as we already are).

With Geo integration, it is up to the Geo OL widget to handle how it wants to do all this. It is very possible that implementing a Geo OL widget should not use our drawfeatures behavior, but may want to look back at 1.x to see how it was put together there.

strk’s picture

strk commented

"Overall, we don't even want to be storing data with this module"

Right, we should just focus on the user interface, and that's what I'm talking about when asking to allow
more closely specification of what can be drawn and what not.

The GEOS OL widget, as far as I can tell, still uses the OL drawfeature behavior, so it's good if it can configure it.

zzolo’s picture

zzolo commented
Status: Active » Closed (works as designed)

It seems what you are talking about is how data is stored, not what the interface provides and I think that is not something we should get into. Yes, GEOMETRYCOLLECTION is limited, but this module should not go any farther than it has. I think this shoudl be more address in a another field, like Geo and OL widget.

Specifically on the user interface, I don't think we should have the ability to manually input WKT value. See #801108: Address Manual WKT CCK Input

strk’s picture

strk commented

"It seems what you are talking about is how data is stored, not what the interface provides"

Actually, I was really talking about what the interface provides.
It's an interface responsibility to eventually limit the editing capabilities.
For example, every new click would move the point rather than create a second one
if POINT editing is requested.

This seems pretty consistent with the current possibility to limit by feature type (ie: allow
adding paths but not points and polygons...).

I do understand that changing the output WKT type to something different from GEOMETRYCOLLECTION
would be somewhat harder at the moment, but that'd be also desired from this side :)

zzolo’s picture

zzolo commented

Well, all interface features should be in CCK except #721924: CCK does not limit features

Currently, the module does not respect the number of features to add. If this is what you are talking about, then this would be a duplicate.

strk’s picture

strk commented

Alright, let's close this then.
I still think it'd be nice to have a stricter type editing but I understand it would need to be implemented in the core OpenLayers library first. Limiting the number of values would be good enough for me.