Map location


I want to set a starting location for a MapView. I can’t find in the documentation on how to do this. I understand I can set a marker, that the map will focus to, but then I can’t make this marker invisible.

Also is it possible to set a location from a search input? One way I can think of doing this is having a user input a latitude and longitude, which then will set a marker for the map to focus on, but this zooms into a very close area. Is there another way?


Hi Charlie,

Setting a default focus indeed is not possible at this time, we are tracking this internally and I will add your use-case to the issue. The same goes for marker visibility and default zoom levels.

Setting a location from search input could indeed be established through a lat, lon input, again, a default zoom level is currently not possible. I will add this case to the issue as well.

1 Like

Thanks for the reply, this is our current solution for a search function

    def search_location(self,params, address: str):
        resp = None
            # if address is not found, need to popUp a message and pass a default location.
            http = urllib3.PoolManager(1, headers={'user-agent': 'my-test-app'})
            url = '' + urllib.parse.quote(address) +'?format=json'
            resp = http.request('GET', url)
        except urllib3.exceptions.HTTPError as e:
            raise UserException(e.reason)
        result = json.loads(

        return [float(result[0]["lat"]), float(result[0]["lon"])]

The current solution uses a text field so to avoid having the app running every time you type a letter we use a high number on the duration_guess.
I was thinking what about having a silent field? In this case, the silent field will be the text, and having a button we will search from the location provided.
It could be useful having a silent field to pass data that shouldn’t trigger the application until is requested.
What do you think @dsommers?


I am not sure I understand your question @sonomirco, what about the current solution you are using is not sufficient? It sounds like a good way to go: using the duration_guess on a view to make sure it doesn’t slow down your app whenever input is updated. Is there something about this flow that is undesired?

Using duration_Guess required you to press update, meaning the view is not updated until than.
Having a silent field allows you to keep interact and still having a viewer visible.

I’m afraid I don’t really understand still. How is the TextField you are using now implemented? I think the snippet Charlie posted is only the function that generates the coordinates, perhaps you could share the code where that function is called, the TextField and/or the controller method that is relevant? I ask because I am having some trouble understandig what exactly the problem you are trying to solve is. The description you give of a SilentField sounds vaguely like the Storage we offer, but I am not sure if I understand your “need” fully.

The TextField is implemented as I described and using duration_guess allow you to search from a new address once you finished typing and press update, and this is fine.
I was just suggesting the idea of a silent field because duration_guess in any case will stop the viewer until you press update.

I’ll make an example using the search location.
Let’s say I type a new location, but after I typed I remember I need to look at something on the map, I can’t because I need to press update, instead if I got a silent field the value will be stored but won’t trigger any updates to the viewer and only when, for example using a button, the value is consumed and the view is updated. It is just a suggestion to improve the interaction with the application.

Hi Mirco,

I understand that it was just a suggestion, and I don’t want to waste your time or interrogate you about your suggestion. I am just not sure I fully understand the problem that leads to your suggestion, which is really helpful when thinking about features. What is actually currently not going right, what is the underlying problem. That is why I am curious to understand your issue a bit better.

In the example you give, you say:

Let’s say I type a new location, but after I typed I remember I need to look at something on the map, I can’t because I need to press update

This is where I get confused: the map does not disappear when you type in a new location right? What happens is: a button appears that let’s you choose to redraw the map. In the meantime, you can still look at the map, scroll it, etc.

As far as I understand your use case, that is desired behavior: the value is stored but does not trigger a rerun, only when clicking a specific button (“Results are not up-to-date with current input: Update”) that value is used and the view is updated. If it was relevant to use the search location on the map, you have to click the update button, but that would be the same for the SilentField, as per your suggestion you would have to click a button to use the information stored in the field.

I don’t want to nag or waste your time, so if it’s not relevant to continue this thread feel free to let me know!

Yep, you are right, sorry I didn’t get chances to re-test until now and I was talking by memory and I was completely wrong :slight_smile:
Really sorry! I was totally sure the app froze waiting to be updated.
Again sorry!


No worries and no need to apologise! Glad to hear it was a simple misunderstandig, and good to hear the current implementation does what you want it to do.

Sorry @rweigand to come back to this point again but I think this video is useful to understand.
Here are some points:

  1. A bit strange opening an app and being asked to update, but ok not a biggy
  2. duration_guess is perfect if I have to interact with only one field, but if in my case I have also to draw a polyline, I do not expect to update the application again.
  3. Yes the second text field is not necessary, but is there to give you an idea of the problem, and why I was talking about silent fields.

Do you have any suggestions to make the UX a little bit smoother?


No problem at all! Supernice that you included a video, it helps me understand your issues a lot better. The duration_guess is the best and (roughly) only option you have, and I will try to explain why. The answer for all three of your questions is roughly these points:

  • VIKTOR has no way of knowing in advance how long your view is, hence we ask you to indicate it. Anything “long” we do not draw whenever it is triggered, including when you first enter the editor. If your view was e.g. 30 seconds, it would still be annoying to enter an editor and immediately facing a 30 second wait. Imagine for example if you by accident enter the wrong editor…
  • We built the editor, and the platform in general, based on several paradigm. One of them is: input goes on the left, output goes on the right. Another one is: VIKTOR is stateless. That means that, we do not save intermediate results: whatever the user has provided on the left side of the screen, that is what is being used to calculate the results for the right side of the screen. Whenever anything in the input changes, we recalculate the entire output. A downside of that is what you are facing: when you update the textfield (which is not relevant for the view), the result is immediately marked as “out of date”. The (we think) huge benefit however is that whenever a result fails, you do not need to know anything about the state of the input. You do not have to ask a user: did you first fill value A and then click B? Or did you first click B, then filled A? All you need is the list of input values, and nothing else. We also explain this in our docs here
  • The GeoPolyLine seems like it breaks the rule of “input left, output right”, but it actually does not. The user draws on the map, but the result of his/her drawing is a list of coordinates that you can see (and modify) on the left side of the editor. These values are filled in automatically after the user has finished drawing, therefor triggering the view to be “out of date” because the input changed.

As to your question if I have suggestions for a smoother UX, I am afraid my answer is: not really, nothing major. You could obviously consider grouping the map and only inputs relevant for the map on a page. Perhaps if you combine them in a page you can set the duration_guess to be low again, meaning the view will be update whenever anything on the page (so, map-specific inputs that you put there) changes, but not when you update fields on other pages. Perhaps that helps?