Type of Geometry

bump.
I seem to remember this feature being available for D7, but maybe i'm thinking of a different module?

The D8 Geofield module already supports geoPHP geometries (unique in the D8 panorama), also in a mixed way. You just need to manage its input with the Raw Geofield widget (via WKT format/syntax) or some existing widget able to handle them. At the moment the only one for D8 seems to be the Leaflet Widget module that works pretty well ...
Both the Leaflet module and the Geofield Map module are able to handle basic Geometries path styling via their formatterà and Geofield view displays styling ...

@AndyLicht thanks for you clarification, but I think that you are not still completely right.
WKT syntax let you input both only a geometry type (point, line string, polygon ... etc.) or a mix of them (as geometries collections),
in every field (single or multiple) instances ...
You could do it with the above mentioned widgets (Geofield Raw widget and Leaflet Widget module ones).
Their exact type will be stored in the corresponding field_[geofield_name] field of the D8 database (check it out).

Of course at the moment specific Widgets and Field Formatters (& View Style Plugins) are very limited with these potential functionalities,
as still the Drupal 8 Geofield Stack is far to be a complete Web Gis 2.0 tool ...

All this is Ppensource contribution, and would take time and effort to develop all this you may be minding about.
But, for the same reason, everybody is free and really welcome to start and try to contribute on this with its own time, skills and capabilities ... ;-)

@AndyLicht your english is ok for me ... (I am not english too, but italian).

I can understand what you mean, ... and your frustration on the actual Geofield limitations.
I like to work on GIS and Web GIS (advanced) applications too.
And I am already minding a possibile extension of the actual Geofield schema to add a new geofield field table column/attribute able to store and manage just additional and general "options" in a serialized way (key: value, in json syntax?) so to let contrib modules and plugins to associate to each geometry specific attributes (such as paths stroke & fill color, opacity ... etc) and thus be functional able to set them in the widget and render them in formatter/geofield view display style, accordingly ...

This would be an amazing and super useful achievement (game changer) for the Geofield module in D8 (and a major upgrade release for sure) ...

But still this need some (free) time, quietness and effort to plan and implement it in the best and most scalable way.

Will see ...

@AndyLicht ... we are in the opensource world here, and you are really welcome to contribute, with your approach and vision.
I would look and review it, for sure ... at least to better understand real user needs.
Just try (I would say be sure) to use the Drupal 8 and PHP coding standards writing your patch or contributions (whatever they are),
because at the end all the Geofield code should be compliant with that ...

Thanks @AndyLicht for the quick patch.
I quickly review it.
Well ... not perfectly complying with the Drupal 8 and PHP coding standards but not that bad (few corrections might make it "green").

The matter (IMO) is that it seems quite limited in its approach (and correct if I am wrong).
Bear in mind that the D8 Geofield module is fully relying on (wrapping) the GeoPHP library
so that I think that the 'geometrytype' select should be more general, then better defined so to embrace all the possible geophp geometries definitions and their possible combinations.

Instead of a select I would use the a checboxes element,
to make it possible to choose (and allow) more than 1 geometry type for each Geofield definition ...

The constraints validator should then adapt accordingly and able to face also the following use cases:
- if MultiPoint is selected (allowed) then also a single Point geometry should be allowed / pass the validation (and not the opposite);
- if MultiLineString is selected (allowed) then also a single Linestring geometry should be allowed / pass the validation (and not the opposite);
- if MultiPolygon is selected (allowed) then also a single Polygon geometry should be allowed / pass the validation (and not the opposite);

- the GeometryCollection might be omitted as a checkbox option, as it might match the 'none' => $this->t('all allowed') option ... (that would/should override all the other checkboxes);

So indeed (IMO) if we really need to implement this feature (and add geometry type constraints in the Geofield inserting) we really need to better, and very carefully, tune the settings themselves and all their possible use cases constraints & validations ...

Sincerely I am not soo persuaded that this patch should be committed in the module itself,
unless many other contributor step and subscribe for this same feature, and it is proved that the Drupal 7 version of the module has it.

Thanks for your effort @AndyLicht BUT IMO the Geofield module main goal is mainly to enable and bring into Drupal the capability of handling Geo data, via the GeoPHP library ...
It is already used JUST for that by tens thousands of Drupal implementation world wide.

This issue implementation (and patch) would be structural, and introduce "constraints" and limitations (although optional) to its functionality in its core structure that might better (and should?) handled in a custom module.

A couple of simple form alters would make the trick ... isn't it?

Anyway ... let's see your final outcome, and then I will decide.
Please make it solid, and make it simple, without any possible regression on the core functionalities (... besides strictly standards compliant).

PS: The GeometryCollection shouldn't be a constrain/option ... and simply allowed in the Default scenario (no constraints set).

Besides all else, the patch is also not following Drupal patches naming conventions ...

No @AndyLicht ... the right patch naming conventions are found in each module Version Control page instructions, so for Geofield they are here: https://www.drupal.org/project/geofield/git-instructions
@look the "Patching" section ...
So your patch is still mismatching the proper Drupal patch naming convention.

Besides that, in its #21 version it is overwriting the changes committed into dev, with this last comment/commit: https://www.drupal.org/project/geofield/issues/3057111#comment-13121207

We should be VERY careful when posting patches, because we risk to reintroduce regressions and are asking for maintainers reviewing time.

Sincerely I am still not persuaded this feature should go into the module, but I would still be happy to further review your last attempts,
if, and only IF, you will be able to provide a proper patch (complying with naming conventions and not overwriting last dev commits).

Thanks @AndyLicht ... for you amends. It is always a learning by doing.
I will test and review ASAP ...

@AndyLicht I made a brief but accurate and meaningful review of your last patch.

Here are my observations, and warnings, from the weakest to the worst and most critical one:

- weak warning: the name of the patch is still not the best and most conventional. Usually it has to be prefixed with the module name (geofield-add-GeometryType-storaging-2770313-23.patch);
-strong warnings: the patch content doesn't comply with Php and Drupal Coding standards:
some properties or variables names don't conform (geometrytype, $givenGeomType, $hasToBeGeom ...),
a class method (geomList()) documented with {@inheritdoc} but not listed in the interface (GeoPHPInterface)
etc ...
-strong warnings: I still don't think that a single geometry type instance (i.e: point, line) should validate differently from the multi correspondent one (i.e.: multi point, multiline string). This validation logic should be really made smarter and less rigid ... (eventually);
- critical/major warning: once applied the #23 patch (wherever, and in particular to my demo Geofield stack application: http://www.geodemocracy.com/geofield_d8/web/), saving the Geofield storage settings and even without changing them from "geometrycollection" every time I try to save an entity containing that Geofield the application breaks with the following error message:

The website encountered an unexpected error. Please try again later.Symfony\Component\Validator\Exception\InvalidOptionsException: The options "geometrytype" do not exist in constraint "Drupal\geofield\Plugin\Validation\Constraint\GeoConstraint". in Symfony\Component\Validator\Constraint->__construct() (line 151 of

This error is totally un-acceptable
and I didn't find the time (and the will) to better investigate its cause..

As a conclusion of all my last time spent on this, I say that this patch applies (on the current dev branch) but seems indeed not even close to be committable into the module code base.

BUT I am quite tired to review and still follow up this, because besides all the above I am still not persuaded at all this functionality should be added to the Geofield module, in this structural way ...

May be this might be embedded and added in a custom module or submodule, don't know, and may be its logic should be better applied in a custom widget instead of the Geofield storage level. Not sure of anything and still quite far to be convinced about this feature.

Thanks for your attempts and your contributions on this, but I won't adopt and commit a working patch on this as long as many other Geofield users won't step in subscribing for this issue same feature request ...

My regards

@AndyLicht ... Geofield IS NOT MY MODULE,
but a super widely used community module on Geo mapping.

I just took it over its D8 version last year,
and that's why I feel so(ooo) responsible about it.
I should carefully check and filter every user contribution in terms of solidity, opportunity, coding quality & standards, functionality, etc.

You said this was your first patch, and I appreciated your effort, but I should consider that ... too.
And you are just one voice among thousands of Geofield users.

Let's see if (and how many) will step in here and subscribe for this same feature request, and will push for you patch to be committed,
as it is, or somehow further optimized.
My only voice is not definitive in any sense, too.

In the meanwhile, sure ... you could extend the Geofield module by a custom module of you, with the functionalities you need,
so that you might be set.
Also you might pack a sort of Geofield submodule, yes why not ... but then you should care about its compatibility with the evolving parent.

I repeat: if other Drupal users will subscribe this functionality ... then it might be taken into account for its adoption into Geofield.
Let's see ...

Thanks @AndyLicht ... I appreciate your agreement.

+1
would be useful to have some sort of geometry validity check

+1