Can't create geo_shape multi field

[owainb]

I tried to create a mapping with a multi field where the default type was geo_shape. The mapping created successfully but the field was not created as a multi field. I raised this on the mailing list and it was suggested to raise it as a bug https://groups.google.com/forum/#!topic/elasticsearch/iSeKove6vOQ.

For an example see the gist at https://gist.github.com/owainb/392a5c03b89f2024fb61#file-geo_shape_multi-txt.

Elasticsearch: 1.3.0
OS: Linux 32-bit
JRE: 1.7.0_65

[clintongormley]

What are you planning on indexing into that field? I'm not sure that any other field type (including geo_point) can make sense of geojson.

[dadoonet]

@clintongormley Not sure but I think that you can use that in a plugin and do special transformation there.

At least, if it's not doable we should reject that mapping.

[owainb]

I think I misunderstood the capability of mulit-fields. I thought I could store different values in the sub-fields (e.g have a GeoJSON representation in the main field and geo_point representation in the sub-field), but now I think it has to be the same value, and you can just analyse it in different ways?

I do think the mapping should be rejected if it's not valid however.

[clintongormley]

@owainb what you need is just an "object", eg you could index:

 {
     "location": {
        "shape": { .....},
        "point": { "lat": 0, "lon": 0}
 }

But I agree, the invalid mapping should throw an error.

[owainb]

Yeah, that looks like what I want to do. Thanks @clintongormley.

[colings86]

@clintongormley the issue with not throwing an error is wider than this specific case. None of the field mappers throw an error if they encounter a field that they don't recognise. I think this is because the scope of the settings for a field is wider than the mapper for it's type.

In the same object in the mappings (as in these are not split into sub-objects) we have the type declaration, the settings common to all fields (such as store, etc) and the type specific settings. So the field mapper for a particular type does not know at the moment whether a setting it doesn't recognise is an invalid setting or if it is a valid setting that something else will deal with.

I think we should probably open a separate more generalised issue for this and close this issue. what do you think?

[colings86]

Closing in favour of #7205