# Convert string field to geo\_point field for map visualisation **URL:** \ **Category:** Elasticsearch\ **Created:** [February 1, 2023, 8:37am UTC](https://discuss.elastic.co/t/convert-string-field-to-geo-point-field-for-map-visualisation/324397 "2023-02-01T08:37:03Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![cf4455](https://avatars.discourse-cdn.com/v4/letter/c/e68b1a/32.png) [@cf4455](https://discuss.elastic.co/u/cf4455)\ **Post date:** [February 1, 2023, 8:37am UTC](https://discuss.elastic.co/t/convert-string-field-to-geo-point-field-for-map-visualisation/324397/1 "2023-02-01T08:37:03Z")
Hello, We collect in our logs, among other things, geo-coordinates and their accuracy in 2 "string" fields. Currently there are over 3,200,000 logs since the beginning of 2021. Now we want to display these coordinates on a map. However, the "geo\_point" type is required instead of the "string" type. So all of our logs have the wrong data type in our "geolocation" field. The other fields in the logs work without problems for other evaluations. How can we achieve that we can show the data of the existing and new logs in the map? I've already read about the mapping API and scripts, but unfortunately I don't know how to use it. Does anyone know of a tutorial or an example of how the data can be mapped or converted? However, the logs and the index must not be deleted. Can the mapping of the logs be corrected easily during operation? With this query, the "geolocation" field would be set to "geo\_point" wouldn't it? All other fields would remain as they are and are therefore not included here. ```auto PUT / logs { "mapping": { "logs": { "properties": { "geolocation": { "type": "geo_point" } } } } } ``` Or could a new field "geolocationNew" be created with the type "geo\_point"? For this I would rebuild the query from above and use "geolocationNew" instead of "geolocation". Then perhaps all new logs could be written to the "geolocationNew" field. How could the old logs with the wrong fields be written to the new field? Thank you once again ---
**Author:** ![jsanz](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jsanz/32/53734_2.png) [@jsanz](https://discuss.elastic.co/u/jsanz)\ **Post date:** [February 1, 2023, 11:46am UTC](https://discuss.elastic.co/t/convert-string-field-to-geo-point-field-for-map-visualisation/324397/2 "2023-02-01T11:46:00Z")
Elasticsearch encourages to **not modify** your existing indices. Yet, if you are OK on modifying your current index, you can update your mapping and run an [update by query](https://www.elastic.co/guide/en/elasticsearch/reference/current/docs-update-by-query.html), as the documentation states (bold is mine): > If no query is specified, performs an update on every document in the data stream or index without modifying the source, which is **useful for picking up mapping changes**. Of course, be sure you have backups of your data. If you prefer not to touch your existing data and better move to new indices, I guess the workflow would be as follows: - [Optional] Consider adopting [Data Streams](https://www.elastic.co/guide/en/elasticsearch/reference/current/data-streams.html) for easier management - Create an [index template](https://www.elastic.co/guide/en/elasticsearch/reference/current/index-templates.html) with the correct mapping and settings that matches against an index pattern name say `new-logs-*` - Point your ingestion process to the new index, defined by your template (example: `new-logs-YYYY-MM-DD` if you want to create one index per day) - [Reindex](https://www.elastic.co/guide/en/elasticsearch/reference/current/docs-reindex.html) your old data into a new index (`new-logs-old` for example). If the field names are the same and types are compatible you only need to define origin and destination names. That is, if your `geolocation` strings are compatible with `geo_point`. - If you need to adjust types or make any other changes you should create an [ingest pipeline](https://www.elastic.co/guide/en/elasticsearch/reference/master/ingest.html) to transform your data on re-index. I'll move this question to the Elasticsearch forum since this is not really a Kibana question. ---
**Author:** ![cf4455](https://avatars.discourse-cdn.com/v4/letter/c/e68b1a/32.png) [@cf4455](https://discuss.elastic.co/u/cf4455)\ **Post date:** [February 6, 2023, 1:39pm UTC](https://discuss.elastic.co/t/convert-string-field-to-geo-point-field-for-map-visualisation/324397/3 "2023-02-06T13:39:16Z")
Thanks for your quick answer, but isn't there an easy (!) way? It is possible to add new attributes to the documents in the existing index. For example, I could send the attribute "Test" with the content "Hello" to the Elastic and then see exactly this content under the item "Discover". First the data type is "Unknown field", later it changes to "String field". We have often done this for other fields. Can't I send a new attribute "geolocationNew" with the content "1.123, 5.678" to the Elastic? Isn't that the same? The type would then only have to be "geo\_point" and not "String field". ---
**Author:** ![jsanz](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jsanz/32/53734_2.png) [@jsanz](https://discuss.elastic.co/u/jsanz)\ **Post date:** [February 6, 2023, 2:37pm UTC](https://discuss.elastic.co/t/convert-string-field-to-geo-point-field-for-map-visualisation/324397/4 "2023-02-06T14:37:26Z")
> [@cf4455](#): > > Thanks for your quick answer, but isn't there an easy (!) way? First option using `update_by_query` seems quite straight forward to me. The second option involves learning more about Elasticsearch, but in my opinion gets you in a better position to manage your data. > [@cf4455](#): > > Can't I send a new attribute "geolocationNew" with the content "1.123, 5.678" to the Elastic? You can do that, yes, and then create a query that filters documents **without** that field (or just use the date or any other method) and use it on a [reindex call](https://www.elastic.co/guide/en/elasticsearch/reference/current/docs-reindex.html) to add it with an ingest pipeline to get **all** your data with that new geometry field. ---
**Author:** ![jsanz](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jsanz/32/53734_2.png) [@jsanz](https://discuss.elastic.co/u/jsanz)\ **Post date:** [February 6, 2023, 2:42pm UTC](https://discuss.elastic.co/t/convert-string-field-to-geo-point-field-for-map-visualisation/324397/5 "2023-02-06T14:42:59Z")
Additionally, you can just add your new field and if you ever need geospatial support for your old data you can just generate that field on the fly using a [Runtime Field](https://www.elastic.co/guide/en/elasticsearch/reference/current/runtime.html). Check this other interesting thread on this topic. > [@How to a emit a value for a runtime field of type geo\_point?](https://discuss.elastic.co/t/how-to-a-emit-a-value-for-a-runtime-field-of-type-geo-point/271889/4): > > Sorry. I wasn't involved with the docs for this one. Looks like it is lat, lon. [https://github.com/elastic/elasticsearch/blob/50152589cab00fbb984f9f40d68173addee5970f/server/src/main/java/org/elasticsearch/script/GeoPointFieldScript.java#L59](https://github.com/elastic/elasticsearch/blob/50152589cab00fbb984f9f40d68173addee5970f/server/src/main/java/org/elasticsearch/script/GeoPointFieldScript.java#L59) Runtime fields are always going to be **slower** that stored data, but they are useful for changing mappings and ad-hoc analysis. ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [March 6, 2023, 2:43pm UTC](https://discuss.elastic.co/t/convert-string-field-to-geo-point-field-for-map-visualisation/324397/6 "2023-03-06T14:43:36Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.