You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Sometimes you want to search on coordinates instead of an address or a real estate name. You can open up the "View coordinates" dialog, but as you often get the coordinates as a single line, it is rather clumsy to split it up, and paste to the right textboxes. Also the position on the map seems to disappear if you leave that dialog. I.e. this is clumsy and time consuming.
I suggest that you enable pasting WGS 84 decimal into the search box. Where longitude and latitude are separated with a comma, like "59.3442,15.2273". This is supported in Eniro and Google Maps, and very convenient.
If you for some reason don't want the search box to have different behavior depending on text input, you could have a mode selector close to the search box, to switch between what kind of input that is expected. I prefer without the mode selector, WGS 84 decimal can't be mistaken for an address or a real estate name.
The alternative would be to have a checkbox/tab in the "View coordinates" dialog that allows you to enter longitude and latitude where they are separated with a comma instead of the separate boxes. Still, the vanishing position when exiting that dialog should be solved.
The text was updated successfully, but these errors were encountered:
Good suggestion, but this will require some different solution (or extension of) to the search model. Currently it searches using WFS sources and DocumentHandler texts. In this case, we would want to translate it to the Map View's x and y and center that position (on some specific zoom level). In addition a marker is needed (similarly to how Coordinates work).
One idea is to utilize the current Coordinates Model but allow for triggering it from the Search box as well as a hash state param.
One idea is to utilize the current Coordinates Model but allow for triggering it from the Search box as well as a hash state param.
Without knowing anything about the Hajk code, this sounds like the best idea. A small extra step when parsing the input of the search dialog, and call old code or the Coordinate Model depending on syntax. It could even throw up the coordinate dialog with the value filled in, so you can use the Zoom and other buttons found there.
Maybe I should file a separate bug report that the marker disappears when leaving the coordinates dialog. It should of course stay. And the Print dialog should have a checkbox if to include the marker or not.
Sometimes you want to search on coordinates instead of an address or a real estate name. You can open up the "View coordinates" dialog, but as you often get the coordinates as a single line, it is rather clumsy to split it up, and paste to the right textboxes. Also the position on the map seems to disappear if you leave that dialog. I.e. this is clumsy and time consuming.
I suggest that you enable pasting WGS 84 decimal into the search box. Where longitude and latitude are separated with a comma, like "59.3442,15.2273". This is supported in Eniro and Google Maps, and very convenient.
If you for some reason don't want the search box to have different behavior depending on text input, you could have a mode selector close to the search box, to switch between what kind of input that is expected. I prefer without the mode selector, WGS 84 decimal can't be mistaken for an address or a real estate name.
The alternative would be to have a checkbox/tab in the "View coordinates" dialog that allows you to enter longitude and latitude where they are separated with a comma instead of the separate boxes. Still, the vanishing position when exiting that dialog should be solved.
The text was updated successfully, but these errors were encountered: